Thoughts on the "core value" of the software testing team

I have previously written the dilemma and Countermeasures of software quality management, and talked about the Development Department and Quality Management Department (QA) A dual-ring structure with "intersection" should be formed instead of a "dumbbell-shaped" organization. It is also pointed out that software quality management should focus on lightweight practices, the goal should be to help engineers improve work habits and improve the efficiency of the development environment. At that time, I did not seriously think about the core values of the test team until I read @ Duan Nian-Duan Wentao's "test team and coffee shop".

In general, software development teams seem to barely talk about their "core values". But does the test team always have a special reflection on this issue? However, when exploring "core value", it often means that the value is not clear enough or the key points are not accurate.

According to my past experiences in software development, the unique thinking of the test team on "core value" is indeed inevitable. Exploring the root cause begins with a game.

Zero-sum games

Most software enterprises have set up two departments for development and testing, and the two Departments belong to two interactive but independent nodes in the enterprise value chain. In an enterprise, as long as it is a department, most of the performance appraisal problems exist. It seems that only this can prove the necessity of the Department.

The role of the software testing department is usually positioned as "Quality Guard ". Naturally, the number and severity of Software defects they discover are closely related to their performance. Therefore, in order to reflect its value, the test engineers hope to create new defect records in the defect tracking system as much as possible. But the Development Engineer does not do it, because the number of defects can also be used as an evaluation indicator to measure the development quality. Further, we have such a scenario: after the test engineer finds a problem, he first communicates with the Development Engineer, create a new defect record after obtaining the consent of the Development Engineer (this process sometimes becomes a game, not a real work efficiency ); developers are not grateful for the problems found by test engineers, but think they are "looking for trouble ". Due to the existence of "quality guard", the development engineers are confident that it is a matter of testing departments to ensure the quality of software.

It is not hard to find that such a system actually creates a "zero-sum game ". This game brings us the dilemma: the "Win" (more defects discovered) of the testing department means that the development department is "lost" (poor development quality); and vice versa. All in all, it is difficult for the two departments to achieve a win-win situation, and sometimes even the extreme situation of independent Government.

Concept of software quality

It is estimated that no one will question the value of the test activity. I am afraid the reason behind this is no longer simple. However, we still need to first discuss what is software quality (hereinafter referred to as "quality"). It is difficult to ensure that testing activities are targeted if this concept is not clear.

I have pointed out in my book professional embedded software development that quality is classified and contains two levels: user and team. Simply put, user-level quality is reflected by Software defects, the team-level quality reflects the development team's ability to implement development work in a step-by-step manner, rather than being in an "emergency" state. The team-level quality is a higher form covering the user level. I also pointed out in this book that software design is the foundation of quality. Only high-quality software design can ensure the quality of the team and ultimately bring us user-level quality for a long time. These claims clearly indicate that quality is the first responsibility of software development engineers.

User-level software quality can be evaluated by testing cases written in the requirement document. However, team-level quality (that is, software design quality) is difficult to evaluate through these test cases, but the number of Software defects can also reflect a certain situation. If the number of Software defects in a project fluctuates significantly for a long period of time, most of them mean that there are problems with the software design. It also indicates that the development team has not solved the problem from the root cause, instead, it adopted the short-term "Seven repairs and eight supplements. In addition, whether the development team is often in the "fire-fighting" status can also reflect the software team-level quality level to a great extent.

Do we need test engineers?

Ideally, testing can be done by development engineers because "They know all the implementation details of the software", but there is always a gap between reality and ideal. The following operability problems exist when developers complete the test:

1) the requirements for development engineers are too high. These guys not only need to be proficient in programming languages and business, but also have to master the testing theory, testing methods and the scripting language required for testing. Once the requirement is too high, it is prone to resource scarcity. In addition, let's imagine how engineers can meet such high requirements? In school? Or work middle school? If they are at work and middle school, what are their roles at work before they meet the requirements?

2) When the development time is very tight, it is almost impossible for developers to focus on both design quality and test quality. In reality, taking into account the former is a very good development engineer. In addition, this kind of misunderstanding cannot be determined by development engineers unilaterally, but too many project management teams always have the misunderstanding that "compression of time can prompt the development team not to be casual, without being aware of the side effects of this cognitive-driven behavior-affects the design quality of software.

3) development engineers implement collaboration through software modularization. In this case, someone must guide the entire system from the test perspective, and it is really difficult to rely on development engineers themselves.

In the face of these operability problems, if some people still insist that the testing work should be completely completed by development engineers, they can only say that they are denying the benefits of social division of labor, it is also likely that I forgot my role before I became an all-powerful player.

To sum up, we need testing engineers and development engineers to work together to achieve quality objectives, which also means that testing engineers are valuable!

How test engineers contribute value

To make a good contribution to the value, test engineers should first share their goals with development engineers. That is to say, the development and testing team should first turn the quality goal into "ours" instead of "yours" or "mine ", otherwise, it is difficult to break the dilemma brought about by zero-sum games. In this regard, I fully agree with @ Wu Qiong's article titled "dual purpose and rational quality of testing", "only by completely mixing development and testing together, we should not try to isolate the development and test teams if we can truly achieve good quality without being equal to each other ". In other words, the relationship between the development and testing teams in the organizational structure should be appropriately revised to support such claims; otherwise, it is the first huge obstacle that hinders the test team from delivering value.

The common quality goals set are best at the team level, because from the perspective of development engineers, only in this way can the development work be ensured in a step-by-step manner, which also means that they and the company can obtain the greatest benefit from it. From this perspective, test engineers can consider "How can I help improve the design quality of the software ". This problem may be too big, and the requirements for test engineers are too high (we will talk about it later ), but we can start with a more guiding question of "how to ensure software testability.

Second, the test team shares the same user-level quality objectives with the development team. At this level, the test team will find a huge space to play. For example, whether a testing team can build or improve a unit testing platform to help development engineers implement unit testing more conveniently, or help development engineers build a continuous integration platform.

Please note that I do not advocate that the test team should listen to the development team, but that the test team should use its own testing expertise to help the development team improve development quality and efficiency, rather than serving as an examiner only. Test engineers must build confidence in their teams: testing is a specialized field. We have our own unique insights on quality assurance and can help development engineers.

In general, the test team must provide guidance and help to the development team in the test field. Only in this way can the development engineers feel that "we have the same quality goal ". I want to emphasize this idea in the article "test team and coffee shop. In addition, Google has made the testing team affiliated with the engineering productipipeline FA (focus area) Probably out of this consideration!

Helpless reality

Readers can search for the series of translation articles "how Google performs tests" on the Internet. The article describes how Google organizes tests. The content is worth learning and thinking. In general, I think Google has higher requirements for test engineers and test development engineers than I have seen in China. In addition, the role of development and test engineers is critical, they review the design, review the quality and risks of the Code, reconstruct the code to provide better testability, write unit tests and automated testing frameworks.

Looking back at China, it seems that testing is more important than development. The requirement on the test engineer does not seem to be as high as that of the Development Engineer. This can be seen from the fact that an engineer is not suitable for a development position when recruiting, considering whether the engineer is suitable for testing. In my understanding, the test engineer should be a development engineer with a higher level, because only a higher level can have a deeper understanding of the software quality, ability to guide and help development engineers in their daily work from the quality level.

The Confusions of the test team regarding the "core value" are largely due to the lack of domestic emphasis on testing and the forced separation of development and testing activities. The greater harm it brings is the lack of a certain gradient of testing talents.