All software projects have bugs, it is inherent in their nature. Each individual defect ranges in severity from minor annoyance to critical showstopper. Our focus here is on some of the most common bugs we have encountered. Of course, what is common on one project may not be on another. Developers will tend to follow their habits and generate some of the same sort of bugs from one project to another. We will break these down by category and severity, discuss how to test for these common bugs, and highlight some prevention strategies.

Bug Impact & Severity

In terms of severity, you can categorize in whatever way makes the most sense for your project and your team. Some teams like to add some customized humor and get silly with the naming schemes, and this is a suitable place for that. Some like a complicated layered list, but we like to keep ours simple.

Critical

Critical bugs are the direst, and the most destructive. These can result in the loss of data or personal information, may involve security threats, inability to login, inability to submit or save through a workflow or have financial implications.

High

Examples include missed requirements, glaring UI flaws, functional bugs, and user experience bugs where the workflow is not clear, blocking the user’s progress.

Standard

It is generic and flat – but also noticeably clear. A standard bug serves as the default if no other selection is made. A standard defect is just that – it is a defect that needs to get fixed, no questions asked, just with less priority than a high or critical bug.

Low

Low severity bugs include low-impact edge cases, minor spelling mistakes, and small UI imperfections. Every project has them, and every project has a budget, ensuring that not everything will be fixed. Very few bugs are created at ‘low’ severity.

We use these across our various projects, and the plain approach simplifies assessing a bug’s priority to be fixed. Through Target Process, we have customized Kanban boards that will flag, or visually encode the high & critical severity issues – indicating they are first to be worked on by developers, and first to be tested by QA.

Types of Common Bugs

Confusion between UI and API layers

These can result in incorrect function signatures, including case sensitivity, etc. This leads to broken form submissions and blockers, impeding testing of other system components.

Severity – High to Critical depending on the bug’s symptoms.

Prevention – Automate integration testing of your API layer between front end and back end, helping to guarantee a consistent and clean slate for the UI developers.

Missing or unclear requirements

When you boil them down, these types of issues are really about miscommunication. A business analyst or PM might write up the description of a feature change, but not cover all the nuances or edge cases. Developers may either not notice or attempt to fill in the gaps themselves. As a result, the customer is not getting the exact features they wanted.

Severity: High or Critical. These often have ripple effects across the project, and the customer is not going to get the exact product or experience they paid for – so it is best to remedy this asap!

Prevention: Taking the time to fully document the requirements at the beginning of the cycle will simplify and accelerate both development & testing.

Disconnected flow

When the user is going through a form or wizard but cannot complete the process due to underlying logic errors. These types of common bugs are frequently due to either missed- or misunderstood requirements, and most often result in a blockage of testing.

Severity: High to Critical, as it prevents the user from completing tasks and disrupts workflows.

Prevention: Allow for a solid comprehension across the team of the original story’s requirements and encourage questions for clarification from all team members. Kickoff meetings are an effective way to get communication flowing and invite input from everyone.

Missing translations or error message definitions

Front end engineers often forget to connect the error messages, which results in poor user experience. For instance, instead of seeing a helpful and useful error message like “First and last name fields are required,” the user instead sees: Missing translation ‘serverErrors.user.badInput’ for locale “en-us.” The latter does not help the user complete their task and seeing anything resembling code “gibberish” can sometimes send users into a panic.

Severity: Low to High, depending on the impact to the user and the workflow.

Prevention: Bolstering unit testing seems the appropriate strategy for these types of issues. They are easy enough to mockup, and the testing is simple. Otherwise, these need to be checked as part of a normal QA regression test.

Time zone / date mismatches

It is essential that all integrated systems use the same date format and time zone. Otherwise, transactions will not line up, and you will incur logic errors. These can be especially difficult to nail down. These errors have a way of sneaking through QA if you are not prudent and can cause considerable damage with mismatched data. It should be one of the first steps in creating a project – to determine the common time source & format and ensure the UI & API layers are speaking the same language. Sometimes these are not found until production since lower test environments have already been put through the rigor of testing, whereas production is a fresh pristine environment.

Severity: These types of bugs tend to be critical, having far-reaching effects on various parts of the system, including financial or security concerns.

Prevention: Standardizing on UTC dates should be done early in a new project. Developers should certainly have unit testing around the initialization of dates. Also following Dev Ops procedures and ensuring the creation and teardown of your environments are automated. This way, when the bug is fixed in a testing environment, it will be fixed in the template and propagated to production.

Maxlength issues

These come up often, as they are easy to test for, and if they break, they can affect the end user. A good rule of thumb is always having your client side validate the same length that is used in the database.

Severity: Most of these are benign, but there are oddball cases where users will break the UI because maxlength was not considered. Consider a state field expecting 2 characters, but the user is allowed to enter whatever value they like. Across the site, you can have a long state name overflowing the UI where you are expecting a finite 2 characters.

Prevention: You need to rely on your QA team to test for these and perform the initial evaluation of the risk involved. Alternatively, if you have automated testing, you should be checking the maxlength field attributes.

Strategies to Limit Common Bugs

Catching common bugs early in the development cycle allows us to limit their fallout & damage. As bugs linger in the system, developers are more likely to forget the minutia surrounding the issue, and other developers become more likely to compound the error, unknowingly programming new code from the code containing the bug. Defects are also cheaper to fix when found early in the cycle.

Planning for bugs before the QA cycle is important, so that our test plans are in-line with the desired outcome, and so that you have realistic expectations of the time required to complete the dev & QA cycle. Hopefully, planning will also empower your development team to think about these errors ahead of time.

Other techniques that can help reduce bugs are holding retrospectives after a project or release, to allow everyone to reflect on what went well, and what did not. Through process improvements/standards, you can ensure that your QA team is catching these bugs, and the development team is doing their best to prevent them from even existing.

Final Thoughts

At all steps through the Software Development Lifecycle (SDLC), we take care to catch and fix as many of these issues as possible, but some bugs will get through – it is impossible to catch them all. We test strategically to attempt to catch the most high- and critical- severity issues possible. On each new feature or user story, and through each testing cycle, making sure to test all the ends of the system that have been touched.