Five (disrespectful) why not have testers


"Five (disrespectful) why not have testers" remarkable, in our opinion, the article Joel Spolsky, translated into Russian in 2000, and remains to date relevant and interesting material.

  • Errors occur because of laziness of programmers.
  • My software is in seti.Ya can correct the error within seconds.
  • My users test the software for me.
  • Neither good tester does not want to work tester
  • I can not afford to keep the testers!

We put the material in the section OpenContent, as we believe that the material so long published in open access and translated into several languages can claim the role of public benefits, and its author does not indicate directly or indirectly, to ban its distribution. The editors reserve the author or translator of the right to withdraw material from publication, and does so at their request.

In 1992, the software bugs to worry too much of a James Glyayka (James Gleick), the author of scientific works. Glyayk felt awful just which appeared at that time a new version of Microsoft Word for Windows. He sent in the Sunday New York Times Magazine "long scandalous article in which he ridiculed the Word development team for their insensitivity to the aspirations of clients and for the release of an extremely not regulated product.

A little later, using the services of a local Internet service provider Panix (whose services, by the way, take me), he wanted to find a way to automatically sort and filter your mail. In UNIX this is for shaman utility called procmail. Its interface is somewhat … let’s say, nevrazumitelen. Agreed with this, even the most convinced fans of UNIX.

In short, Mr. Glyayk inadvertently made an innocent typo in procmail or something like that. In general, all his mail was gone. With anger, he decided that would create his own company that provides Internet access. He hired a programmer Yudeya Ayvechuri (Uday Ivatury) and created a company Pipeline, really ahead of its time: it was the first commercial Internet service provider, offering at least some graphical user interface.
Of course, the Pipeline also had problems. The very first version, there was no correction protocol, which is quite often led to distortions in the data transfer – up to the fact that emergency conditions. In their programs, as well as in all others, were wrong. And I, when in 1993 took a job in the Pipeline, the interview asked the opinion of Mr. Glyayka written about his earlier article. "Now, when you’re on the other side," I asked, – "you have become a little bit to realize how difficult it is to create good software?"

But Glyayk not repented. He denied that there were errors in the Pipeline. He denied that his program was no better than Word. And he said to me: "Someday, you, Joel, you begin to hate Microsoft». I was amazed that despite the annual development experience – do not use, namely software development – it is not a bit did not realize how difficult to make a really reliable and easy to use product. That’s why I ran away from there, after rejecting a proposal to get a job. A Pipeline was subsequently acquired by PSI, the most bizarre Internet service provider in the world, and then was unceremoniously put to the wall and shot.
In any software has bugs. The fact that processors are extremely pedantic. They are completely child-like refusing to work with something that is not chewed for them carefully. When my laptop is away from home, he’s always buggy, because I can not find the network printer, which is used to. Wee small. And the problem is most likely, lies in a single line of code, which allowed a cheap and virtually no meaningful error.

That’s why you need to have strong control department (QCD). You will need a tester for every two programmers (and if your software needs to work with many different settings or on different operating systems, or even more). Each programmer should work closely with one tester, giving him a private assembly as often as necessary.
TCI must be independent and powerful. It should not report to the department of development. Ideally, the head of the TCI should have a veto on the issue of a product that has not passed a successful examination.

First real job in the software industry, I have received at Microsoft. She did not say to praise the high quality of its code, but still worked there quite a lot of software testers. So I thought that software development is never complete without testing.
Often this is true. But simply amazing how many companies do not have testers. In fact, many teams are not even believe in testing.

It would seem – after the mania of Quality with a capital that has engulfed the world in the 80′s, after all these senseless international certificates such as ISO-9000 and the fashion for phrases like "six sigma", the managers would have to already understand that the issue of quality products with business point of view is not so meaningless. By the way, they are, in general, it is understood. Most of them failed to realize this – head. However, they still find many reasons to decline the test software. While all of these reasons are disrespectful.
I hope I can explain to you why they are disrespectful. But if you’re in a hurry, skip the rest of this article. Just go and hire a full-time one tester for every two programmers.

So, here are the most common laments of Babylon on the topic of why do not hire testers:

1. Errors occur because of laziness of programmers.

"If we hire testers," according to this fiction on – "that programmers will work carelessly and begin to write buggy code. With the refusal of testing, we can get programmers from the very beginning to write the code correctly.

Horseradish. If you think that means you either have never written code or deceived about how it’s done. Bugs, by definition, get out, because programmers do not notice them in your own code. But in many cases simply to notice an error, can not do without a second pair of eyes.

When I wrote the code in the firm Juno, all the time I stepped on the same rake. I, for my peculiar habit, largely relied on the mouse. But our amazing, just the same supernatural testershi were slightly different habits: she often use the keyboard (while, oddly enough, did not forget to carefully check all the possible user input device for proper operation of the interface). She quickly discovered a whole gulf of errors. Sometimes she tells me that the interface does not work, just the same at 100%, even though I have it always worked fine. But when she was with me reproducing the bug, I wanted to hit himself on the forehead. Key Alt! So that’s it, you presses the Alt! And how could I not checked?

2. My software is in the network. I can correct errors in the second.

