Converting QA to QA is not a QC, and we also talk about lean, kanban and TDD (below)-Reflection on the team

From: http://www.cnblogs.com/CaiAbin/archive/2010/09/18/1830388.html

Why are so many bugs?

It is shocking to see more than 200 in a month and 10 in a day on average on weekdays. I think there are many reasons:

2. Environment. Under the concept of "Progress first,CodeLibraries are gradually filled with poorly designed and trap-filled code. We do not know that slow is fast, but on the surface, fast actually slows down the team's pace. As a result, there are not only many bugs, but after being fixed, I don't know which day it will pop up again.
4. ProgramPersonnel habits. Bad habits in a team are more contagious than good habits. If the code is full of irregular naming, long functions, useless code, comments inconsistent with the code, and the complexity of the circle is several hundred, if there is no special motivation, who is still in the mood to write clean code?
6. Scrum-. For example, there is no demo, no product backlog, and no user story at the end of the sprint. For scrum-but, there is a PPT download here. A good phenomenon is that these situations have improved significantly.
8. No XP practice. Now we have code review and occasionally have pair, but it is not enough. People without pair cannot realize the improvement of code quality and production. There are also few unit tests, and many of them are not "unit" test, because they rely on databases or external files, and they are rarely run. In addition, unit test cannot be written in some places, because a method of a class does too much work and it is not solid enough.
10. No continuous integration. Only daily build, no local build script. Many times the code in the code library cannot be compiled, but it is discovered after a long time.
12. Organizational structure issues. Daily build is dedicated to CM Department maintenance, and CM Department members do not belong to our scrum team. Scrum should be one team, a cross-functional team.
14. Project structure issues. The entire project is divided into several solutions by module, and each solution contains a dozen common projects. If you build by solution, it will inevitably lead to repeated builds of public projects. How is the daily build script of CM handled? It does not build solution, but builds all projects in a certain order. Therefore, if Dev adds a project, the script must be changed. -- This script is really not used as a local build script.
16. VSS. We are a distributed team. The VSS server is located in Shanghai. It takes several hours for foreign teams to obtain code, so they almost don't get it. They only get a solution (not all) that their team is working on every week, and Others copy it from them. The team's code is always outdated. This situation lasted two or three years and finally switched to SVN. SVN is not an aim, but a basic prerequisite for checking in dance.
18. Process. So many bugs, but we should blame not the team members, but the process. In the previous articleArticleThe process mentioned at the beginning actually happens to our team.

Kanban We have been using scrum for nearly three years, but the word "use" can only be enclosed by quotation marks. For a long time, there was no user story; there was no collective code; there was too little communication between QA, Dev, and Dev ...... In order to strengthen the communication between the team members during the development and to encourage the Po to write a smaller story, we made an attempt a while ago: we tried not to split the task and did it directly after receiving the story, the discussion of task splitting should be postponed from plan meeting to actual code writing to avoid individual operations when writing code. -- In fact, it is very suitable for pair at this time, but unfortunately ....... (A: What is the biggest obstacle for a software team in China to implement scrum ?) Without a task, we bring about a related change, that is, the change of the scrum board. We introduced some Kanban concepts. The changed Whiteboard is as follows: The Whiteboard is easy to understand: story is all the story of the team commit on plan meeting. When Dev starts writing code, it moves to the ongoing column of development, and QA designs test case. After the code is complete (generally, the QA case is also completed), move to the right to done. Then, when QA starts the test, it moves to ongoing in Verify. If all test cases pass, it moves to the Right to done. Check the last Po. If there is no problem, put it in the last live column! In addition, both development and verify have limits on WIP, namely, Dev + 1 and QA + 1. Everything is perfect until a bug occurs: What if there is a bug in QA verify? What if the wip of the development column has reached the limit and there is a bug in story? Move one story of the Development column to the left, and then move the bug story from verify back to the development column? This is a good start. I mean, one goal of Kanban is achieved-It visualizes potential problems. The problem should be solved. Looking back at the content of the previous article, the solution is very simple-since there is a QA test case, why is there a bug in the verify stage? Dev writes a story and throws it to QA when it does not pass the test case test. At the same time, it starts to write the code for the next story. -- This is a typical and common error process. Why is "writing code + passing case" a condition for done during development? Yes, but for this change, there will be no fewer bugs, However, bugs are discovered in advance, In addition, the round-trip between Dev and QA is reduced. So my idea is to change the whiteboard to the following:
Of course, the fine-tuning of the Whiteboard is just a representation. What needs to be adjusted is the process, concept, and Test first Concept. What is TDD? TDD is beyond the reach of many people. It requires high skills. In fact, such people may have some misunderstandings about TDD. Many people think that tdd t is only a unit test. Actually not. TDD is a test drive. The tests here include unit test and acceptance test. In scrum, each story has an "Acceptance condition". QA designed the test case as a blue object. The test case is actually an "Acceptance Test" of story ". So we use this "Acceptance Test" to drive our development. Isn't it TDD? Although we still cannot write automated acceptance tests, we will not use fit, story teller or spec flow ......, However, if QA maintains a communication and a collision of ideas with Dev when designing test case, it uses test case to guide our code writing (instead of "discovering" bugs after code is complete ), I think this is also TDD, the cheapest but equally effective TDD. While practicing TDD skills, do not forget a simple definition of TDD: TDD is a technique where teams use short development iterations based on pre-written test cases.

How to Reduce bugs?If all the problems listed at the beginning of the article are solved, will the bug be reduced? Maybe, and that's just the problem I saw. Maybe it's right, maybe it's wrong.The focus is on developing teams to reflect, discover problems and learn habits.