ALT-1 Qualities you need to be a Good Software Tester
Want to become a truly great software tester? If so, you need to develop a "little kid" mentality! (No, I'm NOT suggesting that you sit in the corner and pout when you don't get your way.) It's my belief that truly great testers are able to focus their efforts around two questions all little children ask themselves whenever they're given a new toy: "How does it work?" and "How can I break it?"
How does it work?
This is the fundamental question all testers must be able to answer. It's developing a thorough understanding of the software under test, and how it responds to different inputs and circumstances. Note, the question isn't, "How is it SUPPOSED to work?" or "How did the development team INTEND for it to work?" It's an understanding of the software AS IT EXISTS: the good, the bad, and the ugly.
A tester must understand who will be using the software and what technical expertise the user should have to be able to use it. They need to understand how the software will function in "normal" circumstances, and what other REASONABLE conditions exist. They need to understand enough about the architecture to identify possible bottlenecks and potential points of failure. At any point during operation, they should be able to answer the question, "what will happen next?"
How does a tester gain this understanding of the software? While they should review any available documentation and talk with anyone familiar with it (e.g., developers, business analysts, customer service representatives) to get their insights, the tester MUST spend time working with the software and trying different operations. That's the only way to understand the difference between what it SHOULD do and what it DOES.
How do I break it?
Far too much emphasis is placed on making sure that software "works," and not enough on actually understanding its true condition. With tight deadlines and other pressures, it's easy to fall into the trap of running through a set of documented positive-path procedures and certifying a software product without actually taking the time to try to make it fail. That can be very, very costly in the long run.
I was once asked to certify a customized version of a product that had been deployed and used for several months by another customer. Since their new version contained only cosmetic changes to the user interface for the new customer, I was told I should be able to complete all testing within a day or two.
I had a good understanding of the system, and I also knew the pressure that had been placed on the original project, so I believed that the system might still contain some major bugs that had not yet been identified. I went to the lab and started the system with an alternative, yet legal start-up sequence, and watched as the system locked up and was made unusable.
Three minutes in the lab, one critical bug that stopped work on my project and required an emergency patch to be created and deployed to all of our existing customers. Not a bad effort! When word spread, one of the original testers came to ask how I had found such an important bug when they'd spent weeks testing the software without finding anything major at all.
The answer was simple. They'd spent their time trying to make sure that all the expected paths worked. I used my understanding of the architecture and the assumptions upon which the design was made to identify potential problem areas, and I focused my attention on those areas and found the flaws.
Conclusion
There are many things that good testers do. They create test plans and test procedures. They execute tests and log results. They learn and apply new tools and techniques to their efforts. These are all good things, but it's the development of the "little kid mentality" that will make your testing more productive and help you make a more powerful impact on your organization.
