How it really works and what is delivered in a test project
6min. de leitura
In this post, we’ll go into more detail on how it actually works and what gets delivered in a test project.
GX2’s Test Factory works with both projects and software products, regardless of technology, we can guarantee excellent quality in deliveries. And when we say that we work with any technology, it’s not bullshit, we develop automated tests even for more rudimentary environments, such as the AS400 platform (Cobol).
Despite having our own methodology, we were able to adapt our way of working to any development process. We can act within Sprints, in continuous cycle flows, or in a more traditional methodology such as the waterfall model.
First of all, the project needs to be budgeted. For this, we received the functional documentation of the scope to be tested. Based on the documentation, we evolved to estimate the project’s cost and deadline.
Once the project actually starts, we detail the Test Plan, where all test scenarios are raised, as well as the creation of Test Cases. Basically, the Test Plan defines WHAT will be tested and the Test Cases define HOW it will be tested. Both Test Plan documentation and Test Cases are submitted for approval.
As soon as we receive the software to be tested, we start running the tests. For each completed test, the Test Case status is updated and evidence of the executed tests is sent. The idea is that the interaction with the development team is quite large at this stage, as all reported defects must be fixed and retested.
At the end of the test plan execution, we generate a project closing term with all the quality indicators raised during execution.
How we measure project quality |
The project’s Status Report is carried out daily, where the quality metrics are presented, as well as the evolution of the test execution.
Do you want to add more quality in deliveries and avoid unnecessary scares when delivering the software working?
For us, Quality is non-negotiable!