Avoiding Buggy Software: How the PR and QA Process Saves Projects

Nobody Wants a Software Bug

In the world of software development, nothing spells trouble quite like bugs.

From relatively minor glitches to a significant security threat; a poorly timed bug can bring a company to its knees. So, buggy code should be avoided at all times - especially if you’re hiring a team to build something for you.

If that’s the case, why is there so much F£!k*ng buggy software in the world?

It usually comes down to a lack of strict quality control and a misunderstanding of why they occur. Some developers may spot faulty code, but they can overlook how the software actually performs and how adding additional functionality can affect performance.

Imagine you’ve just launched a shiny new app. You’re excited about it. The development team is proud of it. Your users start getting to grips with it and… BAM! The issues begin.

To fix it, you get the development team to make changes - which they check internally and approve. But what the team didn’t realise is that these new changes would break something else in the app. It’s a vicious cycle.

How can you avoid situations that evoke user frustration and even dissatisfaction? That is where pull requests (PR) and quality assurance (QA) come in.

How Developers Can Prevent Software Bugs: Pull Requests

Even the best development team should never have someone write new code and then insert it into an existing codebase (your app/project/site) without first having it checked by peers.

To prevent this, your development team should use pull requests.

What is a Pull Request?

A pull request describes what a change is, what it should do, and some explanation as to why it is required. The reason can vary from being asked to add a function or change by you, the client, or it can be to fix a current issue.

Regardless of the reasoning, a pull request allows a developer to document every line of code they’ve changed - allowing then for a peer review, who can look at it on a line-by-line basis.

Not only does this process allow better testing of changes before they are pushed ‘live’ and implemented into the main code, but it also allows a team to improve the code instead of just fixing it.

In short, one member of the team sends the pull request and the other reviews it. Rather than only ‘approving’ it as an addition to the main code base, you can also make suggestions on the changes. These can range from ‘no, it will break the app’ through to ‘okay, it works, but is it the best way to do it?’

Pull requests aren’t just a safety net to avoid bugs - you can also employ them to improve your app or project in the long run. Choosing a team that doesn’t practice pull requests means opening yourself up to potential unexpected errors, security risks or worse.

But that’s not the end of the story. After the development team approves a change, you should bring in an outside eye to spot issues that a coder may never see - this is Quality Assurance.

The Role of Quality Assurance (QA) in Software Development

QA helps identify problems with a project from a user experience point of view, rather than a technical one. For example, the code itself may be correct when launching a new timer on your app, but only the QA who checks the change will see that the numbers from the timer display are too small for anyone to see them.

Essentially, they see the wood and the trees.

At KOMODO, we engage in a thorough client discovery process and create user stories as part of our development journey. We want to understand what a user is trying to accomplish when using your app or software. A project has acceptance criteria, which is what the coders need in the product. Our QA team will then check the app’s performance against these criteria.

Think of a simple function such as a button in your app. For a coder, the button is pretty straightforward - it must direct a user somewhere else. But for the QA, they must check it against acceptance criteria that goes deeper than just: ‘does this work or not?’

Instead, the button needs to behave correctly, not cause any errors when it presents new information. The QA team must check it doesn’t affect other parts of the app, be accessible on all devices, and fit within a brand’s existing design scheme.

The QA often tests each new code function independently, before checking through the app's performance as a whole. Once this new code snippet has passed the QA process, it's added to the main codebase.

Code Regression in the QA Process

A code regression is where a new addition to the code negatively impacts performance.

During each sprint, our QA process checks for code regressions with a regression run-through. We use 200+ manual tests on the application. These tests focus on maintaining the critical user flows through the app. Finally, we ensure that at the end of every dev sprint that the app still works - how it should. TA-DA!

Pull requests and QA testing help spot issues before we add them to the main codebase. It can identify any additional problems that occur even once the main codebase is running.

How a QA Process Works in Real-time

Imagine you come on board with KOMODO for a project.

We agree on user journeys - with specific stories established such as 'I want X to do Y so I can accomplish Z.'

Developers then build the functions needed to fulfil these stories - and the PR process actioned. Once the development team reviews the changes, the finished code passes to our QA team. They test the finished code against the story (do these changes let the user do Z?) and check for code regressions and bugs from a user's POV.

If everything is correct, the code merges into the main codebase. The best QA process repeats for every code change done within a sprint. If you need a feature launched quickly, a QA can check the code for that feature and merges it into the main code first, rather than waiting until the end of the sprint.

Furthermore, quality assurance carries out processes that developers never even consider.

For example, if a team codes in a log-in functionality, they can use the pull request process to ensure users can enter their details and get into the app.

They do not, however, consider practicalities and user quirks, as a QA does.

A good QA tester would take that log-in process, and test for unknowns such as extremely long names, logging in without any details entered, whether the log-in screen masks a critical button, whether it breaks something else in the app, and so much more.

How to Avoid Buggy Software

At KOMODO, the combination of pull requests and QA testing has led us to create a regression pack, which has been built up throughout various sprints during our 18 years in the business, to test the critical functions of any app. The regression pack lists various functionality asking questions like: ‘This is what should happen, does it?’

The pack allows us to spot issues and then alert you, the product owner, because - beyond best practice - ultimately it’s up to you to decide how critical an issue may be.

For example, a colour displaying incorrectly may seem a minor error to a dev or QA tester, but to a client whose users with colour vision deficiency (CVD), this would be critical and prevent release. Every project is different.

So whether we inherit code or build it from scratch, the PR and QA process helps us spot bugs, elevate them to our team and then to a client. We can prioritise our order of fixes, prevent the release of new versions and control how a project is delivered to users.

Without these processes done on each sprint, each new release/update would be a blind jump into the unknown - resulting in the same kind of buggy as F%&K software that plagues the world now.