test-case

1. Понятие тест-кейс

1.1. Тест-кейс — это четкое описание действий, которые нужно выполнить для проверки отдельной функции вашего приложения.

2. Что такое чеклист

2.1. Чеклист QA — это список того, что нужно протестировать. Благодаря ему процесс тестирования проходит более четко и аккуратно.

3. Виды тест-кейсов

3.1. Позитивные

3.1.1. Используются корректные входные данные и сценарии ожидаемой работы системы. Цель здесь — убедиться, что программный продукт выполняет то, что должен делать, и что система не выдаст ошибку, если это не предусмотрено.

3.2. Негативные

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

3.3. Деструктивные

3.3.1. создаются, чтобы узнать предел прочности системы. Нагрузочное тестирование — распространенный вариант деструктивного тестирования.

4. Атрибуты тест-кейса

4.1. ID

4.1.1. уникальное сочетание букв и цифр

4.2. Заголовок

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

4.3. Предусловия

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

4.4. Шаги

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

4.5. Постусловия

4.5.1. список действий, возвращающих систему в исходное состояние (указывается при необходимости).

4.6. Ожидаемый результат

4.6.1. то, что мы ожидаем получить после успешного выполнения тест-кейса.

4.7. Фактический результат

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

4.8. Статус

4.8.1. Success (успех)

4.8.2. Failed (провал)

4.8.3. Blocked (блокировка)

4.9. Дополнительные атрибуты

4.9.1. Требования к среде

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

4.9.2. Специальные процедурные требования

4.9.2.1. особые процедуры настройки, выполнения или очистки, уникальные для этого тест-кейса.

4.9.3. Межкейсовые зависимости

4.9.3.1. тест-кейсы, которые нужно выполнить перед этим тест-кейсом.

5. Best practices в написании тест-кейсов

5.1. Перед созданием нового тест-кейса убедитесь, что он не дублирует ни один из уже существующих в системе.

5.2. Убедитесь, что тест-кейс покрывает 100% требований, которые вы должны проверить.

5.3. Помните о теории методов тестирования, таких как анализ граничных значений, разделение эквивалентности, техника перехода состояния, угадывание ошибок.

5.4. Помимо требований к системе, всегда помните о конечном пользователе, который будет взаимодействовать с системой.

5.5. Не забудьте указать учетные данные, если они необходимы для выполнения теста.

5.6. Позаботьтесь о тестировщиках, которые будут работать с этим тест-кейсом в будущем. В частности, убедитесь, что все ссылки верны и кликабельны. Пожалуйста, не используйте ссылки на продакшен.

5.7. Используйте повелительное наклонение, например: «Перейдите на главную страницу», «Введите данные», «Кликните» и т. д. Такая формулировка упрощает понимание этапов тестирования и ускоряет их выполнение.

6. Характеристики хорошего тест-кейса

6.1. понятен любому члену команды

6.2. аккуратно и точно написан

6.3. соответствует требованиям

6.4. воспроизводим

6.5. пригоден для многократного использования

7. Как описать тест-кейс

7.1. То есть что должно быть в его секции заголовка: краткое, но ёмкое описание конкретной цели тест-кейса — что он будет проверять.

8. Как правильно называть тест-кейсы

8.1. То есть, каким должно быть идеальное название тест-кейса. Помимо того что название («тема») должно быть кратким, ёмким и понятным не только вам, название может зависеть от того, высокоуровневым (дымовым, интеграционным или системным) или низкоуровневым является этот тест-кейс. Высокоуровневый, без конкретных входных данных и ожидаемых результатов, походящий на тестовый сценарий, может быть назван более широко и удобочитаемо. А в целом, название должно как можно чётче обозначать предназначение.

9. Чего не должно быть в тест-кейсе

9.1. Зависимости от других

9.2. Нечетких формулировок шагов

9.3. Нечетких формулировок ожидаемых результатов

9.4. Излишней детализации

10. Формирование тест-кейсов

10.1. Чаще всего в обычной таблице в Экселе ). Но давно существуют удобные инструменты для создания тест-кейсов, а также их упорядочивания, запуска, контроля, и генерации и хранения отчетов по результатам. Например, есть инструменты TestLink и TestRail.

11. Сколько времени нужно на написание тест-кейса

11.1. Зависит от проекта и от опыта, простой несколько минут, сложный 10-20 минут и более.