Luxe Quality logo
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.

QA documentation: what and when needed
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

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.

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


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

Launch URL and login

Launch URL and login

Test Case ID




Test Step





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

Login button should be clickable, and login should be successful

Actual Result

Page displays

Login can’t be entered

Login is impossible





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.

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

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 IDDescriptionApplication VersionStatus
1.Login button not functioning1.2.3Open
2.Incorrect data display in dashboard1.2.3In Progress
3.App crashes when clicking on settings1.2.3Resolved
4.Missing validation on input field1.2.3Open
5.UI alignment issue on mobile devices1.2.3Closed

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.)


Was this article helpful to you?


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

Log in

Looking for reliable Software Testing company?

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


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.