Home
Blog
QA documentation: what and when needed

Quality Assurance

Jun 29, 2023 12 min read

Volodymyr Klymenko

CEO, Senior QA

QA documentation: what and when needed

QA documentation is a set of documents created before and during testing. Mistakes made by people or unpredictable interaction of code elements can lead to defects at any stage of software development. The impact of these flaws can vary from minor to catastrophic. The QA process allows detecting and reporting defects, reduces risk, and improves product quality.

Considering the complexity of modern IT products, it is challenging to imagine a situation where the development process takes place without any testing.

In most cases, we must deal with tight deadlines, varying team abilities, and changing product specifications.

In these situations, having accurate QA documentation is crucial. We have gathered and organized information about creating testing documentation, which we are happy to share. This guide will be helpful for newcomers in the field of QA or managers who aim to understand when and what test documentation is needed to organize quality assurance processes.

What Is QA Documentation ?

QA documentation refers to a set of documents that record the testing process. It assists in verifying that the software satisfies the intended quality criteria and that any problems are promptly detected and resolved. QA documentation includes various documents such as test plans, test cases, test results, defect and bug reports, and other relevant information.

QA testing documentation is crucial in the testing process. It also helps assess the team's efficiency, comparing planned progress in the test plan with the actual progress.

Different types of QA documentation serve a specific purpose in the testing process. Test plans are comprehensive documents that outline the testing strategy, scope, and objectives. Test cases provide step-by-step instructions on how to test a specific software feature or functionality. Bug reports document issues. You can create most documents in any format. The company or team establishes the standard of documentation. Let's dive deep into QA documentation.

Types of QA Documentation and Their Purpose

QA documentation encompasses various documents created and maintained throughout the software testing and quality assurance processes. Each type of documentation has a purpose and enhances the efficiency of QA tasks. Usually, these are the following types of test documents:

Test Strategy
High-Level test plan
Low-Level test plan
Test Case
Checklist
Test Suite
Test Coverage
Test Run
Bug report

To organize, maintain and effectively reuse those documents, it’s recommended to use specialized resources (own or third-party):

Test management system
Task (bug) management system

Let's delve into the details.

Test Strategy

A Test Strategy is a high-level document that guides the testing team and stakeholders on testing activities throughout the software development lifecycle. The Test Strategy ensures the application meets the requirements and delivers a high-quality user experience.

So, it is a list of necessary testing types, desired or available tools, quality criteria, and the criteria for starting and ending testing. The Test Strategy is typically created during the early stages of the project.

Amid the debate over who should determine the testing strategy, one thing is sure: involving a project manager (product owner) can ensure higher quality. Therefore, consider the test strategy before creating a more formal and comprehensive test plan.

Test Plan

A test plan is a step-by-step guide that outlines how to test something, like software or a system. It includes details on what needs to be tested, how it will be tested, and the resources required. The test plan helps ensure that everything is tested thoroughly and helps identify any issues or problems before the final product is released. Typically, high-level and specific-level test plans are used on projects. Having both types of test plans for the project is recommended. You can familiarize yourself with our articles on how to write a test plan in software testing and a typical software test plan for an in-depth understanding.

High-Level Test Plan

A high-level test plan is created based on the testing strategy, but it provides a more detailed and project-specific approach. It expands upon the information in the testing strategy and includes specific details, deadlines, and resources required for the project. The high-level test plan outlines the objectives of the testing effort, identifies the features or functionalities that need to be tested, and defines the testing techniques and approaches to be used. By creating a high-level test plan, the team can effectively plan and execute testing activities, ensuring thorough testing coverage and early identification of issues or problems before the final product is released.

For more detailed information, click on the link.

Low-Level Test Plan

This document contains all test cases arranged logically to align with user behavior. For example, the first logical set of cases would involve creating a user account, followed by cases that include actions and interactions with the application. Testing teams commonly create separate Regression, Smoke, and API testing plans.

Main functional test plan (Smoke test plan)

Preconditions: Application is opened.

TC001: User Registration

Test Steps

1. Click the “Registration” button

2. Enter valid user data (name, email, password)

3. Click on the "Register" button

Expected result

The registration page is displayed

Entered data is shown in name, email, and password inputs. Inputs are displayed with a green frame

The creation of the user account is successful

TC002: User Login

1. Click on the "Login" button

2. Enter valid credentials (email, password)

3. Click on the "Login" button below the login form

The login page is displayed

The entered data are displayed in the fields. Fields are displayed with green frames

The user is logged in and redirected to the home page

TC003: Create New Post

1. Log in to the application

2. Click on the "Create Post" button

3. Enter post details (title, content) and click the “Post” button

The user is successfully logged in

Create post page is displayed

