Jason Barile – Testing Testing

I’ve been reviewing a lot of test plans recently. As I review them, I’ve compiled this list of things I look for in a well written test plan document. Here’s a brain dump of things I check for, in no particular order, of course, and it is by no means a complete list.

That said, if you see a major omission, please chime in to let me know what you expect from or include in your test plans. These requirements may or may not work for you based on your development methodology, but it’s what I look for. I’m sure I’ll think of several more points as soon as I publish this post!

Test Strategy

I always like to see the testing strategy called out early in the test plan. In general, it’s always best to vet your testing strategy with your team as early as possible in the product/feature cycle. This helps set the stage for future test planning discussions and most importantly, it gives your teammates an opportunity to call out any flaws in the strategy before you’ve done a bunch of tactical work such as creating individual test cases and developing test automation. Some key points I look for in this section are:

  • An Understanding of the Feature Architecture – For the bits you are testing through “glass box” approaches, reflecting a simple understanding of the feature architecture in the test strategy section is very helpful. I don’t expect to see a full copy of the feature architecture spec—just the “interesting” points called out and how the tester is using that knowledge to create an efficient testing strategy. For example, if the UI build is using MVC, a lot of testing can be done “under the hood” against the controller rather than driving all the tests via automation through the UI.
  • Customer-Focused Testing Plan – Are you going to do any “real world” testing on your feature? Some examples include “dog-fooding” (either using the product yourself or deploying frequent drops to real customers to get feedback), testing with “real” data, install/uninstall testing on “dirty” machines (as opposed to cleanly installed VMs, for example).
  • Test Case Generation Methodology – List the approach you’re taking to generating test cases. Are you using the typical “sit around a table and brainstorm” approach? Model based testing? Pairwising? Automatic unit test stubbing tools?
  • Identification of Who Will Test What – For example, developers will write and run unit tests before check-ins, testers will focus on system level, integration, and end-user scenarios, etc. This serves multiple purposes: reducing redundancy, driving accountability for quality across the feature area.

Testing Risks and Mitigation Plans

What known risks are you aware of? Some examples might be building on top of a new platform/frame-work that hasn’t been fully tested yet, tight schedules, or relying on components delivered from external sources or other teams. Once you’ve called out the major risks, list what you are doing to mitigate the chances each one could impact your project? For example, do you have escalation paths identified in case you find bugs in those external components?

Testing Schedule

Ideally, this would be merged into a common team schedule so you can see dates from each discipline alongside each other. Dates/testing events listed should include dependencies (e.g. Test Plan Initial Draft Complete” probably depends on “Feature Architecture Spec Complete” and “End User Scenario Spec Complete” dates being hit). Sharepoint is a great place to keep a team calendar for feature development, and the test plan can simply contain a link to the current schedule.

Test Case Details

Each test case listed should be written in such a way that someone who is only loosely familiar with the feature (and armed with the feature specifications) can execute the test cases. This is helpful for several reasons: churn among testers on the project, it facilitates hand-offs to test vendors or servicing teams (if you’re lucky enough to have one), and most importantly, clarifying what is and isn’t being tested by reducing ambiguity in the test plan.

  • A clear description of the test case and steps
  • A description of expected output/behavior
  • Things to verify to prove the test case worked (or not, in regards to negative testing)
  • “Clean up” steps, in a situation where the test changed something that might invalidate the entry point for other test cases
  • Mapping back to an end-user scenario (this can be accomplished by grouping your tests by scenario, for example)
  • Priority of the test case (from the end-user’s perspective usually, though there are an infinite number of ways to prioritize)

And last but not least…

Make sure you use the right cover sheet! Seriously, if your team has a test plan template, by all means start with that! Chances are it’s much more than a “TPS report.” Templates give you a framework to help you think through your test planning process. You probably don’t need to include each and every section in your final plan—just include the sections that are relevant to the feature/product you are testing.

There you go. I hope this helps you think through your own test planning process. 

 

Jason Barile
Jason Barile is the principal test manager for Visual Studio Team Foundation Server at Microsoft. He moved from Redmond to North Carolina in 2003 when Microsoft started the TFS project. Prior to TFS, he was a tester and test lead on the Windows User Experience team. Visit his blog at Testing Testing.
Jason Barile
Jason Barile is the principal test manager for Visual Studio Team Foundation Server at Microsoft. He moved from Redmond to North Carolina in 2003 when Microsoft started the TFS project. Prior to TFS, he was a tester and test lead on the Windows User Experience team. Visit his blog at Testing Testing .

The Related Post

Experience-based recommendations to test the brains that drive the devices In essentially every embedded system there is some sort of product testing. Typically there is a list of product-level requirements (what the product does), and a set of tests designed to make sure the product works correctly. For many products there is also a set ...
LogiGear Magazine March Testing Essentials Issue 2017
“Combinatorial testing can detect hard-to-find software faults more efficiently than manual test case selection methods.” Developers of large data-intensive software often notice an interesting—though not surprising—phenomenon: When usage of an application jumps dramatically, components that have operated for months without trouble suddenly develop previously undetected errors. For example, newly added customers may have account records ...
LogiGear Magazine March Issue 2018: Under Construction: Test Methods & Strategy
Introduction Many companies have come to realize that software testing is much more than a task that happens at the end of a software development cycle. They have come to understand that software testing is a strategic imperative and a discipline that can have a substantial impact on the success of an organization that develops ...
At VISTACON 2011, Jane sat down with LogiGear Sr. VP, Michael Hackett, to discuss complex systems.
Has this ever happened to you: You’ve been testing for a while, perhaps building off of a branch, only to find out that, after all of this time, there is something big wrong. It’s a bad build and now you have to go backwards, fix something, and get a new build. Basically, you just wasted ...
Test design is the single biggest contributor to success in software testing. Not only can good test design result in good coverage, it is also a major contributor to efficiency. The principle of test design should be “lean and mean.” The tests should be of a manageable size and at the same time complete and ...
Regardless of the method you choose, simply spending some time thinking about good test design before writing the first test case will have a very high payback down the line, both in the quality and the efficiency of the tests. Test design is the single biggest contributor to success in software testing and its also ...
Reducing the pester of duplications in bug reporting. Both software Developers and Testers need to be able to clearly identify any ‘Bug’, via the ‘Title’ used for the ‘Bug Report’.
From cross-device testing, to regression testing, to load testing, to data-driven testing, check out the types of testing that are suitable for Test Automation. Scene: Interior QA Department. Engineering is preparing for a final product launch with a deadline that is 12 weeks away. In 6 weeks, there will be a 1 week quality gate, ...
LogiGear Magazine – July 2011 – The Test Methods & Strategies Issue

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe