Текст книги "tестирование dot com"

Автор книги: Роман Савин

сообщить о нарушении

Текущая страница: 5 (всего у книги 17 страниц)

началась.

14 ноября. У Буханкина новая идея. Спек по-тихому изменен.

15 ноября. Спек распечатывает для себя программист Ложкин. Работа

по спеку началась.

16 ноября. У Буханкина новая идея. Спек по-тихому изменен.

17 ноября. Спек распечатывает для себя программистТарелкин. Работа

по спеку началась.

18 ноября. У Буханкина новая идея. Спек по-тихому изменен.

19 ноября. Спек распечатывает для себя программист Салфетка, рабо-

тающий над кодом по интеграции функциональности кода из этого

и своего спека. Работа по спеку началась.

25 декабря. Все выясняется. 30

декабря.

17:00 – начало празднования Нового года в офисе компании.

17:30 – начало избиения Буханкина руками Ножова, Ложкина и Та-

релкина.

18:00 – начало избиения Буханкина ногами Ножова, Ложкина и Та-

релкина.

18:30 – в офис влетает Салфетка, вернувшийся после разговора с

менеджером, разбрасывает в стороны подуставших Ножова,

Ложкина и Тарелкина и добивает Буханкина контрольным

ударом клавой по голове.

Надо отметить, что во многих случаях спек меняется не по воле

продюсера, а по приказу сверху.

Ситуация

25 марта.

Менеджер присылает продюсеру е-мейл, что необходимо срочно

изменить спек #8337.

За день до этого, т.е. 24 марта.

Представьте себя на месте продюсера:

продюсер уже вовсю работает над новым спеком и надеется, что

релиз функциональностей согласно спеку #8337 пройдет без сучка

без задоринки.

Представьте себя на месте программиста: код для спека

#8337 написан, влегкую протестирован самим программистом,

частично позабыт и уже кажется частью безвозвратно потерянной

юности.

Представьте себя на месте тестировщика:

документация для тестирования спека #8337 написана. Новые проекты

бьют в паруса, и настоящее наконец-то стало залечивать раны прошлого.

На следующий день, т.е. 26 марта.

Спек #8337, а также код и тест-кейсы к нему должны быть изменены,

т.е. минимум трое работников должны

Цикл разработки ПО

79

• бросить текущие проекты,

• вспомнить спек #8337, понять изменения к нему и

• потратить время на воплощение изменений.

Эта ситуация является идеальной питательной средой для воз-

никновения багов, так как это будет работа (включая продюсера)

на скорую руку, как правило, без возможности погрузиться в этот

прошлый проект и понять риск внесения изменений. Мало того,

новые проекты также могут

а) пострадать или

б) даже быть отложенными

из-за того, что

а) на них будет потрачено меньше времени или

б) времени может физически не хватить.

Что же нам делать, чтобы избежать кордебалета с изменяю-

щимися спеками?

Если менеджер говорит, что нужно изменить спек, или продюсер

"вспомнил" о реально важной вещи для спека и эти "НУЖНО"

или "ВСПОМНИЛ" приходятся на самое наинеподходящее время,

то никуда не денешься, но все же две очень нехорошие ситуации,

связанные с изменением спека, можно превентировать.

Две нехорошие ситуации:

1. Спек может быть изменен по-тихому.

2. Изменения к спеку не утверждены программистом и тес-

тировщиком.

Вопрос: Как конкретно мы превентируем две нехорошие ситуации?

Ответ: Мы заморозим спек.

В любой интернет-компании существует программа контроля за

версиями. Во многих случаях это старая добрая CVS («си-ви-эс» —

Concurrent Version System – система по согласованным версиям).

CVS – вещь многофункциональная, и мы о ней еще поговорим,

но сейчас она нам будет полезна для следующего:

1. С помощью CVS продюсер может сохранять версии спека и

всегда вернуться к старым редакциям.

2. С помощью CVS можно «закрыть» директорию так, чтобы

документы из этой директории могли читаться, но не мог-

ли редактироваться.

80

Тестирование Дот Ком. Часть 1

