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

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

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

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

Покупка с использованием Switch (TS7131)

Author:

Spec ID:

Priority

Producer:

Developer:

И. Новикова

1422

1

M.Чучиков

Н. Назаров

OVERVIEW:

Данный тест-комплект проверяет оплату картой Switch

GLOBAL SETUP and ADDITIONAL INFO:

1. SQL1: select result from cc transaction where id = <номер заказа>;

2. Баланс счета карты можно посмотреть здесь:

www.main.testshop.rs/<четыре_ последних_цифры карты>/bа1аncе.htm

ТС ID/Priority

SWPL0001

1

IDEA: Оплата может быть произведена картой Switch

SETUP and ADDITIONAL INFO:

Эккаунт: testuser1/pa$$wOrd

Данные карты:

Номер: 3333-1988-4444-5699 Окончание действия:

12/05 CVV2: 451

60

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

Revision History

Created on: 01/21/2003 by И. Новикова

Новый тест-кейс

Execution part

PROCEDURE

EXPECTED RESULT

1. Запиши баланс счета карты

> «30»

2. Открой www.main.testshop.rs

3. Войди в систему.

4. Найди любой товар.

5. Добавь товар в корзину.

6. Произведи оплату картой из секции

SETUP and ADDITIONAL INFO

(!!! запиши полную сумму заказа:

).

7. Запиши номер заказа

8. Запроси базу данных с SQL1.

9. Запиши баланс счета карты

S* Шаг 1-Шаг 6

Теперь нам остается просто объединить оба файла. Таким образом,

у нас получился all new credit_card_payments.doc. Откроем его:

Покупка с использованием кредитных карт

Часть 1 тестирование с VISA и MasterCard

Часть 2: тестирование со Switch

Часть 1

<Шапка, CCPG0001 и

2CPG0002 из старого файла credit doc

