Blog

If you would like to have a great career in QA, and be seen as a Super Hero in your development team, here are 4 critical mantras to keep in mind at all times:

1. Adopt a neutral, non-judgmental tone... no matter what!

Sometimes it can be tempting to quickly downgrade a developer's mental agility and furiously write something like:

• "Feature was implemented completely wrong."
• "Developer obviously didn't read the spec."

But how you "feel" about the bug and getting on the developer's bad side will reduce open communication with team members. Instead, bug reports should use neutral language and remain non-judgmental.

2. Be explicit and describe how the system should behave

Here's a common example: an issue ticket says "Header on page 1 and page 2 is blue." Developer responds by changing all other page headers to blue. But the tester had assumed the developer knew that they meant the header on page 1 and page 2 should be black, like all the other pages. Assumptions like this one cause unnecessary work for developers and can negatively affect a project's budget. Rather than describe a problem, be sure to explain how the system should behave.

3. Do NOT follow developers' test instructions

Developers will send you comments like this one: "Create 3 terms: apple, banana, mango. The drop-down should display the terms sorted alphabetically."

If you were to follow the developer's test plan to a T, the following issues may be missed:

• Sort order could be defaulting to ascii value instead of alphabetical (found by adding terms with different capitalizations or numerical values, etc.)
• Sort order could be defaulting to order the terms were created instead of alphabetical
• Drop-down menu could not display entire text of much longer terms than "banana"
• Drop-down menu could throw error when odd characters are included in labels (e.g. "apple & banana")

While it's useful to review developers' descriptions of how it "should" work, be sure to formulate your own ideas about how to test!

4. Spend your time where it matters most

Are those 2 pixels left of the column driving you nuts? Have you sent it back already, and now there are 3 pixels? And it comes back again, only this time there is 1 extra pixel?

Meanwhile, you've spent almost half an hour worrying to death about these 2 pixels while main functionalities of the site, such as an e-commerce cart, remain untested. This is obviously a pretty inefficient approach to testing.

Instead, try to organize your day so that mission critical or time sensitive issues are tested first. Some examples might include:

• Very first releases of large features
• Any complex logic situation
• Features that would satisfy an entire Business Requirement in one shot