Процессуально все можно сделать так:

1. К определенной дате все спеки должны быть утверждены.

Неутвержденный спек не кодируется, и точка.

2. Директория со всеми утвержденными спеками закрывается,

и никто ничего не может изменить в этой директории...

...если только не будет следовать процедуре изменения спека.

Кстати,

техническую сторону, связанную с заморозкой спеков (spec freeze), обес-

печивают инженеры по релизу.

Процедура включает:

1. Утверждение всех изменений составом лиц, утвердившим

предыдущую редакцию.

2. Посылку е-мейла с перечислением изменений и именами

утвердивших всем департаментам, непосредственно свя-

занным с разработкой ПО (продюсеры, программисты,

тестировщики и инженеры по релизу). Одно из хороших

качеств такого е-мейла – это то, что люди, не участво-

вавшие в пункте 1 и имеющие старую версию спека, тоже

узнают об изменениях.

3. Открытие CVS-директории для закладки файла и ее закрытие.

Конечно, без изменений в спеках не обойтись, но путем

1) замораживания спеков;

2) введения процедуры изменения спека;

3) тщательного рассмотрения необходимости каждого из-

менения спека с участием менеджмента

можно превентировать ряд серьезных проблем с качеством.

Идем дальше.

Одна из частых причин, по которым в ПО появляются баги кода, —

это неверное толкование спека (misinterpretation) – ситуация,

когда программисты и/или тестировщики, работающие со спе-

ком, понимают по-своему то, что пытался донести до них продю-

сер, и при этом

• на 100% уверены, что на 100% понимают то, что имел в

виду продюсер, и,

• имея уверенность, не уточняют, так как не будешь же бе-

гать за уточнениями того, что тебе и так ясно.

Цикл разработки ПО

81

Причина неверного толкования спека может быть связана

• с одной стороны, с возможностью множественного тол-

кования некой части спека и,

• с другой – с тем фактом, что многие вещи в этой жизни,

для того чтобы быть адекватно понятыми разными людь-

ми, нуждаются в многоплановой презентации.

Кстати, именно поэтому на чертеже физического объекта (например,

двигателя мотоцикла) последний обычно изображается с трех сторон:

вид спереди, вид сверху и вид слева.

Тезис

Тестировщики должны настаивать, чтобы спеки по максимуму

иллюстрировались:

• макетами (mock-up),

• блок-схемами (flow chart),

• примерами (example).

Аргументация

С примерами все понятно: написал что-то – придумай пример

для иллюстрации, заодно и сам лучше поймешь, о чем пишешь.

Народная мудрость гласит: "Лучше один раз увидеть, чем сто раз

услышать". Отличной идеей является разработка продюсером

макетов интерфейса пользователя (User Interface или просто UI —

"ю-ай"). Делается это так:

во время (или после) написания спека продюсер берет генератор

веб-страниц типа Microsoft FrontPage и путем нехитрых манипу-

ляций создает веб-страницу с кнопками, полями, картинками и

прочими милыми деталями интерфейса.

Затем эта страничка "подшивается" к спеку и помогает всем за-

интересованным лицам увидеть, ЧТО, по замыслу продюсера,

должен будет увидеть пользователь.

Кстати, если спецификация предусматривает, что пользователь будет

проходить через несколько веб-страниц для совершения какого-либо

действия (например, покупки книги), то макеты этих веб-страниц могут

не только являться частью спека, но и служить в качестве обоев, если

их развесить на стенах офиса в том порядке, в котором их будет видеть

пользователь.

82

Тестирование Дот Ком. Часть 1

Пример

Вольное изложение опека #1023 «Регистрация нового пользователя»:

Регистрация пользователя состоит из трех страниц, идущих в следую-

щем порядке:

• первая страница (1) – поле для индекса места жительства

пользователя и кнопка «Продолжить регистрацию»;

• вторая страница (2) – поля для имени, фамилии, е-мейла и па-

роля/подтверждения пароля пользователя, кнопка "Зарегистри-

роваться";

• третья страница (3) – текст с подтверждением регистрации.

