Being the QA (Quality Assurance) guy is fun. I get paid to be critical. I can honestly say that I have a love-hate relationship with most of my co-workers. They hate me for the bugs I find, and they love me for the bugs I find (and the quirky sayings I insert in site filler copy).
All web developers have to test their work, and we can choose to be systematic in our testing, or haphazardly test potential bug breeding grounds. I have learned from experience that approaching QA in the most systematic, organized way possible will save headache for everyone involved in a project, from the coders to the users.
Here are a few tips from my adventures as a QA guy.
1) Plan, plan, plan.
Make a list of all the items in a project that need to be tested, and reference that list for each browser and device used for testing. I have found that a list like this massively helps me to stay on track when I’m testing.
Know your audience; what browsers are most commonly used? Too many times I’ve made the mistake of testing in an entire browser, only to discover that the browser wasn’t included in the contract for compatibility. (facepalm)
I have found it helpful to create a master list with each browser/device needing QA, and the above mentioned list of all items that need to be tested. This gives me the master schedule for QA on a project, and as I complete items and mark them off, I have a feel for exactly where I am on the project at any given point.
2) Have an inquisitive mindset.
This might seem obvious, but being involved in QA means that you need to be inquisitive, and constantly wondering what the user might want to do. Use funky characters in passwords. See if those demo discount codes are actually active. Push the limits of the application you are testing, and try to break stuff :D
3) Manage perfectionism.
Check out this site. When I first started in QA, I documented every single teensy inconsistency between the comps and a project – even down to legacy browsers. This can be frustrating for both the developers and I if these things do not need to be fixed. Now I will say to proceed with great caution here, because every project is different, and there is a very fine balance between impossible, perfectionistic QA and lazy, sloppy QA. But, it is important to determine the “QA level” needs of a project before beginning, so that everyone is on the same page.
4) Use clear communication.
If you are not the one fixing discovered bugs, it is extremely important to make descriptions of the bugs very clear, thorough, and succinct. This means including the browsers, devices, and pages that the bug appears on. It might also be necessary to include an annotated screenshot for additional clarity. It’s not fun to waste time badgering somebody for more information, so make bug documentation easy to understand, and even fun!
5) A miscellaneous tip I thought I’d include is to use multiple, meaningful email addresses during QA. You may be aware of the handy little “+” email trick. Appending a “+” sign and some text after your username (email@example.com) will make most applications think that it is a unique email address, when in fact, anything sent to that address will end up at the vanilla address, firstname.lastname@example.org. With this trick, you can have as many email addresses as you need. I have found that using unique addresses specific to the browser being tested helps to keep logins organized. For example, when testing in Firefox, I’d use the address email@example.com, and when testing in IE9, I’d use firstname.lastname@example.org. Just a little tip to make QA a little easier.
BTW, the above image is a picture of my desk, “The QA Corner”.
If you have any QA tips of your own to share, please do so in the comments below!