Yes, they are related.
There isn’t a job out there that doesn’t have a pain point. Writing test cases very well may be the pain point for a tester, but it’s a necessary one. Also the quality of a written test case can very well gauge the level of competence a tester has. I don’t know how many times I’ve seen a test case with 1 step that isn’t a login test. I’ve even written a few being that they were at the end of my task list and I really didn’t want to write out those 4 or 5 other ‘assumed’ steps. However too many steps and the test case will be a maintenance headache for each release.
I’ve talked about my side of the testing vs. checking argument, but there is a happy middle ground. The fact that when you find a bug you should develop a test (check) case against it so that it doesn’t rear it’s ugly head in production again is a necessary step to take. However the benefits of documenting the case can very easily bring a tester to the career defining question of “What happens when…”.
Exploratory testing is purely directed by the limits of the tester’s imagination, patience, and resolve. “What happens when…” is the starting point and typically this is where the most elusive of bugs are found. The reason that there is no piece of complex software out there that contains no bugs is because there hasn’t been enough “What happens when..” questions asked. The end-users end up asking the question, unintentionally, and come up with bugs, but because they are the end user the effect isn’t job security it’s insecurity about the software they are using (depending on the level of bug they encountered).
A tester can get more exploratory testing done if he has a tool to use that can track his movements without a lot of interjection and concentration stoppage. Two products come to mind: Evernote and LivenoteOneNote. These two applications weren’t designed to be used by testers, but their nature is exactly what testers fight with themselves over all the time; duplication. How can you duplicate a bug if you aren’t sure of the exact steps you took to get there.
Most bugs found can be duplicated under a number of different environmental circumstances. However the ones that usually cause the most post-release problems are the ones that are duplicated under specific environments (ie browser version, navigation choices, and application settings).
Which brings me back to unwritten test cases. How do you plan for those incidentals that cause problems? What do you do to cause the least amount of pain for your user base? Do you test for new users or for seasoned users (and is there really a difference)?
See Also:
