One of the areas of testing that is often overlooked is how critical communication really is. Your job description as a tester, is not to only do the testing, but to somehow report on it. Something a developer never has to do.
A developer has to present an architecture design, to which the test plan is a simile. Although test plans rarely live that long nor look that grand. A developer has to demonstrate their working code, but the tester never gets a demo moment, all they get is Jira tickets. And let's face it, like any agile project, agreement on JBGE . Of course I'm talking about a project where developers also do a lot of the testing itself too, and for this reason a test plan needs to also prevent too much test coverage of risks we do not care about.
So now we know why at least on one level, that test plans matter, lets look at writing your plan, and communicating it. It's a dead document unless you use it to support your test report outcome anyway. Effort on plan document would fail you on JBGE criteria if it was not a concise and readable document.
Title and Author
This gets the metadata out of the way, having a sell-by date on any document, up-front is critical.
Introduction
I'm using a Template presented by Ministry Of Test, in one of their free modules here . Keep the intro really short, anyone reading this already knows that the project or feature is, stick to a one-liner like the "unique" goal of the test cycle undertaken.
Resource
Describe what kit you will need, and what amounts of time you will need. This is to help you decide what kit you already have, must rent or buy, and to size the work. Any kit you need to "book" needs actions taken earliest, along with time that belongs to other people.
In Scope
At this point, remember that you ideally want this to fit onto one page, sharpen that pencil now. You might just refer to the product requirements doc if there is a good one. Think not functionality, but think behavior or use other frames of reference that condense a description of the testing activity.
Out of Scope
This is pretty much a one-liner and a reminder to the tester of any functionality we are not looking at, but was added during the project anyway. Remember time is against you, stick to listing only new behaviour that is delivered, but which you are not going to test.
New functionality
Components that have changed or been added. Describe the changes in behavior a user will notice, but also the changes a user will make to how they do/can use the new product version.
UAT
Identify who will be responsible for UAT.
Infrastructure
This is the bit that probably describes to someone who want to run this test iteration again at a future point, or who wants to learn from the activity afterwards.
Risks and Assumptions
Describe what functionality or what behaviors you will do less deep testing in, and why. Describe mitigations for the reduced coverage. For example "We decided not to automate test the SMS message reception for new SIM holders, but instead we tested the emails the system sent and did boundary analyses and used trace logging automation scripts to verify that SMS does get sent out."
Here is a link to the template in docx. There are a host of other test plan formats, and I also like experimenting with for example using a Trello board and creating tickets for each part of a plan so you can mark them off, and also arrange them in a way that engages the audience. I prefer short and sweet, with some formality. The mind maps form of planning testing is useful, but I have found these are not always easy to explain to someone else afterwards. Mind maps are better in my experience in test analysis - but if your team is comfortable with a way of communicating using something like a mind map, it may be better to discard the proform.
If your field requires detailed test documentation, you can use this same format and go really deep. But we are not actually building a house that will stand for 50 years here, so a bill of materials is not needed in my case. Some product fields , or where you are doing external contracted testing will require a lot more detail, down to quoting which specifications you will comply with, regulations and will refer to actual quality criteria docs. Otherwise don't go into detail in the document, detailed lists of what kit you needed, what tools you have to find or to create will be overkill in most projects. Try to timebox the document effort into 10 minutes, for every 1 day you will spend doing this testing.
The test plan is a communication document after all, target it not at yourself, but at the stakeholders. It's your version of an architecture diagram with a difference, it shows someone else how you checked that all of the doors, windows and roof did not leak on your new house. Not what materials were used and why, that would be boring.
Comments
Post a Comment