The journey of becoming (stumbling..) a Software Tester.
By: Viktor Ng
Tags: Software Testing, Software Development, Blog

The journey of becoming (stumbling..) a Software Tester.

Well, to be more accurate, formally my title is Quality Assurance Engineer (or QA). Things is, Software Tester is what makes people goes “Ahhhhh Software Tester then Software Tester lah….” Sooo, yup.

Quick! What is the first thing that comes into your mind when you saw “Software Tester”? Most probably it will end up as something below.

Play with the systems? Clicking the application here and there to see if any error pops up.

Understand requirement and check is the software meet the requirement.

A job for me? Can I get excitement from it as I just interact with system all day long?

This is what I thought of when I first go to interview as a QA. In fact, I don’t even set out to be a Software Tester, I just happened to stumbled upon it in a job fair in my college, apply to try it out and… whoosh, almost 2 years spent in the industry.

Role as a QA

For me, the essence of QA is about improving a software so that it meet the users requirement as close as possible. This require answering questions like:

Does the software meet the users / client requirement and expectations?

Does it help them to solve their usage and business problems?

It is ease to use?

And so on…

Some of the items, like the bullet point #3, is impossible to lay out the complete extensive requirement on this that nothing falls through the cracks! User might not even know the ease of usage can be possibly improved unless we suggest to them.

The daily task of QA can varies a lot, for example, testing developer fixes, understand user requirement, summary report on the software status, creating test data for developer, facilitate discussion among team member to discuss an issue, maintain automation script and many more.

Challenges of being a QA

Being a QA is not as easy as it seems. For starters, QA has very little influence on what will be developed in the system. Why do I say so? I like to imagine that QA functions similarly to an investigator of the system, akin to the detective in a crime scene. A detective can’t control how a judge deliver his judgement, but can provide evidence that leans toward a side of judgement.

This means that as a QA, a lot of things is out of our sphere of control. The bugs reported that we feel important might not seem so in the project leader eyes. At best, we can come up with convincing arguments that it is essential. But it is something that we have to keep reminding ourselves in order to not go insane.

Another thing is the timing of task that is delivered to QA. We often can’t control what developer needs to be worked on now, as the priority of the task can be change in a whiff of notice. The development time may eat up a lot of testing time, and in the end, the build that is ready for test may be passed to QA at a very late stage, and oh boy, it is a stressful one. There is only so much we can do, that we just have to make do with what is given to us, for example OT all night to complete the task. And it is such a dreadful feeling to find a bug in this timing and the process has to go over again while we are racing to a release deadline.

And also, it feels very bad when a severe bug is leaked to production environment (software version deployed for user usage) and user found out about it. I’m currently working with banking industry, hence the stakes is much higher than say, normal Android App. Any bugs that may have a business implication require quick hot-fix and negotiations with bank on the release schedule. In severe cases, it might impose a penalty on us. I understand that catching bugs is a team effort, but sometimes when it is leaked, you just can’t stop asking yourself “How could I missed that?”

Is QA rewarding?

Despite the shortcoming, I liked QA as it can be very rewarding if you done your job well and your team really appreciate. One of the best thing becoming a QA is you get to feel good when you caught something really obscure but really important, and explain it to BA and Tech in a way that they completely understand it and came out a way to do a fix for it.

I also liked the variety of people I get to know when I’m working with them. Everyone comes from different background on their technical skills and analyzing skills, that I feel that I can learn a lot from them. It is not to be said that I can’t do this with other jobs, but I feel that one of the QA main task is to communicate communicate communicate, and facilitate communications, so naturally the opportunities presents more of itself that you can learn from others.

Closing thoughts

I think that is all on my surface observation as being a QA. Of course that is more but it will take way to long to write about it. After went in to the job, I just can’t be helped but feel appreciated on the service as a QA provides to others, that I cant fathom how more stressful is it to work on other big software that is used by millions of user around the world, or very critical industry such as aviation or healthcare.

Do connect with me if you are a Software Tester as well!