без измен (

е

ний>

card_payments

Часть 2

<Шапка и SWPL0001 из файла

.doc без изменений>

switch_payments

Прошу обратить внимание на следующее:

мы не меняли

• ни содержимое файла switch_payments.doc, которое вста-

вили в основной тест-комплект credit_card_payments.doc,

• ни содержимое старого файла credit_card_payments.doc.

Можно, например, было сделать для них одну общую "шапку" или

заменить SWPL0001 на CCPG0003 (чтобы иметь единую систему

нумерации в одном тест-комплекте), но ни этого, ни других объеди-

нительных мероприятий не было (и не будет) проведено, так как:

• это два независимых модуля и каждый из них прекрас

но исполняем по отдельности (пусть даже они и объеди-

Искусство создания тест-кейсов

61

нены в одном файле (и одном тест-комплекте) из-за того,

что они покрывают ту же функциональную часть нашего

проекта);

• уникальный ID тест-кейса дается последнему один раз и

никогда не меняется. Это как номер налогоплательщика

– нас ведь нужно учитывать, где бы мы ни были, а то

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

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

патрициями, должны содержать, платя налоги.

Кстати, генерировать уникальный ID тест-кейса можно

• автоматически (для этого может быть написана простая про-

граммка) или же

• вручную, для чего должна быть заключена конвенция внутри де-

партамента качества.

Пример

Мы договариваемся, что ID состоит из двух частей:

• первая часть – это буквенное обозначение (например, четыре

латинские буквы), а

• вторая часть – это цифровое обозначение (от 0001 до 9999).

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

кейсы (без ID) добавляются в тест-комплект, то буквенный ID берется из

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

цифровое обозначение + 1. Так если мы решим добавить тест-кейс для

тестирования оплаты картой Switch, то как мы его назовем? Правильно!

SWPL0002. А картой VISA или MasterCard? Правильно! CCPG0003.

Кстати, CCPG – это «Credit Cards Payments Global» ("общее по платежам

с кредитными картами"), a SWPL – «SWitch Payments Local» ("локальное по

платежам с картой Switch"). Почему я выбрал ТАКИЕ буквенные

обозначения? Потому что мне так захотелось. Никакого правила здесь

нет, как нравится, так и называйте, но постарайтесь, чтобы не было

двух тест-кейсов с одним ID.

Пример

Процесс присвоения ID идет следующим образом:

1. Пишем тест-кейсы. ID не присваиваем.

2. «Обкатываем» их при первом исполнении с удалением тех из них,

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

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

3. Присваиваем оставшимся тест-кейсам по ID.

Мы продолжим разговор о тест-комплектах на одном из следую-

щих чаепитий.

62

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

Состояния тест-кейса

У них все, как у людей. Рождаются, изменяются и умирают...

Рождение:

состояние – «Новый» (New).

Это первая редакция тест-кейса: "Created on: 11/17/2003 by

0. Тарасов".

Изменение:

состояние – «Измененный» (Modified). Модификации, как

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

тест-кейс, или с улучшением тест-кейса, например, для

удобства в поддержке: "Modified on: 11/26/2003 by И.

Новикова".

Смерть тест-кейса наступает

• вместе со смертью тестируемой вещи (определенной функ-

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

например www.testshop.rs перестал принимать кредитные

карты либо

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

ет другой, т.е. имеем

состояние – «Более недействителен» (Retired).

Рекомендую не удалять тест-кейсы насовсем, так как

во-первых, всегда возможна ошибка в суждении и нам нужно

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

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

шенному мнению, перестал быть актуальным, может еще приго-

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

штурвалом пиратского брига "Черная жемчужина", а за монито-

ром "Хундаи" с неотдирающимся стикером "Моя компания —

мой дом".

В общем:

1. Создаем специальную директорию в том же месте, где хра

ним файлы с тест-комплектами, и называем ее

retired_testcases.

2. Создаем в этой директории файл с тем же именем, что и

файл тест-комплекта, из которого удаляем тест-кейс.

Искусство создания тест-кейсов

63

3. Переносим тест-кейс (cut/paste) из файла, больше не нуж-

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

рии retired testcases.

В жизни все выглядит проще, так как обычно пускается в расход

не отдельный тест-кейс, а весь тест-комплект.

Иногда возникает дилемма – что лучше:

• изменить тест-кейс или

• удалить его и придумать новый.

Зсе ситуации уникальны, но, как показывает жизнь, легче возвести

здание на пустом месте, чем делать генеральную реставрацию

старого особняка. Кстати, судя по Москве, этой концепции при-

держиваюсь не я один.

Вот такие дела...

А напоследок я скажу...

Важный момент перед подведением итогов.

Все то, о чем мы говорили в этой беседе, является хорошей прак-

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

имеет место в реальных и успешных интернет-компаниях Сили-

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

как оно было рассказано и показано. Я же хочу, чтобы вы всегда

помнили главное:

тестирование – это процесс творческий и, следовательно,

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

фективно работает именно в вашей компании и в конкретной

ситуации.

Для иллюстрации творческого подхода те же тест-кейсы, но в

другом виде.

Таблица 1

Test Case

Priority

Card

Card Number

Card

Card Expected

ID

Expiration CVV2 Result

date

CCPG0001 1

VISA

9999-5148-2222-1277 12/07

778

10

CCPG0001 1

MasterCard 3333-7112-4444-7844 12/08

676

20

SWPL0001 1

Switch

3333-1988-4444-5699 12/05

451

30

64

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

IDEA: Оплата может быть произведена картами из Таблицы 1.

Для каждого тест-кейса из Таблицы 1:

1. Запиши баланс счета карты :

www.main.testshop.rs/<четыре_ последних цифры_карты>/balance.htm

2. Открой www.main.testshop.rs.

3. Войди в систему как testuser1/paSSwOrd.

4. Найди любой товар.

5. Добавь товар в корзину.

6. Произведи оплату картой (!! !запиши полную сумму заказа: ).

7. Запиши номер заказа

8. Запроси базу данных:

select result from cc_transaction where id = <номер заказа>;

Сравни с Expected resultl.

9. Запиши баланс счета карты

Шаг 1 – Шаг 6

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

Краткое подведение итогов

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

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

даемых результатов.

2. Шаги (procedure) – это часть тест-кейса, ведущая исполнителя

тест-кейса к фактическому результату (выводу). Излишняя

детализация

может

осложнить поддержку,

а

излишнее

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

тест-кейс.

3. Шаги для повторяющихся сценариев можно вынести в отдель-

ный документ в локальной сети, и в тест-кейсе мы даем лишь

ссылку на этот документ.

4. Исполнение тест-кейса завершается либо положительным

(pass), либо отрицательным (fail или баг!!!) результатом. Причем

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

мы нашли баг.

5. Исполнение тест-кейса не является завершенным, если испол-

нитель не смог "пройти" все шаги.

6. Тест-кейс должен быть независим от других тест-кейсов из того

же или любого другого тест-комплекта.

7. Наиполезнейшими вещами являются следующие атрибуты тест-

кейса:

• уникальный ID, который уникален в пределах всех сущест-

вующих в компании тест-кейсов;

Искусство создания тест-кейсов

65

• приоритет, чтобы все знали, кто здесь главный;

• идея, которая на простом языке объясняет предназначение

тест-кейса;

• подготовительная часть, которая... ну, в общем, подго-

тавливает нас к исполнению тест-кейса;

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

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

легковерных попугаев.

8. Поддерживаемость тест-кейса – это легкость и удобство, с

которыми он может быть изменен. Поддерживаемость тест-

кейса – одна из основных формальных вещей при создании или

модификации тест-кейса.

9. Тест-кейс "проверяет" не более одной идеи. При этом два и

более ожидаемых результата легитимны, если истинность идеи

вытекает из одновременной истинности этих ожидаемых

результатов.

10. К плохому стилю относятся:

а) зависимость тест-кейсов друг от друга;

б) нечеткая формулировка шагов;

в) нечеткая формулировка идеи тест-кейса и/или ожидаемого

