The reality is that no human-engineered system can be perfect. And, despite defensive development techniques, there is one glaring truth: as we aspire to build more intelligent systems, it is inevitable that bugs will be unintentionally introduced.
As a senior Quality Assurance (QA) professional, this fact forms the basis of my work, and, in an odd way, I owe my career’s existence to the looming threat of Sod’s Law – if something can go wrong, it will.
Playing The Fool
Douglas Adams once said in “Mostly Harmless” that a common mistake people make when designing something foolproof is to underestimate the ingenuity of complete fools. Adams’ twenty-year-old quote is often repeated online today because there is a spark of truth to it.
At Frogslayer, we never use the term “foolproof.” For starters, we value and respect our clients and the users of their software systems and don’t consider them fools. Our clients are intelligent and work hard to solve their business challenges. But we also know that software is not infallible and, more often than not, users will use applications in entirely new ways that were never part of the original design. That is why we at Frogslayer aim to develop software for them that can handle any scenario and not just the expected use cases.
When testing, my focus is not solely on how the user will use the application. I am also considering how the end user might do unexpected things or behaviors. Our clients are innovative, and I make a conscious effort to remember that fact when testing their product. Furthermore, they often work side-by-side with other users, who may, for example, be accessing the same customer account simultaneously, leading to concurrency and/or data deadlock issues. As one of the first people to use the application, QA is in a position to prevent innocent users from encountering avoidable problems or situational edge-cases that the original design may not have anticipated. Ultimately, the end user will likely never reflect on how brilliantly we overcame a race condition, which is reasonable. They are only interested in an app that works.
Speaking The Same Language
Having studied a few languages other than English, I have learned that making mistakes is an integral part of learning a new language. I have had to accept that when starting a conversation in a foreign language, people may laugh at me, even as I try my best to connect with them. I know that I will appear “foolish,” however, I also know that they will instinctively correct me as they would a child because most of my mistakes will be logical, albeit misguided. I have learned how many mistakes I make — and then carefully correct — directly relate to how fluent I can eventually become in the language. True learning requires the willingness to make mistakes and equal determination not to repeat them.
That same correlation applies to testing software. Every bug fix incrementally improves how smoothly a product works. The more issues developers, testers, and end users can identify and solve, the better the software will become for its intended purpose. In short, the intersection between theoretical design and practical application is where we can ‘speak the same language’ as the client.
Before beginning exploratory testing, it is essential set aside ego and have the courage to ask any questions – even the foolish or basic ones – because it requires creativity and knowledge of the software system. In addition to setting aside ego, it’s important to not let yourself become distracted by concerns that you might miss a bug the client will find later. Testing isn’t about your image or fears. It is only about ensuring that the application works well. Prioritizing functionality and quality of the application allows you to provide valuable feedback to the development team, who then can use this feedback to improve the systems and ensure it meets the needs of its users.
Ultimately, testing is critical to our clients’ businesses, and as testers, we serve as their advocates. And that mission has always been worth looking ‘foolish’ for.
-
Allen Holman
