What is the actual role of a software tester?
Is every bug that gets released into production our fault?
Are we the sole guardians of a released product?
The book “Lessons Learned in Software Testing” by Cem Kaner, James Bach, and Bret Pettichord tells us that we are the headlights of the product. It is our job to “Light the way” for the rest of the department. Let’s delve into what this means.
There is a bit of a misunderstanding on what the actual “role” of a software tester is. The perception is different from department to department. I think we can all agree that our goal is to ship great and quality software, but what is our actual role in accomplishing that goal?
The answer is simple.
Our role is to provide data.
In my first interview I answered the question “What is the purpose of a software tester?”, with the obvious, “To provide quality.” The answer isn’t wrong, but it wasn’t the right one either. I was corrected that the purpose is to provide data. As software testers we are not the ones releasing the product. We are not the ones making business decisions. It is our job, however, to analize risk, provide details and information on issues, whether they be upcoming or current, and to give stakeholders a clear understanding of what to expect.
We need to avoid being the “gatekeeper” or portraying that mentality. The more of a gatekeeper we are, the more of the blame that falls on us. We will never find every bug. We will never know 100% that a product is working in every aspect, but we can provide the data that we do know. It is also our role to provide it in a way that the stakeholders can understand and use to make business decisions.
We also need to be thinking about being the headlights. This means to be preemptive testers, rather than waiting for things to test. I find that stress testing is a great example of this. When we perform stress testing on our applications, we are able to push it past the limits that we know it can handle, thereby “lighting” the way to see what would happen if the product were under this amount of load. This is excellent data to give to a stakeholder or your product manager, allowing for proper prioritization.
We need to remember that we are never the cause for broken code. It comes to us already broken and I think that we don’t always remember or realize that. We need to portray that to the department by being confident, presenting well written and relevant data, and by being a headlight rather than a gatekeeper.