“Our primary aim is to please the client through early and continuous delivery of valuable software,” reads the Agile Manifesto’s first principle.
You’d think that after 20 years, this would be commonplace among agile teams. Do teams, on the other hand, actually understand why they’re building what they’re building? Do they understand the impact their solution will have on the individuals who receive it or the value it will provide to end users?
Many teams, in my experience, still lack that concentration. “We require good quality in our solution,” “Our consumer expects high quality,” and so on. They don’t have a clear idea of what “high quality” implies, except from having no severity 1 or 2 issues and a maximum of 19 severity 3 bugs when moving into production, for example.
In other words, even while the answer is probably not obvious to everyone and you don’t necessarily share the same picture, there is still a need for a debate within the team and with your stakeholders about what quality means.
However, it is never too late to begin that conversation. Here’s how the VOICE model can assist you in achieving your goals.
What is quality?
Quality can be defined in a variety of ways. ISO 25010, for example, provides various different quality criteria depending on whether you’re talking about product quality or quality in use. Gerald Weinberg, on the other hand, offered a fairly straightforward definition of excellence, which was later developed by James Bach and Michael Bolton:
Quality is important to someone, at some point in time.
To gain a sense of what quality is in your situation, start by identifying the people that matter. End users, customers, product owners, marketers, salesmen, and support staff all have an understanding of what value is. However, you must first select the appropriate stakeholders with whom to conduct this conversation.
When you know who they are, you can start talking about what they value, which leads us to the VOICE model.
The VOICE model
The VOICE model is the successor of the goal, question, metric (GQM) paradigm, which was first proposed in Rik Marselis’ book Quality for DevOps Teams. Value, Objectives, Indicators, Confidence, and Experience (VOICE) are acronyms for value, objectives, indicators, confidence, and experience. It explains how to have that crucial conversation with the people who matter about what they expect, how to make the goals measurable as objectives, and how to utilize them as indicators of whether you’re delivering the value the stakeholders anticipate.
The VOICE model’s goal is to instill confidence in the ability to generate the desired business value. Here’s a glance at the model, along with a description of each component:
Source credit: Sogeti
Value: Whatever you’re working on is supposed to benefit someone somewhere. You and your stakeholders should define that value, and it should be evident to you. You will frequently uncover implicit expectations for solutions during the process of defining value, and you will have the option to make them explicit while defining the pursued value.
Objectives: To fully comprehend the goal of the system under development, you must first identify the desired value and then translate it into quantitative objectives.
Indicators: As a group, you’ll need a mechanism to assess if those goals have been accomplished and whether the desired business value has been realized. This can be accomplished by recognizing key indications. The most common method of determining these signs is to test the solution.
Confidence: You can provide information to your stakeholders based on the results of testing and the measurement of indicators, giving them confidence that the solution will deliver the desired value.
Experience: No matter how many indications you have, the only way to determine whether the system provides the desired value is to gain experience by putting it to use. You will receive feedback based on the end users’ practical experience with the system’s operational use, and you may also identify further areas for improvement. The VOICE model will then enter a new cycle, the value improvement loop.
How to use the VOICE model
It’s one thing to have theories and models, but how can you put them into effect with the VOICE model? When you start a new iteration, a new project, a new increment, or a new feature—whatever level best suits your context—the discussion about value should happen as soon as the scope is defined. Not simply the practicality of what the features are expected to do in terms of functionality, but a solid, agreed understanding of the scope and what value it should bring.
“We want to give our sales personnel a more effective way to register orders in the business-to-business side of our organization,” for example, or “We want to give our customers the option of paying for their orders using a credit card,” for example.
The following are some possible aims for the first goal:
- An order must be able to be registered using simply a keyboard (which is more effective).
- For all fields in the order window, validation rules must be set up.
The second goal is as follows:
- It must be possible to pay with Visa, Mastercard, and American Express credit cards.
- The credit card company’s verification procedure must be included in the payment.
- Credit card payments should not take more than twice as long as other types of payments.
These goals can also serve as a foundation for your quality risk analysis, allowing you to see the quality risk associated with each. Most importantly, now that the objectives have been specified, you can specify the indications that will be used to determine whether the objectives have been met or not.
A couple of indicators-related recommendations:
- Don’t have too many; five to ten should suffice (with a preference for fewer).
- Indicators should never be fixed in stone; review them on a regular basis, perhaps every three months or so, to ensure that you’re on the correct track.
Here are a few examples of indications that could help with communication regarding goal achievement:
Indicators connected to information technology:
- Test pass/fail ratio (structure the test so that the objectives may be deduced from it; for example, a test suite for the first goal’s validation rules and another for navigation. Consider arranging test cases by credit card type for the second purpose.)
- When compared to the quality risk assessed, quality risks have been mitigated (as mentioned, use the objectives as input for your quality risk analysis, making it possible to communicate targeting each of these)
Indicators of a problem:
- The number of anomalies found in the tests, sorted by the objectives
- In comparison to the agreed-upon level, the average time to investigate and fix problems
When you look at the indications above, you’ll notice that they’re not that dissimilar from what you’re used to. However, how you structure the data basis for them is critical for communicating about the status of each aim.
You can now document the results of the indicators as part of the testing and convey them to your stakeholders so that they can decide whether they have trust in the solution and are ready to put it into production.
Instead of employing a standard set of measurements and metrics that you reuse from project to project, this technique creates a thread between your stakeholders’ goals and values to the indicators you use to evaluate the solution generated, and you can communicate with them based on those goals/values.
Use the VOICE model to take a value-driven approach to IT delivery, ensuring that what your stakeholders really need is at the center of the team’s focus throughout the lifecycle.
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html