Why testing and development are at odds

Let's think about a few common questions:

• What is the purpose of software testing?
• Can developers build flawless software without bugs?
• What is the relationship between testers and developers?
• Can software testing ensure software quality?

Close your eyes and meditate for five minutes, and then try to answer the above questions.

Computer pioneer Maurice Wikes recalls working in Cambridge, England in 1949, when he saw his future as he dragged a punched paper tape upstairs to load a program for the rudimentary computer EDASC:

我强烈的意识到，生命中剩下的好日子，都将耗费在给自己的程序找错误上头。

Maurice Wikes tells us that there is no perfect software.

I published a book recommendation article in my WeChat subscription account "Program Vision", recommending " Subverting Perfect Software :: Several Things You Must Know About Software Testing " in Weinberg's technical thought trilogy . In this book, Weinberg also tells us that there is no perfect software. All developers and testers should read that book.

Weinberg discusses almost all common concepts, problems and guiding ideology related to software testing in "Subverting Perfect Software" , so, in this article, I can only complain, I will list some of the following aspects A common phenomenon, I hope it can arouse everyone's thinking.

• The relationship between testing and development
• Procedures and Standards
• resource
• Attitude

The relationship between testing and development

Are testing and development opposites?

From a bug-handling point of view, that seems to be the case. Developers produce both code and bugs . Because developers inevitably produce bugs, testers must exist to check out as many bugs as possible before the software is delivered, ensuring that the software delivered to customers is of a better quality. One produces bugs, the other picks bugs, it seems to be opposites.

In reality, many test teams and development teams are at odds with each other because of this, or even really confront each other. Think back to what's going on around you in relation to development and testing, and see if you've come across any of the following:

• Developers say that testing is a no-brainer, and customers are unlikely to use the software the way they do
• Tests say that problems always arise under seemingly extreme conditions, and users are always inadvertently exposed to seemingly extreme and impossible conditions
• Developers say that testing spends more energy in abnormal situations than testing the main process, and I don't know the priorities
• The test said that development never considers the feeling of testing, and it is thrown to us without even testing.
• The development said, I have tested it, what do the testers do?
• The test said, if you don't test such an obvious problem, use our test as a trash can.
• ……

Many, many similar problems have caused the relationship between development and testing to go from confusing, loving and killing each other to opposing. I've seen development and testing get into a cold war with someone passing by someone, and I've seen test managers and development managers fight, and I've seen senior leaders deliberately strain the relationship between the test team and the development team in the belief that it will improve testing efficiency and also Putting development pressure on will eventually produce higher quality software...

In fact, testing and development have the same purpose: to make the software better. The relationship between testing and development is two sides of the same issue and should complement each other and coexist peacefully. Testing is not about nitpicking, and the questions he asks are not aimed at developers of production software, but simply in an effort to make the developer's output look usable. As long as developers don't see the behavior of testing bugs as personal behavior, everything has a good premise.

To deny software is not to deny the people who develop it . This is a principle and premise that both development and testing need to be clarified.

Some people think that the relationship between development and testing is similar to skin and hair. If the skin does not exist, what will the hair be attached to? Therefore, some developers will have a sense of superiority because of this: if we didn't write software, you would have been laid off for testing! However, development does not write software, development is also laid off!

Thanks to the imperfection of development, testing can be done and a good eye.

Thanks for the careful and careful testing and patience and thoughtfulness, so that developers can discover their own imperfections and have the opportunity to improve themselves - those who say my software is not good are for my own good.

resource

Don't touch our test server, build one yourself!

We don't have an environment, so who do you use instead of yours?

Who took our test phone away? Why don't you apply for one, you will always take up our equipment.

Who is using our account? Don't say hello! I want to use it, get out now!

Sometimes there will also be resource conflicts between development and testing. We must work hard and creatively to solve them (I can responsibly say that it is not a good way to pretend to be a hacker). Don't let the big guy's work get stuck in the environment. It is the basic problem to be solved by managers . I have seen many great first-line managers, under the constraints of reality, voluntarily donate their mobile phones and iPads as test equipment. This is also a way to solve the resource problem.

Procedures and Standards

Do people around you complain like this:

• Development doesn't look at our test cases at all, review emails never respond
• As soon as we reported a bug, the developer said that it was impossible for users to use it in this way, and also said that he did not know how we would test this way.
• The test scope is not written at all in the test sheet, or a few sentences are the same as not written.
• Development tweak design never tells us
• Why do product managers and UIs only discuss requirements changes with developers?
• Why is there no test time reserved for testing in the release plan?
• Why is it thrown to us after the development and writing of the code even if it is not tested?
• Why do customers find problems there and always ask who measured them and why they didn't measure them?
• Test always silently set bug priority to Major
• Testing always spends a lot of time on features that users simply cannot use
• The test can't tell which is the key point, you tell him that he still has a bunch of reasons, that's all
• The bug mentioned in the test, the description of the phenomenon is not accurate, and there are no reproduction steps, and some simply know whether it is a misoperation
• Tests always interrupt me, call for a while, call for a while, there is no way to focus on development
• The bug repetition rate on jira is too high, and a question is raised N times, can't it be merged?
• The test found a bug, I just told the boss without saying hello, which made me very passive
• Testing is for nitpicking, and it’s hard to use it in the right direction, but you are testing the functions commonly used by users.
• Such simple bugs can flow out to users, I really don't know how to test
• The development old suspects that the test report data is not beautiful, forcing us to adjust

