--
We’re currently hiring a QA Engineer at OnTruck. In order to choose wisely the best candidate, we wrote down a list of soft and hard skills a great QA Engineer should have.
I was going to write a post developing those skills with my own words, but as I’ve found so much great content in Medium I’ve decided to do a summary of several great posts instead (you can find them below). I hope it clearly reflects how a great QA engineer influences and improves design and development processes on technology companies.
Thanks Jamie, Dion Almaer, Daniel Pasco, Philip Chu, Sarah Fittje and Mészáros Melinda!
QA is almost like a heuristic search
Traditional software testing processes have often fundamentally misunderstood people and the needs of testing. By approaching it as a tickbox exercise that follows repetitive and set user paths, they assume a level of rational predictability that is rarely present in human behavior. Technical tests, especially those that are automated, don’t replicate the desire of users to click where they’re not supposed to, and can’t accommodate irrational human behaviors. In other words, the more structured and logical you are, the more likely it is that you will miss the opportunity to improve usability and remove the bugs that actually impact real users.
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.
Testing treats users as a single, hom*ogenous group but QA adopts different user personas in its process.
Stick close to the development and design team
Submitting a long list of fixes at the end of a sprint feels like a process designed to punish developers by highlighting mistakes and errors. A better idea is to work alongside developers as they code to highlight user-improvements so that QA becomes an integrated part of an agile process.
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.
Testing is the last step in the development process, whereas QA runs throughout it.
Avoid QA ping pong
QA ping pong means that one and the same ticket is juggled between QA and developers several times. This can have different reasons.
Either the developer:
- doesn’t want to admit that nobody is perfect and rejects QA Fails without verifying the failed issues
- doesn’t read the test report properly
Or the QA:
- marks a ticket as failed in every test iteration as soon as the first bug occurs
Before you declare a ticket as failed and hand it back to the developer, check whether the failed issue is affecting further use cases or not. If the fail doesn’t affect other use cases, go ahead in order to discover more bugs as early as possible.
Testing is an audit report, QA is a supportive conversation.
Prioritize to maximise the user-benefit
You will find many type of bugs through the process which will affect different type of clients, both internal and external. The key for the success of the agile process is on getting the best return by focusing fixes on what will have the biggest impact for the user.
In order to help with this decision, you must have a well-maintained and prioritized bug database. This is the QA’s own product in fact. The bug database represents the state of the product and should drive all development decisions. Thus it should speak the truth.
This means that you will ship bugs, but you’ll do it on purpose, because you’ll understand the impact and will decide that the risk is manageable. Successful companies routinely ship with known, manageable issues because shipping is a feature and there will always be another build.
Testing has no view on the impact or importance of a bug. QA prioritises legacy fixes into a list ordered to maximise the user-benefit.
Great QAs know what is really going on in the systems
Great QAs often hold the true spec. It isn’t the pretty one that holds the theory, it is the one that holds the truth of the various systems.
You have the slew of tests that go beyond the happy path and a couple of edges. To do this you are often writing a lot of code yourself of course. We aren’t talking about manual wranglers here.
You are the true holder of the use cases. The UX team has some red lines and notes. The product team puts together some business scenarios. The engineering team implements a bunch of this work, and then you do some really hard work to get the full coverage. You need to go back to the members of the team to wrestle these edge cases to the ground.
Testing has a narrow view of each system. QA views them as interconnected system.
User centered point of view
You must be able to empathise with the potential user, sense their behaviour, understand their needs and then use this insight to support the developers. This will also help you to prioritize bugs and inconsistencies.
Good communication (psychology of testing)
Errors and bugreports have to be communicated in a constructive manner because designers, PMs and developers can be sensitive. Every QA is proud when they detect a bug in the system. Yet you have to be careful not to be too proud, because that could hurt the devs feelings.
Precision & monotony tolerance
You must be very detail oriented in order to validate the specifications given by the PM and designers and to test different scenarios every single time. You don’t mind doing similar work every week, as you will be testing the same interface again and again. Some parts of the job are more novel and others require more focus.
Confrontation skill
You have to be able to stand up for your opinion (even if you have nobody on your side). You have to point out the risks, you have to be able to make a case for your proposal but you also have to be able to let it go if business needs dictate.
As Rafa, on of our Senior Full-stack Engineers at OnTruck, says: “The characteristic that best defined the two best QA engineers I’ve worked with was that they applied logic at all times: they were able both to face the development group if the implementation was poor, as the PMs if the specification was bad”.
Fast learning and want-to-learn attitude
This one doesn’t really need much explaining. The tech industry is always changing, new solutions and new technologies emerge and you need to keep up with them so continuous learning needs to be a core part of your life.
This is the reason I haven’t talked about any technology. It should be a given you know the latest tools to be better at your job.
Are you a QA Engineer with this potential?
We’re currently hiring a QA Engineer for our team. I’d like to talk to you.
OnTruck is a new European start-up devoted to bringing the road transportation industry to the 21st century. We realised that, despite how present mobile technology is in our day-to-day lives, it hasn’t yet reached such a critical industry. Our initial product is a B2B platform to streamline the finding of the right carrier for your freight. You can think of it as an Uber for trucks.
Our headquarters are in sunny downtown Madrid, close to several public transportation alternatives as well as public bike stations. We all work from the office to maximise face-to-face interactions and therefore we keep remote working to a minimum.
Investors like our concept and team and we’ve been quite successful in fundraising and gathering resources to support our future growth.
