Discussion around the content of a test proposal Martin Jansson
This is a follow-up on a previous post about Rapid Test Preparation. Some of the commenter’s asked for an example; I’ve tried to go half-way at least. Added some new sections based on some good feedback from Henrik Emilsson.
Test Proposal – <area>
See the test proposal as a work in progress document to enhance communication and sharing of your ideas. I’ve used test proposals for both small and large areas. You stop using it when you start testing, transferring the content of the test proposal into something else. At this stage you have probably prepared yourself as much as you could and will hone our details other kind of documentation. If you go back and look at the test proposal it is probably for reference or what thoughts guided you.
1. Test Mission
Create a list of like 1-5 rows of information objectives. A test mission that guides you on what is extra important and that would meet the stakeholder’s quality goals.
2. Related information
When you start looking for information, what is important to you and perhaps your team? What else should be added that you think would add value?
2.1 Background
Is there any background information that needs to be brought up for everyone to get a better understanding?
2.2 Documentation
When you dig deeper into what a feature really is you will stumble and browse through a lots of documentation. Add those that you think give value to yourself and other readers of this test proposal.
2.3 Contact persons
Consider which people that would care about this and if they care as much that they want to be included in the loop.
* Business analysts
* Documentation responsible
* Developers
* etc
3. Requirements
Are there any requirements that guide you? You can list those here and perhaps discuss around them.
4. Test Model
Are you able to create a model on how you perceive the area or feature? Is it easier to talk around the subject based on this? Did you perhaps misinterpret something which has now been cleared up?
5. Test ideas
Use different heuristics to guide and categorize your ideas for testing. Some of the ideas might become charters others might be as base material for a set of test cases or test scenarios. A test idea, as I see it, is the essence of a test in the minimal amount of words bringing out the most important aspects of it. It can be good to add a note on who came up with the test idea, in case it need clarification. For further reading on test ideas, see Rikards papers and earlier blog posts.
6. Risks, Open Issues and questions
When you start working on the feature you will find issues that are not covered or questions that are not answered. Since you hopefully use this as a document for collaboration and communication it becomes clear what issues that are open and what has been answered.
7. Coverage
Is there any coverage related information that you need to communicate? Is there any hardware coverage or anything related that need to be discussed? Is there anything that you intend not to cover? These discussions help to increase or decrease your estimates. I’ve sometimes experienced complete misunderstanding about the scope of coverage, where I had included too much thus thinking that I needed to test a lot more.
8. Work Packages
In order to give a rough estimate I usually try to include what we intend to spend time on, including things not directly related to the actual testing. I use http://thetesteye.com/blog/2010/05/utopic-estimations-in-testing/ to guide my work packages and estimates. Test estimation is hard and usually inaccurate, but by listing things you think you might need to do can at least put you on the map (hopefully).
Martin, thanks for sharing this, It looks like a very focused lean document.
We’ll be giving this a try with the next project that comes in to our team, I appreciate you providing an example, being one of the people that had requested it.
I’ve got a slight twist to it in mind, I’ll be sure to share it with you when we try it out.
Hi Martin,
I’m not sure I understand what is this “test preparation”. Isn’t it the same as a “test plan”?
Thanks,
Sebi
Hi Eusebiu
A test plan is usually heavier and not as easy to communiate with “all” stakeholders that are involved for all features. Having test proposals might enable a more light weight test plan.
The focus of a test proposal is ease of communication, test ideas and getting the details down as you start thinking about it.
If you do not see the point of test proposals, I guess you work in a way that does not need them. Or perhaps that you might need to change how you work.
BR,
Martin
The most imortant difference between a test proposal and a Test Plan could be the name.
Test proposal invites to discussions, indicates you don’t spend too much time on it, and doesn’t decide what to do, it rather gives input.
To distance it further from a template, you could add “use sections you find appropriate” to the explanation text, and remove the numbering.
The content could also include interesting tools, and ideas around test strategy/methods.?
I agree that the name is inviting, but there are more differences that need to be emphasized.
Most test plans does not have the focus to be easy to communicate. You do not want to go into too much detail for each feature in the test plan since it will swell and because of that be hard to review and talk about.
With a test proposal you might have a lesser group of stakeholders that are interested in being involved and giving feedback.
The test plan serves other purposes than a slim test proposal.
Another thing is that you usually create a test plan early in the project. In some cases you update the test plan continuously, but I do not think you get others to review and discuss it frequently.
A test proposal will appear whenever a new feature/area is identified as something we need to take a look at. This might be in the last iteration.
When asking others to review a document it is harder to review the heavy test plan if it is updated continuously, where you tell the reviewers which section is updated. With a test proposal you know that it is have a short life span, that as you start testing it will not be updated anymore. So having one review before testing get started will have a better effect.
As you are testing you can use your test sessions to communicate how your test design is and how your use the ideas genereated from the test proposals.
Test proposal is planning but it is not “The Test Plan”. Instead of the ever so common test plan that ends up in a drawer, this planning document has a purpose and it works well during the time it is used.
Hi Martin,
I like your post and the way you have explained what should go in a test proposal.
This surely makes it a candidate on my blog which has the best articles and posts across the web.
Do mail me and let me know if it is fine i add this to my blog.
My blog: http://go-gaga-over-testing.blogspot.com/
Hi Aditya
I looked at your blog. Why do you only copy other peoples articles? You are free to write about what I have written and post a link, but copying the whole article to you seems like a waste of space.
If you want to learn as you state in the idea behind your blog, I guess you need to reflect on what me and others have written and make it your own.
So, please do not copy this article to your blog unless you add value to it by joining in on the discussion or finding things to enhance.
BR,
Martin
@ Martin
Thnx for your feedback, as you mentioned the idea was to have the best of testing articles , i also have posts that i have written on my own, anyways thnx for your time.
Respect your views on the same, shall definitely follow your blog and share my thoughts soon.
Best Regards,
Aditya