Ok, if the development and testing around you have never had similar problems, that's great, congratulations, it seems that your team's collaboration is also very smooth, great.

If you are surrounded by such noisy complaints, what does it mean? Is there a problem with the process of development, testing, and release? Or does the team lack a clear direction to guide everyone toward positive, effective behavior?

Processes and standards always need to be explained, no matter how good the rules are, even a crooked monk can pronounce them obliquely...

Let's pick a question at random: why is it thrown to us after the development and writing of the code, even if it is not tested ? This problem is pervasive, and it reflects the inconsistency of the working boundaries between programmers and testers.

Programmers will say, I have tested it all again, what do you need to test for?

The test will say, you can't even test, you can't pass the smoke, do you have a sense of responsibility?

The programmer said that if I want to write test cases, set up various environments, and traverse various normal and abnormal logics, do I still have time to write code?

The test will say, is our test a trash can, throw all the crap at us, and our time is so worthless?

The developer will say that testing is for this purpose. Who will test if you don't?

……

For questions like this, can a standard be formulated to indicate what kind of logic development needs to be covered by self-testing and what kind of logic can be handed over to the test for testing? Can you draw a three-eighth line?

can not. Therefore, at this time, reliable front-line managers are very important. How to creatively find a suitable method for the team to allow everyone to work together smoothly is more important than standards and systems, which often depends on the ability of technical managers and the awareness of team members. There is no one-size-fits-all approach, there are only here-and-now strategies that suit this organization. Come on, find the path that best suits the moment in battle.

So what is a reliable first-line manager?

Weinberg's book Becoming a Technology Leader defines leadership responsibilities as follows:

领导的职责就是创造这样一个环境，每个人都能在其中发挥出更多的能力。

If a team led by a technical leader, most of the people can concentrate on doing things that suit their abilities instead of soaking in problems similar to those listed earlier in this section, then he is basically more reliable.

As for how long the test cycle should be reserved for the test, whether to notify the test when adjusting the design, whether to participate in the test when the demand is adjusted, etc., reasonable processes and standards can play a great auxiliary role, and technical leaders only need to follow a reasonable system. , and guide everyone to participate effectively, it can be resolved.

Attitude

scene one:

测试MM对阿猿说发现了一个Bug。

阿猿矢口否认：不可能，绝对不可能！

MM：真的有Bug，你过来看一下！

阿猿：我都不用看，在我这儿好好儿的。

MM：你来看一下嘛……

阿猿：看什么看，肯定你环境问题，动什么东西了吗？重启了吗？

Scenario two:

测试MM想在jira上提个Bug，先在QQ上对阿猿说：有个Bug，你过来看下？

阿猿：忙着呢，焦头烂额的。

MM：一分钟都用不了，你来看下吧。

阿猿：思路一打断就不好恢复了，等会儿！

MM：你不看我提到jira上了啊。

阿猿：随便，你不就是爱提Bug嘛。

Scenario three:

测试MM呼叫阿猿：阿猿阿猿，程序又崩溃了，快来看看！

阿猿慢腾腾地起身过来，鼠标点几下：看不出来什么问题，你怎么操作的？

MM：这样点一下，那样，这样，……回车……。

阿猿：重现不了啊，你想办法重现，重现了再叫我，我忙着呢。

MM：……

I once drew a violent comic and published it in the WeChat subscription account "Program Vision" with the title " She found a bug ", reproducing a similar scene, if you are interested, you can reply to 10019 in the subscription account to view (click the subscription account) can also be found in the "All Articles" submenu in the Help menu at the bottom).

Part of the reason for the above scenario is repeated in the daily work of development and testing, which is due to attitude. We sometimes hear things like:

• The description of the phenomenon in your bug is useless at all
• You don't understand the logic at all, I can't explain it to you
• The test doesn't know anything...
• You listen to me, you can measure it as I ask you to measure it
• Your kind of measurement method, no matter how good the software is, it can't stand your toss.
• It's impossible for users to use it like this, and you're going to waste time.
• After one round of testing, you told your boss that you can deliver on time, no problem?
• You didn't think about testing at all when you arranged your plan, how could it be possible to finish the test in three days, three days!
• ……

Sometimes, some developers will use their technical advantages to despise testing, thinking that the testing work is low-tech, and they think that testing is subordinate and has no status, so they are not polite when they speak... The test will feel it, and in turn will have opinions on the development... That's it, from respecting each other like a guest to being full of resentment...

A friend's QQ signature file is: There is no ego, only the Dao . I figured that it would be quite applicable in software projects.

In fact, development and testing have a common purpose: to produce high-quality software. Specifically, each product, project, and version has clear goals. These goals belong to development and testing, and belong to everyone. We keep the common goal in mind, put it in the first place, we also need to think about everything other people do, all of them are aimed at the software itself, all are working hard for the goal, so that the mind will be calmer, and it will be easier to get out of the current quagmire detachment, seek common ground while reserving differences and move forward together.