результата.

11. Тест-кейсы объединяются в тест-комплекты (как правило, один

тест-комплект – это один файл).

12. Как правило, тест-комплект включает тест-кейсы, родственные

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

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

спеке.

13. Хорошим стилем является создание нового тест-комплекта для

новых тест-кейсов.

14. Тест-кейсы, написанные после проработки спека (до того, как

представилась возможность "пощупать" написанное по нему ПО),

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

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

мере их исполнения.

15. Создавая или модифицируя тест-кейсы, мы всегда должны

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

16. Состояние тест-кейса: "У них все, как у людей. Рождаются,

изменяются и умирают..." – "Новый", "Измененный", "Более

недействителен". Хорошая практика – не удалять (remove)

отжившие свой век тест-кейсы (или целые тест-комплекты), а

переносить их (move) в отдельную директорию, специально

созданную для таких пенсионеров.

17. Важно понять, что в сегодняшнем разговоре речь шла о форме,

а не о содержании тест-кейсов. Содержание конкретного тест-

кейса – это отражение методологии нахождения багов

применительно к конкретной ситуации, и этой методологии

будут посвящены отдельные беседы.

66

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

Вопросы и задания для самопроверки

1. Без какой части тест-кейс никак не может обойтись?

2. Для чего в тест-кейсе нужны шаги?

3. Два вида исхода исполнения тест-кейса. К какому исходу мы,

как тестировщики, стремимся?

4. Что происходит, если состояние ПО не позволяет исполнить все

шаги тест-кейса? Каковы наши действия?

5. Обоснуйте, почему у тест-кейса должна быть лишь одна тести-

руемая идея?

6. Перечислите полезные атрибуты тест-кейса и причину полез-

ности каждого из них.

7. Изменяется ли ID тест-кейса при изменении самого тест-кейса

или переносе его в другой документ?

8. Придумайте свой способ индексации тест-кейсов, например,

частью ID может быть номер спека.

9. Что такое data-driven тест-кейс? В чем заключается удобство

поддержания такого тест-кейса?

10. Как легкость в поддерживаемое™ тест-кейса позволяет сэко-

номить время?

11. Формальные недостатки, не позволяющие тест-кейсам быть

белыми и пушистыми.

12. В чем удобство написания новых тест-кейсов в отдельный тест-

комплект?

13. Ожидается ли, что тестировщик изменит тест-кейс, написанный

лишь на основании спека, без знакомства с реально напи-

санным ПО?

14. В чем проявляется родственность тест-кейсов, являющихся

частью одного тест-комплекта?

15. Приведите атрибуты шапки тест-комплекта.

16. Состояния тест-кейса.

17. Почему не рекомендуется удалять тест-кейсы?

18. Есть ли стандартная форма тест-кейса, за несоблюдение кото-

рой лишают премий и не приглашают на празднование Нового

года?

19. Разница между идеей тест-кейса и ожидаемым результатом.

20. Напишите тест-кейс с тестируемой идеей "Я могу убедить свою

жену в чем угодно" и ожидаемым результатом "Дорогой, поез-

жайте с Алексеем на рыбалку. Вы так редко с ним видитесь".

21. Напишите тест-кейс с одной идеей и двумя ожидаемыми ре-

зультатами. Используйте пример из жизни.

ЦИКЛ РАЗРАБОТКИ ПО

• ИДЕЯ

• РАЗРАБОТКА ДИЗАЙНА ПРОДУКТА И СОЗДАНИЕ

ОПЕКА

• КОДИРОВАНИЕ

• ИСПОЛНЕНИЕ ТЕСТИРОВАНИЯ И РЕМОНТ БАГОВ

