9 Things a Good QA Engineer Should Be Doing on a Project

QUALITY Assurance(QA) engineers often don’t get the same spotlight as software designers or developers. But without them, we’d all be pulling our hair out as websites and apps keep breaking down. They are the unsung heroes that track down all (or most) of the bugs that undermine a product’s performance and desirability. And they improve the quality of software by making sure the client’s requirements are met, executing tests from a user point of view, and accurately documenting and prioritizing any error found.
Each software development project and the team is unique in its own way, but there are plenty of QA best practices that can ensure smooth and consistent processes regardless of the project specifics. With that in mind, here are nine things all good QA engineers should be doing when working on a project:
1. Be involved from the start...
QA should begin at the very start of a project, even if the actual testing is performed at later stages. Integrating QA engineers in the early stages of software development will ensure they fully understand the business objectives and requirements, the software design, and the target end-user - information that will help when it comes to building a quality test plan. As a QA engineer, you’ll also want to learn as much as you can about the designers and developers you’ll be working with. This knowledge can be used through the development process to try and prevent bugs, rather than just fixing them.
...And remained integrated throughout
Once you’re integrated, stay active. Under the Agile methodology, the software is being developed and test-run simultaneously, so QA engineers are able to interact with the iterations of the product and provide quick feedback to developers. This should mean that any deficiencies are quickly identified and corrected, avoiding delays and more costly fixes down the line. This approach will also help to open fluid communication channels between QA engineers and other stakeholders (developers, designers, project managers, etc.).
3. Choose the right test framework...
There are a wide range of QA tests that need to be carried out during the software development life cycle, and will likely involve a mix of automated and manual testing. Automated testing can save money and time, especially on large projects that involve many repetitive procedures. This is especially useful for things like regression testing (making sure that changes or updates to the software haven’t affected the functionality of existing features). Specialist automation QA engineers will need strong coding skills to build an effective testing framework that fits the project’s specific requirements. Manual QA engineers will typically focus more on test execution than planning. Though more time consuming and prone to human error, manual testing increases flexibility and allows for a ‘real-life’ assessment of the product. Part of the skill set of a senior QA engineer is knowing which balance of automated and manual testing is right for a specific project. And once you have a testing method that you think is robust, start testing that.
..But keep an open mind
A good QA engineer will remain curious when testing software, prepared to take unpredictable turns, and stay open to the unexpected. They will constantly be asking how end-users might engage with a product, and what defects they might stumble upon when doing so. When usability testing - making sure software is accessible, easy to understand, and engaging - QA engineers need to be able to freely explore the program to search for bugs and identify deficiencies in the overall experience. They can also conduct scenario testing based on predicting the (sometimes irrational) behavior of end-users - some will always click where they’re not supposed to, so it’s good to know what will happen when they do. At all times, as a QA engineer, you should maintain a ‘user-centered focus’, getting into the mind of the target audience and noting where the user experience (UX) could be improved. After this round of creative testing, you can then provide detailed, qualitative feedback that will help in the design of future products.
5. Build quality bug reports...
Bug reports are a QA engineer’s bread and butter, but that doesn’t mean you can let standards slip. Properly documenting and reporting a bug is just as important as finding it in the first place - the better the bug report, the greater chance of a quick and reliable fix. Ideally, you want to give developers clear and succinct information about the problem so they can reproduce it and start fixing it without having to come back to you with further questions (though that might be unavoidable in some cases). Details are obviously important but resist the urge to wax lyrical about your discovery, no matter how proud you are of it. A good report will try to answer the following questions in a simple, accessible format: where does the problem occur? What is it, exactly? How can it be reproduced? What’s causing it? 
...And know how to deliver them
The hard data in the bug report is essential, but the way in which it is presented is also key to getting the problem fixed swiftly. Developers may get defensive or even offended if a report sounds too harsh or accusatory, and that increases the chance that the problem will not be dealt with properly. Remember, it’s not about blaming anyone for coding errors but working together to deliver a great product for end-users. Making developers feel comfortable that your bug reports are neutral and objective is a key part of the QA process; accepting that not every bug you discover will be worth fixing is too. This is why good QA engineers should always be honing their diplomatic and communication skills.
7. Develop good relationships (with devs)
The best way to ensure a project runs smoothly and delivers a great end-product is for QA engineers and developers to develop positive working relationships built on mutual respect and trust. Not only will this reduce the likelihood of communication mishaps, but over time it should boost the performance of both parties. For example, by working closely with developers the QA engineer will better understand the thinking behind the code, and be more aware of the ‘risk areas’ where bugs may be found. Meanwhile, developers that are more integrated are more likely to be able to spot and fix any glaringly obvious errors in the code without the need for bug reports and replication procedures. Bottom line: you’re batting for the same side, so a good QA-developer relationship will ultimately lead to better outcomes.
8. Learn to prioritize (for the end-user)
Bugs are inevitable. Sometimes, they will affect basic functionality and have to be fixed urgently. The login function is no longer working? Get on it! But on some occasions, the bugs might be considered manageable, especially if delays to shipping would be more costly. Maybe the user interface (UI) needs to be tweaked to make it more engaging, or you spot some typos - would these be better added to the list of tasks to complete before the next update is released? Your job as a QA engineer will be to know what fixes to prioritize to maximize the user benefit and what to log as a task for next time. Of course, to do this effectively, you’ll need a well-documented bug history or database for the project (see above).
9. And then keep learning
Each project brings new challenges, and each of these challenges can be turned into useful knowledge for the future. Never stop reading, ask for feedback, sign up for training courses, attend conferences, arrange meetups with colleagues. All of these things will help you perfect your craft. 
 
Got any more ‘must do’ tips for QA engineers? Let us know!