BACK
QATesting
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.
Beginning
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.
Planning
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:
- 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
Test plan development
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 and run before deployment from the local environment to the testing environment.
- 70–80 % of code should be covered with unit tests.
Integration testing
- Integration tests are written and run by backend developers and ran in the test environment.
Manual testing
- Manual testing of current tasks as soon as they are implemented.
- Confirmation of the test will be a comment to the task and, if possible, a screenshot confirming the correctness of the action will be added.
- If a bug is detected during testing, this information will appear in the comment and a link to the new task will be added.
- When a bug is fixed, the QA retests it and confirms that the main task is ready to deploy.
- Tasks should be delivered at least two days before the deployment date in order to be able to test them and make any fixes.
Test Automation
Automatic tests will be written for critical paths. Before that, it is worth determining the path stability to avoid having to update them too often. We chose cypress.io as our test automation framework because of using JS on the front end.
- The QA needs to write down critical paths.
- Developers should prepare data-test attributes for all clickable elements on pages, attributes should be unique ex. data-test=”main-menu__item” should have the index of element data-test=”main-menu__item_1". You can also add selectors by yourself if you know how to do it.
- Tests should be run before changes go to the test environment.
Feature testing
- On localhost — feature branch (Unit test, integration test).
- In the test environment — if it’s possible to deploy changes there (functional test).
Regression test
- Manually (critical paths).
- Automatically before launching a feature on the dev.
User Acceptance Test
- UAT tests are performed by the client in the stage environment.
Smoke test
- Production environment after deployment.
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.
Final
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.