Все поля обязательны для заполнения, и если на странице (1) или (2)

вводится недействительное либо пустое значение любого поля, то

пользователю показывается та же страница, но с сообщением об

ошибке (error message). (В данном случае мы не будем говорить о том,

какой ввод действителен (легитимен) для каждого из полей, так как это

сейчас неважно.)

Продюсер разрабатывает три страницы, распечатывает их в двух ком-

плектах, один из которых подшивает к спеку, а другой развешивает на

стене в порядке появления перед пользователем: страница (1), стра-

ница (2), страница (3).

Оговорка 1: Макеты могут быть разной степени детализации, и

вполне допустимо, когда элементы интерфейса, не имеющие от-

ношения к иллюстрируемому спеку, не включаются в макет, на-

пример, в случае с макетами для регистрации нас не интересуют

картинки на веб-странице.

Оговорка 2: Понятно, что макеты интерфейса пользователя не

создаются, если спек полностью посвящен бэк-энду веб-сайта

(например, спек "Автоматизация отчетов по продажам"), так как

детали интерфейса пользователя, т.е. фронт-энд, в таком спеке

просто не упоминаются.

Проблема макетов (даже развешанных правильно) заключается в

том, что они позволяют увидеть в первую очередь интерфейс

пользователя, а не логику работы кода позади интерфейса, на-

зываемую алгоритмом программы.

Интерфейс – это то, ЧТО видит пользователь, а алгоритм –

это то, ПОЧЕМУ пользователь видит то, что он видит.

Для графической презентации алгоритмов используются блок-

схемы, так горячо любимые всеми выпускниками математиче-

ского класса выпуска 1990 г. люберецкой школы № 12.

Цикл разработки ПО

83

Пример

Представим предыдущую ситуацию с регистрацией, но в форме блок-

схемы (такая блок-схема называется process flow chart, так как устроена

по схеме ввод->процесс->вывод).

Кстати, блок-схемы могут создаваться как продюсером, так и

тестировщиком, но независимо от составителя, как правило,

прекрасной идеей является включение блок-схемы в секцию тест-

комплекта GLOBAL SETUP and ADDITIONAL INFO.

Блок-схемы, макеты и примеры (вместе именуемые БМП) помо-

гают превентировать появление багов или найти баги на

уровне спека следующими путями:

84

Тестирование Дот Ком. Часть 1

• БМП – это описание предмета с разных сторон, что ведет

к его адекватному толкованию разными людьми;

• создание БМП – это процесс переосмысления написан-

ного, что ведет к нахождению багов в написанном, т.е. в

спеке;

• макеты и блок-схемы наглядны и во многих случаях по-

зволяют в буквальном смысле увидеть баги в отличие от

ситуации, когда есть только текст.

Еще раз: тестировщики должны настаивать, чтобы спеки по

максимуму иллюстрировались макетами (тоск-ир), блок-схе-

мами (flow chart) и примерами (example).

Теперь, после того как вы услышали про макеты и пошли дальше,

не увидев их (что было сделано намеренно – с целью дать вам

прочувствовать контраст между работой без макетов и с ними),

позвольте представить вам макеты «Регистрации»:

Макет страницы (1)

Макет страницы (2)

* поле обязательно для заполнения

Цикл разработки ПО

85

Макет страницы (3)

Регистрация завершена, Нажмите сюда для

логина

Бонус: Макет страницы (2) в случае ошибки пользователя при

заполнении поля "Е-мейл"

Ошибка

I Проверьте правильность заполнения поля:

Е-мейл

2. Заново введите пароль

* поле обязательно для заполнения

Кстати, макет страницы (2) и бонус-макет страницы (2) противоречат

спеку: по спеку поле «Фамилия» является обязательным для заполнения, но

на макетах оно не выделено звездочкой. Противоречие внутри спека —

это баг, так как любая инструкция теряет смысл, если ее указания не

стыкуются друг с другом.

Постановка мозгов

При обнаружении противоречий внутри спека (а БМП – это части спека!)

нужно сделать рапорт о баге против продюсера, чтобы тот настроил в

