No, testing – it does not ensure quality
To explain this, let’s go beyond software. In the manufacturing process testers examine incoming raw materials or take the products directly from the assembly line and test its compliance with standards. And in both cases, they test products for compliance to documented specifications. Industrial organizations call this process the quality control (QC) and, as you will see later, it’s a totally different kind of activity in comparison with Software Quality Assurance
Types of Quality Control are used either in the production process or after it was made to verify the appropriate level of quality. Unable to control the quality of what is not there. And once the product is ready, you have only two possible actions: accept it or reject it. You already can not possibly affect the quality, you are only able to reach a verdict of finished product: either accept it or send back. Once again I draw your attention: you can not affect the quality of the finished product.
The essence of quality control can be called the term "reactive", ie Its mission – to check for compliance with specification, after the component or product is ready, and decide how to use it to do. Quality control does not ensure quality, he checks it.
No technical analysis – it does not Quality Assurance.
Technical analysis is carried out before the release of the product, while the testing takes place at the end of the development process. But technical analysis does absolutely the same quality control function, and that experts in testing, inspection of parts with assembly-line standards compliance. Despite the fact that the product is not yet ready, the detail, which is part of it is inspected and tested.
Analysis of claims made before a final version of the specification will be ready. Analysis of the architecture 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 carried out after the code for the component was written. Each of these types of analysis is the stage where you want to make sure that on the product can continue to further work.
Technical analysis aims to identify the defects in work products. It is designed for quality control through inspections for compliance with the standards of the product or send it back 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 can not affect the quality of the finished product" raises the question: how money gets into the product? The answer is: you have it in there "to introduce."
In comparison with quality control, the activities of quality assurance is "proactive." Quality Control "looks back" to make sure that the quality meets the standards. A Quality Assurance is carried out before a product or component has been designed to ensure that the final product will be of appropriate quality.
Why did I meet so many experts on quality assurance, which is not even predstavlyuyat yourself what to do to ensure the quality of the product? This is because they have never worked in an organization to develop software that would really do it. Even today it is very difficult to find people who have actually engaged in quality assurance.
So if you have participated in quality assurance processes, which would be pro-active steps would you have done to make sure that the product conforms to established quality characteristics, which require the Customer?
Creating an organization for quality assurance begins with the following steps. They are relatively easy to implement and they really bring tangible benefits:
Agree on the use of common templates
Determine the sequence of actions
Ensure that all follow the established processes and standards
Use the experience of past projects
Analyze information about defects
Apply what they have learned
If your organization has to be some of these steps, then congratulations, you have a handicap. But to get the maximum benefit, yet keep reading.
Paul Simon easily sing you a song "50 ways to part with his beloved, but if you really need 50 different ways to name variables? I found that a group of developers to make use of common templates and standards are much simpler than it seems. Each developer has their favorite way to perform tasks, and almost every gladly agreed to discuss the standards that it uses.
Common templates provide all team members an important basis for cooperation. When each person performs a task in its own way, cooperation can be forgotten. Often the developer is afraid to ask the help of another person, because he can not agree with his approach. And when there is no cooperation, such differences in approach may prevent a common understanding and build knowledge and experience.
Activities for the Quality Control (analysis and testing) would bring more benefits and be more productive if the product was made using a common model. Without their use of peer reviewers and testers will simply try to catch problems wherever touched the hand of the developer. Such a haphazard approach to quality control requires more effort and results in poor coverage and weak detection of defects.
General patterns can also contribute to improving the technical work. The developer, performing tasks in their own way, can easily miss important details or information. When work is standardized, there is no question that the work done must include in itself.
Standards should apply in writing test plans, specifications, user interfaces, documentation, training materials and other products, because common vision of how the project should be done, can help to ensure its quality. But along with the standards necessary to determine the situation of their use and to develop guidelines to adapt standards to the needs of the organization, if necessary. Any standard that you are taking, should help you to do their job as best as possible and should not bind your hands.
Note the title does not say that you need to use standards or processes. This is because each of us already use any of the established processes for everyday tasks. Although you probably already have some tried and tested procedure, you are required to have ask ourselves:
Do they meet your needs?
How often do you use them in appropriate situations?
The first question draws attention to itself on the quality of the process itself. Do they reach their goal? Depending on the purpose you may ask this question: to provide and whether they stimulate the necessary level of cooperation? Do they contribute to an adequate interaction between the team of developers and customers? Whether they support the best of use of technical standards? Do they help to achieve quality goals?
Often people are not well known processes, which themselves and use it. For example, processes may interfere with the interaction of people, improvement of technical skill or simply do not meet the needs of the team. The man who says "I’ve never met a process that would have been to my liking," probably used a lot of good processes, but was simply ignorant of them.
Nevertheless, the visible quality processes contribute to a smoother flow of things. They stimulate the increase in skill, allowing the flexibility to adapt to the unique needs of each project. In other words, they respond to the needs of projects.
The second question draws attention to the quality of following the established processes. If you are performing their tasks improperly and inconsistently, ignoring the agreement, then no benefit from even a good process you do not get. Which means that the consistent use of quality assurance processes? This is when everyone clearly knows how to follow them, knows when and how to do it, and strictly comply with them. Naturally, such behavior is expected from the whole team. "That’s how we work here"
To benefit from the use of implementation of standards and processes, you have to constantly monitor that everything is done according to the established arrangements, and you get exactly the result which is planned. All that is not regularly used, sooner or later cease to exist. It is the law of human behavior.
Integrated model of process maturity of software (CMMI) implements this with audits (CMMI defines audit as a form of quality assurance, because the model testing process, not a product). When using adzhayl methods (extreme programming, Scrum) for this purpose are hiring an instructor. No matter how the test itself and how you have a call – all this brings only a qualitative advantage.
If you encounter a situation where the accepted standard or process is ignored, it is necessary to find out why this is so because the reasons may be completely different. For example:
Each violation of a standard or a process – it is an opportunity to learn and improve to match the needs of the team.
Use the experience of past projects
You can call it "some errors", "postprogramma" or whatever – but this is one of the most powerful tools for proactively improving the quality of your work. Retrospective – is separately allocated period of time, to turn their eyes on their work, learn from experience and ask yourself the following questions: "What was good and how to do the same in the future?" and "What went wrong and how this can be avoided?"
Despite the fact that retrospectives are the best practices, I discovered that they are used very rarely. Two main reasons for this: "It is difficult to gather the entire team for a seminar on hindsight" and "We once did, but it does not do any good."
The first reason arises from the fact that the workshops retrospect occur at the end of development projects. Most team members are already working on other projects, and those who stayed busy release of the project or its support. Adzhayl techniques solve this problem is very simple: you should not do just one retrospective at the end of the project, you need to do a retrospective on its entire length. Advantages:
The second reason for the unpopularity of retrospectives – very often able to gather a lot of interesting and useful information, but there is no way to use the data obtained in practice in future projects. (This is discussed in the chapter "Use what they have learned").
Information on defects – it’s just a gold mine. This record of failures in quality, and hence – a list of opportunities to improve quality of your future projects. If you do not document the defects in your projects, then now is the time to do it. If you collect some information about defects (eg, after release, or only on large projects), then you might want to improve the process.
Information about defects that may be useful for improving the quality, includes the following questions:
When you analyze the information about defects, then look for those defects that are discovered regularly, and those whose removal costs are high. That’s just such defects and should be avoided in the future (or at least remove them at an earlier stage of development), just such a tactic is guaranteed to improve quality.
Most types of quality assurance activities, of which I spoke, to give you an amazing amount of information about your opportunities to improve the quality of the created product. But this information alone does not guarantee the desired quality. You have a special way to put into practice all the things you’ve learned. For example, if your design process is inefficient for use on certain types of projects, then you need to develop an alternative process and use it on all future projects of this type.
On a regular basis (annually, monthly, daily) to consider new ways to improve your standards, processes and practices and make necessary adjustments. Plan for this special time and assign responsible people, otherwise this type of activity simply does not make sense.
In the end, at the beginning of a new project just turn around and take back lessons learned from previous projects. Browse the knowledge base of experience (LessonsLearned) and a history of defects and determine what needs to be improved based on "lessons learned" from past projects. What action can be taken at this time, to ensure a better quality product than what has been achieved to this point? Moreover, it should be done at the start of each new project, otherwise it will be skipped under the onslaught of new projects.
If your company sells anything from the fact, as I said, if you’re on your way to the organization really is aware of the importance of quality in the software development process. Scroll to such activities in their own company, and continuously improve them for use.
If your organization is still involved in the process of quality assurance, then you have a great opportunity to improve the situation, based on the experience of your past projects. But before you begin receiving benefits, you must realize that the path to good quality involves some cost to your company. But the choice of the person or group of people who will be responsible for quality assurance, and delegation of authority to conduct the activities described by me above, fully justifies these costs.
Quality assurance – a process of learning: learning what does not work and how to fix it, to study what is working correctly, and under what circumstances, and how to do their job better with each new project.
Any organization involved in quality assurance processes are constantly trained. The very first step – do Quality Assurance an integral part of product development. And then "O" will really be for you the beginning of the word "welfare".