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’s important to deliver bad news tactfully and diplomatically to cushion the blow. My quality assurance soft skill advice is to use objective language 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.” I find that people are usually more receptive to this type of language because it feels like less of a personal attack.
2. 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 (and we) 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.
3. ALWAYS CONSIDER THE USER EXPERIENCE
Sometimes when we’re working to a deadline and have a lot of QA tasks we get so focused on just the functionality of a feature, we develop tunnel vision. If we can’t find any bugs and the tests pass, then we move the ticket to the “Passed” column and move on to next thing on the list. When this happens, we often miss user experience issues because we “don't see the forest for the trees.” A feature might work as designed, and with no functional defects but it might be really painful and frustrating to use. Usability issues can result in loss of users just as much as a functional defect can. Remember to put yourself in the shoes of the end user when you’re testing, and if a behavior would frustrate you, recommend changing it.