It’s a familiar scene for any software development team: after days and weeks of working on a particular functionality of your game-changing software, just as you’re about to move from staging to production (or worse, while live in the production stage), you discover a huge bug in your program.
It’s a real bugger (pun intended). Launch schedules are short-circuited, operational plans are thrown into chaos, and career aspirations are threatened. Why, o why, did this happen?!?
To avoid finding yourself in setbacks of such catastrophic proportions, this article offers you the benefit of learning from the common reasons for missed bugs that have beleaguered many a software developer/manager such as you:
#1 – A bug was found, but was forgotten
Sometimes, too much efficiency can be a problem. Dev teams can be extremely zealous about lodging a ticket for every finding and detection, including non-critical ones. Soon, this log of tickets becomes so long that the real bugs become buried under many months of ticketed non-issues.
The key here is to indicate priority levels of each ticket, and regularly check back for tickets that have not been acted upon, or to even close tickets that have become obsolete.
#2 – A bug was found, but no one said anything
Believe it or not, a tester can actually find a bug but not report it. Why? There can be a number of reasons:
- The tester was so tired lodging an unusually long list of bugs that day, that that last bug was deemed insignificant and therefore ended up being unreported.
- The tester is so intimidated by the lead developer that he is afraid to lodge another ticket on to his plate. In this case, fear has paralysed reasoning.
- The tester was not sure if it was a bug. So, he thought not to ticket it.
To prevent this, proper protocols and guidelines should be established and explained well, especially when dealing with junior testers.
#3 – A bug was hidden by other bugs
In some instances, a bug can be hidden by another bug. For example, Bug 1 can be found in the tablet version of the program, but you don’t find Bug 1 because Bug 2 is preventing your program to run on tablets. In this case, Bug 2 is preventing Bug 1 to be seen because the tester is not even able to get to the level where Bug 1 is.
The key here is to establish a checklist after resolving each bug. In our example, once Bug 2 is fixed, the software testers should restart their tests from the beginning until the end of the program.
#4 – We ran out of time to look for bugs
In terms of industry practice, this is what developers may call a necessary evil. Sometimes, deadlines and targets are set in stone, while unexpected variables may come into play. Finishing tests for certain functions would take longer than what was planned, leaving the remaining tasks with less than necessary time to accomplish.
Granted that it may be impossible to come up with a bug-free program, dev teams can plan better and minimise the bugs that customers may discover later on. Decide on which areas of the software are the biggest priorities and include more leeway in the planning of your calendar.
#5 – We couldn’t see the bug
Sometimes, it would require the rare combination of the OS, browser, screen dimensions, device, time of day, etc. for the bug to surface. And sometimes, it could seem humanly impossible to test every single possible scenario out there. To counter that, take particular note of the most common combinations of user conditions, and be as thorough as possible in those conditions. The latest digital user data for your particular software category would do well to guide you here.
Another scenario is by spending so much time staring at the same code over and over again, sometimes the details get blurred and we miss the bug in the program. Wrong time zones, typos, and the like can easily be missed out in these conditions. Take some time to rest your eyes and brain from time to time.
Apply the 20-20-20 rule to keep your eyes fresh and your mind mentally sharp. For every 20 minutes spent on the screen, take 20 seconds off to gaze at something from 20 feet away. It will reduce eye and mental strain, and help minimise human errors. Take regular breaks too to stretch your legs and back if you’ve been on your chair all day.
#6 – We couldn’t do anything with the bug
Sometimes, we discover the bug and it’s too late. The launch is scheduled for the next day, and your team has no other choice except to go live even with a known bug or two. The typical remedy for that is to just issue updates later on.
The worst thing that can happen is that there are fixes that need to be made, but it will involve too much change, with so little time left. It would almost always come out as expensive as starting from scratch. This happens when we miss out on a few bugs here and there from the start of the development stage. By the time the launch date nears, all of the missed bugs would require a major overhaul of the coding.
To prevent this from happening, software testers and quality assurance (SQA) specialists should be diligent in ticketing every single bug they encounter, and label priority ones appropriately. As in #1 above, make sure also to check back on old tickets if they have been addressed already or not.
#7 – We don’t have enough (or any) people looking for bugs
It’s possible that your software development teams might not have enough software testers or SQAs on board. Or worse, you might not even have one. For example, recent global statistics show that 52% of all digital activity is done on mobile devices (only 44% for desktop). However, 42% of software teams do not have a mobile tester on board, and only 41% have an in-house testing environment in place.
Unfortunately, the global trend shows that budgets for software testing has fallen to 26% of the total software development budget in 2017, as compared to 35% in 2015. But with the growing complexity of software, and emerging tech trends such as the Internet of Things (IoT), the need for software testers is expected to go up.
Is your team built to have the appropriate level of talent and manpower for software testing? If you find your developers and programmers spending significant time waiting for feedback from your testers, there is a chance you might need to revisit your SQA team structure. And if you find yourself always running into bugs that derail your launch schedules, or worse, turn-off potential stakeholders during your demo, you can be sure that you will need to shore up your SQA team.
Kinetic Innovative Staffing has been providing more than 150 Australian companies with professional remote staff, such as software developers and testers, since 2013. Get in touch here if you would like to know more about SQA experts working remotely from the Philippines.