унисон несогласующиеся части. В нашем случае продюсер должен из-

менить либо текстовую часть спека ("все поля являются обязательными,

кроме поля «Фамилия»), либо соответствующие макеты (добавить

звездочку к полю «Фамилия»).

Идем дальше.

86

Тестирование Дот Ком. Часть 1

В заключение краткого экскурса о спеках дам еще одну полезную

идею.

Каждая более или менее уважающая себя компания имеет свой

сайт в локальной сети (intranet), который недоступен внешним

пользователям. На этом сайте можно прочитать тезисы о корпо-

ративной морали, узнать имя любимого лемура президента ком-

пании, посмотреть фотографии тех, кто по-тихому правит утвер-

жденные спеки, и найти много другой полезной информации. Так

вот, все когда-либо утвержденные спеки должны быть выло-

жены на этот сайт. При этом они группируются по номеру релиза

и доступны для просмотра, поиска по директориям (название

директории – номер релиза), ID, ключевым словам в названии и

имени продюсера. Если спек ссылается на внешний документ

(например, на правила расчетов Центрального банка), то спек

должен содержать гиперлинк на адрес такого документа в локаль-

ной сети.

Постановка мозгов

Не стесняйтесь рапортовать баги, которые вы будете находить в

спеках. Если продюсеры не понимают, то объясните им без пере-

водчика, что баги, посеянные в спеке, могут, как зараза, перенестись

в код и тест-кейсы и баг, найденный раньше, стоит компании дешевле

(об этом чуть позже), а посему учет таких багов является не правом,

а обязанностью тестировщиков.

Следующий этап цикла разработки ПО – это кодирование, осу-

ществляемое программистами (в то время как тестировщики

планируют проверку пишущегося кода).

Кодирование

Работа программиста заключается в том, чтобы перевести вещи,

отраженные в спецификации (или словах босса), на язык про-

граммирования.

Перевод осуществляется

• напрямую, т.е. программист берет спек и напрямую кодирует

его предписания (плохая, недальновидная и опасная идея),

• или после создания внутреннего дизайна кода, т.е. сугубо

технической документации, планирующей, как требова-

ния спека будут воплощены в коде (хорошая, дальновидная

и благодарная идея).

Цикл разработки ПО

87

К документам о внутреннем дизайне кода относятся, например,

• документ о дизайне /архитектуре системы (System /Architec-

ture Design Document);

• документ о дизайне кода (Code Design Document).

развитие культуры создания и поддержания документации о

внутреннем дизайне кода – это один из признаков, что стар-

тап из шарашкиной конторы (пусть даже и с миллионным

финансированием) превращается в серьезную софтверную

компанию.

Идем дальше.

В идеальном случае каждый программист имеет личную версию

сайта (или playground– игровую площадку), в которую входят:

• веб-сервер (web server);

• сервер с приложением (application server);

• база данных (database).

Коротко остановимся на каждом из этих компонентов.

Пример

1. Пользователь набирает в браузере: www.testshop.rs. Через Интернет

запрос идет на веб-сервер, и в ответ на жесткий диск пользователя

сыпятся:

• файл index.htm, содержащий HTML (Hyper Text Markup Language)-код с

инкорпорированным в нем JavaScript (читается как «джава-скрипт»)–

кодом;

• файлы-картинки (images), на которые ссылается веб-страница

index.htm. Эти картинки пользователь должен увидеть в веб-брау-

зере на веб-странице index.htm.

Кстати, первая страница веб-сайта, которую мы по умолчанию видим

в веб-браузере после набора URL веб-сайта (например, www.google.com),

называется homepage.

Кстати, коммуникация между веб-браузером и веб-сервером осуще-

ствляется путем обмена сообщениями, основанными на протоколе, т.е.

своде правил, называемом HTTP (Hyper Text Transfer Protocol). Потоки

таких сообщений, передающихся по компьютерной сети, называемой

Интернетом, являются HTTP-трафиком (HTTP traffic).

2. Пользователь кликаетлинк «Регистрация» (веб-сервер присылает в

ответ файл register.htm и слинкованные с ним картинки).

