Header image by Dikaseva.

First, you’ll need a project management/bug tracking tool. At Made by Many we use Jira, which is my bible for every project I QA: it gives me a quick snapshot of what state the project is in and what features/bugs need to be QA’d. Jira (or whatever tool suits your team) needs to be set up correctly, and most importantly, you need to have buy-in from the whole development team so that it is used consistently.

At Made by Many we also use an agile workflow to do planning, estimation and so on. Our Jira board is broken down into sprints, and the tickets are organised within the sprint board. Our Jira board consists of “To Do”, “In Progress”, “In PR”, “QA” and “Done” columns. Naturally, features and bugs don’t land in the QA column unless the developers are confident that the acceptance criteria of the tickets have been met. What also aids this is developers “pull requesting” their code. This enables other developers — who may not even be working on the project — to cast their eyes over the code to ensure it doesn’t contain any glaringly obvious bugs before it gets to QA.

Also, and this is probably going to cause a stir but… forget about writing test cases and scripts! Why? Because test cases are not the same as performing QA. Using the product, operating it, observing it and evaluating it — that is performing QA.

Now, timebox your QA time on certain features. Some call this “session-based QA”. This is usually about 90 minutes on a certain feature or bug. Also ensure you are not interrupted in this time. Document your findings – I use my notebook to document what I’ve tested; sometimes I just jot down simple flow diagrams of what I’m thinking. This is important in case you need to revisit a certain feature.

There will also be lulls which occur on every project where you are, for example, waiting for a build. This gives the QA time to move on to a different project, and it also serves as a reset for your brain and memory. Focusing too much on one item can cause a QA engineer to become too familiar with the feature they are testing and therefore become blind to potential issues. If QA is blocked for any reason — which can happen — this is a great opportunity to rethink and go over your testing strategy to ensure that QA has captured most issues and covered most scenarios.

As I mentioned, I use Jira as my bible: this is the foundation from which to start the QA process on a particular feature. This enables the QA engineer to do lots of exploratory scenario testing, giving them the freedom to think of realistic user behaviour and create multiple scenarios.

QA is almost like a heuristic search — by which I mean that there is no sure way to find what you’re looking for, and no optimal way of searching for it. To be a QA you must indulge your curiosity, open your mind to playing with a product, and open yourself to the unexpected. Without this as a QA engineer, you almost become a robot and a lot less like a human interacting with the product as a human would. No single person will use the product in the same way, whereas a robot will always be predictable and use the easiest path.

This is hugely important and powerful: by being in and amongst the developers that you are working alongside, they are able to see any issues and bugs first-hand without the need for bug reports and replication steps. That’s not saying you shouldn’t write bug reports — you should! — but if a developer can see first-hand what the issue is, this acts as the best form of bug report. Sometimes developers can fix the issue immediately, which aids the velocity of a project. This is also the case with designers being in close proximity: it allows the QA to voice concerns regarding any small design changes, which can add a lot of work for QA to get through.

In the end, remember: you may be the lone QA, but you’re not the gatekeeper to quality. You are part of a team which — using the above techniques — is responsible for ensuring the product is of a high standard from start to finish.

To the lone QA!