Джоэл о программном обеспечении

Пять (неуважительных) причин не иметь тестеров


Joel on Software - Пять (неуважительных) причин не иметь тестеров

Пять (неуважительных) причин не иметь тестеров

Автор: Джоэл Сполски

Переводчик: Алексей Боленок

30 апреля 2000 года

В 1992 году ошибки в программном обеспечении сильно беспокоили некоего Джеймса Гляйка (James Gleick), автора научных трудов. Гляйк счёл ужасной как раз вышедшую к тому времени новую версию Microsoft Word for Windows. Он отправил в «Сандей Нью-Йорк Таймс Мэгэзин» длинную скандальную статью, в которой высмеял коллектив разработчиков Word за их невосприимчивость к чаяниям клиентов и за выпуск крайне неотлаженного продукта.

Немного позднее, пользуясь услугами местного Интернет-провайдера Panix (чьими услугами, кстати, пользуюсь и я), он захотел найти способ автоматически сортировать и фильтровать свою почту. В UNIX для этого есть шаманская утилита, которая называется procmail. Её интерфейс несколько… скажем так, невразумителен. С этим соглашаются даже самые убеждённые фанаты UNIX.

Короче, мистер Гляйк нечаянно сделал невинную опечатку в procmail или что-то в этом духе. В общем, вся его почта удалилась. Со злости он решил, что создаст собственную компанию, предоставляющую доступ в Интернет. Он нанял программиста Юдея Айвечури (Uday Ivatury) и создал компанию Pipeline, действительно опередившую своё время: это был первый коммерческий Интернет-провайдер, предоставлявший хоть какой-то графический интерфейс.

Конечно же, у Pipeline тоже были проблемы. В самой первой версии не было никакого протокола коррекции, что довольно часто приводило к искажениям при передаче данных — вплоть до того, что возникали аварийные ситуации. В их программах, как и в любых других, были ошибки. И я, когда в 1993 году устраивался на работу в Pipeline, на собеседовании поинтересовался мнением мистера Гляйка о написанной им ранее статье. «Теперь, когда вы находитесь по другую сторону баррикад», спросил я, — «вы стали хоть немного понимать, как трудно создавать хорошее программное обеспечение?»

Но Гляйк не раскаялся. Он отрицал, что в Pipeline были ошибки. Он отрицал, что его программа была ничем не лучше Word. И он сказал мне: «Когда-нибудь и ты, Джоэл, начнёшь ненавидеть Microsoft». Меня поразило то, что, несмотря на годовой опыт разработки —  не использования, а именно разработки программного обеспечения, — он ни капельки не понял, как же сложно сделать действительно надёжный и простой в использовании продукт. Поэтому я и сбежал оттуда, отклонив предложение устроиться на работу. А Pipeline впоследствии была куплена компанией PSI, самым странным Интернет-провайдером в мире, а затем была без церемоний поставлена к стенке и расстреляна.



В любом программном обеспечении есть ошибки. Дело в том, что процессоры крайне педантичны. Они совершенно по-детски отказываются работать с чем-либо, что не разжевали для них тщательнейшим образом. Когда мой ноутбук находится вне дома, он постоянно глючит, потому что не может найти сетевой принтер, к которому привык. Дитё малое. Причём проблема, скорее всего, кроется в одной-единственной строчке кода, в которой допущена копеечная и практически ничего не значащая ошибка.

Вот почему вам решительно необходимо иметь отдел технического контроля (ОТК). Вам понадобится один тестер на каждых двух программистов (а если ваше программное обеспечение должно работать с множеством различных настроек или на разных операционных системах, то и больше). Каждый программист должен плотно работать с одним тестером, предоставляя ему частную сборку настолько часто, насколько это необходимо.

ОТК должен быть независимым и могущественным. Он не должен отчитываться перед отделом разработки. В идеале, начальник ОТК должен иметь право вето на выпуск продукта, который не прошёл успешного освидетельствования.

Первую настоящую работу в индустрии программного обеспечения я получил в компании Microsoft. Она не сказать, чтобы славилась высоким качеством своего кода, но всё же там работало довольно много тестеров программного обеспечения. Поэтому я предполагал, что разработка программного обеспечения никогда не обходится без тестирования.

Зачастую это действительно так. Но просто поразительно, у скольких компаний нет тестеров. На самом деле, многие команды программистов даже и не верят в тестирование.

Казалось бы — после мании Качества с заглавной буквы, охватившей мир в 80-х годах, после всех этих бессмысленных международных сертификатов типа ISO-9000 и моды на словечки типа «шесть сигм», менеджеры должны были бы уже понять, что выпуск высококачественных продуктов с деловой точки зрения не так уж и бессмыслен. Кстати, они, в общем-то, это понимают. Большинству из них удалось осознать это — головой. Однако они всё ещё находят множество причин отказаться от тестирования программного обеспечения. Притом все эти причины неуважительны.

