How does a QA bite into a QA-less project?

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

When I stand before a new project, first of all, I try to gather as much knowledge as possible. I talk with my teammates and read all available tasks and scraps of documentation. If you are more experienced in testing, you can use the exploratory tests method that will give you the feeling of a real user and help you to get to know the key functionalities of the application. In this step, try to find all critical paths that should cover all main scenarios for use of the application, or simply ask your team what they think is critical. All the ways listed above can help you understand the project and prepare for the next stage, flow planning, to support quality control.

Strategic  Planning of QA Processes

When you gather knowledge about the project, please take a look at your project management tool (ex. Jira, Assana, ClickUp, etc.). There is likely some flow previously developed by the rest of your team. Check it out, try to realize if you can improve it and be sure all functionalities were properly tested. For the purpose of this story, I will show you the shortest flow that I think could ensure quality control in the project.

Flow statuses:

  1. TO DO — every task which is ready to work on
  2. IN PROGRESS — tasks that developers are working on
  3. READY TO TEST — all tasks that are ready to test/retest
  4. DONE — Tasks that were tested and are ready to deploy to the production environment

Comprehensive Test Plan for Quality Assurance

The main doc that should be created from your journey through the project is a test plan, which you could show to your teammates. Testing in my project is focused on Safari, Chrome and Firefox browsers on macOS, Windows, iOS, and Android devices. Browsers and devices were agreed upon with the client, including the most commonly used by end-users.

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

The most important thing to do with all the hard work you did previously is to share it with your team. Make sure that all of your teammates understand the upside of quality control and have no doubts about using a QA flow to make your project better.

Concluding Your QA Implementation Journey

Finally, your adventure of exploring a new project ends. Now you can rest and gather strength for an unequal fight against the imperfections of your new, already known project.
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.