Чеклисты и Тест-кейсы
Чеклисты
Идея для проверки. Просто для индикации работает/не работает.
Список тестов. Создается на основе карты приложения. Для индикации процесса тестирования, процент функциональности тестирования. Должна быть последовательность и структура. Инструмент тестирования. Составляется на основе требований (ТЗ) перед началом процесса тестирования. Google-таблиц или Exel- хорошие инструменты.
Можно написать ожидаемый результат. Когда в других тестовых документах не планируется составлять. Когда ПО очень специфичное, трудное и ожидаемый результат трудно запомнить.
Если проект небольшой и нет обширного ТЗ, то можно пользоваться только чек-листом (без тесткейсов). С чеклистом работать проще.
Высокоуровневый документ - без деталей.
Google-sheets - Хороший инструмент для чеклистов
Простой чеклист
| ID | Проверка | Результат (статус) | Вид тестирования | Комментарии |
|---|---|---|---|---|
| TEST1 | Авторизация | ✅ (passed) | Smoke | |
| TEST2 | Регистрация | ❌ (failed) | Smoke | Что-то пошло не так |
Статусы проверок
Passed (Пройден), Failed (Провален), Blocked (Заблокирован), Skipped (Пропущен), No run (Не запускался)
Тест-кейсы
В первую очередь составляются тест-кейсы для дымового тестирования.
Проверка, состоящая из каких-то шагов, условий и ожидаемого результата.
Более подробный детализированный чеклист, расписанный по шагам (набор действий). Можно оформлять также в виде таблиыы. Шаги пути пользователя. (Систематизация и документация процесса тестирования)
Если проект объемный, длительный, версионный, большая команда, то лучше использовать тест-кейсы.
Низкоуровневый документ - с деталями. Чеклист по вертикали, тест-кейсы по горизонтали
Требования к тест-кейсу:
- должен быть понятным
- точное и подробное описание
- независимым от других тест-кейсов
- соответствующий требованиям
- воспроизводимым и переиспользуемым
- единообразие оформления
- граничные значения
Примерные колонки тест-кейсов
Обязательные:
- id
- title (Заголовок проверки)
- author
- modules or sub-module
- priority
- enviroment - тестовая среда
- precondition - условие, чтобы достичь этого тест-кейса (что нужно сделать, чтобы ...). Пишется в прошедшем времени (Открыта главная страница).
- steps - шаги, пишутся в будущем времени (ввести номер телефона)
- expected result
- status - passed/success, failed, blocked
- testing level - Вид/уровень тестирования
- comments - Комментарии
Опциональные:
- requirements - ссылка на требования
- postcondition
- actual result - (можно не использовать, а пользоваться статусом). Лучше описывать в задачах и баг-репортах
- attachments - приложенные файлы
- assigned - кто проверяет
Пример тест-кейса
- Предусловия: описываем необходимые предварительные условия
- Шаги: шаги для воспроизведения
- Фактический результат: что мы получаем в результате выполнения шагов
- Ожидаемый результат: что должно происходить на самом деле
- Скриншот/видео: пруфы, подтверджающие вышесказанное
- Окружение: в какой среде воспроизводится баг
| ID | Title | Module/Submodule | Priority | Requirements | Enviroment | Precondition | Steps | Expected result | Status | Comments | Testing level | Author |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| TC1 | Проверка отправки email | Регистрация/Форма регистрации | Средний | Some link | OS: MacOS 12.6, Google Chrome 105 | 1.Открыта форма 2.Пользователь не зарегистрирован | 1.Step1 2.Step2 3.Step3 | Email отправлен пользователю | Success | Some comments | Smoke/Positive | Some Tester |
Пример таблицы совместимости (кроссбраузерность и кроссплатформенность)
| ID | Title | Окружение №1 | Окружение №2 | Окружение №3 | Окружение №4 |
|---|---|---|---|---|---|
| TC1 | Проверка отправки email | ✅ | ✅ | ✅ | ✅ |
| TC2 | Проверка отправки кода | ✅ | ✅ | ✅ | ✅ |
| TC3 | Проверка отправки sms | ✅ | ✅ | ❌ | ❌ |
Виды тест-кейсов
- Простые - очень узконаправленные, точечные (одно поле, один ui-элемент и т.д.)
- Сложные - проверка функциональности, где может быть много шагов и много разных элементов
Виды тестирования у тест-кейсов
Сначала проверяются позитивные, потом негативные. Нет смысла проверять негативные, если позитивные фейлятся.
Позитивный - корректные входные данные. Цель - убедиться, что все работает правильно, как и задумывалось (под большинство пользователей). "Я всё проверил и у меня все работает!" (тестировщик с идеальными входными данными).
Негативный - некорректные (ошибочные) входные данные. Цель - убедиться, что система не ломается и остаётся стабильной, даже при вводе неправильных данных. "Нифига оно не работает!" (тестировщик-ломатор). Чаще всего баги кроются в негативных сценариях.
Валидация - как раз должна предотвратить негативные сценарии. Валидация на фронте и вылидация на бэке.
Уровни тестирования и приоритет у тест-кейсов
- Дымовое - высокий приоритет
- Функциональное - средний приоритет
- Нефункциональное - низкий приоритет
Жизненный цикл тест-кейса
Test run
Прогон тест-кейсов, test suite. Индикация того, какие тест-кейсы прошли успешно, а какие нет.