This is a test

Testing is usually the dreaded part of most projects. Not because developers are afraid of something being found, but because determining why an issue has cropped up can sometimes be a hassle. Next time you have a test phase, think about the points below before you jump right in.

Start with a blueprint

You can’t really test that well unless you know what the end result is supposed to be. Having an understanding of a website that helps you calculate your tax returns will eliminate bug reports from users confused on why they can’t order a Christmas Story leg lamp. If that sounded confusing to you, let me say it simply: having requirements is a good way to build a site, but it’s also a good way to focus your testing. Our process here at High Monkey is to start with a "Build Book" – a framework that explains how a site is put together and how each piece will work, and it’s a great way to start a test script.

Follow a script

Get a script together for users to follow – steps 1, 2, and 3. Ok, maybe a little more detailed that than, but you get the idea. Having a script (and it’s best if the script can be put together based off of the site requirements) is a good way to repeatedly flush out multiple ways users may interact with a site. Get creative – have testers insert a smiley face into a number field and see what happens. The more variety you can guide testers to, the more likely you are to find bugs before an end user does.

Bugs versus features and enhancements

It’s important to be able to understand the difference between a bug and a feature or enhancement. Sure it would be nice if I could upload a picture of my cat, but if those details are not in the blueprint (aka requirements), then odds are they were not budgeted for and would need to be something added further down the road. Keep a separate list of features your team can focus on after the original product has been launched – it’s always good to have a working list.

The devil’s in the details

One of the biggest peeves a developer is getting a bug report ‘x feature doesn’t work’ with a screenshot of the infamous "Server Error in ‘/’ Application" red and yellow screen. Details with each bug will help developers be able to replicate the bug and troubleshoot the issue. This includes step by step instructions on how to reproduce the bug (which you should already have a good framework for by having a script) as well as screenshots of the process. Some errors (like the one listed above) are generic application errors which do not help anyone in the end. Knowing what was clicked in what order with what values input is the only way to be able to effectively troubleshoot an issue.

Have a filter

If possible, have a central filter for all bug reports – preferably someone with at least some technical knowledge and a good understanding of the requirements. This person is the one who can filter out bugs from features, and can tackle those low-level bugs where a setting here or there just needs to be tweaked. This leaves the developers more time to tackle those heavy-hitters instead of wading through rows and rows of reports.

You will never find it all

Sounds cynical I know, but as creative as you think you are in your script writing, you may never think to load up a form field with the entire first chapter of the Iliad. The reason bugs come in after a site has launched is because end users are the most effective testers of all – they have the biggest variety of browsers on the biggest variety of computers with the biggest variety of browsing habits. A soft launch (launching a site to your entire internal staff or a limited number of external users) is a good way to open up for more feedback before you open up to the public at large. As long as you have a support plan to tackle those issues, it’s ok to remember that these reports will come in as long as you’ve done your due diligence in the testing process ahead of time.