Do you write test cases to kill time?
Submitted by Ainars Galvans on Mon, 08/12/2008 - 10:52.
exploratory testing
I wouldn’t believe myself until saw this really happening. Testers keep writing detailed test cases up-front with the primary goal to justify the time they spend early on the project. And right they are (are they?). At least they believe so. Managers see evidence that testers have red and understood all the requirements, covered them by test cases. Testers don’t have to think how to prove time spent on reviewing requirements even if they don’t find any issues there. And if developers delay a milestone we have more time to polish the test cases, do one more review or them, write more details, etc. Test lead doesn’t have to worry that on the next project testers will be added much later on the project schedule. Everything is fine but quality.
Be careful of what you want - You can as well get it
I don’t remember when and where I first hear this but it looooong time ago. So the problem is that as we add testers early on the project we need to task them with something, especially when development delays (and it does all the time, doesn’t it?). Writing up-front test documentation is a great way to keep them busy.
Do you believe this will help then test faster once there is something to test? Probably you are right - they won't need to spend their time thinking what and how to test. But, be careful of what you want! If you want testers not to think, you could as well get it!
I want more serious bugs found faster
Yes this is what I want that I’m not afraid to get. I want more serious bugs found. And I want them found faster. Because the real reason for adding testers early as far as I know is the rule “the earlier you find a defect the cheaper it is to fix”. No I don’t mean the 1:10:100:1000 rule talking about difference between finding bugs in requirements, construction, testing or production. I could as well come up with 1000:100:10:1 rule saying that it is much harder to find a defect in requirements compared to how simply it is for end-user to state that what program does is not the expected. I mean the testing phase.
Even in testing phase I want serious bugs to be found early. And by serious bug I mean what developers mean by it – one that is hard and risky to fix. It will allow them to make right decisions weather to fix the risky or effort-full defect and do it early so that we don’t find all the regression/impact defects at the very end of the project.
Alternative resource spending
Well, I know a few alternatives, but I have only seldom success clarifying that it is better alternative to managers. And sometimes even to testers.
- Training and improving skills. I do particularly suggest (beside my blog) everything written by Cem Kaner or James Bach
- Learning about the technologies and 3rd party software that is going to be used. Search internet for what are the typical problems applying the technology in solutions. What are the known bugs of 3rd party software?
- Learning domain and competitive software solutions
- Trying to find better ways to test: applying advanced techniques at requirements analysis. For example I like myself to draw business-object models and try to visualize their life-cycle and possible changes in diagrams
- Trying to come up with better test reporting approach – specifically suited for this project context
- Investigate what tools may help you with testing later. SQL viewing/editing tools, log-file parsing. Test Data generation (database population)
Endnote
I write this because I has experienced situation like this in two projects at a time. I try to solve it different in each case, as cases are different. I’m not sure about my success. But I hope I will have interesting stories to share.
Be careful of what you want - You can as well get it
I don’t remember when and where I first hear this but it looooong time ago. So the problem is that as we add testers early on the project we need to task them with something, especially when development delays (and it does all the time, doesn’t it?). Writing up-front test documentation is a great way to keep them busy.
Do you believe this will help then test faster once there is something to test? Probably you are right - they won't need to spend their time thinking what and how to test. But, be careful of what you want! If you want testers not to think, you could as well get it!
I want more serious bugs found faster
Yes this is what I want that I’m not afraid to get. I want more serious bugs found. And I want them found faster. Because the real reason for adding testers early as far as I know is the rule “the earlier you find a defect the cheaper it is to fix”. No I don’t mean the 1:10:100:1000 rule talking about difference between finding bugs in requirements, construction, testing or production. I could as well come up with 1000:100:10:1 rule saying that it is much harder to find a defect in requirements compared to how simply it is for end-user to state that what program does is not the expected. I mean the testing phase.
Even in testing phase I want serious bugs to be found early. And by serious bug I mean what developers mean by it – one that is hard and risky to fix. It will allow them to make right decisions weather to fix the risky or effort-full defect and do it early so that we don’t find all the regression/impact defects at the very end of the project.
Alternative resource spending
Well, I know a few alternatives, but I have only seldom success clarifying that it is better alternative to managers. And sometimes even to testers.
- Training and improving skills. I do particularly suggest (beside my blog) everything written by Cem Kaner or James Bach
- Learning about the technologies and 3rd party software that is going to be used. Search internet for what are the typical problems applying the technology in solutions. What are the known bugs of 3rd party software?
- Learning domain and competitive software solutions
- Trying to find better ways to test: applying advanced techniques at requirements analysis. For example I like myself to draw business-object models and try to visualize their life-cycle and possible changes in diagrams
- Trying to come up with better test reporting approach – specifically suited for this project context
- Investigate what tools may help you with testing later. SQL viewing/editing tools, log-file parsing. Test Data generation (database population)
Endnote
I write this because I has experienced situation like this in two projects at a time. I try to solve it different in each case, as cases are different. I’m not sure about my success. But I hope I will have interesting stories to share.