Главная страница

Роман Савин - тест dot com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин


Скачать 5.26 Mb.
НазваниеПособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
АнкорРоман Савин - тест dot com.pdf
Дата26.04.2017
Размер5.26 Mb.
Формат файлаpdf
Имя файлаРоман Савин - тест dot com.pdf
ТипПособие
#5534
страница6 из 24
1   2   3   4   5   6   7   8   9   ...   24
идеей (продукта) и дизайном
(продукта) заключается в том, что
идея — это описание ЦЕЛИ, а
дизайн — это описание ПУТИ к достижению этой цели.
Профессионально весь этот джаз осуществляется менеджерами продукта (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. Изменения к спеку не утверждены программистом и тес- тировщиком.
1   2   3   4   5   6   7   8   9   ...   24


написать администратору сайта