Quality Assurance for Apps
The perception of quality assurance or QA, one of the less well-known components of a successful app project, usually falls somewhere between “It’s a must” and “Haven’t we already done that?”.
Why quality assurance is so important for apps
Quality assurance plays an important role as early as the development stage. It consists of different tasks in the areas of quality engineering and the actual quality assurance. The first describes the process of defining a high-quality outcome: How do we ensure quality? The second step is the actual implementation of this quality concept in the form of acceptance testing and documentation.
And that’s why QA should not be an annoying burden that comes at the end of the process, but rather an important part of app development. Parts of the tests should take place automatically: they are built into each new version of an app either as unit or integration tests. The developers write routines which define and check the desired outcomes.
During compiling, one method for checking a shopping basket can automatically check whether an empty basket is filled after product X is added. This relieves the burden on human testers and leads to stable releases, as certain errors will not go undetected. The budget for these test routines can be included in the project plan from the start.
Then comes the human element. An app comes to life, it travels the world and is used and needed in the most unlikely of places. A good test should also reflect this – only testing an outdoor navigation app at a desk? Doesn’t sound like a truly comprehensive test. A music app which hasn’t had its sound checked? It shouldn’t need to be tested by customers in app stores.
A good QA allows us to provide our customers with high-quality, stable apps.
Our QA process = Quality Assurance
We use ticket systems such as JIRA to coordinate our app projects. Our tasks are described there in the form of user stories. Our product owners test the function of every ticket after completion and are supported by our QA (if required).
We use the information in the user story – the acceptance criteria – to create a test report with priorities and comments. The test report can therefore be filtered according to importance in order to carry out a useful short test. This is also known as smoke testing – a term that comes from gas and water installations, where smoke was used for the detection of leaks in devices and pipe systems.
This allows us to ensure that basic features are working, such as after an update.
In the test report, we also record the special features of the use cases described above – such as limited internet and the associated limitations to the app experience which occur during the day-to-day life of the user. To perform very detailed testing, our tester can also select lower priorities. When our QA identifies errors, it creates bug tickets. The product owner then decides on the priorities. As a rule, we don’t move on to new features before the old bugs have been fixed.
Approaches for different stages of app development:
DEVELOPMENT OF A NEW APP
We add to the test report step by step or sprint for sprint. Besides the report, we also create documentation for app features.
TAKEOVER OF AN EXISTING APP
For large projects, QA is usually the first step. We determine the current state and connect it with any known user problems. We then test new features and add them to the document.
We use QA and the corresponding tests to ensure that the app works as it should. Our customers know best how the app will be used in future. That’s why we involve them in the testing process, allowing us to deliver the best possible results and uncover potential problems at an early stage. We factor in QA as an important aspect of good apps.