• РЕЛИЗ

• БОЛЬШАЯ КАРТИНА ЦИКЛА РАЗРАБОТКИ ПО

икл (процесс) разработки ПО (software development life

Ц cycle) – это путь от идеи до поддержки готового продукта.

Чем более отлажены каждая из стадий цикла и координация меж-

ду ними, тем эффективнее работает интернет-компания, тем вы-

ше качество и тем счастливее пользователи.

Сегодня мы поговорим о модели цикла разработки ПО, называе-

мой «Waterfall» («Водопад»), которая используется в подавляю-

щем большинстве интернет-стартапов.

Наша цель – понять логику взаимосвязи между стадиями

Цикла и основные моменты каждой из стадий.

Большая картина цикла будет представлена в конце разговора,

когда будет понятно, что уже ничего не понятно.

Постараюсь свести к минимуму вещи типа: "в одних компаниях

Эгпо называется так, а в других – этак", нельзя объять необъ-

ятное, но если будет схвачен принцип, то, несмотря на разницу

67

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

69

в названиях и нюансах, вы мгновенно свяжете то, о чем я вам

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

те (несомненно, будете работать).

Итак, поприветствуем участниц и участников нашего шоу. Ими

сегодня будут:

1. Идея.

2. Разработка дизайна продукта и создание документации.

3. Кодирование (в смысле создание кода).

4. Исполнение тестирования и ремонт багов.

5. Релиз.

Идея

Для начала расскажу вам, как образовывались стартапы в США в

конце 90-х гг. прошлого века. И не подумайте, что я утрирую.

Калифорнийская история

СИДЯТ два бывших одноклассника в спорт-баре даунтауна Сан-Фран-

циско и думают, как заработать денег: кругом интернет-бум, некото-

рые друзья стали миллионерами и ездят на сверкающих «Феррари»

между офисами-аквариумами интернет-компаний и своими домами

на холмах Лос-Алтоса.

70

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

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

взгляд на другого, вытягивает вверх указательный палец и говорит: «О!»

Это «О!» означает рождение идеи, например, о создании веб-сайта по продаже

туалетной бумаги.

На следующий день раздается звонок в офисе венчурного капиталиста и назначается

встреча для обсуждения «проекта века».

Кстати,

венчурные капиталисты – это такие непростые товарищи, бизнесом которых

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

Встреча проходит в теплой и дружественной обстановке, и под проект "Туалетная

бумага Дот Ком" дается 50 млн долл.

Сказавший «О!» становится CEO (Chief Executive Officer), а егодруган –

соответственно COO (Chief Operating Officer).

Снимается помещение, покупаются ораклы и линуксы, начинается набор народа на

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

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

страховыми агентами, в общем все «счастливы, влюблены, раздавлены».

Процесс пошел!!!

Слушая эту историю, которая вполне могла быть правдивой, можно

заметить, что все началось с «О!», т.е. с ИДЕИ.

Вопрос: Кто генерирует идеи в действующей интернет-компании? Ответ:

Как правило, это отдел маркетинга. Нередко идеи инициируются службой

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

по процессингу кредитных карт (credit card processor).

В общем вариантов множество.

При разговоре о большой картине сводному персонажу, генерирующему

идеи, будет присвоено имя Маркетолог.

Как правило, идеи компонуются в MRD («эм-ар-ди» – Marketing

Requirements Document – документ о требованиях маркетинга, суть

которого: "хотелось бы это иметь").

Затем

• менеджмент проворачивает MRDШКИ через жернова анализа,

утверждения и приоритезации, а

• выжившие идеи передаются продюсерам, которые их полоскают,

высушивают и гладят, чтобы получилась спецификация.

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

71

Разработка дизайна продукта и

создание опека

На основании идеи, утвержденной менеджментом, разрабатыва-

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

дизайном продукта (product design) или, простыми словами, то,

как та или иная часть нашего веб-сайта должна выглядеть и/или

работать.

Концептуальная разница между идеей (продукта) и дизайном

(продукта) заключается в том, что

• идея – это описание ЦЕЛИ, а

• дизайн – это описание ПУТИ к достижению этой цели.

Профессионально весь этот джаз осуществляется менеджерами

продукта (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»)". В

этом спеке пропущено множество вещей. Например:

а. Не указано, что е-мейла с двумя "@" быть не может.

б. Не указаны другие неприемлемые знаки (il egal 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 ноября. Спек распечатывает тестировщик Ножов. Работа по спеку