Quality Assurance

Software quality assurance (SQA or just QA ) - an activity to assess the quality and ensure compliance with standards and processes (although many believe it is synonymous with testing).

Does the following of the process of quality? Perhaps, if the process is focused on quality and has the means to maintain it. And during "regular" people.

Of course, theorists say that the process ensures the quality that all the problems caused by the violation of the procedures that the project is "wrong" or that all the errors because of the people, rather than due process. In fact, people are the most important part of success, while even a complete adherence to the process can lead to failure. In this sense, the term SQA misleading. SQA ensures no product quality and conformity to standards and processes, which is not the same thing.

Let’s look at it is the quality of the product, rather than following the process. Quality can be checked or it could be "embedded" in the product creation process. These approaches are complementary. In case if you are using only the control, you have to spend much time on fixing bugs, and if not control, it increases the risk to release a defective product.

To improve the quality, you can use a variety of tools and approaches. It is important to understand that we need to do, how to do it and how to verify that the product is made is what is needed to the customer.

Quality assurance - this is a very big topic. The Internet has lots of information on techniques given below, in this review, I just briefly mention a few. Consider the following areas:

·         Requirements

·         Creation

·         Preventing future problems

Requirements

The project should solve the right problem, not just to make things right, but first of all do the right thing. The team must help the client understand what to do. If the customer explained his vision for the product team can analyze the required functionality given a vision. And to point out potential problems or defects at an early stage that will reduce costs and increase overall satisfaction with the project.

Sometimes the customer does not want to provide even a vision (for example, it is considered a trade secret). The team may try to explain the shortcomings of this approach and the potential risks, but the final decision still rests with the customer. Of course, in such a situation will create its own version of the vision, but it may be different from the vision of the client (most likely it will be different).

The client may not have time even to discuss requirements. Again, it’s his decision. A team can only warn about possible negative consequences for the project.

To improve the quality of the team can provide its expertise in solutions - the user interface (particularly specialists in user interaction and information architecture), the technical details (such as platform, performance requirements or scalability depending on the business requirements for the system) or even in business region, if the team has experience with similar projects.

Creation

The team has done that I could to figure out what to do. Now the question is - how? For a start it is important to understand that quality has its price. In the short run, high quality costs more, but in the long low quality may cost more (as is usually the case) than the high - the team must constantly correct errors with the code to work hard, you need a lot of time trying to change something or add new functionality.

Need to decide what level of quality required for this project. And then the team must constantly maintain this level throughout the project.

To this end, the team can use:

·         Architecture

·         Definition of done

·         Peer code review

·         Refactoring

·         Testing (unit, integration, manual, performance, etc.)

Architecture

Previously, it was a lot of noise about the architecture in agile approaches. The most radical say that architecture should arise during development, without any pre-planning and architectural design. I think this is an exaggeration. Sum of the parts is not always an integer, so a good design of small units does not guarantee a good system architecture. In practice, attention to the architecture depends on the complexity of the system - for small systems in a well-known area of ??the team already has a ready-made solutions, but for large systems with significant non-functional requirements need to separately address architecture. While you should not go to the other extreme - in advance to think through all the fine details; enough to think the most important and those that are difficult to change later.

Sometimes about architecture as a forgotten after its creation. Naturally, over time, deteriorating quality attributes of architecture - architecture is becoming less clear, it is difficult to sustain, stability is violated, etc. It is therefore necessary to periodically (or when new requirements do not fit the existing design), architecture review and modify, if necessary.

Definition of done

In Scrum, there is a good concept of "done". History or done, or not. It can not be "done, but …" or "almost done". How do I determine that the story is actually done and there is no "but"? Use the definition of done.

Definition of done - it’s a simple checklist. It contains conditions that must satisfy a story to be considered completed.

If we want to build quality, the definition of done a great place for this. For example, to avoid simple mistakes, the team may decide to include the condition that "No new warnings from the PMD and FindBugs».

The idea of ??definition of done may be offered by anyone, but to make a decision about using the command should be (and not the project manager and ScrumMaster). If a team does not see the benefit, then it will find a way around these criteria.

Definition of done can be extended beyond the stories - for example, a team can enter the definition of done for sprint or release (carried out performance testing, system works well under Windows and under Linux). This helps ensure that your system meets the non-functional requirements.

Peer code review

One of the most powerful tools to improve the quality of a peer code review (besides, it allows you to transfer knowledge and build a common understanding and standards within the team, and develop skills and learn faster). Sometimes a team forgets about code review, some deadlines are close (yes, deadline is very often somewhere very close to J), but the team does not conduct code review. To avoid this problem, the team can simply include code review in the definition of done - and then not be able to move forward until it had a code review.

In one team my proposal to include code review in the definition of done thoroughly discussed, and then the team came to the conclusion that it would be helpful. Subsequently, it has helped detect some serious problems and create a common style and understanding. In another team like the proposal was rejected. Some time later, the second team also concluded that the inclusion of code review in the definition of done is helpful.

Refactoring

Code deteriorates over time due to constant changes. Refactoring - one of the most popular and effective tools for improving code quality and increasing its understandability. You can make it part of definition of done. Or to allocate special time to refactor (for example, at the end of the sprint).

Testing

Unit and integration tests to increase stability and reduce errors by detecting problems early phases. They also help to think through a variety of options, making the system more reliable.

Manual testing can be performed by developers (when completed the story), testers, and team Owner’a Product (this may be one person) during acceptance testing.

Of course, there are many other types of Software testing , performing their special tasks.

Before you use any kind of testing is to analyze whether it is Software testing Services is useful for the project.

Preventing future problems

Ok, the team has corrected the problem. But a little later, again battling the same problem. Again and again. Lesson is lost. To learn the lesson, the team needed to define the problem, identify, analyze and fix the problem. And this is just one of the purposes of the retrospective.

Quality as part of development

All of the above can be summed as a simple checklist:

·         Make the requirements are quite adequate to the real business problem

·         Build quality in the process of creating

·         Architecture

·         Unit / integration testing

·         Definition of done

·         Refactoring

·         Peer code review

·         Test

·         Check that the result is that the sought

·         Check that the result is something that is really needed

Hmmm, very similar to the procedure of J. Not quite. The main difference - all these practices can be used separately, depending on the context. Some practices may be useless or even harmful in a particular project.

And most importantly - do not forget about people. It is important that the team understand how these practices can help them. And then a need for consensus. Jean Tabaka in her book "Collaboration Explained" defined consensus as a decision that everyone is willing to maintain and there is none who emphatically disagree with this decision. The team must decide on a set of practices that each team member is willing to maintain.

And then just enjoy the high quality product.