The Documentation Roadmap: Navigating the QA Process With Clarity

Every project usually starts with an initial kick-off workshop to define the whole development process. During this phase, our focus, as QA Engineers, is on the QA aspect where we explain the various responsibilities we'll be in charge of. It’s important to mention that there are projects and cases where a QA Engineer won’t be available full-time – this usually leads to us switching focus to the most critical aspects of the project in order to meet quality requirements at a satisfactory level. However, this approach can sometimes result in skipping important phases of the QA process – such as writing documentation. In this blog post, I'll explain why excluding this phase is not recommended, and how writing documentation can benefit both the QA Engineers and the clients.

Why is writing documentation so important?

There are many answers to this question, and I've highlighted the ones that are, in my opinion, the most important. So, without further ado, let’s dive right into the perks of writing and including QA documentation into a project.

1. You’ll understand the product better

Drawing from my experience as a QA Engineer, I can confidently say that we possess a comprehensive knowledge of the product's functionality and behavior. When testing a product, QA Engineers will always put themselves in the shoes of an end user, which will lead to observations from a more critical perspective. It’s the QA Engineer who ultimately decides if a product meets the required quality standard for release. 

Just imagine what would happen if someone gave the green light for a release without knowing the product to its soul. Well, one thing’s for sure; there would be a higher risk of errors and users encountering significant problems faster. 

To avoid this, make sure to provide the QA Engineer with enough time to get familiar with the product, thoroughly review the requirements, and document them in the form of test documentation. 

2. No important cases will be overlooked

You’ve probably heard the Latin phrase Verba volant, scripta manent at least once. If not, here’s the translation: Spoken words fly away, written ones remain. This is exactly why writing test documentation is so important! It’s the same as in regular life – if you don’t write something down, chances are you’re going to forget it. 

To keep this from happening, make sure that the QA Engineer on your project has sufficient time to document test cases. This way, they won’t miss any critical cases during the testing phase later on. 

3. You’ll reduce project costs and defect risks

If I ever decide to develop my own product, there are three things I'd expect from the agency I hired: high quality, low costs, and fast delivery. But here's the twist – achieving high quality requires money and time to properly test the product. I’m aware that some think that anyone can be a software tester or that it doesn’t take much to test a product, but that’s far from the truth. 

To achieve high quality, it’s important to involve a QA Engineer in your project from the very beginning. They’re the ones who will typically review the project's requirements during the initial production phase. They are also the ones who will consider cases that may not be explicitly addressed in user stories, identifying issues that the rest of the team might have overlooked. Why is all of this important? Because this approach can result in cost savings for the client. Sounds good, right? 

The problem appears when a QA Engineer, due to the project’s complexity, doesn’t have enough resources for quality management. As a result, they often have to reduce their workload, which, unfortunately, mostly reflects in their test documentation writing efforts.

Writing test documentation brings many advantages – both to the client and the project team. So if a QA Engineer lacks the necessary time to go through the requirements list, there's a chance that some critical cases might slip through the cracks. When this happens, a bug might go unnoticed until a QA Engineer:

a) starts with testing, or

b) when the app is already live. 

To understand the whole picture, these are all the backward steps the project team would have to take in both of these cases:

1. The client will have to inform the agency that there’s a new bug
2. The client will need to re-hire a project team (if they stopped working on the project)
3. The project team will have to analyze and understand the nature of the bug
4. The project team will need to discuss how to fix the bug
5. Then, the developers will have to fix the bug
6. The QA Engineer will have to make sure that the bug is fixed
7. The QA Engineer will ensure that fixing the bug hasn't led to any side effects on other connected features, verifying that they still meet the desired criteria
8. Developers will have to push changes
9. The client will need to approve the new product version
10. The hotfix will be ready for release

That's 10 steps right there.☝️ If you take into account the time each of these steps requires, you might end up with an unhappy user sooner than you think – and they may even decide not to use your app ever again. Think about it; If a QA Engineer had more time to go over the requirements thoroughly and document these cases, this entire scenario could've been avoided. Even if they detected a bug during the testing phase, it could still lead to a significant loss of both time and financial resources. This is because the team would have to backtrack and fix the issue. Booking a QA Engineer full-time on your project could significantly reduce these risks. 

So next time you’re starting a new project, think of the QA Engineer as an additional team member who’ll prevent uncovered cases from sneaking in and contribute to cost control. 

4. Regression testing will be more detailed and structured

If you're familiar with QA, then you’ve also probably heard of regression testing. If not, continue reading:

Regression testing means testing of a previously tested program, following modification to ensure that defects haven’t been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It’s performed when the software or its environment is changed. - ISTQB

Without proper documentation, there's a chance that the QA Engineer will overlook some cases. This could increase the risk of running into significant challenges at inconvenient times, such as post-release.

5. Better stability and overview of the product status

When building a complex product, there's always a higher risk that something could potentially go wrong. To avoid that, the QA Engineer should document and highlight all critical aspects of the product to ensure they're taken care of before each release. This proactive approach guarantees that, even when there isn't much time for regression testing, vital areas remain protected, enabling a seamless user experience. 

With proper test documentation, it’s much easier to track down the critical aspects of the app and manage quality assurance. Additionally, this approach naturally leads to higher test coverage, which, as you can probably guess, comes with its own set of advantages.

6. You’ll find greater confidence in the product

Quality means doing it right even when no one is looking. -Henry Ford

The work of a QA Engineer tends to be less visible than that of developers or designers. While designers create visible UX/UI design using tools like Figma, developers produce tangible app functionality through coding. For some clients, it might take time to see the concrete benefits of having a QA Engineer on the project.

Let’s face it, it’s human nature to make mistakes from time to time. However, in our development team, a QA Engineer’s job is to spot and catch those mistakes at the earliest stages possible. This typically involves discovering bugs in both the project requirements and the app itself, all the while enhancing its quality and guaranteeing that the entire process works as defined. In the end, this method leads to contented clients and end-users. 

Now, let’s explore a scenario where the QA Engineer is either not in the picture or lacks the necessary time for a thorough QA process. One, possible, outcome is a product with a lot of bugs – and not just minor ones, but major and critical ones as well. To learn more about bug prioritization, read this blog post. The aftermath? A rapid decline in trust, with clients beginning to question the team’s effectiveness. Meanwhile, the team itself grows frustration in light of negative feedback. This dynamic could make the collaboration difficult for both sides and to be completely honest – faced with these issues, the project’s success could be called into question as well. This is why having a QA Engineer on board of your next project is essential: it helps prevent mistrust and foster a connection based on mutual trust. 

The end 

And there you have it! I hope this blog post has shown you the true value of having a QA Engineer who can effectively write comprehensive test documentation. If you're not convinced just yet, my advice is to witness the benefits firsthand when you start your next project. If you have any questions, feel free to reach out directly. I’m here for you. 😊