Imagine that you are going to work on a project that has not been touched by the hand of a QA. You could definitely feel like the Christopher Columbus of Quality — taking a deep dive into a new unexplored area.
Most likely there is no documentation and only a few badly described tasks. I will try to share my experience with you and tell you what worked for me in such a scenario.
In my project, there were many reasons for the demand for a QA, mainly a lot of errors in the production environment. There was also a recurring problem with the stability of the test environment. This, in effect, brought frequent doubts about whether it was possible to upload changes to production.
Initial Steps for Understanding the QA-less Project
Strategic Planning of QA Processes
- TO DO — every task which is ready to work on
- IN PROGRESS — tasks that developers are working on
- READY TO TEST — all tasks that are ready to test/retest
- DONE — Tasks that were tested and are ready to deploy to the production environment
Comprehensive Test Plan for Quality Assurance
Here’s an example of my test plan which includes all required levels of testing:
Unit testing
Unit tests, written by developers, play a crucial role in ensuring code quality before deployment. Ideally, 70-80% of the code should be covered with these tests. They help in identifying issues early and provide a safety net for developers by verifying the functionality of individual components. Regularly running unit tests as part of the development workflow can significantly reduce the number of bugs and improve the overall stability of the application.
Integration testing
Integration tests, conducted by backend developers, focus on verifying the interactions between different system components in the test environment. These tests ensure that the integrated modules work together as expected, catching issues that unit tests might miss. Effective integration testing helps in identifying problems related to data flow, module communication, and overall system architecture, thereby ensuring a cohesive and functional system.
Manual testing
Manual testing involves hands-on evaluation of current tasks as soon as they are implemented. Testers manually execute test cases, document results, and log any detected bugs. This approach allows for a more intuitive understanding of the application's functionality and user experience. Tasks should be completed and available for testing at least two days before deployment to allow sufficient time for thorough testing and any necessary fixes.
Test Automation
Automatic tests will focus on critical paths. It’s important to ensure these paths are stable to minimize frequent updates. We chose Cypress.io for test automation due to our use of JavaScript on the front end.
The QA team should document critical paths. Developers need to add unique data-test attributes to all clickable elements, such as data-test="main-menu__item_1". QA can also add selectors if capable. Tests must run before changes are deployed to the test environment.
Feature testing
Feature testing is conducted in two stages: on localhost for the feature branch and in the test environment. Initially, unit and integration tests are performed locally to ensure the new feature works in isolation. Once the feature is deployed to the test environment, functional tests are carried out to validate the feature's performance in a more integrated setting. This two-step process ensures comprehensive verification before the feature is released.
Regression test
Regression testing is essential to ensure that new changes do not adversely affect existing functionalities. This can be done manually by testing critical paths or automatically before launching a new feature. Regular regression testing helps maintain the application's stability and prevents the re-emergence of old bugs, ensuring a consistent and reliable user experience.
User Acceptance Test
User Acceptance Testing is performed by the client in the staging environment. This final phase of testing validates that the developed solution meets the client's requirements and is ready for production. UAT focuses on verifying that the application works as intended from the end-user's perspective, ensuring that all business needs are satisfied before the final release.
Smoke test
Smoke tests are quick checks performed in the production environment post-deployment. These tests verify that the core functionalities of the application are working correctly and that the deployment was successful. Smoke testing acts as a final safeguard, ensuring that the most critical aspects of the application are operational before users interact with the new release.
Introducing a QA’s Value to the Team
Concluding Your QA Implementation Journey
Mirumee guides clients through their digital transformation by providing a wide range of services from design and architecture, through business process automation to machine learning. We tailor services to the needs of organizations as diverse as governments and disruptive innovators on the ‘Forbes 30 Under 30’ list.
Learn more about who we are and what we do. Have a look through the open positions here and become a part of our team.