Don’t Forget your QA Soft Skills
Communication and teamwork are skills that are vital to effectively meet project goals. When it comes to QA, don’t spend so much time working on your technical skills that you neglect your soft skills.
Remember to be Tactful
As testers, we are often the bearers of bad news. A lot of the time we have to tell the developers that their baby is ugly. When we’re reporting bugs we have to be mindful that a dev may have spent weeks or months working on the feature we’re testing. They’re normally very proud of what they’ve created, and can get understandably defensive about any sort of criticism. It is possible to deliver bad news tactfully, and diplomatically in order to cushion the blow. Objective language can be used when reporting the bug to make the issue more palatable - “This is what I see happening” as opposed to “This is what you’ve done wrong, and this is what I think you should do differently.” People are usually more receptive to this type of language because it feels like less of a personal attack.
Don’t play the Blame Game
It can be stressful when you’re coming up to an important deadline and you come across a high impact bug during your testing. Sometimes it can seem as though a developer has performed absolutely no testing of their own before turning a feature over to QA. It’s important to remember that developers are often under pressure to get features finished as quickly as possible and they don’t always have time to test things as thoroughly as they would like. Blaming the developer for causing the bug is a waste of time and doesn’t help the team to meet project goals.
Similarly when a bug makes it to production – nothing is gained by spending time trying to figure out if it was the fault of the BA with missed requirements, the designer with bad mockups, the developer with buggy code, or another tester who missed it. When a failure happens in production the entire team is responsible for resolving the problem quickly and efficiently, and figuring out how their processes can be improved to reduce the likelihood of a similar failure happening again.
Celebrate the Wins
A big part of our jobs as QA Engineers is to constantly find the flaws in everything. It’s our responsibility to go through things with a fine-tooth comb and report any defect or inconsistency. It’s important to also remember to celebrate the things that are done right. Don’t forget to thank or celebrate a member of your team for a particularly well written requirements document, a really helpful design document, a great quality feature in the application. This attitude can be especially helpful in a retrospective meeting - remember to include items in the “what went right this sprint?” column instead of filling up the “what went wrong this sprint?” column.