Роман Савин - тест dot com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
Скачать 5.26 Mb.
|
Часть 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) или, простыми словами, то, как та или иная часть нашего веб-сайта должна выглядеть и/или работать. Концептуальная разница между |