The testing workflow
This documentation is a work in progress, and we are looking to improve the testing process. The testing working will describe it below in the order of the steps that should happen.
Understand the requirements and the goal of a feature#
The first step is to understand what we want to achieve with that feature. We will use some tools to help with this that are:
User Story#
Every feature should have at least one User Story scenario. The QA should review all User Stories of a feature to make sure that they make sense, and we will focus on solving the problem.
Acceptance Criteria#
Every feature should have enough Acceptance Criteria Scenarios that should preferably be created by who created the issue and reviewed by the QA, or created by the QA team. These scenarios would help the person test the feature, giving a north to what should validate into the feature.
Plan ahead#
The second step is to create a testing plan on our QAse repo in the respective Project section for the feature. The test case must be created BEFORE actually testing it to avoid some confirmation bias. We will use the test cases while executing the manual tests as well as when automating the tests.
Testing the feature#
After the feature is developed, we will validate and check if the requirements are met and how they will add value to our product.
The issues which are ready to test will be in the In review/QA column on the GH Projects page. After testing, move them to the next column, usually Ready to merge if the tests are already automated; if you need to automate them, add a label called automating-tests and move to the next column after all tests are automated.
For more info about how to do the manual tests, please go to the Manual Test Section
Automating the tests#
Automated tests should cover new features, usually, you will automate the test cases that you created into the Plan Ahead section. Do not allow merging until automated tests cover the feature.
You should do this step after manual testing the issue; please add a label to indicate that the issue is in the automated tests stage, and do not move it to the Ready to merge column before finishing all the automated tests.
For more info about how to do the manual tests, please go to the Automated Test Section
Merging the PR#
You can merge the PR to the development branch after testing and ensure that the PR is working. The Ready to merge column means that the issue is ready to be merged into the main or master branch and that the PR is ready to go for the production environment in the next release.
Finishing it up#
After doing all the steps above, the feature is finally ready to deploy! Please move it to the Ready to merge column if you didn't move it yet, and we are done!