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