My official job role is a “QA Tester”, working in a startup you have to fill multiple hats as resources are always tight.What is a tester meant to do? What is my role in a project? What value do I add to the project? These are the key questions that I am going to talk about in this blog. This is written for people in software development teams, testers, product managers, developers, executives and many more. As I strive to become better in my role, I hope that you’ll gain some insight from the lessons I have learned with my experience in Software Testing.
This blog is not a definitive answer to what a tester does. These are lessons of what I have learned based on my experiences. I believe these things apply to all the testers out there.
- The light in the dark
Imagine you have a goal, to achieve these goals what do you need to do? You set objectives. Although we try to account for multiple scenarios that might come our way, It is impossible to think that there will be no trouble ahead. The tester’s role is to find information along the journey so that the team is able make better decisions to reach the goal. Let’s say you are mid-way through your project, the developers have completed the code and it has come to you, it is now ready for QA but you find that what the developer has done maybe a waste of time as there is a better way of doing it and the system that you have can already do it. As the tester, it is your responsibility to tell management what you feel about the project. It could be that management decides that you will not test anymore, It could be that they say to continue ahead with testing. Whatever the case, you got your point across and you make yourself responsible - What you find is critical to the progress of the project.
- Verify what is being built is what has been asked
Your job is to clarify the mission, the goal. You get the team to sit down and agree with the mission objectives. Finally, if you find yourself losing track, remind yourself of your goal. This is what will keep you going.
I have worked in multiple projects when some stories have been completed by the developer without the verification of requirements - In short, what was built was not the correct solution. Is it the developers fault? No. As a team member, it is one of your roles to verify if what is being built is correct. Imagine building a car without blueprints? Imagine baking a wedding cake without asking the couple getting married what they would like? Sounds like a nightmare end result. This goes the same for testing. How do you start? What do you test? How do you fit in the software development life cycle? What do each stakeholders expect to happen? This is why it’s important that requirements are agreed upon.
- Find Issues Quickly = Issues are quickly resolved
One of our core missions - finding bugs that are important quickly. Why do this? It is the job of the tester to inform the stakeholders about anything that threatens the value of the system. Imagine having a payment system and it allows you to multiple clicks on “Pay Now”, If the client finds this they will have lost a lot of money on their bank accounts, complain, and will have a profound negative effect on the business. It is the duty of the tester to show that the product will not be valued.
What does this mean about what the tester does? They test that the core functionality still works before looking at the new functions. They test items of higher-impact before testing items of lower impact. The tester finds important problems soon and will make sure that the team knows about it.
- You have multiple Stakeholders
This is not an exhaustive list - testing is a vital role. You serve multiple stakeholders all with different needs, and they don’t necessarily align.
- Developers - You make the programmer’s job extremely clear by writing out clear acceptance criteria, clear test plans, and clear bug reports, as soon as possible. The tester needs to know the product like it’s the back of their hand so you don’t waste the time of the developers, your product manager, and other teams. When you know about the product, you will gain influence and credibility.
- Project Manager - The project manager needs to know your process, what you do, why you are doing it. The project manager is served by reporting the status of the testing, reporting problems fast. This information is important to the project manager as he the right to steer the project, and what you say will drive the decision.
- Technical Support - The bugs that are still present in the system becomes a burden for the customer team or the technical support team. This group is served by alerting them of what parts of the platform maybe inhibited and if there is a workaround.
- Top management - Your role is to create reports in an extremely simple manner so that they are able to take actions into your findings. You may find that despite something has been “Ready for QA” when you start testing in the staging server it doesn’t work. What could it be? Could it be that it works on local but it does not work in the server? Whatever case you may find, you must have solutions to your problems rather than being the bearer of bad news all the time.
- The end user - Deep inside you now that you serve the one true master, the user. There is an exhilarating effect that you have the responsibility to ensure that the product works as expected. If you so much as say you are not happy with a certain feature then what you say is taken seriously. What I’ve found is that most of the time, the functionality works but the User Experience is not taken into account. It is the tester’s duty to tell the team that if the color of a button is not consistent with the same type of button in a different part of the system. You may ask why should you care about the color of a button? To me, finding inconsistencies is a major issue and detrimental to the usability of the product. Who wants to use an inconsistent platform?
- Do not take ownership of the quality
You are not the one sole responsible for the quality of the product. Sometimes, you may find yourself not having a say with how something should be implemented and that’s fine. It is important that you make your team feel empowered that they are doing the job their own way so as to preserve their creativity. The tester does not “break the product”, the tester finds a product that is already broken. You must work with the team to ensure that you keep on improving. If you find that in sprint retrospectives no one is making suggestions to improve the process, something is going terribly wrong. Be a quality fanatic, if something can be automated and would save 5 minutes a day, say it.
The role of the tester is not to find issues, it is to ensure that the product quality remains at a high standard and never accept that something cannot be improved for the next iteration.
Find out what it's like working in a startup as a tester Here
This piece of writing was inspired by this book: