Development Flow – Quality Assurance
There are so many procedures we do in blankontech solutions to maintain the product quality. You might already seen our article on startup execution process where it explain how we maintain product quality by implementing minimum code quality, and in this article we will dive in more details other procedure related with how do we maintain product quality from Quality Assurance side.
If you are implementing scrum methodology you must be familiar with sprint refinement session, please have a look on our separated article that explain scrum in Blankontech. more details.
One of the things about sprint refinement is the Backend, Frontend and QA sessions need to discuss and understand certain story tickets, we will create a test case which will later be used as a guide for unittests in the Backend and Frontend will also be implemented as end-to-end automation testing as well as with manual QA processes.
Once test-cases are ready and based on components defined from sprint refinement, we will start to create end-to-end automation testing using selenium and later this will be added as part of the test pipeline on the CI/CD part.
We have 3 product environments which are development, staging and production and ticket movement will be based on those 3 environment.
- once developers or programmers are done with story ticket and it’s merged to development environment, they will mark this ticket as ready for QA Dev, and we will run manual QA testing on this, if it passed then we will mark this ticket to QA DEV Passed and ask maintainer to move this feature to staging environment otherwise it will be marked as QA Dev Failed and write observation result on ticket’s comment box.
- the same cycle once it’s deployed to staging, maintainer will mark this ticket as ready for QA staging we will pick up this ticket and test on staging environment, if it passed then we marked the ticket as ready for production and ask maintainer to move it to production otherwise we will mark it as QA staging failed and write observation on ticket’s comment box.
- And the last once it’s deployed to production by the maintainer then we will do the last manual QA process on production if it passes then we will close the ticket otherwise we will mark this ticket as QA Production failed and ask to do rollback for this feature.
Why deployment is by feature
Rather than big deployment to production with multiple features included, by doing production deployment by feature it will be easier from project management perspective to keep track of each feature and will be less effort to maintain when rollback required.