Master Test Plans

By Mark Gunn

Prior to writing test cases for your project testing, you must create a master test plan that encompasses the complete range of testing tasks to be accomplished. To continue the construction analogy from my previous article (I just finished building a game room in our basement so forgive me) you can’t construct a building without a blue print and the same applies for testing a system.

The Master Test Plan is the blue print for how you will conduct your testing for the entire project life cycle. This is the vehicle that will communicate the testing scope and strategy to the rest of the project team. Development, project management, the test team and the user community will review the plan to ensure that all aspects of the application are being properly quality assured.

The information that encompasses the Master Test Plan must be detailed and well thought out. Putting together the plan requires many hours of reviewing the system design documents, project scope, business requirements, and the release schedule from development. Part of developing the test plan will be ascertaining the proper staffing needs for the testing the application, how those resources will be utilized and when.

The following are the major areas that all Master Test Plans must cover:

1. System Overview – a description of what the application is intended accomplish.


2. Purpose and Scope – the purpose for what QA will accomplish and the scope of the effort the QA team will be making.


3. Assumptions and Risk Assessment – what are the assumptions QA will be making on the nature of the project and what risks QA will be taking.


4. The Strategy – the overall approach QA will use for the testing. An explanation of testing methods to be used.


5. Data Preparation – what type of preparation will be required to prepare data for testing. This could require database refresh or data refresh scripts to be written.


6. The Build Matrix – each phase of the testing Unit, Functional, System Integration, Volume and Stress, Data Conversion (if necessary) and UAT will be outlined as to what will be tested in each phase and each build within each phase.


7. Work Plan – the Work Breakdown Structure (WBS) for what resources will be used and how they will be applied to each phase of the project. Also included will be milestone and target dates and any environmental requirements (PC’s, Networking, software, etc.) the team will have.


8. Testing Procedures – consists of version control, change control, and defect tracking procedures that will be used for all project participants.


9. Sample Forms – this will include a sample test case, sample defect tracking document and any other relative documents QA will be using for the project.

Once your test plan is approved, NOW you can start to write test cases. It is still not time to start testing yet, more on this in the next issue.

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at mark@mgdservices.com