Lessons From My 2nd Year as a Quality Assurance Engineer

You build a connection with the product; Testing is Iterative

Atul Jha
Technology Hits

--

Photo by Christina @ wocintechchat.com on Unsplash

So what is Quality Assurance & why is it different from the role of a tester?
Quality Assurance is a practice for finding the right balance between the business side and the technical side of the product.

If you have read my previous article, What Did I Learn From My First Year Working as a Quality Assurance Engineer? then I’d like to thank you. If this is your first time following an article from this series, I welcome you to go ahead, find some insights, and if you have some feedback, I am always open to receiving them.

I have been working as a QA for 3 years now. So follow me for more content in this series.

  1. Testing Can be an Equally Technical Job
  2. You Build a Connection With a Product
  3. Testing Makes a Product Better (Testing is an Iterative Process)
  4. Soft Skills on The Job are More Crucial (sometimes) Than Just The Hard Skills

1. Testing Can be an Equally Technical Job

So how do you define technical? Is it being a good programmer? or as a QA, being good at writing great automation scripts?

Testing can be equally technical. You can either choose to just traverse through the application manually, but when you take a little step ahead, there is a lot that you can offer.

You can choose to walk through the application, which you will always have to, to replicate the use scenarios from the eyes of an end user i.e. the classic Manual Testing.

Step up the game, by learning about how things work. You can learn about how things work on the backend, and the frontend side, which will increase your understanding of the product while increasing the range of input you can provide.

There are always things you can get an overview of to grasp the bigger picture such as the design process, CI-CD, APIs, cloud, Version Control, Databases, and interaction between each unit that makes up the whole system.

Having a bigger picture of the whole system has helped me identify the root cause of many issues, which could have cost the team more time.

Tip: As a habit, it’s a good practice to know what’s happening and adapt your working process around it.

I was recently watching a Youtube video, by Alan Richardson aka, The Evil Tester on how companies are cutting on manual QA and why testers need to up their game.

2. You Build a Connection With a Product as You go

When you invest time and become a part of something, you feel connected to it. This is true for everything and it’s the same with the software that you use.

You know all about the product, each requirement, and how they are interconnected.

One piece of advice that my mentor gave me years ago when I was in my internship period,

“Think from the eyes of an end user. Don’t just use random input, use the actual input that your end users might use.”

I have always kept this in mind and have used this approach ever since.

If I were an end user, what sort of input would I use here? How would I use this feature?

For example: I was once a part of an application built for a pharmaceutical company wanting to digitize their drug discovery process. I spent some time researching the terms being used in the application, the overall protein synthesis process (bigger picture).

With this, my test input were now similar to what a scientist (end user) would actually go on to use.

While this required me to do some extra background research, not too deep though, this approach to understanding the product has helped me deliver great value for the customers and clients.

There was a satisfying payoff in finding the actual issues first before an end user ever could.

This has helped me build a connection with a product letting me add my own creative touch.

3. Testing Makes a Product Better (It is an Iterative Process)

The purpose of testing is not to find the bugs. It is to make a product better.

I like to draw insights from various disciplines like books, medias etc. I was once watching an anime, Kengan Ashura on Netflix. There was an instance that reached out to me.

If you have watched Kengan Ashura, you may know of the Lethwei (Burmese brutal kickboxing) fighter named “Yoroizuka Saw Paing”.

Saw Paing is a Lethwei fighter since birth. Lethwei is an ancient martial art that laid the foundation for Muay Thai, or Kickboxing.

I thought I was reading a testing-related article, when and why did it switch to Martial Arts?

There is a concept in Lethwei, a discipline in which the fighters’ body becomes stronger the harder they break them. Lethwei is one of the most brutal sports where almost all the fights lead to injuries or breaking of bones, much more than any other sport.

Here’s an article from MMA Channel that backs this claim.

What fascinates me is that as the body breaks and recovers itself, the recovered version is now much stronger than the previous version.

When you reframe the same concept in the making of a software, every time we break an application, report an issue and the issues are fixed, it becomes better over time. This is why testing is an iterative process of making a product better, improving it rather than finding bugs.

In my previous article, I wrote a point where I mentioned that “Your primary job is to know how to break a software by any means.” While this is not completely wrong in itself, a QA should know how the cycle of breaking and fixing makes the product better over time and strive to make a product better.

A product that users love to use.

Rome wasn’t built in a day, and neither are great products. Testing makes a product better iteratively.

4. Soft Skills on the Job are More Crucial (sometimes) Than Just The Hard Skills

The first Project Manager that I worked with said to me,

You need to know how to communicate well. Good communication can always solve all the problems.

Yeah, it made sense. But the statement that I wasn’t even bother to internalize stuck with me on a deeper level as I carried on with my work.

Years later as I look back, this statement is as true as it can get.

As I failed (yeah, did that alot), as I learned from my own mistakes I realized that the way you communicate with people around you, the way you carry yourself, and the energy you portray is really helpful when you are working in teams and building relations.

As a QA, my role requires me to communicate much more than anyone else out there. I have to communicate with all the product stakeholders.

Maintaining fluidity in communication is critical if I want to ACE my role.

There is something even more important than communication, your sub-communication.

Having good soft skills associates you with reliability & trust when you are working in teams. And what you associate yourself with is what you are getting in return.

Tip: To communicate an idea with full effect, you need to fully believe in if yourself. Communications happen on a deeper level.

Bonus: Beware of your sub communications. They are more important than your words.

I am sure there are takeaways and feedback, tell me more about them in the comments.

I will be sharing a lot of insightful articles. Follow me for more content like this.

Ba Bye 👋

--

--

Atul Jha
Technology Hits

find VALUE in my article? buy me a delicious cup of coffee for $5 ☕ at buymeacoffee.com/atulzh07.