ТЕСТ-КЕЙС

1. https://lh4.googleusercontent.com/yBm0qNM9Xt8aZYFIJG1vHW7kw4aVvKT1UP_fb5bOVTo7DQDx5t5HT3ZRa9RH5GFfmJ-ptNAq5FIdwA9JuZLq1wJx4RgnCZHFN04J5zKunNUwC6DzUtuRDD8QjBuEN00Zg3_gzN2c

2. ОПРЕДЕЛЕНИЕ

2.1. набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства. Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса

3. ПЛОХОЙ ТЕСТ-КЕЙС! НЕ НАДО ТАК

3.1. Если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс!

4. ЕЩЕ НЕМНОГО ОПРЕДЕЛЕНИЙ

4.1. Высокоуровневый тест-кейс

4.1.1. тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования.

4.2. Низкоуровневый тест-кейс

4.2.1. тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов.

4.3. Спецификация тест-кейса

4.3.1. документ, описывающий набор тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента.

4.4. Спецификация теста

4.4.1. документ, состоящий из спецификации тест-дизайна), спецификации тест-кейса и/или спецификации тест-процедуры.

4.5. Тест-сценарий

4.5.1. документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).

5. ДЛЯ ЧЕГО МЫ ПИШЕМ ТЕСТ-КЕЙСЫ

5.1. Структурируем и систематизируем подход к тестированию

5.2. Вычисляем метрики тестового покрытия и принимаем меры по его увеличению

5.3. Отслеживаем соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).

5.4. Храним информацию для длительного использования и для обмена опытом

5.5. Проводим по ним регрес

5.6. Повышаем качество

5.7. Быстро вводим в курс дела нового сотрудника

6. ЖИЗНЕННЫЙ ЦИКЛ ТЕСТ-КЕЙСА

7. АТРИБУТЫ ТЕСТ-КЕЙСА

7.1. id тест-кейса

7.1.1. Что-бы было проще найти

7.2. приоритет

7.2.1. чтобы понять на сколько важен тест-кейс

7.3. связанное с тест-кейсом требования

7.3.1. главное требование, которое тестируем

7.4. Модуль и подмодуль приложения

7.4.1. где конкретно тестируем

7.5. Заглавие (суть) тест-кейса

7.5.1. кратко о функционале, который тестируем

7.6. Исходные данные, необходимые для выполнения тест-кейса

7.6.1. состояние баз данных, сервера и др. технические условия

7.7. шаги тест кейса (сценарий)

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

7.8. ожидаемые результаты

7.8.1. после каждого шага - что должно произойти

8. СВОЙСТВА КАЧЕСТВЕННЫХ ТЕСТ-КЕЙСОВ

8.1. Правильный технический язык, точность и единообразие формулировок

8.2. Баланс между специфичностью и общностью

8.3. Баланс между простотой и сложностью

8.4. «Показательность» (высокая вероятность обнаружения ошибки)

8.5. Последовательность в достижении цели.

8.6. Отсутствие лишних действий

8.7. Неизбыточность по отношению к другим тест-кейсам

8.8. Демонстративность (способность демонстрировать обнаруженную ошибку очевидным образом).

8.9. Прослеживаемость

8.10. Возможность повторного использования.

8.11. Повторяемость

8.12. Соответствие принятым шаблонам оформления и традициям.

9. ТИПИЧНЫЕ ОШИБКИ ПРИ СОСТАВЛЕНИИ ТЕСТ-КЕЙСОВ

9.1. Отсутствие заглавия тест-кейса или плохо написанное заглавие.

9.2. Отсутствие нумерации шагов и/или ожидаемых результатов

9.3. Ссылка на множество требований

9.4. Использование личной формы глаголов

9.5. Использование прошедшего или будущего времени в ожидаемых результатах.

9.6. Постоянное использование слов «проверить» (и ему подобных) в чеклистах

9.7. Описание стандартных элементов интерфейса вместо использования их устоявшихся названий. «

9.8. Пунктуационные, орфографические, синтаксические и им подобные ошибки.

9.9. Ссылка на другие тест-кейсы или шаги других тест-кейсов.

9.10. Детализация, не соответствующая уровню функционального тестирования

9.11. Расплывчатые двусмысленные описания действий и ожидаемых результатов.

9.12. Описание действий в качестве наименований модуля/подмодуля.

9.13. Описание событий или процессов в качестве шагов или ожидаемых результатов

9.14. «Выдумывание» особенностей поведения приложения