BLOG
This is a test
Testing doesn't need to be a chore. It can be a methodical and well-executed process to minimize issues when releasing to the public.
August 30, 2016
Reading time: 5 min
|
CMS & Custom Development
VP of Consulting, High Monkey
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.Latest Blogs
| Digital Experience Strategy
Welcome to High Monkey's new website!
High Monkey has a brand-new website! See why we redesigned it, how we built it, and what’s new in our smarter, more intuitive digital home.
March 24, 2025
Reading time: 5 min
| Business Process & Collab.
Elevate your productivity with this OneNote Kanban Board strategy
Boost your efficiency with our OneNote Kanban Board strategy. Perfect for anyone looking to streamline their task management and enhance productivity with practical, easy-to-implement tips.
March 23, 2025
Reading time: 7 min
| DIgital Experience Strategy
Discussing Stupid gets a fresh new look for Episode 11
Discover how Discussing Stupid leveled up with a fresh new look in Episode 11—new colors, a refined intro, and a branding update to enhance the experience.
March 18, 2025
Reading time: 5 min
Your success story starts here
Contact us for a free consultation, and let’s work together to build a strategic plan that tackles your challenges and lifts your organization to a new level.