фабпждфуквп. Савин Тестирование dot-com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
идеей (продукта) и дизайном (продукта) заключается в том, что • идея — это описание ЦЕЛИ, а • дизайн — это описание ПУТИ к достижению этой цели. Профессионально весь этот джаз осуществляется менеджерами продукта (PMs — Product Managers), которые также могут назы- ваться продюсерами (Producers) или дизайнерами продукта (Product Designer). Результатом продюсерских усилий являются спеки, называемые также PRD (Product Requirements Document — документ о требова- ниях для продукта) или просто requirements (требования). Самые эффективные продюсеры в интернет-компаниях — это профессионалы, имеющие бэкграунд в предмете, на котором они специализируются, и ненавязчивую техническую подготовку. Первое необходимо, чтобы детально разбираться в том, что найдет отражение в спеках (например, это могут быть правила торгов НАУФОР). Второе полезно, чтобы говорить на языке программистов и тестировщиков. Спеки должны иметь уникальное название и уникальный ID и внутри разбиваются на логические составляющие (части, пункты), имеющие индексацию для удобства ссылок. Каждый спек имеет также обозначение своей важности (при- оритета). Обычно это цифра по 4-балльной шкале. Так, спек приоритета 1 (Ш) — это самый приоритетный спек. Практическая ценность придания спекам приоритетности состоит в следующем: 72 Тестирование Дот Ком. Часть 1 • если речь идет об исключении каких-либо функционально- стей из релиза, так как не хватает ресурсов (например, времени у программиста), то жертвуют функционально стью из спека с меньшим приоритетом. Так, при наличии одного спека с Ш и другого спека с П2, равноценных по трудоемкости для программиста и тести- ровщика, отбрасывается П2; • программист и тестировщик всегда должны начинать (про- граммирование, подготовку к тестированию и исполнение тестирования) со спека с большим приоритетом; • так как мы знаем, что невозможно протестировать все, приоритет спека для тестировщика — знак, указы- вающий, чему нужно дать больше любви и заботы. Как правило, приоритет присваивается спекам менеджером про- дюсеров. Идем дальше. Хороший спек, как и хороший закон, отличают следующие вещи: 1. Акцент на деталях и их четкое определение. 2. Забота о недопущении неверного толкования. 3. Непротиворечивость внутри спека и с другими спеками. 4. Логическая взаимосвязь компонентов. 5. Полнота охвата предмета. 6. Соответствие нормативным актам. 7. Соответствие деловой практике. Ошибки в спеке появляются в случае отклонения содержания спека от пунктов 1 —7. 1. АКЦЕНТ НА ДЕТАЛЯХ И ИХ ЧЕТКОЕ ОПРЕДЕЛЕНИЕ Пример ошибки "1.5. При регистрации система должна проверить е-мейл на наличие: "." перед именем глобального домена (например, "ш" или "com")". В этом спеке пропущено множество вещей. Например: а. Не указано, что е-мейла с двумя "@" быть не может. б. Не указаны другие неприемлемые знаки (illegal characters) е-мейл- адреса. в. Не приведен список существующих глобальных доменов. Цикл разработки ПО 73 Пример последствий ошибки Стандартная практика регистрации нового пользователя состоит из трех этапов: а. Пользователь заполняет регистрационную форму и нажимает кнопку "Зарегистрироваться". б. От веб-сайта приходит е-мейл с липком для подтверждения ре гистрации. в. Пользователь кликает линк, и регистрация автоматически под тверждается. Если пользователь случайно введет неправильный е-мейл (например, с двумя "@") и сообщение об ошибке сгенерировано не будет, то реги- страция не будет завершена, так как е-мейл с липком для подтвержде- ния регистрации не придет. Пользователь будет бесполезно ждать этого е-мейла, а не дождавшись, скорее всего введет в адресной строке веб-браузера URL конкурента. Кстати, URL ("ю-ар-эл" — Uniform Resource Locator) — это просто ад- рес файла в сети, например "http://www.testshop.rs". URL можно вво- дить в адресную строку веб-браузера без "http://" (ее добавляет сам браузер при запросе к веб-серверу). Имя файла может даваться на- прямую: www.main.testshop.rs/1277/balance.htm, либо веб-сервер сам найдет для нас нужный файл в соответствии со своими настройками, например, в случае с нашим проектом набор в адресной строке браузера "www.main.testshop.rs" или "www.main.testshop.rs/index.htm" даст нам тот же самый файл index.htm. 2. ЗАБОТА О НЕДОПУЩЕНИИ НЕВЕРНОГО ТОЛКОВАНИЯ Пример ошибки Игорь Саруханов. Песня "Скрип колеса". Произнесите вслух название этой песни. Я, например, многие годы думал, что песня называется "Скрипка лиса", а моя жена была уверена, что "Скрипка. Леса...". Пример последствий ошибки Если для вашей профессиональной деятельности не имеет никакого значения, как называлась эта песня, то адекватность понимания спека — это вещь наиважнейшая. Опасность заключается в том, что программист и/или тестировщик, выбрав неправильный смысловой вариант, может быть уверен, что все понял правильно, и в итоге напортачит с кодом и/или с тест-кейсами. У нас будет отдельное рассмотрение того, как превентировать возможность неверного толкования спека. 74 Тестирование Дот Ком. Часть 1 3. НЕПРОТИВОРЕЧИВОСТЬ ВНУТРИ СПЕКА И С ДРУГИМИ СПЕКАМИ Пример ошибки "7.3. В целях безопасности доставка может быть осуществлена на адрес пользователя, по которому зарегистрирована кредитная карта" и на следующей странице или в другом спеке: "8.1.1. Для доставки пользователь может ввести любой адрес в преде- лах континентальной части США". Пример последствий ошибки Один программист может запретить доставку на любой адрес, кроме адреса регистрации кредитной карты, а другой программист незави- симо от первого напишет код, позволяющий пользователю ввести лю- бой адрес, который тот пожелает. Вследствие этого вполне возможна ситуация, когда пользователь, за- вершив заказ, будет ждать посылку, которая никогда к нему не придет, так как система • позволит сделать заказ (код второго программиста), НО • не даст команду кладовщику, чтобы тот послал заказ по почте (код первого программиста). 4. ЛОГИЧЕСКАЯ ВЗАИМОСВЯЗЬ КОМПОНЕНТОВ Пример ошибки "1.1. Мои мама и папа, я живу хорошо, просто замечательно. У меня все есть. Есть свой дом. Он теплый. В нем одна комната и кухня. Я без вас очень скучаю, особенно по вечерам. 1.2. А здоровье мое не очень. То лапы ломит, то хвост отваливается. 1.3. А на днях я линять начал: старая шерсть с меня сыплется, хоть в дом не заходи, зато новая растет — чистая, шелковистая. Так что лох- матость у меня повысилась. До свидания. Ваш сын, дядя Шарик". Спасибо Эдуарду Успенскому за иллюстрацию "логической" взаи- мосвязанности компонентов. Пример последствий ошибки Вспомните реакцию мамы, а затем папы дяди Федора после прочтения письмеца. Примерно то же самое может быть с пользователем, когда он столкнется с функциональностью, написанной и протестированной согласно подобному спеку. Цикл разработки ПО 75 5. ПОЛНОТА ОХВАТА ПРЕДМЕТА Пример ошибки В условиях массового интернет-мошенничества с кредитными кар- тами дополнительной степенью защиты является CVV2 (Card Verifica- tion Value 2) — трех- (для всех карт, кроме Атех) или четырехзначный (только для Атех) номер, идущий за номером карты на обратной ее стороне (на полоске с подписью). Продюсер по незнанию или по ха- латности может не предусмотреть в опеке, что пользователь должен ввести CVV2 при регистрации карты, что в итоге приведет к большему числу мошеннических транзакций. Пример последствий ошибки Многие интернет-компании, включая платежные системы, закончили существование из-за огромного количества транзакций с крадеными картами. Даже если дело не дойдет до закрытия компании, службе поддержки клиентов, финансовому и правовому департаментам пред- стоит испытать много чудных мгновений, которых могло не быть, не за- будь продюсер о CVV2. 6. СООТВЕТСТВИЕ НОРМАТИВНЫМ АКТАМ Пример ошибки Здесь, как правило, речь идет о продаже специальных предметов (на- пример, рецептурных лекарств). В этом случае спек (например, в он- лайн-аптеке) должен предусматривать, что такие предметы не могут продаваться. Еще одним примером являются вещи, связанные с авторским правом, например распространение аудиофайлов. Пример последствий ошибки Возможно судебное преследование. Вспомните историю компании Napster. 7. СООТВЕТСТВИЕ ДЕЛОВОЙ ПРАКТИКЕ Пример ошибки Если денежный перевод обычно занимает 3 — 6 бизнес-дней включи- тельно, то пользователю не должно сообщаться меньшее или "точное" количество дней. Нужно так и указать на соответствующей странице сайта: "Денежный перевод обычно занимает 3 — 6 дней включительно". Пример последствий ошибки Пользователь будет уверен, что в конкретный день на его счете будет определенная сумма. Представьте себе ситуацию, что пользователь, рассчитывая на эти деньги, поехал в Лондон на аукцион русской живо- 76 Тестирование Дот Ком. Часть 1 ПИСИ , выиграл там картину Айвазовского, за 200 тыс. фунтов, расплачи- вается своей дебетовой картой, а ему говорят, что на карте нет денег. Останется ли он клиентом нашей компании? Идем дальше. Некоторые продюсеры убеждены, что спеки должны давать про- граммистам указания по сугубо техническим аспектам кодирова- ния, как, например, об установлении связей между таблицами в базе данных или о названиях функций в коде. Если они не пони- мают всех проблем, вытекающих из этого порочного подхода, и слушать никого не хотят, предложите им самим написать весь код. Скорее всего, они откажутся... Пример Где-нибудь в городе N в стенах прихватизированного авиационного завода открывается фирма по отливке золотых унитазов для новых русских. Жена одного такого приезжает на завод и говорит: "Хочу, что- бы мой унитаз: с 00:00 до 5:59:59 проигрывал в стерео сочинения Сибелиуса в испол- нении оркестра английской Королевской оперы; с 6:00 до 11:59:59 голосом Марчелло Мастроянни читал пелевинскую "Жизнь насекомых"; с 12:00 до 17:59:59 философски молчал; с 18:00до 23:59:59 транслировал "Народное радио", а для формы подойдет модель 5 из вашего каталога". Очень даже приличная спецификация. И на этом неплохо было бы ос- тановиться, но если эта дама с многокаратными каменьями начнет да- вать ценные указания о температуре нагревания презренного металла перед литьем, изоляции контактов или моменте вступления кларнета в Седьмой симфонии, то будет совсем худо. Давайте уж так: каждый должен заниматься своим делом. Итак, после проведения водораздела между работой продюсера и работой программиста продолжим о спеках. Спеки имеют следующую очередность статусов: 1. Во время написания они имеют статус Черновик (Draft). Продюсер пишет спек. 2. После написания и до утверждения — Ожидание утвер- ждения (Approval Pending). Спек написан, и назначается совещание (meeting) с про- граммистами и тестировщиками по его обсуждению или же просто им посылается е-мейл с приложением. Цикл разработки ПО 77 3. После утверждения — Утверждено (Approved или Final). Если на митинге все закричали "Ура!" или получены по- ложительные отзывы от всех реципиентов, утвержденный спек немедленно выкладывается на один из серверов в ло- кальной сети, чтобы быть доступным любому лицу внутри компании, которому положено его видеть. Если же спек не принят, то все начинается с пункта 1. Постановка мозгов Факт утверждения спека не означает, что тестировщик и программист объявили спек идеальным. Факт утверждения спека означает, что в результате первоначального ознакомления со спеком последний был признан годным для дальнейшей работы. Политический момент: спек — это ответственность продюсера, и продюсер остается ответ- ственным за качество спека даже в том случае, если программист и тестировщик утвердили спек, в котором позднее были найдены проблемы. Идем дальше. Спасский после игры с Фишером неделями ходит и думает: "А вот здесь нужно было бы его конем пришкварить", но, к сожалению, исправить ему уже ничего нельзя, "можно только забыть". Продюсер же может проснуться утром с идеей улучшения спека или вспомнить какую-нибудь важную вещь, упущенную при соз- дании спека, и, придя на работу, подредактировать спек и заме- нить файл со старой редакцией файлом с новой редакцией на упомянутом внутреннем сервере... И так пять раз. Далее. Обычно спек распечатывается непосредственно перед началом работы по нему. Учитывая, что время начала работы по спеку у каждого индивидуально (я говорю о минутах), если спек будет по-тихому изменяться между распечатываниями, наступит ситуа- ция, когда программисты и тестировщики хотя и работают над одним проектом, но руководствуются разными редакциями спека. Причем даже если у программистов и тестировщиков будут рас- печатки одной и той же версии спека, то в случае тихого измене- ния их работа в той или иной части все равно не будет иметь смысла, так как они руководствовались устаревшей редакцией. 78 Тестирование Дот Ком. Часть 1 Пример 11 ноября. Спек утвержден Ножовым, Ложкиным и Тарелкиным. Про- дюсер Буханкин. 12 ноября. Спек распечатывает тестировщик Ножов. Работа по спеку началась. 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. Изменения к спеку не утверждены программистом и тес- тировщиком. |