Ha-ha-ha-ha-ha! Well, suppose it is true, the network makes it possible to distribute bug fixes much faster than before, at the time of packaged products. But we should not underestimate the cost of fixing errors, even on the website after the project has already been frozen. Let’s start with that, fix one bug, you can naplodit more. But much worse is this: if you look okinete whole process, it becomes clear that putting some patches can be quite expensive alternative laid out new versions. In addition, you will make a bad impression. This is described in the following paragraph:

3. My users test the software for me.

Yeah, terrible and horrible "Protection of Netscape». This unfortunate company dealt a crushing loss of his reputation following the methodology of "testing":

  • When programmers are ready in half, lay not regulated program in the network.
  • When programmers say that they have done everything, to lay out a program not regulated in the network.
  • Repeat six or seven times.
  • Call a version of the "final".
  • Produce releases .01, .02, .03 every time on c | net to mention another ignominious failure.

This company was a pioneer in the use of the idea of "widespread beta. In a literal sense, millions of users have downloaded the unfinished and not regulated releases. During the first few years, virtually all users have Netscape was some pre-release or beta version. And, although the final release was usually quite stable, has always existed a Tuyev hucha people using intermediate versions of Netscape, that the overall impression of the program was bad enough.

In addition, the very essence of testing "your users" is that they find mistakes, and you correct them. Unfortunately, neither Netscape, nor any other company in the world does not have the human resources sufficient to razgresti 2000000 bug reports from users and determine which of these bugs are really important. When I send error reports to Netscape 2.0, then their site is constantly falling, and simply would not let me send a report (which, of course, you still have sunk into oblivion). But Netscape does not learn. Testers of the current "introductory" version 6.0, complain to the news that the site still does not send reports. Years later! All have the same problem!

I’ll bet that almost all of the myriad reports one way or another dealt with 5 or 10 really obvious mistakes. And in these haystacks are buried one or two interesting, subtle errors that someone has taken the trouble to report. But as these reports still no one is watching, mistakes are lost.

The worst thing about this method of testing is that of your company is extremely disgusting impression. When a firm Userland released the first version of its flagship Frontier for Windows, I downloaded it and started to work through the tutorial. Unfortunately, Frontier fell down several times. I literally complied with all instructions in the same order in which they were printed in a textbook, but I was not able to work with the program for more than two minutes. I got the impression that nobody in Userland not bothered to even a minimal amount of testing to make sure that at least the manual work. Poorly understood, as generally apply to such product of the word "quality". It was this that turned away from me Frontier for a very long time.

4. Neither good tester does not want to work the tester.

That is – a really serious problem. It is very difficult to find a good tester.

Among the testers, as well as among the programmers, the best order of magnitude better than the average. At Juno, we had one testersha, Jill McFarlane (Jill McFarlane), which found three times more errors than all four other testers combined. I’m not exaggerating. I really measured. She was twelve times more useful than the average tester. When she retired, I sent an email to our director, to read: "I’d rather take one Jill to work on Mondays and Tuesdays than other employees OTC, taken together, a full week."

All you can do with this problem – is to recognize that it exists, and solve it. Here are some suggestions:

  • Use testing as the next step after the tech support department career ladder. For all the boredom of testing, it is much better than the telephone to communicate with irate users. This could provide a way to suspend the turnover in the department of technical support.
  • Allow testers to improve their skills in programming courses, and encourage the brightest to the development of automated systems testing with software tools and scripting languages. It’s much more interesting than again and again and again to test the same dialogue.
  • Realize that, among the best testers will be a big turnover. Aktivno hire people to achieve a steady influx of people. Do not stop hiring just because you run out of lines in the payroll. Every day is not Sunday, will come Lent.
  • Look for the "nontraditional" employees – savvy teenagers, students, retirees, working part time. You can create a wonderful testing department of two or three highly qualified professionals working full time, and the gang lads from the Bronx Science (the strongest institution in New York), working for the payment of school.
  • Hire temporary employees. If you hire 10 temporary employees, so they came and fiddled with your product within a few days, you will find an eerie number of errors. Most likely, two or three of these workers show up the makings of a good tester, and in this case it makes sense to buy out their contract and take them to a permanent job. Pre be aware that some of the temporary staff will be useless as testers, to dissolve them in their homes and move on. Just for this, and need staffing agency hiring temporary employees.

But as it is impossible to deal with the problem:

  • Do not even think to offer a college graduate with a degree in computer science to work for you with the proviso that "everyone must go through testing before you begin writing code." I’ve seen, and not once. The programmers do not get good testers, and you’ll lose a good programmer, who replaced – much more expensive.

And finally, the number one reason for which people do not hire testers:

5. I can not afford to keep the testers!

This is the reason – the most stupid, and the easiest to debunking.

Regardless of how hard to find testers, they are still cheaper than programmers. Much cheaper. And if you do not hire testers, the test will have to deal with programmers. And if you think that the turnover rate among testers – it’s bad, wait and see how costly replacement of genius programmer at the cost of $ 100,000 per year, which will bother to listen to passages such as "spend a few weeks to test, and only after that we release a ", and which will go into a professional company. At only one commission, which will be spent searching for his replacement, you could have a year to keep the three testers.

Savings on the tester – the absurdity is so blatant that you wonder just how many people do not understand.

See Also

    Advertising

    Archives