Я надеюсь, что смогу объяснить вам, почему же они неуважительны. Но если вы торопитесь, то пропустите остаток этой статьи. Просто ступайте и наймите на полный рабочий день одного тестера на каждых двух программистов.

Итак, вот самые распространённые плачи вавилонские на тему того, почему не надо нанимать тестеров:

1. Ошибки возникают из-за лени программистов.

«Если мы наймём тестеров», говорится в этой небылице далее, — «то программисты станут работать небрежно и начнут писать глючный код. С помощью отказа от тестирования мы сможем заставить программистов с самого начала писать код правильно».

Хрен. Если вы так думаете, значит, вы либо никогда не писали кода, либо обманываетесь насчёт того, как это делается. Глюки, по определению, вылезают потому, что программисты не заметили их в своём собственном коде. А ведь во многих случаях, чтобы просто заметить ошибку, никак не обойтись без второй пары глаз.

Когда я писал код в фирме Juno, я всё время наступал на одни и те же грабли. Я, по свойственной мне привычке, во многом полагался на мышь. Но у нашей потрясающей, просто-таки сверхъестественной тестерши были немного другие привычки: она чаще пользовалась клавиатурой (и при этом, как ни странно, не забывала тщательно проверять все возможные устройства пользовательского ввода на предмет корректной работы с интерфейсом). Она быстро обнаружила целую пропасть ошибок. Иногда она заявляла мне, что интерфейс вообще не работает, просто-таки на все 100%, хотя у меня он всегда работал замечательно. Но когда она при мне воспроизводила ошибку, мне хотелось стукнуть себя по лбу. Клавиша Alt! Так вот оно что, ты нажимала клавишу Alt! И как же это я не проверил?

2. Моё программное обеспечение лежит в сети. Я могу исправить ошибки в течение секунды.

Ха-ха-ха-ха-ха! Ну ладно, положим, это действительно так, сеть даёт возможность распространять баг-фиксы гораздо быстрее, чем раньше, во времена коробочных продуктов. Но не следует занижать стоимость исправления ошибки, даже на веб-сайте, после того, как проект уже был заморожен. Начнём с того, что, исправив одну ошибку, вы можете наплодить ещё больше. Но гораздо хуже вот что: если вы окинете взглядом весь процесс, вам станет ясно, что выкладывание исправлений может оказаться довольно дорогой альтернативой выкладыванию новых версий. Помимо этого, вы произведёте плохое впечатление. Это описано в следующем пункте:

3. Мои пользователи протестируют программное обеспечение за меня.

