How to write great QA documentation for your mobile app

Quality assurance (QA) is an essential part of the development life cycle of an app, as it ensures the product meets the desired standards and requirements.

One part of the QA process is writing documentation—a set of written records that provide detailed information about the software quality, testing activities, and methods, among other things.

These documents can help ensure the testing phase of development runs smoothly and consistently, affecting the quality of the finished product as a result.

To help you understand what makes great QA documentation, in this article, we’ll guide you through the process of creating these documents.

Design a test plan

The first step in writing detailed QA documentation is to write a document outlining all the plans surrounding the testing phase of development.

This document is called a test plan, and a well-written one can set the stage for the entire testing process, outlining the goals, responsibilities, and expectations of everyone involved in the software testing life cycle (STLC).

Before committing to any testing procedures, testers and other professionals need to have a clear understanding of what is required from them—a sort of blueprint for the actions that need to be taken.

Therefore, a test plan has numerous components that cover these areas:

The test plan includes detailed information about what needs to be done, how and when it should be done, and who is responsible for doing it—highlighting all the testing efforts that need to be undertaken.

It is a flexible document that can be changed according to the needs of the project but should always give comprehensive information about each of the attributes shown above.

For detailed information about each of them, you can check out this article.

Clearly, there are a lot of attributes to keep in mind, so following a helpful guideline when writing out the test plan is a good way to make this process easier.

A step-by-step guideline such as the one above can help test managers be less likely to miss important aspects when designing the test plan.

It can help them create the overall strategy and the objectives of the testing phase while taking into account the product and its value.

While they do this, they can focus on specifics such as the deadlines, hardware and software environment where the testing will take place, and what needs to be delivered before, during and after testing.

Overall, the test plan is an integral part of QA documentation, as it’s the foundation of the entire QA process.

Without an effective plan, QA teams and testers won’t have a clear understanding of what they need to do, leading to possible mistakes and delays.

Prepare a test progress report

The next essential part of great QA documentation is the test progress report.

This document has all the necessary information outlining the conducted testing activities and their results and is produced regularly during the testing phase of development to monitor this phase’s progress.

Progress reports are created to answer questions such as:

As you can notice, these questions concern the project as a whole, not only the testing efforts—this is because the progress of the testing phase directly affects the progress of the entire project.

In the process of answering these questions, a number of different metrics should be collected and reported, usually as quantitative data.

For example, the QA team can capture data about the test cases—the ones that were planned and executed, and the results of the tests—displaying it in a table or chart, like this one:

Number of test cases planned	Number of test cases executed	Number of passed test cases	Number of failed test cases
200	120	110	10

Another metric the QA team can measure in a test progress report is the types of tests that were performed on the app, making sure all the critical tests are conducted before release and that the app is appropriately examined with maximum coverage.

Using this data, your company can keep track of the project effectively—figuring out which areas of testing are covered and which are yet to be completed, the status of the tests, and tracking other testing metrics.

Overall, the test progress report aids in creating a continuous history of the entire project, helping your company keep track of how the project is advancing.

Create a checklist

Although it’s a simple document, a testing checklist in QA documentation is highly useful for the testing process as it can provide a comprehensive list of everything that needs to be tested in a piece of software.

Look at this example of a testing checklist:

Checklist item	Status
Login function	Passed
Face recognition	Failed
Push notifications	Not run
Voice commands	Not run
Search function	Not run

As you can see, the items on this list are the various functionalities of a mobile app that need to be tested, and the status column shows the results of these tests—whether they were successful, unsuccessful, or not yet tested.

In the example above, the testers assessed that a user could successfully log in to the app, so they marked this item as passed on the checklist, while the facial recognition function was not working as intended.

Checklists can have more information than this—for example, info about the results divided by the specific environments where the test was run.

Using these lists, testers can easily keep track of their progress, have a clear way of figuring out what they need to do next, and can avoid testing a specific functionality multiple times by mistake.

If you are considering using a checklist, you can use a pre-existing one as a guide, such as the one provided by SpaceO Technologies, which has 183 checklist points.

It covers an app’s main areas, such as its security, network performance, UX/UI, and compatibility.

Your QA team can use templates like these and create a checklist that covers the specific functionalities of your app.

This provides a straightforward way of tracking the testing process and helping ensure nothing gets overlooked.

Write test cases

