You get a bonus - 1 coin for daily activity. Now you have 1 coin

Quality Assurance Concept

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.

Is testing quality assurance?

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.

Is Technical Analysis Quality Assurance?

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.

Then what is Quality Assurance?

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:

  • Agree on the use of common templates.
  • Determine the sequence of actions
  • Make sure everyone follows established processes and standards.
  • Use the experience of past projects
  • Analyze defect information
  • Apply what you have learned

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.

Agree on the use of common templates.

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.

Determine the sequence of actions

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:

  1. Do they meet your needs?
  2. Do you often use them in appropriate situations?

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.”

Make sure everyone follows established standards and processes.

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:

  • The person simply forgot to use any standard or process. Remind him
  • The person simply did not know about the existence of a standard or process or did not know how to use it. Improve communication in a team or conduct training
  • The standard or process is not suitable for this task. Either adapt the process itself, or try to find an alternative way.
  • The standard or process was ineffective or too “cumbersome” for a given situation. Simplify it so that it meets the needs of the project.

Every violation of a standard or process is an opportunity to study and improve it to meet the needs of the team.

Use the experience of past projects

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:

  • Project members are always available because they are still assigned to the project.
  • A monthly seminar on the results of, for example, one phase of the project is much easier to plan and it will take only about an hour (instead of a whole day).
  • All the experience gained and developments are still fresh in memory, and it is unlikely that something will be missed.
  • And most importantly, the lessons learned can be applied to the rest of the project.

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”).

Analyze defect information

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:

  • What was wrong? You need to solve the problem itself, not its symptoms. For example, looping is a symptom, and changing the loop index is a problem.
  • When was the problem created? What kind of action in the development was its source? Was that a problem in the requirements? System design? Code? Testing? (Yes, we create new defects during testing, when we fix old ones).
  • When was the problem identified? Maybe it was not immediately eliminated, but what interests us is how long it existed before we discovered it.
  • How was this problem found? The method of detection can be implemented in a constantly used practice.
  • Could it have been discovered before? Is there any Quality Control process that could reveal it if it were more effective?
  • How much did it cost to fix this problem? This moment is very easy to underestimate. Make sure that you take into account the process of diagnosing the problem and all the work you have to do to eliminate it, including re-design, rewriting code, re-compiling, reworking tests, re-testing, re-release, releasing a patch, generating a report on the defect, report by project status, etc. (Do not forget even the possible costs of fixing a tarnished reputation in the software market)
  • What kind of problem was this? When you have a huge number of defects, their categorization facilitates analysis and training.

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.

Apply what you have learned

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.

We start to provide Quality

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”.

created: 2016-04-02
updated: 2021-03-13
132474



Rating 9 of 10. count vote: 2
Are you satisfied?:



Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Quality Assurance

Terms: Quality Assurance