Ага, страшная и ужасная «Защита Netscape». Эта несчастная компания нанесла сокрушительный урон своей репутации следующей методологией «тестирования»:

  • Когда у программистов всё готово наполовину, выложить неотлаженную программу в сеть.
  • Когда программисты говорят, что у них готово всё, выложить неотлаженную программу в сеть.
  • Повторить шесть-семь раз.
  • Назвать одну из версий «окончательной».
  • Выпускать релизы .01, .02, .03 каждый раз, когда на c|net упомянут об очередной позорной ошибке.

    • Эта компания была первопроходцем в использовании идеи «широкого распространения бета-версий». В буквальном смысле этого слова миллионы пользователей скачали незаконченные и неотлаженные релизы. В течение первых нескольких лет практически у всех пользователей Netscape стоял какой-нибудь предварительный релиз или бета-версия. И, хотя окончательный релиз обычно был достаточно стабилен, всегда существовала такая туева хуча людей, пользующихся промежуточными версиями Netscape, что общее впечатление о программе было достаточно скверным.

    Кроме того, самая суть тестирования «вашими пользователями» состоит в том, что они находят ошибки, а вы их исправляете. К сожалению, ни Netscape, ни  какая-либо другая компания в мире не обладает людскими ресурсами, достаточными, чтобы разгрести 2 000 000 отчётов об ошибках от пользователей и решить, какие из этих ошибок по-настоящему важны. Когда я посылал отчёты об ошибках в Netscape 2.0, то их сайт постоянно падал и просто-напросто не давал мне отправить отчёт (который, конечно же, всё равно канул бы в Лету). Но Netscape ничему не учится. Тестеры текущей «ознакомительной» версии, 6.0, жалуются в новостях, что сайт по-прежнему не даёт посылать отчёты. Годы спустя! Всё та же проблема!

    Готов спорить, что почти все из мириад отчётов так или иначе касались 5 или 10 действительно очевидных ошибок. И в этих стогах сена похоронены одна или две интересных, трудноуловимых ошибки, о которых кто-то дал себе труд сообщить. Но, так как на эти отчёты всё равно никто не смотрит, ошибки потерялись.

    Самое плохое в таком способе тестирования то, что о вашей компании составляется в высшей степени отвратительное впечатление. Когда фирма Userland выпустила первую версию своего ведущего продукта Frontier for Windows, я скачал её и начал прорабатывать учебное пособие. К сожалению, Frontier несколько раз упал. Я дословно выполнял все инструкции в том же порядке, в котором они были напечатаны в учебном пособии, но я не смог проработать с программой более двух минут. У меня создалось впечатление, что никто в Userland не озаботился даже минимальным объёмом тестирования, чтобы убедиться, что хотя бы учебное пособие работает. Плохо понятно, как вообще применять к такому продукту слово «качество». Это-то и отворотило меня от Frontier на очень долгое время.

    4. Ни один хороший тестер не хочет работать тестером.

    Вот это — действительно серьёзная проблема. Очень сложно найти хорошего тестера.

    Среди тестеров, как и среди программистов, лучшие на порядок лучше средних. В Juno у нас была одна тестерша, Джил Макферлейн (Jill McFarlane), которая находила в три раза больше ошибок, чем все четверо других тестеров, вместе взятых. Я не преувеличиваю. Я это действительно измерял. Она была в двенадцать раз полезнее среднего тестера. Когда она уволилась, я послал нашему директору электронное письмо следующего содержания: «Я бы лучше взял одну Джил работать по понедельникам и вторникам, чем остальных сотрудников ОТК, вместе взятых, на полную неделю».

    Всё, что можно сделать с этой проблемой — это признать, что она существует, и решать её. Вот несколько предложений:

  • Используйте тестирование как следующую после отдела техподдержки ступень карьерной лестницы. При всей нудности тестирования, оно гораздо лучше телефонного общения с разгневанными пользователями. Это может послужить способом приостановить текучку в отделе техподдержки.
  • Позволяйте тестерам повышать свою квалификацию на курсах программирования, и поощряйте самых умных к разработке автоматизированных комплексов тестирования при помощи программных инструментов и сценарных языков. Это гораздо интереснее, чем снова, и снова, и снова тестировать один и тот же диалог.
  • Осознайте, что среди лучших тестеров будет большая текучка. Активно нанимайте народ, чтобы добиться постоянного притока людей. Не останавливайте приём на работу только потому, что у вас кончились строчки в зарплатной ведомости. Не всё коту масленица, придёт Великий Пост.
  • Ищите «нетрадиционных» сотрудников — сообразительных подростков, студентов, пенсионеров, работающих на полставки. Вы можете создать великолепный отдел тестирования из двух-трёх высококлассных профессионалов, работающих на полную ставку, и ватаги парнишек из Бронкс-Сайенс (сильнейшего вуза Нью-Йорка), работающих за оплату учёбы.
  • Нанимайте временных сотрудников. Если вы наймёте 10 временных сотрудников, чтобы они пришли и повозились с вашим продуктом в течение нескольких дней, вы найдёте жуткое количество ошибок. Скорее всего, у двух или трёх из этих работников обнаружатся хорошие задатки тестеров, и в этом случае имеет смысл выкупить их контракт и взять их на постоянную работу. Заранее отдавайте себе отчёт, что некоторые из временных сотрудников будут бесполезны в качестве тестеров; распустите их по домам и двигайтесь дальше. Как раз для этого и нужны кадровые агентства по найму временных сотрудников.

    • А вот как нельзя бороться с проблемой:

  • Даже и не думайте предлагать выпускникам колледжа по специальности «вычислительная техника» поработать у вас с тем условием, что «каждый должен пройти через тестирование прежде, чем приступить к написанию кода». Я такое видел, и не раз. Из программистов не получается хороших тестеров, и вы потеряете хорошего программиста, заменить которого — гораздо дороже.

    • И, наконец, причина номер один, по которой люди не нанимают тестеров:

    5. Я не могу позволить себе держать тестеров!

    Эта причина — самая глупая, и легче всего поддаётся развенчиванию.

    Вне зависимости от того, как тяжело найти тестеров, они всё равно дешевле программистов. Намного дешевле. И если вы не нанимаете тестеров, то тестированием придётся заниматься программистам. И если вы думаете, что текучка среди тестеров — это плохо, подождите, и вы увидите, как дорого обойдётся замена гения-программиста ценою в 100 000 $ в год, которому надоест выслушивать пассажи типа «потрать несколько недель на проверку, и только после этого мы выпустим релиз», и который уйдёт в более профессиональную компанию. На одни только комиссионные, которые будут потрачены на поиск его замены, вы смогли бы целый год держать трёх тестеров.

    Экономия на тестерах — нелепость настолько вопиющая, что просто диву даёшься, как много людей этого не понимают.



    В английском оригинале статья называется Top Five (Wrong) Reasons You Don't Have Testers  


    Джоель Спольски - основатель Fog Creek Software, небольшой компании по
    разработке программного обеспечения, расположенной в Нью-Йорке.
    Окончил Йельский Университет, работал программистом и управляющим в
    Microsoft, Viacom и Juno.

    Содержимое этих страниц представляет собой мнение одного человека.
    Всё содержимое Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

    FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky



    Содержание раздела