You are visiting the High Monkey blog archive. Posts prior to 2016 may not meet accessibility standards. Please visit our current blog area at to view accessibility compliant blog posts published since January 1, 2016.

This is a test

Written By: Chad Heinle
Posted: 8/30/2016

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.

Chad's Bio Coming Soon!

More About Virgil

Virgil Carroll is the owner and president of High Monkey – based in Minneapolis Minnesota. Virgil also wears the multiple ‘hats’ of Principle Human Solutions Architect and SharePoint Architect.

Virgil is one of those rare individuals who can dive deep into technical topics while speaking clearly to the business owners of a project and never forgetting that the end user experience has the highest priority. He calls it using both sides of his brain. Virgil is passionate about leveraging technologies ‘out of the box’ as much as possible with a focus on the strategic use of content to create websites that deliver the right content to the right audience on the right device at the right time. Virgil brings high energy, an ironic wit, and a sense of grounded perspective whenever he speaks to an audience. Virgil regularly speaks at conferences and user groups throughout the United States and occasionally in Europe.

Posted: 8/30/2016 12:00:00 AM by Chad Heinle | with 0 comments