|
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/
|