|
Читайте также: |
1. Тест-кейс — это инструмент тестировщика, предназначенный для документирования и проверки одного или более ожидаемых результатов.
2. Шаги (procedure) — это часть тест-кейса, ведущая исполнителя тест-кейса к фактическому результату (выводу). Излишняя детализация может осложнить поддержку, а излишнее абстрагирование привести к непониманию того, как исполнить тест-кейс.
3. Шаги для повторяющихся сценариев можно вынести в отдельный документ в локальной сети, и в тест-кейсе мы даем лишь ссылку на этот документ.
4. Исполнение тест-кейса завершается либо положительным (pass), либо отрицательным (fail или баг!!!) результатом. Причем именно отрицательный результат является желанным, так как мы нашли баг.
5. Исполнение тест-кейса не является завершенным, если исполнитель не смог "пройти" все шаги.
6. Тест-кейс должен быть независим от других тест-кейсов из того же или любого другого тест-комплекта.
7. Наиполезнейшими вещами являются следующие атрибуты тест-кейса:
• уникальный ID, который уникален в пределах всех существующих в компании тест-кейсов;
Искусство создания тест-кейсов
• приоритет, чтобы все знали, кто здесь главный;
• идея, которая на простом языке объясняет предназначение тест-кейса;
• подготовительная часть, которая... ну, в общем, подготавливает нас к исполнению тест-кейса;
• история редактирования, которая помогает указать на друзей, испортивших наши идеальные тест-кейсы и наших легковерных попугаев.
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" ("Водопад"), которая используется в подавляющем большинстве интернет-стартапов.
Дата добавления: 2015-12-07; просмотров: 217 | Нарушение авторских прав