Quality Check Point of Project Management

In the theory of software engineering, there is no "Quality checkpoint". This is just a measure I have taken in project management to cope with the quality pressure of the project, I am writing it here and share it with you. I hope you can communicate with us here.

The so-called "Quality checkpoint" is the point where developers know their needs. This recognition Point serves as the basis for development and self-testing by developers. It is also the basis for the development team to analyze bugs after the customer discovers bugs after the product is submitted.

Maybe my interpretation of the "quality checkpoint" is incomplete. After all, the implementation of the "quality checkpoint" in our project team is only two weeks.

First of all, I want to talk about the origin of the "Quality checkpoint. My project team is responsible for the development of an outsourcing project. The customer has high requirements on the quality of the submitted products. Our project team does not have dedicated testers. Therefore, developers are responsible for product quality control. Although the project team members are enthusiastic about their work, there are still bugs in the submitted products, and some bugs are very low-level. This problem really puts a lot of pressure on me, but the project members are not very picky about their work attitude. In the face of bugs, I can point to XX and say, "the product you submitted has a problem, do you need to pay attention to the product quality? I once wanted to do this, but I still didn't, because I knew they had done their best. Such criticism not only did not benefit things, but also hurt their enthusiasm and self-confidence.

I think it must be ours.Working MethodThere is a problem. In our project team, a Project Manager checks the completion status of each task. During this process, I found that there is definitely no problem for developers. This is actually a dark light. For example, if you change a tag value in an event added to a record, the tag value will affect the exit of the form. But developers think this is a very simple implementation, so they did not test it after finishing the task. When I checked the results, there was a problem. The first check result was that the events added to the record were not triggered because the event was to be triggered, the update of data binding is required. The developer ignores this process and the bug occurs. Of course, this is only a typical case.

Another case is that the task itself is very complicated. After the developer completes the task, they can test it based on their memory of the requirement. There is a process here, and we will not talk about "Thinking that developers are unwilling to detect bugs in their own code ", even if developers start to remember 100% of the objective content to be tested, they usually find problems during the testing process, then the developer stops the test and changes to the bug. Another objective fact is that the time passes by one minute. As the task submission time approaches, developers' psychology will change a lot. One of them is certain that they will gradually become anxious. In this case, 80% of the Test content may remain in the developer's brain. If the number of bugs found during the self-testing process is large or the problem solving time is long, the test content left in the developer's brain may be less.

The above two problems are actually blind spots in the process of thinking. From the perspective of others, it is a subjective problem because the tasks they submit contain bugs. In fact, it is an objective problem for developers because it is a blind area of thinking, how can they find bugs in task submission (just as a person's eyes cannot see his or her head, so when the bug is in the back, he cannot see it )?

In this context, I came up with a solution, that is, developers write their own "Quality checkpoints ".

What is the content of the quality check point? I only use one case in my work practice as an example. The user sends a new requirement to add related sales items to the original sales project. For this new requirement, the current test points of our developers are:

.....

Add the related sales project function to the rental sales project

Add the related sales item function to the ordering item

.....

Add an associated sales project and click exit. The system prompts whether to exit after saving the project.

......

From the perspective of the system analysts, it has a demand analysis color, but is not systematic enough. From the perspective of testers, it is also like a test case, but not detailed enough. Indeed, the test point was originally born in a development team without full-time system analysts and full-time testers. But I believe it has other values. I always encourage developers to write the checkpoints they think of before entering development. I hope that it will become a direction that can help developers with the right goals and efforts in the development process. In fact, after more than two weeks of practice, it has indeed played a role in this regard. I feel that the developer's thinking has become more rigorous in the development process. This is before the task is completed. After the task is completed, it enters the testing phase. I also tell developers that they can test based on their test points, but they do not seem happy to do so.

This is actually a normal thing. It is caused by the inertia of the work. As a project managerMake a difference at this stageTo enable project members to implement new work methods. My approach is to have a meeting to analyze the benefits of doing so, and then we suggest you pilot it in one person, and then check the code based on the quality check point. Every Friday, meeting to discuss the quality checkpointUnderstanding and implementation methods. In this way, three weeks later, everyone can start to write Quality checkpoints before the project.

It is very important for project management to hold a meeting to discuss people's understanding of some points of view and specific practical methods. It not only enables the communication of ideas between project members, but also deepens the understanding of views, which cannot be achieved by talking alone.

After a period of practice, we have improved the quality of development through quality check points. This is what I expected, but we have also found some bugs that have long existed in the system but have not been found, this surprised me. After all, after our program is handed over to the customer, the customer will send professional testers for testing. Is the test effect so amazing?

Later, after thinking, I found that this is related to the existence cycle of the quality check point. the quality check point is added by developers before and after the code is written and during the code writing process. The three time periods actually involve the third role code to a certain extent. Before development, the write quality check point is the role of the requirement analysis personnel. This role focuses on what functions should be implemented. during development, the write quality check point is the role of a programmer, this role focuses on the features of function execution. After development, the write quality check point is the role of the tester, which focuses on whether the function is implemented correctly. When these three roles are combined in the quality check point, their effects come out. I think this is what I should continue to think about-analyzing various roles in the development process, and then creating new management measures or implementation schemes to merge these roles, to play a new role effect-just like a chemist who splits the molecules into atoms and then combines them to create new molecules. Of course, we cannot guarantee that these new molecules have better features than the previous ones, but we always have the opportunity to create better elements than the previous one-it depends on the manager's skills.

The discussion on Quality checkpoints is coming to an end here. Quality, which is related to the success or failure of the project and the survival of the enterprise. Every day, it is mentioned by different people in different ways. I hope to have a long-term discussion with you on this topic.

 

Related Articles: Quality Check Points

 

For more articles, visit my blog