Lecture
A few years ago, I gave a presentation that I called “O means Assurance”: a general view on Software Quality Assurance (SQA). The presentation addressed a variety of activities needed to ensure quality. At the end of the report, I answered questions from the audience, and I had the following dialogue:
Person from audience (A): I would love to use all that you told us about, but I do not understand how this can be implemented in my QA department.
I: What is your position?
A: QA analyst
I: And what is your responsibility?
A: I am writing test plans and test cases, as well as testing our product
Me: What other QA positions are there in your company?
A: QA manager - he manages the testing process.
I: Eh ... (or something like that)
Then I didn’t have the courage to tell this person what I’ll say now: “In fact, you don’t work in the QA department, your manager doesn’t manage them at all, and in general everything that you do has nothing to do with quality assurance” .
That dialogue confused my interlocutor and the audience as a whole, because the attainment of quality became something completely incomprehensible. All QA specialists I have worked with have always been focused on quality assurance, but often they all held positions that could not achieve this goal.
No, testing is not quality assurance.
In order to explain this, let's go beyond software. In the production process, testing specialists study incoming raw materials or take products directly from the assembly line and check them for compliance with standards. In this and in another case, they check the products for compliance with the documented specifications. Production organizations call this process Quality Control (QC) and, as you will see later, this is a completely different type of activity compared to Quality Assurance.
Quality Control activities are used either in the production process or after it is manufactured to check the appropriate level of quality. It is impossible to carry out the Quality Control of that which does not exist. And after the product is ready, you have only two possible actions: accept it or reject it. You can’t affect the quality in any way; you are only able to render a verdict to the finished product: either accept it or send it back. I once again draw your attention: you cannot influence the quality of the finished product.
The essence of Quality Control can be called the term "reactive", i.e. its task is to check for compliance with the specification after the component or product is ready; and decide how to deal with it. Quality Control does not provide quality, he checks it.
No, Technical Analysis is not Quality Assurance.
Technical analysis is carried out before the release of the product, while testing occurs at the end of the development process. But Technical Analysis performs exactly the same Quality Control function as testing specialists who check parts from an assembly line for compliance with standards. Despite the fact that the product itself is not yet ready, the part, which is part of it, has already been inspected and tested.
Requirements analysis is carried out before the final version of the specification is ready. Architecture analysis is planned when the application architecture is close to its final state. Analysis of the design occurs after the end of the design component. Code analysis is performed after the code for the component has been written. Each of these types of analysis is a stage at which it is necessary to ensure that further work can be continued on the product.
Technical analysis aims to identify defects in work products. It is intended for Quality Control by checking for compliance with standards, accepting a product or sending it for revision. Technical analysis is carried out before the product development process and is an important part of Quality Control.
Returning to the phrase: “you cannot influence the quality of the finished product” the question arises: how does the quality get into the product? The answer is: you have to “inject” it there.
Compared to Quality Control, Quality Assurance activities are “proactive”. Quality Control "looks back" to make sure that the quality meets the established standards. And Quality Assurance is carried out before the product or component has been developed to ensure that the final product will be of the appropriate quality.
Why do I meet so many quality assurance specialists who do not even know what to do to ensure the quality of the product? Because they have never worked in a software development organization that really does this. Even in our days, it is very difficult to find people who are really involved in Quality Assurance.
So, if you were involved in the Software Quality Assurance process, what proactive steps would you take to make sure that the product you created meets the quality specifications requested by the Customer?
Creating a quality management organization begins with the following steps. They are relatively easy to implement and they bring real tangible benefits:
If your organization already follows any of these steps, then congratulations, you have a head start. But to get the maximum benefit, still read on.
Paul Simon will easily sing the song “50 ways to part with his beloved”, but do you really need 50 different ways to name variables? I found that getting a development team to use common templates and standards is much easier than it seems. Each developer has his own favorite way of accomplishing a task, and practically everyone will happily agree to discuss the standards he uses.
Shared templates provide all team members with an important basis for collaboration. When each person performs the task in his own way, you can forget about cooperation. Often, the developer is afraid to ask for help from another person, because he may not agree with his approach. And when there is no cooperation, such differences in approaches may impede common understanding and the accumulation of knowledge and experience.
Quality Control activities (analysis and testing) will bring more benefits and be more productive if the product was made using a common model. Without their use, reviewers and testers will simply try to catch problems wherever the developer’s hand is concerned. Such an unsystematic approach to quality control requires more effort and leads to poor coverage and poor detection of defects.
Shared templates can also help improve technical work. A developer who performs tasks in his own way can easily miss important details or information. When the work is standardized, there are no questions that the work done should include.
Standards should be applied when writing test plans, specifications, user interfaces, documentation, training materials and other products, because A general vision of how a project should be made can help ensure its quality. But along with the standards, it is necessary to determine the situations of their use and develop guidelines for adapting the standards to the needs of the organization, if necessary. Any standard you adopt should help you do your job as best you can and should not tie your hands.
Note that the title does not say that you need to use standards or processes. This is because each of us already use any established processes for everyday tasks. Although you probably already have any established procedures, you should ask yourself:
The first question focuses directly on the quality of the processes themselves. Do they reach their goal? Depending on the goal, you can ask this question: do they provide and stimulate the necessary level of cooperation? Do they contribute to sufficient interaction between the *** developer and customers? Do they support the best practices of technical standards? Do they help to achieve quality goals?
Often, people are not well aware of the processes that they themselves use. For example, processes may interfere with the interaction of people, the improvement of technical skill, or simply not respond to the needs of the team. The person who says “I have never met a process that I would like” most likely used many good processes, but was simply ignorant of them.
However, visible high-quality processes contribute to a smoother flow of things. They stimulate skill improvement, allowing you to flexibly adapt to the unique needs of each project. In other words, they meet the needs of projects.
The second question pays attention to the quality of following the established processes. If you perform your tasks improperly and inconsistently, ignoring agreements, then you will not get any benefit even from good processes. What does the consistent use of quality assurance processes mean? This is when every person clearly knows how to follow them, knows when and how to do it and strictly observes them. Naturally, this behavior is expected from the whole team. “That's how we work here.”
To benefit from the use of embedded standards and processes, you must constantly monitor that everything is done according to an established agreement, and you get exactly the result you planned. All that is not regularly used, sooner or later ceases to exist. This is the law of human behavior.
An integrated software process maturity model (CMMI) implements this through audits (CMMI defines auditing as a Quality Assurance activity, because this model tests processes, not a product). When using agile techniques (extreme programming, SCRAM), an instructor is hired for this purpose. It doesn't matter how the check itself happens and how you call it - all this brings only qualitative benefits.
If you encounter a situation where an accepted standard or process is ignored, you need to find out why this is happening, because the reasons may be completely different. For example:
Every violation of a standard or process is an opportunity to study and improve it to meet the needs of the team.
You can call it “bug fixes,” “post-program,” or whatever you like — but this is one of the most powerful tools to proactively improve the quality of your work. A retrospective is a separately allocated period of time, in order to turn our eyes to the work done, to study the experience gained and ask ourselves the following questions: "What was good and how to do the same in the future?" and "What was wrong and how can this be avoided?"
Despite the fact that retrospectives are among the best practices, I found that they are used extremely rarely. The two main reasons for this are: “It’s hard to gather all those *** in a retrospective workshop” and “We did it once, but it didn’t do any good.”
The first reason arises from the fact that workshops on retrospective occur at the end of project development. Most of the team members are already working on other projects, and those who remain are busy releasing the project or supporting it. Adjal techniques solve this problem very simply: you should not do only one retrospective at the end of the project, it is necessary to do retrospectives throughout its length. Benefits:
The second reason for the unpopularity of retrospectives is that it is often possible to collect a lot of interesting and useful information, but there is no way to use the data in practice in future projects. (This is discussed in the chapter “Apply what you have learned”).
Defect information is just a gold mine. These are records of quality failures, which means a list of opportunities for improving quality on your future projects. If you are not documenting defects in your projects, then now is the time to start doing it. If you collect some information about defects (for example, after release or only on large projects), then you may want to improve this process.
Defect information, which may be useful for improving quality, includes the following questions:
When you analyze information about defects, then look for those defects that are detected regularly, and those costs for the elimination of which are high. It is precisely such defects that should be avoided in the future (or at least eliminated at an earlier stage of development), such tactics are guaranteed to help improve quality.
Most of the Quality Assurance activities I have mentioned will provide you with an incredible amount of information about your ability to improve the quality of the product you create. But this information alone does not guarantee you the desired quality. You must put into practice all that you have learned in a special way. For example, if your design development process is not effective for use on certain types of projects, then you should develop an alternative process and use it on all future projects of this type.
Regularly (annually, monthly, daily) consider new ways to improve your standards, processes and methods and make the necessary adjustments. Plan for this special time and assign responsible people, otherwise this type of activity simply will not make sense.
In the end, at the beginning of the development of a new project, just turn around and learn from previous projects. Review the Lessons Learned Knowledge Base (LessonsLearned) and Defect History, and determine what needs to be improved based on the “lessons” from past projects. What actions can be taken this time to ensure better product quality than what was achieved before? Moreover, this should be done at the start of each new project, otherwise it will be missed under the pressure of the start of new projects.
If your company implements something of what I have said, then you are already on the way to an organization that is truly aware of the importance of quality in the software development process. Highlight such activities in your company and constantly improve them to benefit.
If your organization is still not involved in the quality assurance process, then you have a great opportunity to improve the situation, based on the experience of your past projects. But before you start getting benefits, you must realize that the path to good quality implies some costs to your company. But the choice of a person or a group of people who will be responsible for ensuring quality, and the delegation of authority to carry out the actions described by me above, fully justifies these costs.
Quality assurance is a learning process: learning what works wrong and how to fix it; studying what works correctly and under what circumstances, as well as how to do your job better with each new project.
Any organization involved in the Quality Assurance process is constantly being trained. The very first step is to make Quality Assurance an integral part of product development. And then “O” will really be for you the beginning of the word “Provision”.
Comments
To leave a comment
Quality Assurance
Terms: Quality Assurance