3. На странице register, htm пользователь вводит имя, е-мейл и прочие

данные и отправляет форму, нажав кнопку «Зарегистрироваться».

88

Тестирование Дот Ком. Часть 1

4. Через веб-сервер эта форма, т.е. запрос о регистрации, поступает

на сервер с приложением, которое

• обрабатывает этот запрос;

• запрашивает базу данных, есть ли уже эккаунт с таким е-мейлом;

• обрабатывает ответ от базы данных;

• если е-мейл не найден, посылает запрос к базе данных о созда-

нии записи для нового пользователя;

• формирует ответ для пользователя;

• в виде веб-страницы с подтверждением регистрации или веб-стра-

ницы с ошибкой посылает пользователю ответ через веб-сервер.

Так вот, программисты разрабатывают код вышеупомянутого

приложения, который впоследствии отдается на растерзание тес-

тировщикам, в злорадном предвкушении потирающим ручонки и

знающим, что причинами возникновения багов в коде явля-

ются как возможность программиста полдня бродить по Интер-

нету, так и другие объективные вещи:

а. Некачественные и/или изменяющиеся спецификации

Об этом мы уже говорили.

б. Личностные качества программиста

Такие, как халатность, невнимательность и лень.

в. Отсутствие опыта

Программист может просто не знать, как нужно сделать пра-

вильно.

г. Пренебрежение стандартами кодирования

О стандартах чуть позже.

д. Сложность системы

Современные интернет-проекты отличаются такой сложностью,

что мозг простого смертного порой просто не в состоянии про-

анализировать все последствия создания/изменения/удаления

кода и предугадать появление проблемы.

е. Баги в ПО третьих лиц, т.е. баги

• в операционных системах;

• в компайлерах (compiler – ПО для переведения (напри-

мер, C++) кода в машинный язык и создания исполняе-

мых файлов);

• в веб-серверах;

• в базах данных и др.

Цикл разработки ПО

89

ж. Отсутствие юнит-тестирования,

х.е. тестирования кода самим программистом: "И вообще, почему

я должен искать баги в своем коде, когда есть тестировщики?"

(Поговорим о юнит-тестировании через минуту.)

з. Нереально короткие сроки для разработки

Об этом мы тоже скоро поговорим.

Возможности оздоровления кода и превентирования багов до

передачи кода тестировщикам (иллюстрации последуют не-

медленно) включают:

1. Наличие требований к содержанию спеков и следова-

ние правилам их изменения;

2. Возможность прямой, быстрой и эффективной комму-

никации между программистами и программистами и

продюсерами;

3. Инспекции кода;

4. Стандарты программирования;

5. Реальные сроки;

6. Доступность документации;

7. Требования к проведению юнит-тестирования (о кото-

ром мы поговорим уже через 30 секунд);

8. Реальные финансовые рычаги стимуляции написания

эффективного и «чистого» кода;

9. Наличие понятий «качество» и «счастье пользователя»

как основных составляющих корпоративной философии.

Подробности.

1. НАЛИЧИЕ ТРЕБОВАНИЙ К СОДЕРЖАНИЮ СПЕКОВ

И СЛЕДОВАНИЕ ПРАВИЛАМ ИХ ИЗМЕНЕНИЯ

О спеках мы уже говорили.

2. ВОЗМОЖНОСТЬ ПРЯМОЙ, БЫСТРОЙ И ЭФФЕКТИВНОЙ

КОММУНИКАЦИИ МЕЖДУ ПРОГРАММИСТАМИ

И ПРОГРАММИСТАМИ И ПРОДЮСЕРАМИ

Здесь есть следующие аспекты:

а. Психологические аспекты

Очень важно привить в культуру компании следующее правило:

«Если к тебе обратились – помоги».

90

Тестирование Дот Ком. Часть 1

Пример

Программист приходит к продюсеру с просьбой объяснить некую часть

спека. Продюсер говорит, что он сейчас слишком занят. "Давай завтра,

добро?"

Очень часто после пары «давай завтра» программист что делает? Пра-

