The unaccustomed reality of a tester!

I have been a QA for my entire career even though this was not the exact expectation when I graduated. Being in the software regime in which I was less interested during the initial days of my career, was expecting to be a boring job. Being a voracious reader and a constant believer of never judging a book by its cover, I took the leap. Not really the leap that Armstrong made, but I fashioned myself as Armstrong here and testing was my moon. 

Initially, it was all routine stuff. Executing test cases that were written by seniors who had a great knowledge about the application. Obedience came in hand as a beginner but at times the very same obedience in following the exact steps of outdated test cases put me in trouble. Me being ever enthusiastic, started the correction of test cases just to make sure that I don't get into the same trouble again. And to me this was the giant leap. The ”Mankind” sort of leap. 

As anyone would probably know, correction is not something that is very big when it comes to test cases or generally software testing. It varies from simple "is-to-should be" to entirely replacing a drop down list with a few buttons. But I believe this is where a real tester arises. Once we look for corrections, we see the mistakes that make our application look bad. From simple spelling mistakes, image discrepancies, form loading time frames, first time load issues, data issues, button misplacements to a really serious does-a-customer-really-require-this-feature or a how-will-the-customer-tolerate-this type of issues.

In other words, this is where a tester explores the application. Be it Columbus or a simple tester, only exploration can bring the unidentified areas into light. More the exploration, less the unknown areas. Less the unknown areas, more the application knowledge. And believe me, other than requirement mismatch which is quite rare, every single production issue comes from ad-hoc scenarios which would never come across by following a test case as is.

Every person who recognizes himself as a tester should own this trait of exploration. A person who tests food can never say that he cannot taste chicken just because he is vegan. To be a good tester , to be that "quality" oriented person, you need to break the barriers of your comfort zone. Merely following the test cases that cover happy flows and closing out tasks is not what a committed test engineer is. A good test engineer is a person who knows the system well, analyses the error logs and guides the developers towards the root cause, carries out various ad-hoc methods that the customer would possibly encounter, discusses and inputs relevant suggestions to the Subject Matter Experts and the System Engineers in refining the requirements. He/she should not only be able to dwell into databases to scrutinize the data issues but also be able to understand the code of the application he/she works on. 

Apart from interest and passion, people management and maintaining healthy relations with fellow developers is a key factor in a test engineer's life.

You should be fully aware that no code can be wrong. It is only the way of implementation that can be wrong. It is never the implemented scenario that's wrong, it is always the scenarios that are not considered during implementation.

A tester should define this as their approach towards ensuring quality. Nothing is more than a nightmare for a developer to have a fellow tester who throws a critical bug over him on Fridays. So when you have a bug to throw over a developer, make sure you take the time to discuss the same. Fixing the issue is never a lone responsibility of the developer. It takes assistance from a well versed test engineer who knows the scenarios and areas of impact to fix a bug as well.

I had the good fortune to work with a team of developers who never see testers as a barricade, but as a ‘force’ that shrinks chances for production issues. This does not come often and with ease. And this does not mean that they are afraid of testers and will always fix the issues regardless of its validity. They digest the issue patiently, analyze the same from the prospect of Code and its impact area(s), human logic, given requirements and business necessity. Then they are happy to either fix it when it's valid or to explain in detail to the tester why this cannot be considered as an issue. And the tester should also be patient in digesting this information in its context. It is when that healthy conversation blooms to not be a truce but an agreed decision, the application’s quality begins to improve. 

Trust me, every developer wants to know the application better and it's only and only the testers who could help them achieve the same.

This requires a well maintained bridge among developers and the testers in a duplex manner. There are times where we have not made the said agreement, both parties stay where they are, not because of their adamancy but both have their own reasons that leads to ambiguity in the issue. Still the conversation is healthy, both know they are right and this ambiguity is just the result of being beyond their control to make a decision. If you can't find a solution, initiate a discussion with the superiors and make sure they get to know all the details behind the issue. It is important to let them be aware that we are here to arrive at a decision that benefits the application, and it is not anything about the tester or the developer. 

And if you still take every single discussion individually to your superiors for a decision, you are that tester who should take the giant leap and yet to build bridges. And Yes, the bread and butter of a software engineer is not the organization, it is and should always be the “QUALITY” of the application that he/she is part of.!