Post is successfully created and displayed on the home page

TC004: Edit Profile

1. Log in to the application

2. Click the user profile icon

3. Click the "Edit Profile" button

4. Modify user details (name, email, bio) and click “Save” button

The user is successfully logged in

The user profile page is displayed

The edit profile form is displayed

User details are successfully updated

TC005: Delete Account

1. Log in to the application

2. Click the account settings icon

3. Click on the "Delete Account" button

4. Confirm the account deletion

The user is successfully logged in

The account settings page is displayed

A confirmation prompt for account deletion is displayed

The user account is permanently deleted

This table provides an example of a Smoke test plan. The test plan includes positive test cases for various functionalities such as User Registration, User Login, Create New Post, Edit Profile, and Delete Account. Each test case outlines the necessary test steps and the expected results for each step, ensuring the successful execution and validation of the corresponding functionality.

Test Case

The test case is a QA documentation example. It is a detailed description of a specific scenario or condition that defines the steps to be executed, the data to be used, and the expected results for testing a particular aspect of an application or system.

Test cases are crucial in software testing, as they help ensure the software functions correctly and meets the specified requirements.

Here is an example of a test case from the previous test plan. It also may include test data, preconditions, and postconditions that verify requirements.

TC001: User Registration

Test Steps

1. Click the “Registration” button

2. Enter valid user data (name, email, password)

Click on the "Register" button

Expected result

The registration page is displayed

Entered data is shown in name, email, and password inputs. Inputs are displayed with a green frame

The creation of the user account is successful

Writing and using test cases have a significant impact on business success. It results in happier clients, increased customer loyalty, reduced customer service expenses, and improved product reliability. As a result, the company's reputation and brand image are greatly enhanced. You can also read our article on how to write a test case in software testing.

Checklist

The checklist can be a part of the Test Plan or a separate document. It is a specific list of items to be verified. It helps in planning particular test suites or some application parts checking. A checklist is created in a flexible format when there is a need for quick testing planning. A checklist serves as a tool to ensure all required steps or items are completed or considered.

It's essential to regularly update the status of a checklist to reflect the progress and ensure that we complete all necessary steps. Due to its simplicity in implementation, a checklist can be used for quick testing and as a reminder for essential test activities.

Here’s an example of the checklist created from the test suite above:

User Registration

User Login

Create New Post

Edit Profile

Delete Account

The user should be able to create an account

The user should be able to log in to his account

The user should be able to create and save a new post

The user should be able to edit his Profile and save changes

The user should be able to delete his account

Test Suite

A test suite typically includes specific instructions or objectives for each set of test cases, along with details about the system configuration employed during the testing process. Test cases may consist of prerequisite states or steps and descriptions of the following tests. A test suite is a collection or container of many related test cases. Grouping your test cases into adequately named suites makes it easier to manage them. You can group tests into suites according to several criteria:

by type of test (e.g., integration tests vs. unit tests);
by execution time (e.g., slow vs. medium vs. fast running tests);
finally, by modules or areas in the application.

What a test suite looks like in practice will depend on the type of testing. A test suite can be as simple as a Word document folder for manual, scripted testing.

Test Coverage (e.g., matrix/table)

The Test Coverage measures the extent to which the system has undergone testing. It provides visibility into which tests cover system areas and which areas still require test documentation. Matrices, tables, or other visualizations can represent it to depict the coverage status. To calculate test coverage, you can use the following simple steps:

Step 1: Count all the lines of code in your program.

Step 2: Find out how many lines of code are covered by your current test cases.

Now, divide the number of covered lines (Y) by the total lines of code (X) and multiply the result by 100 to get your test coverage percentage. For instance:

If you have 500 lines of code in a system component and your current test cases cover 50 lines, your test coverage is 10%.

Test coverage helps us keep track of the features we need to test and the tests we have.

Test Run

During a test run, testers execute test scenarios or cases, record the results, and identify and document errors or discrepancies. It allows the development team to address the identified issues and improve the quality of the software product before its release.

Here is an example of a Test report based on a test case example.

Test Case Name

Launch URL and login

Test Case ID

BS_01

Test Step

Description

Go to URL https://www.browserstack

Enter username password

Click on login button

Test Data

Username: Test Password: XYZ

Expected Result

Page displays

System accepts username and password

Actual Result

Page displays

Status

Passed

Failed

Blocked

The status of a whole test case or its separate steps can vary depending on the context and purpose, but some common statuses include:

Passed
Failed
Blocked
In progress
Skipped
Retest
Not run

Test run results are usually summarized in a test run report, which shows the statistics that allow project management to evaluate the quality level of the whole product or some parts before releasing it.

Bug Report

