Me, Myself, I. Chronicles of a Solo Tester
I began as a lone tester in my project and the initial days were really tough. I was surrounded by the developers and it was difficult to understand their lingo and coders jargon were intimidating most of the times. But it helped me in many ways.
I understood the pulse of the developers by being part of that team. Being part of their countless brainstorming sessions, I started feeling their frustration when a tester reopens an issue and the satisfaction when issues are closed. When there is a bug, they explain the root cause by diving deep into the problem, the solution, the limitations and the time required. They also seek my advice or my approach; and the best part is, it works, just like that.
Being a solo tester is dreading but also has its own perks and I’m glad I’m one. I am now more technically sound (I know how stack overflow works) and can think like a developer. I started learning coding and developed my first module. It was one of the best learning experiences of my life. It’s a challenge that every tester should take.
It makes us understand how the development process works, not just the theory of it.
When you are the only tester, the developers will lend a hand in testing. They wisely test it once before giving you the test build. There is usually less formal documentation as they sit right next to you and can be alerted about the issues immediately.
The communication is smooth, easy and quick.
Traditional testers are always or sometimes not very savvy with the development team. There is always that friction between the two teams that leads to a lot of delay in getting the issues resolved. But it’s different here, in my case, it’s one team. The developers accept me as one among their pack and on the contrary, I see them as my pride.
The downside of my journey so far has been the ‘idle timeouts’. While the developers are busy coding, I just sit there blank. Also I’m always the lone wolf, I need to carry a lot of responsibilities. I’m answerable to all the issues, especially when the clients find one. But the biggest flaw is the lack of diverse testing. There is only one way, my way. At one point, eventually, my testing skills may reach a point of saturation and without competition I do not have a scope to measure myself too. The regression testing is a long and a tiring journey which requires me to design, execute, report and close. Things go messy when the developers won’t agree on a particular issue and it is tough to deal with 5 of them against me all alone. It’s a heavyweight battle to prove them wrong and sometimes, I just give up.
There are times when I feel very incompetent when I see the coders work. They use algorithms, mathematics and technology to build and I am the fault-finder. which is sometimes not so gratifying. I feel sad that my attitude demands me to be doubtful, cynical and unacceptable.
In coming days, the traditional methods must be broken. There should be no separate testing or development team. It should be one team of software builders. A large team can be broken into smaller groups. It provides better micro management and agility with the increase in mutual learning experience leading to an amazing and a performing team. Better decision making abilities will be developed. Collective brainstorming can be done resulting in an efficient development cycle.
So in conclusion, I’d like to say…, oops! found a bug. Be right back.