What does the tester do? They question everything, they bear responsibility for the success of the project, and is the gatkeeper to releases.
You can test without asking questions, but you will not test well. Asking yourself questions is critical to the success of the project. Without questioning - you become aimless and mechanical.
Here are the initial questions that guide my role:
- What is my mission?
- Is everyone in the project in the same page on the mission?
- Is the mission clear enough that we can start planning?
- Do I know who my clients are?
- What are my clients trying to achieve?
After asking myself these initial questions, I go through a checklist to answer the following questions:
- How do I find important bugs fast?
- What is the minimum standard that the product should be?
- What resources do I have for testing?
- Are the testing documentations up-to-date?
- Is the testing team up-to-date with the latest changes?
- How do I minimise testing time?
- How do I maximise testing effectiveness?
- Who is accountable for what part of the testing process?
- How will the progress be reported?
Initially, when I just started testing, I found myself not asking any questions. I just agreed with everything and went with it. Over time, I found out that during the whole development life cycle and I’m not asking questions, there’s something wrong. When this happens, I take a quick walk around the office and then sit back on my desk asking “What’s my mission?”
Focus on the project’s success
I’ve been told too many times that testing does not focus on the success of the project. I tell them wrong, why should I tell them that we’re going to release a faulty product? The constant notion of people thinking of your negativity is quite depressing, but ask yourself this “What is your mission?”
You will tell your stakeholders about the status of the project something along the lines of “for the tests agreed and performed, I did not see the product not functioning to its expectations" . Testers need to focus on successfully finding failures to improve their chance of finding it. If we come in blind assuming that we’re not going to find anything, it’s not too fun.
You focus on successfully finding the issues to the team can make a decision on how to proceed with the project at hand, what the product’s risks are, and what are the new timelines. The tester makes the product better not just for the team, nor the clients, but for the perspective clients.
Beware “Did you test every scenario?”
There is not enough time to test everything. When your manager asks how long testing is going to take and you say “It’s going to take 3 days”, this might be mistaken to meaning that you will find every bug in the next 3 days and you’ll release on the 4th day. However, this does not take into account whether you’ve gotten distractions, you’ve found bugs that need to be fixed, and having to re-test certain parts after a fix.
This book talks about the meaning of completeness:
- Complete discovery of every bug in the product
- Completely examined every aspect of the product
- Completed the testing that you believe is useful and cost effective to perform
- Completely fulfilled the objectives of the project to the best of your ability
- Completed the agreed upon tests
- Completed everyone’s part of testing
When dealing with your stakeholders, you need to clarify to them what you are testing and what your definition of testing completely means. This will make sure that you are not to blame and that you are able to defend yourself when a bug appears.
We do not assure the quality of testing, it is the whole team’s job. Quality comes from the process and the team. The test results that you will report will be used to dictate what the next-steps are in the project.
Challenge the software development process
You always find problems, the worst thing is, they’re always the same problems, and you wonder “It’s better to prevent this”. You think if there is a certain process that can be done before it gets to you that it will be all better. This makes sense, processes need to keep evolving to become more efficient and effective.
It's release day, you release after lunch. 5 minutes later, someone finds a bug. A learning lesson! You did not find the bug in the test process and it’s caused problems. Now it’s time to ask ourselves why it happened until you get to the root cause. .
This does not just apply to testers, everyone has the desire to improve. Everytime you go through a development lifecycle, you gain more insight into how the product works, how the users use the product, and what your clients care about. In the next iteration, you’ve loaded up your gun with more ammunition to tackle the challenges in the future. You didn’t just challenge the process, you are going to suggest improvements. In your report, you will mention what the situation is, how it’s affecting your users, your suggestion, and then how will this suggestion improve the process.
Here’s a snippet from a previous post:
When you evaluate your process, look first at the quality of the people in your project. How do they think? What affects what they do? What can you do to enhance their effectiveness? Once you have answered these questions then evaluate your process.
It is up to you to let your team and the wider business team to know what you need in order to do your job more effectively. You are affected by the choices made by everyone in the team. If they’re unclear about their plans or the mission, the project will fail. Explain your testing to your team so that your team is able to fulfill the mission.
You are the gatekeeper
Well, one of them anyway. Once upon a time, there was an inventor called Daedalus. He angered the King of Crete and was sentenced to imprisonment at the top of a tower. Desiring to flee the confounds of the prison tower, he used wax to build some wings for his son and Icarus. Icarus, warned by his father gets too close to the sun and his wings melted, plummeting to the sea and drowns.
A tester’s dream is to have control over the release of a product. Like Icarus, they deserve to bear full responsibility of their actions. This will result in the team to become relaxed, too relaxed. If any bug sneaks by the tester, the tester will be the one to blame. “Why did the tester ship such a buggy product?” Inversely, if the release is taking too long, people are going to wonder “Why is it taking so long to test? Are you testing more than you should?” You can never win.
Ultimately, it’s the whole team’s responsibility for shipping a product. This is the way forward, insist on sharing the authority on release with everyone on the team will mean that everyone will be more mindful of the release and not put the blame on the tester.