5 lessons learnt as a QA Engineer

Quality Assurance allows you to learn and develop techniques for looking at a product in new ways. Every product requires a different approach to testing. I’ve been lucky enough in my career to have worked on a variety of different digital products across multiple industries.

I started my career in testing nearly 5 years ago, originally working for a software testing consultancy where I learnt a lot of the key principles of quality assurance. Here I gained my ISTQB certification as I shaped my core understanding of software testing whilst consulting as an Analyst for a few organisations; namely an online retailer and one of the Big Four accounting firms.

A year later, I left the consultancy to join another e-commerce retailer where I continued to build on my knowledge, specifically in test automation and working with Agile methodologies as a QA Engineer. I spent nearly 3 years here and learnt so much from the people around me in a number of different product aligned squads.

That takes us to present day, where I’m currently working with one of the UK’s fastest growing digital banks, continuing to grow as a QA Engineer whilst working with incredibly talented people around me.

Throughout my journey there have been a number of lessons learnt that have been valuable and transferable as I’ve moved from role to role.

1. Make sure that what you find is really a bug

The ISTQB glossary defines a bug as “a flaw in a component or system that can cause the component or system to fail to perform its required function”. As a rule of thumb, I try to apply this to bugs I’ve found in order to gauge whether or not it actually is a bug. It’s also key to make sure that the bug you’ve found is reproducible by yourself and by others in your team.

2. Be detailed but concise

It’s a bit of an oxymoron but it’s important to convey your findings as succinctly as possible without missing any key details. Developers don’t usually have the time to read through long winded bug reports, nor do they know exactly how you found the bug. Keep things brief and be sure to include any test data and steps that are needed in order to effectively reproduce the issue.

3. Understand the requirements (even if it means asking lots of questions)

One of the most important aspects of QA is understanding the requirements. When I first started out, it was quite common to receive tickets from a Developer with a simple screenshot of their changes and little information about what was needed to test. I often felt apprehensive to ask for more information, but very quickly found that this was the wrong approach to have as it lengthened the time it would take to test new features. You should feel comfortable enough to ask as many questions as you need in order to enable yourself to carry out your job properly. It’s a key characteristic of a Tester to be inquisitive so asking questions is the way forward.

4. Work collaboratively

There’s often the idea that Testers and Developers don’t get along. I’ve found this to be the case only when there’s no collaboration between the two. I’ve worked within companies that only test their product towards the end of their development cycle, with the only communication between the Tester and Developer being the handover of new code into a test environment. This is a big no from me. It creates a bottleneck and can load pressure onto a Tester, ultimately leading to bugs falling through the cracks.

Ideally QA should be involved as early as possible and throughout the development process. Working collaboratively in an iterative delivery model is one of the best ways to deal with this. Slice your project into smaller, manageable tickets in order to develop and test these gradually until the feature is complete. To streamline this further you could even use the Three Amigos approach which comprises of a Tester, Developer and Business Analyst working together to complete tasks.

5. Encourage others to test

As a Tester you shouldn’t be the only one responsible for the quality of the product. It’s the responsibility of everyone in the team. As much as I’d love to help test everything that the team is working on, it just isn’t feasible. Testing isn’t rocket science and you should definitely enable other people in your team to test features by coaching them. For example low risk, trivial changes can be peer assessed by developers in the team, whereas more impactful changes can require a QA Engineer to take a look at.

Similarly, with automated testing, many developers I’ve worked with are very interested in helping write test cases. It can be great to pair with developers and more often than not, you can both learn a lot by doing so.

To wrap things up

We should remember that Quality Assurance is an important job from start to finish. Everyone can test and a great QA Engineer should empower their team members and coach best practices around testing. Ultimately the goal is to reduce bottlenecks and work collaboratively in order to achieve a shared end goal. Doing this encourages a team to create high quality products.