A Bug report is a technical document that provides a complete description of a bug, including information about the actual error (short description, severity, priority, etc.) and the conditions under which it occurred. In addition, the bug report should contain consistent terminology that describes the elements of the user interface and events that trigger the bug.

Let's have a look at an example of a bug report. (Read more about how to create a bug report)

Name (short description): The text field has a "NUMLOCK" value in the "Blood Product Number" control after pressing the "NUMLOCK" key

Status: Ready for QA

Project: Desktop

Affects versions: 1.0.5

Fix versions: 1.0.5

Priority: Medium

Assignee: Deepanshu Vashist

Reporter: Denis Terpylo

Description

Steps to reproduce:

Login
Create a new patient in DCR mode
Open RESUS on CDS Panel
Switch to Intake tab
Set “Whole Blood (WB)“ into “IV Fluid“ filed
Click on the “Blood Product Number“ field
Press the “NUMLOCK“ button on the keyboard
Take a look at the “Blood Product Number“ field value

Actual result: The text field has a "NUMLOCK" value in "Blood Product Number" field after pressing the "NUMLOCK" key

Expected result: The field value is clear

By reporting even seemingly minor bugs, you become a vital guardian against the emergence of interconnected complications. Imagine it as tending to a leaking pipe in your home; addressing it can save your abode from being submerged under unforeseen floods.

Test management system

A test management system efficiently creates, organizes, and manages test cases,test runs, and test results. Tools like TestRail, Redmine, and Xray enhance testing processes. As the number of test cases grows, maintenance becomes crucial. These systems provide structured test cases with fields for steps, expected results, and data. Integration with Jira enables collaboration by linking failed tests to bug reports.

This integration streamlines issue tracking and resolution, ensuring prompt fixes. Specifying the Jira ticket number in the failed test case allows easy status checking and retesting. A test management system organizes and controls test cases tracks execution, and integrates with project management tools for efficient bug tracking and retesting.

Task (Bug) management system

A task (bug) management system is a software tool or platform designed to facilitate the organization, search, and resolution of tasks and bugs within a project or organization. It provides a centralized and structured approach to managing tasks and bugs from creation to release. Prevalent task (bug) management systems include Jira, Azure, and Bugzilla.

We can use these systems to provide various features and customization options for project management and bug-tracking needs.

Here's an example table for recording bug information on the functionality of the shopping cart:

Bug ID	Description	Application Version	Status
1.	Login button not functioning	1.2.3	Open
2.	Incorrect data display in dashboard	1.2.3	In Progress
3.	App crashes when clicking on settings	1.2.3	Resolved
4.	Missing validation on input field	1.2.3	Open
5.	UI alignment issue on mobile devices	1.2.3	Closed

A bug report can include a large amount of information. Retaining the title (briefly describing the bug), the environment, preconditions, steps to reproduce, expected and actual results, and attachments (additional files) is often essential. QA can also determine the bug's impact on the system by assigning a severity level. It is crucial to mark this severity level, especially if the bug is a blocker for other functions. In the Comments section of a bug report, QA and developer can discuss bug-related questions (how to reproduce, fix and retest the bug) with the involvement of other specialists (tech leads, PMs, etc.)

Conclusion

QA documentation is vital to successful software development by understanding its importance and utilizing appropriate documentation throughout testing. QA documentation templates are valuable resources for standardizing the creation of test plans, test cases, and bug reports. Using templates saves time and ensures consistency in documenting the testing process. Talk to us to discover how QA documentation can benefit your software development.

Was this article helpful to you?

Comments

There are no comments yet. Be the first one to share your opinion!

Share This Article

Looking for reliable Software Testing company?

Let's make a quality product! Tell us about your project, and we will prepare an individual solution.

FAQ

Why is QA documentation necessary?

QA documentation is crucial because it provides a structured approach to testing, promotes effective communication, and ensures the understanding of product quality throughout the software development process. It serves as a reference for stakeholders and helps to release a high-quality product to the market.

When should test documentation be used?

Test documentation should be utilized at all stages of the software development lifecycle, including requirement analysis, test case creation, test execution, defects reporting, fixes retesting, and pre-release product quality evaluation. It ensures thorough testing and aids in identifying and addressing issues early on.

What should be included in QA documentation?

QA documentation should consist of test cases, test plans, defect reports, and any other relevant documentation specific to the project. It should provide clear instructions, be well-structured, and incorporate examples and visual aids.

How is QA documentation different from technical documentation?

While technical documentation describes how a software system is designed and how to use it, QA documentation focuses on the process of verifying and validating that the software meets its intended purpose and quality standards.

How detailed should my test cases be?

The detail in test cases can vary based on the complexity of the feature being tested and the target audience. However, they should be clear enough that another tester could execute them without ambiguity.