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

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


Скачать 5.26 Mb.
НазваниеПособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
АнкорРоман Савин - тест dot com.pdf
Дата26.04.2017
Размер5.26 Mb.
Формат файлаpdf
Имя файлаРоман Савин - тест dot com.pdf
ТипПособие
#5534
страница5 из 24
1   2   3   4   5   6   7   8   9   ...   24
Часть 1
тестирование с VISA и MasterCard
Часть 2:
тестирование со Switch
Часть 1
<Шапка,
CCPG0001 и
(
2CPG0002 из старого файла credit card_payments doc без изменений>
Часть 2
<Шапка и SWPL0001 из файла switch_payments
.doc без изменений>
Прошу обратить внимание на следующее:
мы не меняли
• ни содержимое файла 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
ID
Priority
Card
Card Number
Card
Expiration
date
Card
CVV2
Expected
Result
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) или, простыми словами, то, как та или иная часть нашего веб-сайта должна выглядеть и/или работать.
Концептуальная разница между
1   2   3   4   5   6   7   8   9   ...   24


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