Five Questions With Bliss

Bliss is an interesting guy, and not just because he has only one name! I encountered Bliss when I attended his turned-out-to-win-the-people's-choice-award talk at STAR East last year. Although currently Engineering Manager at Captaris, Bliss has also spent time spelunking Kentucky's caves for the Center for Cave and Karst Studies. He focuses the other direction too, working with Minor Planet Research, Inc. and the Lowell Observatory to look for and observe Big Chunks Of Rock which have a chance of running into our local Big Chunk Of Planet.

Like I said, Bliss is an interesting guy! Here's what he has to say:

DDJ: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?
Bliss: I started at a small software company that did not have a quality department. All testing was handled by technical support engineers between calls. As new code was being readied for release, the tech support department would begin testing it to validate its effectiveness. I began complaining about not having a structured test organization and feared that we were going to have a catastrophic failure at some point. The squeaky wheel gets the grease, as it were, so they charged me with putting together a Quality Assurance group.

It was clear from this that this organization did not initially take testing seriously, so I had to work hard to raise awareness of the value this group added to the software lifecycle. The importance of reporting and communication became evident and I found myself, as solitary tester and manager, spending a great deal of time putting together testing reports. It wasn’t just about the testing – it was about communicating what value the testing was giving back. I wasn’t simply finding bugs; I was reporting the areas where we could be more confident in the software and pointing out areas of higher risk.

DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
Bliss: That would have to be how misunderstood the testing process is by non-testers. All too often testing is perceived by non-testers as being the magic at the end of the cycle that magically puts the “quality” into the product. Many organizations leave all the quality planning for the end of the development cycle, pushing all responsibility onto the QA group. Of course, we all know that quality beings with the design, continues with the development, and is only checked by QA. Designs can be made with quality in mind and software can be coded with quality in mind, but, try as you might, you cannot test quality into the product.

DDJ: What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?
Bliss: Testers to know and do: Plan testing to find every single bug – spend every working moment improving the test planning, and don’t let any bugs get through. N.B.: Bugs happen. Bugs are pretty sneaky. Bugs get through your best efforts. There is no way around that – you are not going to find every one. It feels awful when something you think should’ve been caught, wasn’t. Don’t get bogged down in the “shoulda, woulda, coulda” thinking. It doesn’t help. When something gets through, focus on how it got through and change your plan for next time. Learn from it.

Developers to know and do: Write perfect code. You must test your code yourself, on clean systems (not development environments), before giving it to anyone else. Use manual testing, use unit testing, use whatever you want, just give it a few different run-throughs before you call it, “good”. Then don’t be surprised (or offended) when a tester reports problems. Bugs get through your best efforts. The tester is not trying to make a statement about your work; they are trying to help improve your customer’s experience. Be positive. Work together. Make better products as a team.

DDJ: Is there something which is typically emphasized as important regarding testing that you think can be ignored, is unimportant?
Bliss: Yes. Detailed, step-by-step test plans – they are about as useful as a record-and-playback automation script. It works the first time and has to be painstakingly modified with each release. The better approach is to have test plans that describe the purpose/goals of the test and the areas of the software to concentrate on. Let the experienced tester work out the details as they test. They are better at responding to the software’s behavior when they aren’t constrained by a step-by-step procedure (of course, when they find a defect, they will have to detail the steps to reproduce it in the defect report). Constraining their creativity will not help to find defects, and letting them enter unexpected data at unexpected times might surprise everyone.

DDJ: What do you see as the biggest challenge for testers/the test discipline for the next five years?
Bliss: To keep up with the agile trends in our industry. For too many years we’ve relied on volumes of step-by-step test scripts and documentation. It is easy to inundate the project stakeholders with meaningful-looking stacks of paper, showing our testing activities. Agile techniques move us away from the stacks of paper and force us to provide status and activity reports in other ways. Even defect trend reports might become less meaningful as the developers begin to use their own defect prevention techniques --with our assistance. QA organizations will find fewer defects in the code, but will continue to add defect-prevention value to the projects. Under those circumstances, finding a way to show the benefit of the QA organization to the stakeholders will be challenging.

Posted by The Braidy Tester at 07:30 AM  Permalink