In the traditional cycle of software development, it is often assumed that both implementation and testing is done by the developers. Quality assurance is often overlooked and not accounted for when estimating the budget and defining timelines for the product release. What could go wrong, right? Well, quite a lot, actually. Typically after developing and demonstrating the first few features, the development team starts encountering multiple inconsistencies and weird behaviour inside their software application. In some cases, especially when developing a complex platform, the amount of bugs piles up so high that it slows down the development of features themselves as now the developers need to fix the bugs or hack their way around them before they can implement new features. It is usually at this point that the initial timeline starts falling apart, the Product Owner has to spend extra time explaining to the stakeholders that they will see the end result later than expected and the whole thing starts to crumble.
Why can’t developers do all the testing?
As a company that develops custom software, we quickly found out that the “developers will test it all” approach doesn’t work. Development and testing require two different mindsets (creating a new functionality vs evaluating an existing solution) and expecting all developers to fulfil both roles would only increase pressure on them and decrease focus on a given task due to context switching. Additionally, testing requires a fresh pair of eyes that look at a feature from different perspectives. If a developer had to test their own code, they would keep the bias from their understanding of the feature and potentially not discover missing use cases or straight up bugs in their code.
Expecting the client to do the testing on their own wouldn’t do either – we want to present our clients with a working product that they can use, not one where they need to investigate what’s wrong with it.
Therefore, in order to ensure that the final result will be of high quality, we introduced the Quality Assurance Engineer role, QA for short, on our projects – someone whose main focus is maintaining and improving product quality throughout the whole development process.
What does a QA Engineer do exactly and why should I want one on my project?
Primary responsibilities
A QA engineer is the quality safeguard. QA does everything they can to design and deliver a good quality, sustainable and scalable product by working closely with the rest of the team. Their primary responsibilities are as follows:
Defining test cases
When it comes to defining test cases, more does not necessarily mean better. Testing is not deterministic – you don’t know what you are looking for until you come across a bug. As such, you want to make sure that the test coverage of each feature is proportionate to the value it creates for the end product.
Before writing tests, the QA’s job is to map all features of the end product and identify, often with the help of the Product Owner, the so-called critical paths of the system (user flows that have to work correctly all the time). QA can then utilise their time and resources to primarily focus on the critical features and user flows.
Manual testing
This is the QA’s bread and butter. Going through all the defined use cases, verifying that the application behaves the way it should and reporting any discrepancies before the feature is released to the end users.
While this is certainly an important part of the QA role, if all testing was done manually, it would take up most of their working hours. That is why it is strongly recommended to add features that belong to the critical paths of your system to an automated test suite.
Implementing automated test suites
In order to have a scalable application, it is necessary to implement a combination of different sets of tests. Some of these are implemented by the developers (unit tests, integration tests) and some by the QA engineers (end to end tests).
These test suites help catch bugs automatically in both new and already implemented features when introducing a change or enhancement, so that the product does not fall apart as you add more to it.
Further QA engagement
Additionally, QA can engage in several processes to help set up and maintain quality control over a product.
Requirements analysis
During the initial analysis of all requirements, a QA engineer can offer insights into potential user experience problems, identify unhandled use cases and ask the right questions to minimise the risk of designing and implementing a product with unclear functionality expectations.
A part of this process can also be risk analysis, during which QA can help communicate potential problems so that they can be either prevented from happening or the team at least has an easier time dealing with them if they do occur.
Considering test-driven development
In the traditional software development process, code is written first and unit tests are added afterwards. The test driven development approach does this the other way around – first, the test cases for the intended feature are written and subsequently, the code is written to pass these tests.
While unit tests are mainly written by developers, it is important to agree on the approach from the start. As the quality ambassador, QA can help determine whether this approach is suitable for the current project.
For more information about test-driven development, check out a dedicated ngBeer talk by Matěj Chalk. Presentation slides can be found here.
Establishing and maintaining test coverage
One of the ways of measuring the quality of your product is test coverage – i.e. what percentage of a given functionality is covered by tests. Based on what kind of application you are developing and the nature of critical paths in the system, different test coverage might be required for different features in your system.
As a part of the quality control processes, QA can help communicate the test coverage requirements during the initial analysis, so that the time spent defining enough use cases to cover the feature is already included in the initial estimates.
Integrating bugs into agile delivery process
In the traditional development process, discovering any bugs along the way can mean missed milestones and overall increased tension and workload of the development team. However, by adapting the scrum approach here at flowup, we learned that bugs are no longer a problem as they can be integrated into sprints.
Everything you always wanted to know about the way we work with Scrum (and weren’t afraid to ask)
There are countless approaches that allow a team of developers to develop new software. Over the years of operating at FlowUp, we have verified that the Scrum approach, generally the most popular agile method of software development ever, suits us best. We have written the following article to explain to you why we chose Scrum, how we work within it and what benefits it will bring to you, our clients.
15 min. read by
During sprint planning, a part of the sprint capacity is typically reserved for the unexpected, including bug fixes. The QA helps the Product Owner identify the high-priority bugs which are then added into each sprint without affecting the team velocity.
Quality checks in CI/CD pipelines
In order to ensure that changes to the codebase don’t break the currently deployed product and meet the agreed standards, it is useful to have so-called CI/CD pipelines in place. A CI/CD pipeline consists of a series of steps that are run upon adding a new piece of code to the application. Application code is typically validated and tested before a deployment of a new version in the target environment. Pipelines are usually created and managed by the development team.
Among other things, pipelines can include running some of the test suites implemented by the QA to verify that the newly added code still passes the tests written for already existing features.
So does a QA guarantee having 0 bugs in the system?
By mapping the system features and regularly testing them both manually and by implementing automated tests, the QA ensures that the risk of any bugs getting through these checks into the final product (and to the end users) is minimal.
It is important to note though that bugs are a natural part of development. What having a good QA on your team does is provide visibility and control of your bugs. They make sure that any encountered bugs are reported and gradually added into the development interactions without affecting the team velocity and that all the critical features are covered by automated tests ensuring their correct behaviour throughout the development process.
Conclusion
In a team without a QA, any bugs that occur during development go directly into production and affect the experience of the end users. Subsequently, any such undiscovered bugs cause further development costs – undetected bugs, especially those that are related to the core logic of the application, can be difficult to get rid of.
On the other hand, having a dedicated QA on your team that regularly checks the quality of the product and functionality of both new and existing features gives you peace of mind. They also help you keep an overview of all the discovered bugs as well as identify the ones to take care of first. So while a QA does not directly implement new features to your product, their extensive work behind the scenes helps make it all happen.
