.png "blog post cover")
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.
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.
Must-have QA tools for software projects
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.
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.