Another aspect of great QA documentation is having well-written test cases, as they are important documents used in the process of evaluating an app and its function.

Test cases are instructional documents that testers follow while examining the various parts of a software application.

They are used to document essential pieces of information, such as the steps and expected results of the tests performed on the app.

Written by individuals from the testing or QA teams, test cases are necessary as they serve as detailed, step-by-step guides to testing an app, ensuring all necessary tests are performed while providing a consistent and organized approach to this process.

Good test cases have to be clearly written and include these essential parts:

The title of the test case should clearly indicate the purpose and scope of the test case, making it easier for testers and developers to identify and understand what they are working on quickly.

The description should add to the title and include all relevant information about the scenario being tested while including any precognitions and assumptions that need to be taken into account, such as the device and operating system the test should be run on.

Finally, the test steps need to be clear and easy to follow, so the testers know how to execute the tests and understand what the expected results of following them are.

Using these tips, QA engineers may create test cases like this one:

Additionally, test cases should be written in a way so they can be used repeatedly—writing them in a reusable format can save time and resources by allowing QA and test teams to use the same test cases for multiple projects.

Overall, test cases are a vital component of QA documentation, as well-written test cases help testers by making their work easier and more effective.

Formulate test suites

After the QA team has written the necessary amount of test cases, the next step is to organize them.

This activity is carried out by formulating test suites—a collection of test cases that are organized and grouped together in a logical manner, having all the test cases related to each other in a single place.

Test suites enable testers to quickly and easily identify which tests need to be run and in what order, helping streamline the testing process and ease test management.

Test suites can be made in several different ways by grouping test cases according to:

The first approach to making test suites is grouping tests according to their different types, for example:

• Functional tests
• Performance tests
• Usability tests
• Security tests, etc.

This practice can make it easier for testers to run tests specific to a particular aspect of a mobile application and track the results of these tests separately.

In short, it provides testers with a clear overview of whether the app is doing well in each aspect.

Test suites can be made by grouping cases by execution time as well.

This grouping allows for efficient use of company time and resources by having all quick, medium, and long-running tests grouped separately.

As a result, testers can run faster running tests more frequently during the testing phase, and properly plan when to run longer running tests.

Finally, grouping test cases by app module can allow for targeted testing of specific areas of the application, for example, using a group of test cases to find bugs and issues in the authentication, messaging, or payment and billing modules, to name a few.

In summary, creating test suites by grouping together test cases in various manners provides organization, efficiency, and targeted testing, leading to an overall improved testing process.

Create bug reports

The final type of document we’ll cover in this article is a bug report—a part of QA documentation that provides detailed information about any bugs and defects in the software.

The primary purpose of a bug report is to communicate any encountered issues to your team of developers, so they can work on resolving the problem and improving the performance and quality of the app.

Clearly written, comprehensive bug reports allow developers to learn more about specific bugs, help them understand the issue quickly and effectively, and start working on a fix while keeping track of the bug’s status.

To get the most out of a bug report, it should contain essential information, some of which are:

• A bug title
• Bug priority and severity
• Expected and actual results
• Steps to reproduce the defect

To read more about these sections of a bug report and the other important parts it contains, read our article on the topic.

Writing these reports can be done manually or by using bug-reporting software such as Shake.

Shake is a bug and crash reporting software that collects over 70 different essential pieces of information when a defect in your app occurs and automatically adds these in a generated bug report.

Some of the metrics that are automatically attached are:

Shake records some of these vital pieces of information like the CPU and memory usage when an issue occurs, giving you a detailed insight into the last 60 seconds before a tester submits a report or ticket.

In conclusion, having well-written bug reports using powerful tools such as Shake can help your team manage bugs effectively, ensuring that issues are identified, tracked, and resolved quickly, improving the overall quality of the software.

Conclusion

In this article, we’ve explored the different components of great QA documentation and what should be done to write clear and useful documents of this kind.

Hopefully, you’ve seen the value great QA documentation can have for the entire QA and testing process.

From ensuring that an app is evaluated thoroughly and efficiently by providing a clear roadmap for testing, to helping manage test cases and bugs effectively, writing great documentation is a crucial part of the development lifecycle.

By following the steps outlined in the article, you can help testers and QA specialists write well-made QA documentation, ensuring that these documents provide great value to your team and the organization as a whole.