Test documentation for software development projects

Category:
Quality Assurance
Artem Stupko
Head of Front-End Chapter
Human Resources Manager
Business Development Manager
Business Development Manager
Business Development Manager
Business Analyst
Business Analyst
Project Manager
Project Manager
UX/UI Designer
IT Lawyer
Chief Technology Officer
Chief Executive Officer
Head of Back-End Chapter
Head of Mobile Chapter
Marketing Manager
Head of QA Chapter
iOS Developer

The quality of software solutions produced by our development teams serves as the most powerful argument in favour of our professionalism. To ensure that we deliver products that really work without bugs, we apply our best practices of testing and Quality Assurance at the very early stages of the software development process. 

As any other activity in a software development life cycle, testing requires creating an appropriate documentation. It serves as a guide of all testing activities that are performed on the project, improves team performance and contributes to better communication within the team. 

In this blog post we plan to go over all test documents that our QA Engineers create on software development projects. Stay tuned! 

Test scenario 

This type of document is created for each user story on a project. Test scenarios correspond to the story parameters, but are not limited by it.

User Story - a natural language description of one or more features of a software system.

Test scenarios may include:

  • positive and negative user flows;
  • UI elements;
  • compatibility checks. 
Test scenario: the structure of document

Our QA engineers create test scenarios immediately after the user story has been approved and ready for development. The process of creation starts while our engineers are working on the feature programming.  

It includes a test design practice application during which QA engineers interview Business Analysts or Product Owners. That allows us to uncover new situations in the user story and save time required for feature testing in order to prevent unexpected issues.

Smoke suite

This is a “checklist” that includes primary User Scenarios.

User Scenarios - stories that cover core functionalities of the system enough to proceed its use and inform regarding system health and stability. 

Smoke Suite is run manually or automatically after deployment of a large part of the environmental changes. The major goal of Smoke Suite is to provide the most valuable number of tests and diagnoses the system regarding critical issues. That allows us to minimize business risks. 


Ready to bring the quality of your software solution on the next level?
Let's talk! We apply our best practices of QA and testing to prevent time and cost overruns on the projects.

Regression suite

This document consists of Test Scenarios which may cover all system modules. Regression Suite is run manually or automatically. Our QA Engineers update Regression Suite after each sprint to be absolutely sure that newly integrated system changes do not affect the previous functionalities unexpectedly. It allows us to get a clear picture about release candidate version status . 

After the Regression Suite has been passed, the Product Owner can decide whether the candidate release version is ready to be deployed in the production environment.

Regression suite: the structure of document

Demo scenario 

Demo scenarios reflect scenarios which will be performed during the Sprint Demo related to the user stories, tasks, improvements, bug fixes within the sprint. 

Sprint Demo - an activity within a sprint where the completed product backlog items are demonstrated to the stakeholders in terms of functionalities and features. 

Our QA Engineers create Demo Scenarios before a Demo Session. Stakeholders can view detailed Demo Sessions in scope and prepare additional questions for the desired scenarios to be demonstrated.

Demo scenarion: the structure of document

QA metrics 

QA metrics are utilized to identify and gather system failures non-compliance of system requirements discovered during the sprint.

We update QA metrics at the end of every sprint. They provide an overview of the mistakes and errors that considered lessons learned by the development team, including their number, type and severity. 

Our QA Engineers also create charts with graphs of the errors by categorizing them by respective environments under test conditions. This allows clients to visualise trends and comprehend the information submitted  in an easier format, as well as to detect deviations in the development process and be more reactive to avoid future risks.

Axon Development Group
December 30, 2020
Quality Assurance

readers who are obsessed with delivering great customer service.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Expertly curated emails that’ll help you deliver an exceptional customer experience.

Contact with us

Upload file with the file dialog or by dragging and dropping onto the dashed region

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.