вильно! Он пишет код так, как его понимает, – без всякой гарантии, что

сей код отразит требуемое.

Следующий аспект:

программист (как и все остальные участники цикла) никогда не

должен стесняться спрашивать (хоть двести раз!) и подтверждать

свое понимание е-мейлами типа: "Просто хотел уточнить, что я

правильно понял, что пункт 12.2 такого-то спека говорит..." Если

же программисту не отвечают, когда он подходит, прекрасно —

нужно послать е-мейл и сохранить этот е-мейл, как и е-мейлы "Я

хотел уточнить". Если снова не отвечают, программист должен

идти к своему менеджеру и просить его принять меры. И это не

стукачество, а деловая практика – business is business.

Следующий аспект:

Менеджмент должен регулярно устраивать так называемые Team

Building Activities (мероприятия по сплочению коллектива) с той

простой целью, чтобы между членами команды кроме профес-

сиональных налаживались и человеческие контакты. Причем, как

показывает опыт, совместный выезд для игры в пейнтбол раз в

месяц гораздо эффективнее для сплочения коллектива, чем со-

вместная проспиртовка мозгов во время пятничных застолий.

б. Технический аспект

Каждый из участников цикла разработки ПО должен быть досту-

пен для контакта: желательно, чтобы все они работали в одном

здании; в локальной сети должны быть доступны служебные, мо-

бильные и домашние телефоны; необходимо согласовать часы

(хотя бы 4 часа в день), когда все (и тот, кто ушел в 6 часов вече-

ра и в 3 утра) находятся в офисе.

3. ИНСПЕКЦИИ КОДА

У некоторых программистов есть такая концепция: "Если я пишу

код, который могу понять только я, то меня не уволят".

Ну, во-первых, при желании можно уволить даже президента

"ЮКОСа", во-вторых, такой подход к работе априори неправи-

Цикл разработки ПО

91

лен: в интернет-компаниях никто никого силком не держит, и

если ты согласился работать на определенных условиях, то будь

добр работать профессионально и добросовестно.

Если же компания не выполняет взятых на себя обязательств

(например, по оплате), то мы просто ищем другую компанию —

ведь никто никому не давал клятву верности.

Постановка мозгов

Компания держит каждого из нас до тех пор, пока мы ей нужны, и если

какая-то конкретная позиция перестает быть необходимой для бизне-

са, то человеку просто говорят: «Гуд бай» независимо от того, сколько у

него

детей плачет по лавкам;

котов мяукает по печкам.

Как поет Тимур Шаов: «Это бизнес, господа...»

Вместе с тем, если вы находите компанию с лучшими для себя усло-

виями и, работая на старом месте, прошли интервью и получили

письменное предложение о работе, то вы просто идете к своему ме-

неджеру и говорите, что собрались уходить, но можете подумать о том,

чтобы остаться, только если компания сделает для вас то-то и то-то,

например повысит заработную плату.

Несмотря на то что бизнес есть бизнес, нужно оставаться профессио-

налом, даже если предложение о новой работе удивительно выгодно и

искушение все бросить велико. Никогда не уходите из компании, не

передав дела и не закончив старые проекты. Ведите себя про-

фессионально !

После небольшого отступления продолжаем основную тему.

В-третьих, чтобы избежать подобных проблем, чреватых багами

и трудностью их фиксирования (fix – починка, ремонт), в ком-

пании должны проходить инспекции кода (code inspection).

Это может быть еженедельное совещание, например, следующего

формата: менеджер программистов распечатывает код любого из

программистов, и последний в присутствии коллег рассказывает,

что, как и почему. Будет ли программист писать код, понятный

только ему, если на совещании его обязательно спросят: "Това-

рищ, а что это вы здесь написали?"

4. СТАНДАРТЫ ПРОГРАММИРОВАНИЯ

С пунктом 3 перекликается идея создания стандартов програм-

мирования.

92

Тестирование Дот Ком. Часть 1

Пример

Вспомним Вавилонскую башню, а вернее, ТОТ момент строительства,

