Shulou(Shulou.com)06/03 Report--

Conceptual and speculative depth

The development of an industry always seems to be accompanied by more concepts being shaped. For testing, we have unit tests, integration tests, system tests, regression tests, smoke tests, and so on. Why do we shape so many concepts to "embarrass" ourselves? The answer can be explained by the sentence that I learned from @ Li Zhiyong SZ teacher,"the purer the concept, the deeper the speculation," which is all to improve the communication efficiency between peers. It is important to note that many similar but different concepts are intended to express differences rather than commonalities. For this reason, if someone is discussing unit testing, you come up with a sentence: "Write a good program, compile it, run it, and see if it is written correctly, this is the simplest UT!" "It's not appropriate, because it shows that you don't understand the concept of unit testing at all (read my article Clear Unit Testing). If you add,"shit, it's all tests, what's the point? "It also shows that you are illogical.

My recent article Thinking about the "Core Values" of Software Testing Teams sparked some discussion. For example,@ Zhu Shaomin teacher (hereinafter referred to as teacher Zhu) pointed out: "'(the test described in this article) helps developers improve their development quality and efficiency 'is one of the value orientations of software testing teams, but it is not the main core value of software testing teams." So I asked Teacher Zhu about the core value of testing he understood, and the reply was "The core value of software testing is to be able to quickly find problems to provide product quality feedback, to be able to provide accurate, objective and complete quality evaluation, and to determine defect patterns and bad behaviors and habits of developers through defect analysis and user behavior analysis, so as to help developers prevent defects (from design to programming, unit testing, not just design)."

My response was,"We should distinguish QA from testing," because I thought Mr. Zhu defined the scope of testing too widely. However, Teacher Zhu helped me point out,"This is an out-and-out test. It seems that you don't understand QA enough." QA's main object is (including development, testing) process, QA personnel review, audit and improve the process to ensure quality. The object of testing is the product, including phased semi-finished products. Strictly speaking, testing is a quality assessment of software products."

Similar discussions related to QA and testing took place when @ Left Ear Mouse wrote "Do We Need a Full-Time QA?" After a text. These discussions brought us "The Role and Division of QA Testing" written by @ Programmer Zou Xin, and "Do We Need Full-time QA?" written by @ Duan Nian-Duan Wentao. The response." In this article I would like to mention in passing the views of the previous reading of these articles.

Who's right and who's wrong?

If you have read my article Software Development: Individuals and Teams Always at the Heart, you will know that I present a performance model for high-quality and efficient software development. The model covers a wide range of topics, including three pillars: behaviour, competence and methodology. To some extent, our career journey in the software industry is a bit like "blind people feeling the elephant"(but we can communicate). This exploration process has a direct relationship with the software segmentation industry we are engaged in (such as Internet, communication, banking), service company (such as state-owned enterprise, foreign enterprise, private enterprise), type of work (such as development, testing), etc. One successful experience obtained may not work at all in another situation. The process of groping is easy to understand things in books through reality, which is not a bad thing, but never think that what you "see" is "universal truth," and never give up your independent thinking.

Controversy is not a bad thing. We argue because we have different paths and depths of thought (age plays a role). The focus of the dispute is not to "blacken" each other, but to reach consensus and perfect self-understanding as much as possible. The more consensus is reached, the more "elephant looks" are known, which is meaningful to all practitioners. Because of this, as a technical person, I often tell myself to "put down a little more arrogance and self-esteem to accept other people's ideas, which is a good way for me to grow." "And I'm more in awe than in denial of areas of technology I'm unfamiliar with. In general, it is not who is right and who is wrong that matters, but what ideas we have in common or the same, and how to put the facts logically so that each other can understand their own ideas. I hope that every reader can be rational about the controversy encountered, this is a small appeal.

QA does not contain tests

I think a lot of the arguments that arise about QA and testing arise when we don't have clear concepts, or when some concepts are too general to cause problems. The word QA is an example!

Quality assurance is easy to think of in terms of software quality, such as testing, processes, defect data analysis, etc. In this case, does the level of development engineers also affect the quality of software? Why is recruitment not managed by QA but by HR and Development? Isn't that a ridiculous question? But this question also tells us that the responsibilities of various departments are not defined by their names, but are assigned by the company according to the needs of the organizational structure. In this case, when we use these terms, we must expand them according to our duties, not according to the meaning of the name itself, otherwise it is easy to cause worthless disputes because of improper words. Some disputes even affect other people's "rice bowls." How can you call people rational? This implies that our words should be as precise as possible.

If QA isn't a test, what is it for? To be honest, I dare not define responsibilities for a role out of thin air, and I am not an expert in QA (and testing), so I can only use Motorola, which I have worked for, as an example to give my general understanding. Simply put, Motorola QA is a completely separate department from the test department, focusing on two major issues: defect data analysis and defect prevention, and process specification and improvement. QA will conduct data analysis (or data mining) according to the defect data generated by the test and development departments, discover the defect model of each product (common mistakes, defect number trend, etc.), and predict the potential legacy defects through the model to help the development department improve (finally acting on the process). In addition, QA participates in software development activities throughout the process to track the execution of the processes established by the company. For example, the Motorola Hangzhou R & D Center where I worked before passed TL9000 certification, QA must ensure that development activities fully comply with TL9000 requirements, so as to avoid failing to pass the qualification review.

