Why develop and test the old rack?

Let's consider a few common questions:

• What is the purpose of software testing?
• Can developers build the perfect software without bugs?
• What is the relationship between the tester and the developer?
• Can software testing guarantee software quality?

Meditate for five minutes first, then try to answer the questions above.

Computer Pioneer Maurice Wikes recalled his work in Cambridge, England, in 1949, when he dragged the perforated tape upstairs to the prototype computer EDASC loader, and saw his future:

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

Maurice Wikes tells us that there is no perfect software.

I have published a recommendation in my subscription number "program Horizon", recommending the "subversion of Perfect software in the trilogy of Weinberg's technical thought": A few things that software testing must know . In this book, Weinberg also tells us that there is no perfect software. All the developers and testers should read the book.

Weinberg discusses almost all the common concepts, problems, and guidelines related to software testing in "subversion of Perfect software," so in this article, I can only come to the trough, I will from the following aspects of a number of common phenomena, hoping to arouse everyone's thinking.

• The relationship between testing and development
• Processes and standards
• Resources
• Attitude

The relationship between testing and development

is testing and development antagonistic?

From the point of view of dealing with bugs, it seems possible to say so. 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 the customer is better quality. A production bug, a bug-picking, seems to be antagonistic.

In reality, a lot of test teams and development teams do not have a relationship or even a confrontation because of this. Think about what's happening around you about development and testing, and see if you've encountered the following scenario:

• Development said that the test net trouble, customers and could not use the software as they do
• The test says that the problem always occurs under seemingly extreme conditions, and the user will always inadvertently touch the seemingly extreme impossible conditions
• Development says testing spends more time in exceptional situations than testing the main process, without knowing the priorities
• Test said that development never consider the feeling of testing, even test all the accidents will be thrown to us
• Development said, I have measured, but also test personnel what to do
• The test says that the obvious problem is that you're going to have to take our test as a trash can.
• ......

A lot of similar problems, so that the development and testing of the relationship from the confusing, love to kill the opposite. I've seen the development and testing of the Cold War someone met someone on the side face, also saw the Test manager and the development manager fights, also saw the senior leadership deliberately let the test team and development team relationship between the tension thought that this can improve testing efficiency also can give development pressure will eventually produce higher quality software ...

In fact, testing and development have the same purpose: to make the software more perfect. The relationship between testing and development is the two sides of a problem and should be mutually reinforcing and peaceful. The test is not for the trouble, and the problem he raises is not aimed at the developer of the production software, but just trying to make the developer's output look better. As long as the development does not take the test to raise the bug as the behavior of the individual, everything has a good premise.

The negation software is not the person who develops the software . This is a principle and premise that both development and testing need to be clear.

Some people think that the relationship between development and testing is similar to fur and fur, with Mao? So some development will therefore have superiority: no we write software, you test early laid off! However, development does not write software, development is also laid off yes!

Thanks to the imperfect development, so that the test can be something to do and develop the eye.

Thanks to the meticulous testing and patient thoughtfulness, so that development can find their imperfections and have the opportunity to improve themselves-those who say that my software is bad, are for my good.

Resources

Don't touch the server we're testing.

We don't have the environment, who do you use?

Who took our test phone? You apply for one, the old to occupy our equipment.

Who is using our account? Don't even say hello! I'm going to use it, get out!

Sometimes there is a conflict of resources between development and testing, there must be a creative solution to the effort (I can responsibly say that the black Apple is not a good idea), do not let the big guy's work card in the environment, this is the basic problem that managers should solve . I have seen a lot of very good front-line managers, under the constraints of reality, the initiative to make their own mobile phones, ipad to contribute to the test equipment. This is also a way to solve the problem of resources oh.

Processes and standards

Will the people around you complain like this:

• Development does not look at our test cases at all, review emails never reply
• We reported the bug, Development said the user is not possible to use, and said that we do not know how we can
• There is no test range or a few sentences in the delivery list.
• Development and adjustment design never told us.
• Why does the product manager and UI only change with the development discussion requirements?
• Why doesn't the test time be set aside for testing in the release plan?
• Why did the development write the code to test all accidents and throw it to us?
• Why did the customer find the problem in the old ask who measured, why did not measure it?
• The test keeps the bug priority set to major when it's always silent.
• Testing always spends a lot of time on features that the user simply can't use
• The test doesn't tell you what's the point, you tell him he's always a bunch of reasons.
• Test to mention the bug, the description of the phenomenon is not accurate, reproduce the steps are not, some simply know whether it is wrong operation
• Test old to interrupt me, a moment to call for a moment, there is no way to focus on development
• Jira on the bug repetition rate is too high, a problem to mention N times, can not be merged?
• Test found a bug, not a say hello to tell the boss directly, make me very passive
• Test is a special fault of the son, strong not to the positive ground son, you are testing users commonly used functions AH
• So simple bugs can flow out to the user, I really do not know how to measure the test
• The development of the old suspect test report data is not beautiful, forcing us to adjust

OK, if your side of the development and testing has never had a similar problem, it is good, congratulations, it seems that your team people nice collaboration is also very smooth, very good.

If you're surrounded by such noisy complaints, what does that mean? Is there a problem with developing, testing, and publishing this set of processes? Or does the team lack a clear direction to guide you towards positive and effective behavior?

Process and standards are always to be explained, and then the good rules, Chang can also read it oblique ...

Let's just pick a question: Why did you throw it to us when the code test was written ? The problem is pervasive, and it reflects a contradiction that is difficult to define in the work boundaries of programmers and testers.

The programmer would say, "I'll test it all over again, what do you want to do?"

Test will say, you measure all contingency, smoke can not live, there is no sense of responsibility?

The programmer said, "Should I write test cases, take various environments, traverse all kinds of normal, abnormal logic, do I have time to write code?"

Test will say, we test is the garbage bin, what bad things are thrown directly to us, our time is not worth the money?

Development will say, testing is to do this, you contingency who test?

......

A problem like this can be set up with a standard that shows what logic development to self-test cover what logic can be given to the tests to measure? Can you draw a 38 line?

No. So, at this time, the reliable front-line manager appears very important. How to creatively find a team-friendly way to make people work together smoothly, more important than standards and systems, often relies on the ability of technical managers and the awareness of team members. There is no universal way, only the right strategy for this organization, this time and place, refueling bar, in the battle to find the best way to the present.

What is a reliable, frontline manager?

The definition of leadership responsibilities in Weinberg's "becoming a technology leader" is as follows:

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

If a team of technical leaders, most of whom can concentrate on what they are capable of doing without having to spend all day in the same sort of problems as those listed earlier in this section, he is basically more reliable.

As to how long test period to test, adjust the design should not inform the test, demand adjustment should not test participation and other issues, reasonable process and standards can play a big role in supporting, technology leader as long as the rational system, guide everyone effective participation, can be resolved.

Attitude

Scenario 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 diffuse, " she found a bug" for the issue in the subscription number "program Horizon", reproduce a similar scenario, interested in the subscription number can reply 10019 view (click on the Help menu at the bottom of the subscription number "All Articles" submenu can also be found).

In the daily work of development and testing, the above scenario is constantly being staged, which is partly due to attitudes. We can sometimes hear something like the following:

• The description of the phenomenon in your bug doesn't work.
• You don't understand the logic, you don't know it.
• The test doesn't know anything ...
• You listen to me, I'll tell you how to test it.
• You are such a test, no good software can not withstand you toss
• Users can not use this, you have to complete the whole net blind delay
• After a round of testing, you tell your boss you can deliver it on schedule?
• You don't even think about testing when you plan, three days, three days how can you test it out!
• ......

Sometimes, some developers will use the technical advantages of contempt test, that the test is low in technical content, the heart of the test is subordinate to the status, the speech is not very polite ... The test will feel and in turn will have an opinion on development ... So, from Xiangjingrubin began to prosecuting ...

There is a friend of the QQ signature file is: no ego, only the avenue . I thought, in the software project, also quite applies.

In fact, development and testing have a common purpose: to produce high-quality software. Specifically, each product, project, version has a clear goal, these goals belong to the development and testing, is everyone's. We put the common goals in mind, in the first place, we also have to think about what others do, are aimed at the software itself, are in the effort to achieve the goal, so much more calm, easy to detach from the current quagmire, common ground to move forward.

Related reading :

• Become a technology leader
• A few things to know about development and testing
• She found a bug ...

For more articles, please follow the subscription number "program Horizon"(programmer_sight) or my column "talking about programmers"

Why develop and test the old rack?