когда все вдруг стали говорить на разных языках (множественность

стандартов). Последствия печальны: проект был начисто заброшен,

название кинокомедии «Some like it hot» перевели как "В джазе только

девушки" и японские фанатки «Тагу» убеждены, что «Мальчигей» – это

название места для романтических свиданий нетрадиционных девушек

на Красной площади.

Такая же катавасия творится в компании, когда программисты

вроде бы и используют тот же язык, например C++, но при напи-

сании кода каждый руководствуется своими привычками.

Пример

Допустим, что отсутствуют стандарты названия новых классов C++.

S этом случае, если Саня любит называть свои классы в формате

«CREDITCARD» (все заглавные и нижнее подчеркивание), а

Леха – «CreditCard» (заглавные только первые буквы каждого слова

и слитное написание),

то, например, Леха, не зная о привычках Сани, но верный своим при-

вычкам, помня лишь «Кредиткард» и желая обратиться к функции из

CREDITCARD, в своем коде так и запишет: «CreditCard». В итоге код не

будет работать, так как C++, ничего не знающий ни о Лехе, ни о Сане, ни о

кредитных картах, думает о CREDITCARD и CreditCard как об

абсолютно разных классах.

Стандарты могут включать:

• правила о комментариях;

• правила об именах таблиц в базе данных, классов, функций

и различных видов переменных;

• правила о максимальной длине строки;

• прочее.

Документ со стандартами должен быть доступен на интранете.

Стандарты программирования – это неотъемлемая часть

процесса, когда в компании работают два программиста и боль-

ше. Они по определению должны быть обязательны для всех.

5. РЕАЛЬНЫЕ СРОКИ

В стартапе изначально и по определению сроки на разработку

нереальны, и приходится балансировать между

• "поспешишь – людей насмешишь" и

• необходимостью закончить кодирование в срок.

Цикл разработки ПО

93

Несмотря на то что стопроцентно действующих рецептов нет, вот

хорошая идея для облегчения нелегкой жизни программистов:

после ознакомления со спеками программисты должны предос-

тавить менеджменту примерные оценки (сметы) сроков для

разработки кода, и исходя из этих смет менеджмент может,

если нужно

• перераспределить нагрузку и

• посмотреть, имеет ли смысл убирать что-то из менее

приоритетных функционалъностей ради того, чтобы

чисто и тщательно написать остальной код.

Единственное утешение состоит в том, что, когда стартап как

бизнес становится более зрелым, сроки и рабочие часы стабили-

зируются во многом потому, что менеджмент понимает, что луч-

ше дать реальный срок (например, перенеся некоторые из спеков

в следующие релизы), чем поступиться качеством.

6. ДОСТУПНОСТЬ ДОКУМЕНТАЦИИ

ВСЕ документы, относящиеся к разработке ПО, включая спеки,

процедуру изменения спека, стандарты программирования, тест-

комплекты, и документы, о которых мы будем говорить в даль-

нейшем, должны быть доступны в локальной сети, и их располо-

жение должно быть максимально оптимизировано для удобства и

быстроты поиска. Все должно быть сделано для того, чтобы за-

интересованный сотрудник быстро нашел нужный документ, а не

тратил свое время и время своих коллег на долгие поиски.

Несмотря на кажущуюся очевидность и легковесность этого мо-

мента, несоблюдение правила о доступности ВСЕХ документов

на практике может принести много проблем.

7. ТРЕБОВАНИЯ

К ПРОВЕДЕНИЮ ЮНИТ-ТЕСТИРОВАНИЯ

Юнит-тестирование (unit testing) – это тестирование, произ-

водимое самим программистом. Здесь нужно подчеркнуть, что

неправильный подход к введению юнит-тестирования вызо-

вет справедливое раздражение программистов, так как за тес-

тирование платят тестировщикам, а отсутствие требований к

юнит-тестированию вообще увеличит стоимость багов.

94

Тестирование Дот Ком. Часть 1

Постановка мозгов

Стоимость бага – это

• расходы компании, чтобы найти баг и исправить его до пе-

редачи кода пользователю. Расходы компании поддаются

