How visualization can help improve manual QA process.
This article will cover
Mind map as an alternative to test cases;
How visualization can help you improve your manual QA process;
Usage of checklists;
We don't want to talk about the advantages of automation QA - we already working on a new generation of tools for that (designed and implemented for Flutter developers). It is obvious that the main direction for the QA process should be Automation, but manual QA is still required and actively used, so in this article, we are trying to introduce some ideas on how to improve it today and think of automation tomorrow.
The manual QA is dead long live the manual QA.
Background
Based on our mobile development experience, we found two methodologies that are working for us: Checklists and Mind-maps.
Mobile applications are changing too often, so maintaining the classic test cases is not efficient. They will almost always be outdated.
Checklists, as test documentation, work better, as they are easier to create and use. We prefer to use them for acceptance testing for the new features.
The main idea is to use the same checklist on both sides (QA and Development). What we wanted to improve is to remove ping-pong in the bug fixing process. Periodically, we saw the following picture: the developer fixed an issue and assigned it to the QA, but introduced a new bug in the same feature. As a result, the QA team returned it back to developers with some further comments. The developer fixes a newly introduced problem, sends it back, etc... So it looks like a ping-pong.
When you don't have enough level of automation testing, you may face this problem as well. One of the main reasons, developers tend to skip the full regression testing of changed functionality. The checklist can help here because, as a developer, you must pass all basic testing scenarios listed in the checklist before assigning it to the QA team for verification.
So, we are not talking about classic testing here (developers making changes, QA team testing them) but more about the verification of functionality already tested by the developers. Another benefit of using checklists is increased number of testings performed by the developers. Even if you made (as a developer you may think so) a small change, you must pass all required test scenarios listed in the Checklist.
It is also quite useful for the management because you can keep an eye on the quality of the delivered features and see how the number of ping-pong cases is reduced.
From Checklists to Mind maps
However, manually creating checklists still remained too time-consuming. So the next logical step in optimizing the process was the use of mind maps.
You probably may ask, but what was the original main issue with test-cases.
Mind maps can help visualize it. Here is a mind map template we use to define the basic requirements for testing for each new feature. As you can see, it does not contain specific product requirements (just placeholders), but even without them, basic testing requirements include almost 350 items. You can only imagine how many test-cases must be created (and stay up-to-date) to cover this volume.
So, visualization allows you to save time, reuse common parts between different mind maps (create reusable trees of scenarios). Mind maps are easy to use, but also more descriptive due to the visual format. Such a high degree of expressiveness helps the entire team quickly discuss various aspects of testing and collaborate.
And finally, you can quickly export the branch of the tree as a spreadsheet to create a checklist automatically!
Typically test cases are quite wordy.
While detailed steps are suitable for junior QA engineers, they are not required to be so meticulous for the regular and senior-level QAs. We see it as more beneficial for us to outline all main directions for testing and let the QA team quickly extend what should be tested without spending a lot of time on keeping test-cases documentation up-to-date.
In addition, we saw that QA engineers often faced the problem of tunnel vision, because they always followed the specific steps defined in the documentation of test cases. We want the QA team to stay open-minded and generate more and more ideas about what and how can be tested. So our next goal is to release the recorder of manual QA testing and let the team do it manually only once (during the initial recording) and after that just run them periodically, as automation tests. Want to learn more?
Stay tuned!