MSD Detection Test Plan Matrix
MSD Detection Test Plan Matrix
When first assigned a feature to develop test cases for, I like to 'stake out the perimeter' before putting anything to ink. I created an XLS workbook for getting all ideas into one place and getting organized and as data comes in, it gets piped to the document. Half the battle in QA is knowing what questions to ask and 'knowing what you don't know'. If your first act is to start writing test cases - you'll be wasting time updating them in the near future. Being the product of an investigation, test cases should come last and ideally should be well written up front.
The RAIL - Rolling Action Items List
Get your ideas down fast - they'll likely fade away just as quickly. The RAIL is a simple tool to keep you focus on what needs to get down, how HOT it is and if it's done. When you step away to work on something else - or come back from the weekend - you'll be able to hit the ground running and be able to give some sort of status of where the effort it at.
This was a little hard to integrate into the same page, so I just grouped a bunch of colums that were used in the other sections and then started the variable lists on the end.
Determine and map out variables into the test matrix. In this exercise my variables were:
Whether or not the system image had the new 4K HDD drivers
Options available in the image processing application
The product of these 3 areas produced 108 options!
Start enumerating a coverage matrix that has all the variables mapped out. Here, you can see I have
Image Validation Service
Yes, the image has the 4K drivers already installed
BLANK for the 4K option in the application.
I eventually pushed the 'Image Type' variables 'Service Type' into the 'Variable Matrix' for a total of 5 variables ( each with differing number of possible values). We can see that if we get the input/output/throughput components to the test, creating the test cases will be MUCH easier as we'll have everything we need to know before test case creation. I've also found that creating test case titles and organizing them is no longer a nightmare if I do the preparation up front. Here, Organizing by OS, then Service Type, then Image Type left the interpolation of only the 'Image Has Drivers' and 'Option Selection' variables amongst each test group. Test Suite organization falls naturally out of this process.
Gether input requirements so you know what is needed to perform the tests. We didn't have system HDD images for many OS and driver combinations - this would be critical to report on as these are testing blocks that a PM needs to make a call on. In our case, the risk was minimal as several OS's didn't need the driver update and others were no longer valid inputs for PET.
Here, I enumerate Test Variables, Expected Result, and auxilliary things to check. these will be inputs to the test cases as well. Where as the Coverage Matrix attempts to identify EVERY POSSIBLE TEST CASE, this logic matrix informs us of how each test should perform.
Questions come up all the time. Get them in the spreadsheet with everything else.