Initially, your website will have to crawl before it could run smoothly, and with crawling webpage comes annoying bugs.
You may have already said these things upon browsing, or trying to repair an error on your own website: “This specific link doesn’t work” “This search is really buggy” “The send button doesn’t function well” “This fix over here broke that over there”
The bottom line is: You’re going to have bugs in your website.
How you properly document and keep track of all of these stubborn bugs can go a long way in actually getting them repaired.
In the beginning, it just may be an Excel sheet and your core team, or (if you’re capable) a collaborative Google Doc. You may start out fine with this low-priced methods, but soon enough, you’ll surely be screaming when you have a 20 page Excel file on your hands that could end up looking something like this.
So, as your business continually grows, your bug squashing may grow wild too, lest you get yourself tied up in so much technical debt.
Luckily, there’s already a lot of sophisticated bug-tracking software out there that can guarantee that you’re squashing the right bugs at the right time, and aren’t wasting any valued hours by trying to get rid of a bug that doesn’t really affect your web guests/users.
There are four major aspects to remember when it comes to identifying which bugs deserve your developers’ precious energy and time to go after, and eventually get to kill them:
1. How many guests are being affected?
Does this only affect a few users or is anyone who sees your website? The more users are affected, the higher priority the bug should be.
2. How damaging to the user experience is this specific bug?
Does this bug only affect a small inconvenience of say, an extra click; or does it influence your customer’s ability to pay their purchase? (Reminder: if it inhibits customers to pay you their bills, then it really is a major and high risk bug) Knowing the difference is extremely crucial to triaging which bugs should you get rid of first.
3. How troublesome would this bug be to squash?
Is it touching a ton of other code that can start domino effects of chasing one fix after another, or is this a fairly isolated issue?
4. Is this specific feature about to get revamped?
Repairing a bug on a feature that’s about to go under some code surgery next month, is like giving a new hip to someone only has a few days to live. It’s only going to be a major waste of resources and your web developers’ valuable time. Always fix a bug when you make the overall feature better.
Think about these things the next time you encounter any annoying bugs on your website! For more information about getting rid of bugs on your site contact us at MLA Web Designs.