приблизительной оценке;

• убытки, которые несет компания, потому что баг не был

найден до передачи кода пользователю. Объективная оценка

убытков в большинстве случаев невозможна.

Подробности:

Стоимость бага в первом случае:

Если баг был допущен на уровне спека и найден во время тестирования

кода, его стоимость вычисляется как

стоимость оплаты продюсера в час, помноженная на количество

часов, потраченных на разработку «неправильной» части спека

(стоимость спека), плюс + стоимость программирования

«неправильной» части спека плюс + стоимость тестирования

«неправильной» части спека плюс + стоимость фиксирования бага и

проблем, из него вытекающих.

Как видно, слагаемые поддаются приблизительной оценке.

Стоимость бага во втором случае:

Если баг был допущен на уровне спека, но не придушен до релиза и найден

пользователем, то к стоимости, вычисляемой по формуле предыдущего

случая, могут прибавиться десятки других убытков (включая упущенную

выгоду), например:

• время службы поддержки;

• компенсации пользователю потерянных денег;

• иски против компании;

• навсегда утраченная потенциальная оплата услуг компании ушед-

шими пользователями и пользователями, которые по рекомендации

ушедших никогда не заглянут на ваш веб-сайт,

а также множество других плохих и неприятных вещей.

Наиболее важное в концепции стоимости бага – это то, что чем раньше

будет найден баг, тем он будет дешевле для компании.

Таким образом, баг (а это, как мы знаем, может быть и отклонение от

здравого смысла), найденный на уровне идеи, – это самый дешевый

баг, соответственно баг, найденный после релиза, – это самый

дорогой баг. Причем убытки от последнего, как правило, не поддаются

объективной оценке.

Как видим, QA и тестирование – это не только обеспечение счастья

пользователей, но и путь САМОСОХРАНЕНИЯ любой интернет-

компании.

Вернемся к юнит-тестированию. Вот две рекомендации:

1. Юнит-тесты должны планироваться в письменной фор-

ме ДО написания кода.

Цикл разработки ПО

95

В таком случае программист после получения спека не бежит

сломя голову писать код, а садится за документацию о дизайне

кода с параллельным созданием юнит-тестов.

Полезность такого подхода заключается в том, что,

во-первых, программист абстрагируется от непосредственного

кодирования и, видя "большую картину", может предугадать прин-

ципиальные ошибки в алгоритмах и,

во-вторых, он сможет заранее представить, КАК он будет тести-

ровать код, это "КАК" занозой засядет у него в голове и при на-

писании кода будет работать по принципу "предупрежден – зна-

чит вооружен".

2. Требования к юнит-тестам должны быть формализованы

в стандартах о юнит-тестировании.

Например, каждая функция должна иметь по крайней мере один

тест-кейс с одним конкретным вводом и одним конкретным вы-

водом (ожидаемым результатом).

Принципиально, думаю, понятно. А так как написание и испол-

нение юнит-тестов – это дело программистов, то мы закончим

рассуждения о нем и пойдем дальше, у нас, тестировщиков, своих

дел по горло.

8. РЕАЛЬНЫЕ ФИНАНСОВЫЕ РЫЧАГИ

СТИМУЛЯЦИИ НАПИСАНИЯ ЭФФЕКТИВНОГО И

«ЧИСТОГО» КОДА

Здесь все элементарно – менеджмент не должен жмотиться, если

люди горбатятся на проект день и ночь, а в итоге не узнают своих

подросших детей и называют своих жен Ленами (по имени колле-

ги, сидящей за соседним компьютером и ставшей почти родной).

• Хорошая заработная плата с возможностью увеличения;

• билеты в "Ленком";

• премии за хорошую работу;

• неограниченные чипсы и диет-кола;

• оплата абонемента в бассейн и гимнастический зал;

• месячные проездные;

• выезды для игры в пейнтбол;

• беспроцентный кредит на машину;

• помощь при первоначальном взносе на квартиру —

96

Тестирование Дот Ком. Часть 1

чем больше заботы проявит компания о сотрудниках (и не только