Agility and quality

When the company is agile for three years, every time it encounters a critical risk that affects shipment at critical times, it will point to quality without exception.

According to the common regulations in the industry and the standards of our company, it seems that every sprint is very beautiful, but you look at the entire release and take the sprint as a point, rather than a time period, it is not difficult to find that the entire process is distorted, and there are many pitfalls that cannot be entered.

A company will brainwash a lot of training during the import process. This is similar to marketing. When selling a product, she only claims that her product is good and does not emphasize the shortcomings and shortcomings of her product. The most important thing is that after-sales personnel are responsible for handling problems. The same is true for companies. Once agile is introduced, the benefits will be promoted desperately and the problems in Agile will not be emphasized. I will try again later. In fact, everyone is a newbie. In fact, they have not encountered many problems in practice. I firmly believe that the people on the market in China who advocate agility and perform training everywhere have their own practical experience? Agility is a real thing. Every team has a different way of playing, because she has no theoretical foundation and no special methodology. This is a collection of previous experiences. The experience of the predecessors will certainly not be fully applied to your project, and you have to crop it yourself. Therefore, agility must be well adjusted to emphasize review. In turn, we asked, for those standards proposed in Agile, are there any other processes? In fact, most of the processes, such as MSF or RUP, are covered by the standards proposed in Agile without exception, and there is a clear recommendation implementation method. All of these standards emphasize quality.

How can we ensure quality? The R & D of a product will take a long period of time, namely several months and several years. Although we will convert it into a smaller stage result. The agile concept is that each sprint must ensure that the story to be defined is completed with high quality. Good. Every sprint is complete. What about the product? Is there any product-dimension quality assurance?

At present, our company's case maintenance is mainly based on the sprint as the time unit, driven by stories. There is a lot of case and data behind each story. So there is no problem for projects that never go back, But what should we do if agile constantly emphasizes changes? Generally, changes are divided into two types: large changes and small changes. If there is a small change, we generally do not create a new story, but let everyone take the time to do it. The big change will make a new story and describe the situation after the change from the user's standpoint, at this time, the case for these changes corresponds to this story, so when future generations see the story in the sprint, they actually do not see the real situation of the product. That is to say, if a latecomer wants to know the test case of a product, he needs to read all the stories in the sprint to form his own context. The formation of this context and the brain, I don't know if it is also the end of the brain, so repeated activities will be done again and again? That is to say, if we consider a testing job, we mean that testing is a sprint, not a product. As a result, almost no one can complete the handover. This means that Agility emphasizes the stability of the team and the high degree of familiarity with the product, but I think these are too good, which means that all the major companies that can be agile are created.

Another serious problem is that agile companies do not have automated testing tools. This is actually terrible. According to agile requirements, the test can be case-insensitive. When the time is not allowed, the test can be executed according to understanding, and the test can be completed when the time is free. My idea is that to ensure the quality of agility, we must perform automated tests in a wide range. The tester's job is to write an automated test script, just like the developerCodeTheir positions and perspectives are different. Once a change is required, the test code is adjusted accordingly. This means that there is no traditional case, and the test code is the case. Is it similar to the code-centric concept of abandon design often described in Agile? Only in this way can we synchronize the maintenance of tests and the maintenance of products. We can confirm at any time that the quality of the entire product is not declining. Because we are not in the output sprint but in the output product.

These are all complaints. For an agile team, it is very important to really understand the quality of TQM. It is necessary to allow QA to get involved in the QA right from the beginning. There is no way to determine how to ensure the quality of products from the beginning to the end. We need the QA personnel to innovate and combine the actual situation of the team and the enterprise environment, in addition, a documented quality management solution should be developed and strictly implemented at the beginning to form an organization-level quality plan for the product line or a higher level. In this regard, innovation is very important. Because agility is a weak planning process, there will be many deviations in the actual process. These deviations are a test for the entire team. However, for any changes, testers are always the last step, they will experience great progress pressure and trust crisis.

With these pressures, it is the driving force for qualified agile testers to grow.