Let’s get straight to the point…
Software testers and QA analysts should not be finding bugs in software. As a software tester, your job should revolve around preventing bugs from ever finding their way into a software product in the first place; but in the current corporate landscape where developers and testers are segregated, that may seem like an impossibility. I want to talk about how we can bring more awareness to this problem and open our eyes to a whole new kind of testing, one that happens before any software is written. If we successfully apply this new kind of testing, then we may dramatically reduce the cost of bugs while at the same time improving job satisfaction for software testers and QA analysts.
The Agile Testing Mindset
Radical change in behavior requires a radical change in thinking, so we will start by looking at how differently we must think about testing in order to truly improve it. First, the quality of a software product should not be the sole responsibility of testers. I too commonly see organizations that place all the burden of software quality on the testing team, instead of the development team writing the product code. This burden should be shared equally among all individuals that are working on a product, from project managers and business analysts to developers and testers. Next, our goal should be to test first, not after. That is, we should give consideration to quality up front, not as an afterthought. Great companies further understand that quality is not a verification technique, it is a design practice. Great design leads to great quality, when the two practices come together intentionally. Lastly, a huge focus and commitment to test automation can greatly reduce waste in the quality assurance efforts.
The following table compares the traditional thinking with our “new” thinking.
|Traditional Thinking||“New” Thinking|
The burnt toast analogy used above explains the way that traditional teams create software products by quickly creating a terrible initial product and then relying very heavily on QA efforts to clean things up by “scraping off the burnt parts.”
This analogy is not my own, but unfortunately I cannot find the original author of this concept, so if you know the original author, please let me know in the comments.
A New Role for Testers
In this new kind of testing, we need a new role for our testers and QA analysts. In order to adhere to the mindset above, our testers will need to work closely with a Product Owner (in Scrum) or Product Manager of some sort to understand and help document and communicate desired system behaviors. This can sometimes be a huge amount of critically important work that directly impacts the overall quality of a product. Great communication about system behavior can reduce a number of communication related software defects by eliminating confusion. Traditional testers may be very familiar with writing test cases, and these are one form of documentation of desired system behavior that testers should write before development begins. Writing the test cases first means that developers have more reference material that will help them to do their job better. Lastly, testers have a technically focused role, and should take advantage of the opportunity to deepen this skill set by learning to automate testing activities.
All of these activities may sound new or foreign to QA analysts that have become accustomed to the traditional daily grind of banging on a software product by hand and recording results. But, mastering these new activities will not only prevent bugs in the first place, it will reduce the monotony of the traditional job. Exciting new opportunities await the tester that expands her skills, automates the repetitive tasks, and focuses more on overall product design and quality from the beginning.
How traditional is your role as a software tester, and can you benefit from this new style of testing? Let us know in the comments below!