We Are All Authors for Quality
When we talk about quality of a software, what we’re really talking about are the functional and non-functional aspects of software. These two are deeply intertwined, in that the non-functional side supports the functional side.
Usually, the quality of software is gauged by counting the number and types of bugs during the software development cycle.
We set quality metrics: how many of each type of bug is present in the system at a time, what is the maximum allowed number of bugs, and how quickly we should respond to a reported bug. We draw nice, clear charts showing trends, turnaround time, percentages, attributions. We identify individuals as responsible for the bugs and individuals with responsibility of finding them.
All of this help us to monitor, measure, and control; in order to assure quality, we should be testing and identifying and fixing issues before the software is shipped.
Quality testing is only one stage of the software engineering supply chain. On one end the client supplies the raw material (requirements) and on the other end the supply chain ships out the product (working software).
We all know that the quality of the raw materials has a significant impact on the product. We also know that the way we work that raw material also affects the product.
As a team and organization, we need to be aware that in our line of business, we must ensure that each stage in our product development is of the highest quality.
The only way the test engineers will be able to assure quality is if they are given product that is built to exacting standards that are documented clearly. The development engineers can build high quality products if the specifications are clearly and exactly documented. This is achieved by talking with the client in detail to extract exactly what the client needs.
The business analysts, developers, quality control specialists and the client sit together and go over details of what they want and refine the wants down to the needs.
This is then documented and signed off by the client – this sets the expectation on which this chain will deliver a product. The delivery team will also need to know how this supply chain will ship products so they can monitor, assist, and ensure the highest quality in delivery. This complete supply chain is then monitored to make sure everything is running according to agreed standards, comparing this with solicited feedback from the client.
Quality is the responsibility of every part of this supply chain.
The core principle to achieve quality is to have a clear understanding at each stage of what raw material they are receiving and what product they are shipping, and the only way to achieve this understanding is by clear communication with the aim to understand what the actual need is.
There was a time when software engineering teams relied on huge reams of pages documenting the software requirements specifications. These days the agile software teams are less focused on such large documents, however, they create these documents incrementally, by building a set of User Stories.
These agile teams start with the title of the story and a short requirement describing the outline of the story. The team sits with the client and grooms the story to become very exacting, in effect documenting the specifications. At the end when there are no more requirements, the project has closed and the client has signed off, all these stories together become the software requirement specifications.
User Stories are also a product that are created during the software development supply chain. This is the key document against which the software will be developed, and is also the document against which we will be testing the software.
It is extremely important that this is accurate, and everyone agrees on what the story says.
We have all heard that good stories must answer five questions — who, what, why, when, and where. This applies to User Stories as well. We need to know who is asking for this thing, what this thing is, why is this important to have, when will they need this, and, where (in the product) they want to see this thing.
It is particularly important to identify and understand the who, the why and the when – these three give us insight on who the client is, what is important for them and what bigger plans they have for their business.
Everyone, in the software development supply chain, including the client, is responsible for quality.
Think of this as a guideline when collaborating in a team and in the organization. We are vendors and we are clients, we are all authors of these stories, and we are all responsible for quality.