Readers, please note that I use Motorola as an example to define QA responsibilities, must it be correct? Not necessarily! This definition may be difficult to accept for those who work in QA departments for some tests. In this case, what we need to think about is, does this definition help us communicate more easily? A definition is desirable if it helps us communicate, otherwise it is debatable. Rational thinking can't forget!

Do we need QA?

If you ask,"do we need tests? "The answer is clear, isn't it? On what basis does the company decide whether it needs a job? Very simple, different skills!

Many software companies need to pass such quality system certification as CMMI, ISO9000 series, TL9000, etc., and review them regularly. These quality systems claim that "quality comes from process," so someone must have developed and monitored the process for the company. Quality awareness in process-driven R & D needs to be cultivated, which requires training such as "Quality begins with me." Defective data can be mined to help discover other valuable things, which requires appropriate data modeling and analysis skills.

It is not difficult to agree that the above knowledge and related skills cannot be combined by the development or test team, so we need a separate QA department.

The role and importance of QA departments vary greatly from industry to industry. On average, products in the Internet industry have a higher tolerance for quality problems (most Internet products go online directly, and problems can be directly rolled back), rather than having to be operated by operators like China Mobile as in the communications industry, and there are no third-party punitive costs caused by quality accidents. In addition, users of Internet products simply do not care whether the product development process follows quality systems such as CMMI, which is completely different from the requirements that operators in the communications industry may have. I further discuss the differences between the two industries in my article "Some insights from leaving the communications industry to enter the Internet circle."

At this point, I hope readers will accept my suggestion to distinguish QA from testing.

One more point.

No matter what kind of random techniques and theories are used, the psychological game defense between the test and development teams must be broken when exploring the core values of the test team, otherwise there is no possibility of success. In my long experience on the development front line, the value confusion of testing stems first from the lack of approval from development engineers. This is a psychological problem, not a technical problem. Thinking about the "core value" of software testing team does not directly give the definition of core value, but it gives the exploration direction, hoping that it is worth our common consideration.

The test engineer thinks about finding a breakthrough from the "pain point" of the development engineer, and may find a way out. Of course, to really start from the "pain point" of development, the test team must have some "brushes," otherwise it can only drift away from the edge of quality and efficiency.

Reply to what Teacher Zhu said

Teacher Zhu: The core value of software testing is to be able to quickly find problems to provide product quality feedback, to have the ability to provide accurate, objective and complete quality assessment, and to determine defect patterns and bad behaviors and habits of developers through defect analysis and user behavior analysis, so as to help developers prevent defects (from design to programming, unit testing, not just design).

Re: This definition has the problem of confusing testing with QA. If I were a test engineer, I'd be shocked to see this definition. It's too demanding. I think quality measurement is prone to subjective phenomena, and it is difficult to achieve the truth of "1+1=2." The purpose of software quality measurement is not to "truly" understand the quality of software, because quality at the team level cannot be measured directly. The purpose of measurement is to help the development team find improvement points. Software quality management should be practice-oriented and lightweight, with the goal of helping engineers improve their work habits and improve the efficiency of the development environment. While I appreciate Miss Chu's dual role of QA and testing, I hope to adopt the suggestion of separating QA from testing in discussing the core values of testing. Only when the concept is clear and light, it is not easy to cause ambiguity, and it is also more conducive to reaching more consensus and improving communication efficiency.

Mr. Zhu: This is an out-and-out test. It seems that you don't understand QA enough. QA's main object is (including development, testing) process, QA personnel review, audit and improve the process to ensure quality. The object of testing is the product, including phased semi-finished products. Strictly speaking, testing is the quality evaluation of software products.

Answer: The first part talks about both testing and QA, which is easy to cause misunderstanding. I agree with the second and third sentences. For the fourth sentence, my question is "Can testing really assess software quality? "

Do we need full-time QA? Comments on related articles

Do we need full-time QA? The argument of this article is QA, but the content is actually about testing, and it is reasonable to cause unnecessary controversy. There are still a lot of ideas worth thinking about in this article, and the shortcomings are refuted in the following two articles.

The article "The Role and Division of QA in Testing" also has the problem of mixing QA and testing together, but there are still traces of QA and testing. For example, it talks about certification. I appreciate the division of labor and why dedicated testers are needed.

Do we need full-time QA? The article "Response to QA" clearly distinguishes QA from testing and focuses only on testing discussions. I have a lot of common ground with Teacher Duan. Although I haven't heard his speech, I have seen some of his PPT sharing topics and can find resonance points from the developer's point of view. Notice the last sentence in the article,"isn't testing the way to go when there is more synergy between testing and development, more love, and testing as a means to improve and drive quality? "

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.