The Benefits of Understanding the QA Measures in Your Project

How your project as a whole assures the quality of the software is valuable information for improving your testing.

Software is built step by step. Each project and organisation has its own process for building it. Has its own departments and roles involved. In the whole process, testing is only one activity and software testers are only one role that can affect the quality of the software.

This post looks at how to understand the QA-related measures in the development process and how you can benefit from this understanding.

Photo by YUNAN WANG on Unsplash

How to Get an Overview

Where do you start to get a better understanding of all the QA measures that your project and organisation have in place? By talking to lots of different people with different responsibilities and asking them questions.

What helps me to find these people and think about these questions is to take different perspectives.

I think the best way to explain this is to give you some examples.

Release

You can get an overview from the perspective of the release process. What are the phases of a release and what measures to assure quality are taken at each phase?

Here is an example from a project I have worked on:

• First Contact

  • First introduction to the topics through workshops and research

  • First rough estimates to help the business prioritise the next release

• Preparation or Start of the Release

  • Getting a better understanding of the topics

  • Consideration of internal (developers, testing, customer support, sales) and external (users, administrators, operations) perspectives

  • Think about, document and review use cases and requirements

  • Answering open questions and further research

  • Split the topics into smaller tasks

    • Estimate these tasks

    • Ensure they can be completed within a sprint

    • Ensure they deliver business value and are therefore testable

• Development

  • Frequently questioning:

    • Can we complete all the tasks required for a valuable feature?

    • Do we keep delaying important bug fixes or features?

    • Does the priority of the tasks reflect the newly gained knowledge?

    • Do the estimates of the tasks reflect the newly gained knowledge?

    • Is what we are building still valuable?

  • Security testing

  • Load and performance testing

• Finalising

  • Regression testing of features that were not tested but could be affected by the changes

  • Catch up on testing that has not yet been done or considered

  • Review release notes

  • Review customer-facing documentation

  • Discuss the value of quality-related tasks compared to the value of adding more features

Task

Once you have a better understanding of the release process, you can go one layer deeper and get an understanding of individual tasks such as features, improvements or bug fixes.

• Open

  • The description of the issues follows the following criteria:

    • Bug: It is clear how to reproduce it, what the impact is and whether there is a workaround

    • Improvement / Feature: It is clear what the value is and who benefits from it

• In Development

  • The issue is estimated

  • Use cases and requirements are defined

    • Use cases and requirements are clarified with the product owner as necessary

  • The implemented solution is documented within the issue or merge request

  • The testability of the feature is considered

  • Static code analysis

  • Automated unit, integration and end-to-end tests

  • Code reviews

  • Release notes

• In Testing

  • Use a variety of tools appropriate to the context of the task (feature maps, test ideas cheat sheets, personas)

  • Documenting and automating the test setup where appropriate

  • Lightweight test documentation

  • Findings are documented, discussed and follow-up actions defined

• Closed

Roles

The previous two examples focus on the process. A different perspective and understanding can be gained by focusing on the roles.

• Product Managers / Product Owners

  • Documents and reviews business rules, acceptance criteria

  • Contacts the architect to draft an initial technical solution

  • Presents features to developers and testers during the backlog refinement

  • Defines the scope of the release

• User Experience Designers

  • Creates and reviews screen designs

  • Presents screen designs to the product managers, product owners, developers and testers during the backlog refinement

  • Reviews implemented screens

• Developers

  • Do code reviews

  • Writes automated unit and integration tests

  • Runs performance and load tests

  • Presents the implemented features during the sprint review

  • Discusses the contract between the backend and the frontend

• Testers

  • Do regression testing

  • Writes automated end-to-end tests

  • Tests the implemented features

  • Extends the regression test set

• Operations

  • Observes the system with monitoring and metrics

  • Be notified by alerts

• Customer Support

  • Presents customer feedback during the sprint review

How to Benefit

OK, now you know how to get a better understanding of the responsibilities of each person, the steps of the processes and how all of this should contribute to a qualitative better software. But how can you, as a software tester, benefit from this information?

Focus on the Risks

Time, money and people are limited. This means that you can rarely test all the aspects you would like to. So you need to prioritise your testing activities.

You can look for risks that are not covered by what other people have already done, and focus your testing on those risks.

Use the History

A lot happens between the initial idea and the implemented feature. There are a lot of discussions, big and small decisions, and assumptions. What you test is the result of all that.

Understanding the processes and roles provides opportunities to learn more about the history of the feature under test.

In my experience, understanding the considerations and decisions that were made, the alternative solutions dismissed, the unknowns that were discovered and the reasoning behind it all is valuable information. It helps me to prioritise my work, question the features, understand the business better, think about personas and brainstorm test ideas.

Discover Gaps

If you know about the history, you know whether all the phases and steps of a process have been done and whether all the roles have taken the actions for which they are responsible. And if you discover that something has not been done, it is an opportunity to question it. Did someone forget? Was it a deliberate decision, and if so, why? Does it create new risks?

Again, this information will help you to know what to test for and how to prioritise.

Early Preparation and Feedback

Understanding the process will help you to identify opportunities for early feedback. Identify steps or phases where you are not yet involved and where you see a benefit in giving early feedback.

Also, the earlier you learn about something, the earlier you can start preparing for testing. This will allow you to test earlier when the feature is implemented.

Sharing Is Caring

You can document your understanding of the processes and roles with others. I think this is valuable information that people in all roles can benefit from. And it is particularly helpful for people who have just joined the project or organisation.

Drawbacks

Having this understanding of how quality is assured across the process and roles can also have its drawbacks, which I also want to make clear.

Expectations and Reality

When you are new to a project or organisation, most of your information comes from what others have told you and written in documents. But this information needs to stand the test of time.

You know those job descriptions that list all the great opportunities and benefits a company has to offer? The only way to really know if it is true is to join the company and experience it for yourself. Maybe it is all true and you have found a wonderful place to work for. Maybe some of it is not true. And maybe it is not true at all.

Use your critical thinking and try to validate what you have been told and what you have read. Even if you have been working on a project for months or years and have gained some experience. Otherwise, the reality might hit you - hard.

Cognitive Biases

The more you are involved in the whole development process and contribute to the solution, the more biased you become.

Try to learn about cognitive biases and you may be able to identify them.

---

---

I hope this inspires you to create your own version of this tool to suit your context.

Have fun,
Florian

---

11 June 2024: I have added a chapter on the possible drawbacks of the approach described in this post.