Well, that depends on what your clients need. How do you know what your clients need? I can think of two ways:
- Ask them. Be careful. Per my experience, clients inflate their test documentation needs when asked. Maybe they’re afraid they’ll insult the tester if they don’t ask for lots of test documentation. Maybe they’re intent to review test cases is stronger than their follow-through.
- Observe them. Do they ever ask for test case reviews? If you are transparent with your test documentation, do your clients ever give you feedback? Mine don’t (unless I initiate it).
Here is what I ask of my testers:
Document enough detail such that you can explain the testing you did, in-person, up to a year later.
Before I came up with the above, I started with this: The tester should be present to explain their testing. Otherwise, we risk incorrect information.
If the tester will be present, why would we sacrifice test time to write details that can easily be explained by the tester? In my case, the documentation serves to remind the tester. When we review it with programmers, BA’s, users, other testers, auditors, or if I review it myself, the tester should always be present to interpret.
What if the tester leaves?
I’ll talk about that in the next post.
RSS
Hi Eric,
I read your blog for some weeks and in my opinion, your posts are realy useful. Thank you.
This article suit to a Test Case Design training that I had this week and I am very curious about Part 2.
I hope you will answer the following questions:
What happens, when the Test Designer is not present and somebody else want to execute the test case(s)? Maybe somebody new with no experience in the application to test.
What is nobody of the the time, the test case was created, is still in the company, because the project was paused for months and will continued with new staff?
Best regards,
Twaldigas
1. Do clients really review the test cases? I have never seen developers had opened the test cases neither.
2.What is meant by "Testers should be present?" - Is it mean, Testers should be available all the time, to explain the test documentation?
3. Documenting tests means - Test Reports / Test Cases ?
4. I see many testers hate to write the test cases / scenarios / step by step - bug descriptions.
Because, no one will read them (Neither BA/Programmer)- see its a waste of time.
Hi Srinivas, good questions. Here are my answers.
2. Yes. Testers should make themselves available to explain their tests, IMO.
3. ...Test Fragments, Test Ideas, yes.
4. That may be because most testers are writing too much. I wonder if testers doing what I suggest will still hate it.
Twaldigas, yes! I will answer that in Part 2.
Thanks Eric,
1. Do clients really review the test cases? I have never seen developers had opened the test cases neither.
What about this ?
Your post is very helpful for tester. I also would like to know if test designer in not available and anybody want to execute this test case(s), than what can happen?
Aswhani, thanks for the question.
A couple answers come to mind:
1.) If we know Tester_A (the test designer) will be unavailable, and Tester_B will need to execute Tester_A's test, than Tester_A should transfer sufficient knowledge to Tester_B before they are unavailable.
2.) If we didn't know Tester_A (the test designer) would be unavailable, and Tester_B needs to execute Tester_A's test, than Tester_B should gain sufficient knowledge through other means. Studying the test idea artifact left by Tester_A may help but there is little value attempting to execute a test that is not fully understood. It is better for Tester_B to design their own test.
What do you think?