Software QA FYI - SQAFYI

Turning a List of Options into a Test Plan

By: Mitch Allen

When testing a new feature, the first thing I do is look at the options a user has for that feature. Then I turn that into a list of test descriptions. For example, let's say you have to test a tree control. For a test, what base states could a tree control have? Well, for starters it could have Zero items, One item or Many items. So I make that my first list of options:

List 1: { 1.Zero, 2.One, 3.Many }

Then I create a template for the first part of my test description:

"For a tree control with { List 1 } item(s) ..."

Now what sort of tests could I do? Well I could insert a Sibling or a Child node. So that would be my next list:

List 2: { 1.Sibling, 2.Child }

Then I could expand my test description template:

"For a tree control with { List 1 } item(s)"
", insert a { List 2 } node."

I could then use that to define a set of tests by walking through the lists and creating a test for each possible combination:

Tree.Insert.1.1 [ 1.Zero, 1.Sibling ]
Tree.Insert.1.2 [ 1.Zero, 2.Child ]
Tree.Insert.2.1 [ 2.One, 1.Sibling ]
Tree.Insert.2.2 [ 2.One, 2.Child ]

Tree.Insert.3.1 [ 3.Many, 1.Sibling ]
Tree.Insert.3.2 [ 3.Many, 2.Child ]

Then for the purpose of documentation, I can use the template to write a test description for each test:

Tree.Insert.1.1 [ 1.Zero, 1.Sibling ]
"For a tree control with Zero item(s), insert a Sibling node."

Tree.Insert.1.2 [ 1.Zero, 2.Child ]
"For a tree control with Zero item(s), insert a Child node."

Tree.Insert.2.1 [ 2.One, 1.Sibling ]
"For a tree control with One item(s), insert a Sibling node."

Tree.Insert.2.2 [ 2.One, 2.Child ]
"For a tree control with One item(s), insert a Child node."

Tree.Insert.3.1 [ 3.Many, 1.Sibling ]
"For a tree control with Many item(s), insert a Sibling node."

Tree.Insert.3.2 [ 3.Many, 2.Child ]
"For a tree control with Many item(s), insert a Child node."

In the case of Zero items or One item, you have no choice as to where you are inserting the node. In fact, depending on the control, trying to insert a child node with Zero items may throw an error (which is a perfectly valid test case and you would note that in your expected results). But in the case of Many items, you have multiple choices. You would want to test how insert works for the First item, the Last item and a Middle item. So you need a third list of options:

List 3: { 1.First, 2.Last, 3.Middle }

and an addendum to your test description template:

"For a tree control with { List 1 } item(s)"
", insert a { List 2 } node"

", with focus on the { List 3 } item." // Only applies if List 1 = "Many"

For the tests where the first parameter is either Zero or One, you would just mark the List 3 parameter as "n/a", use a zero (0) to reference it in your test ID, and just not include the sentence fragment for List 3:

Tree.Insert.1.1.0 [ 1.Zero, 1.Sibling, n/a ]
"For a tree control with Zero item(s), insert a Sibling node."

Tree.Insert.1.2.0 [ 1.Zero, 2.Child, n/a ]
"For a tree control with Zero item(s), insert a Child node."

Tree.Insert.2.1.0 [ 2.One, 1.Sibling, n/a ]
"For a tree control with One item(s), insert a Sibling node."

Tree.Insert.2.2.0 [ 2.One, 2.Child, n/a ]
"For a tree control with One item(s), insert a Child node."

For tests, where the first option equals "Many" you would need to expand the test description, including the sentence fragment for List 3 and add more tests to cover all three options in List 3:

Tree.Insert.3.1.1 [ 3.Many, 1.Sibling, 1.First ]
"For a tree control with Many item(s), insert a Sibling node, with focus on the First item."


Tree.Insert.3.1.2 [ 3.Many, 1.Sibling, 2.Last ]
"For a tree control with Many item(s), insert a Sibling node, with focus on the Last item."

Tree.Insert.3.1.3 [ 3.Many, 1.Sibling, 3.Middle ]
"For a tree control with Many item(s), insert a Sibling node, with focus on the Middle item."

Tree.Insert.3.2.1 [ 3.Many, 2.Child, 1.First ]
"For a tree control with Many item(s), insert a Child node, with focus on the First item."


Tree.Insert.3.2.2 [ 3.Many, 2.Child, 2.Last ]
"For a tree control with Many item(s), insert a Child node, with focus on the Last item."

Tree.Insert.3.2.3 [ 3.Many, 2.Child, 3.Middle ]
"For a tree control with Many item(s), insert a Child node, with focus on the Middle item."

I've used this technique to develop several test plans. To make my life easier, I usually develop such test plans in Microsoft Excel. When testing a user interface component, I either use cell-based text or Excel's crude drawing tools to give a visual indication of the base state, the test and the result.

For example:

Tree.Insert.3.2.1 [ 3.Many, 2.Child, 1.First ]
"For a tree control with Many item(s), insert a Child node, with focus on the First item."

Alpha (focus)
Beta
Gamma
==> Insert Child ==>Alpha
- Child
Beta
Gamma

When I include a visual reference in the plan, developers love it. They say it helps them "see" the tests and they get really excited about it. I find it also makes it easier for me to develop the tests if I have a picture in front of me.

This technique is great, but don't get carried away. I just created a plan that uses six (6) lists of options and that's about as far as you should take it. If you find you have more then six options, either rethink the options or break one test plan into multiple test plans. Plan 1 could cover all tests for Option X and Plan 2 could cover all tests for Option Y. For example, I don't have an option list for inserting or deleting a node. The whole test plan in this articles example covers insertion. For deleting, I would create another plan. Trying to throw it all into one plan would be too much.


Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/

Turning a List of Options into a Test Plan