Разработка смоук-теста
Дымовой тест (англ. Smoke testing или smoke test, дымовое тестирование) — в тестировании программного обеспечения означает минимальный набор тестов на явные ошибки. Дымовой тест обычно выполняется программистом; не проходившую этот тест программу не имеет смысла отдавать на более глубокое тестирование.
Примеры
Ошибки инсталляции: если программный продукт не устанавливается, его тестирование, скорее всего, окажется невозможным.
Ошибки при соединении с базой данных (актуально для архитектуры клиент-сервер).
Ошибки загрузки конфигурации и получения настроек для инициализации при запуске.
Если мы говорим про сайт интернет-магазина, то сценарий будет примерно следующим:
1. Сайт открывается
2. Можно выбрать случайный товар и добавить его в корзину
3. Можно оформить и оплатить заказ
Если мы говорим про мобильное приложение, например, messenger, то:
1. Приложение устанавливается и запускается
2. Можно авторизоваться
3. Можно написать сообщение случайном контакту
Что тестируем?
1) Проверка сборки: первым и самым важным шагом дымового теста является проверка сборки, номера сборки и доступности среды. Все усилия по тестированию будут потрачены впустую, если сборка неправильная.
2) Создание учетной записи: если ваше приложение предполагает создание пользователя, вам следует попытаться создать нового пользователя и проверить, успешно ли система позволяет вам это сделать. Это важный момент, который часто упускается из виду, поскольку тестировщики продолжают использовать старые учетные данные без тестирования для нового пользователя.
3) Вход в систему Выход: если это возможно в вашей SUT (тестируемая система), в рамках дымового теста вы должны попытаться успешно войти в систему со старыми и вновь созданными учетными данными. Также убедитесь, что вы можете успешно выйти из системы без каких-либо ошибок.
4) Критически важные для бизнеса функции: это очень важно. Для всех основных или критически важных функций мы должны провести простой тест, чтобы убедиться, что наиболее часто используемые функции не нарушены.
5) Сценарии интеграции: это самая важная часть дымового теста. Эффективность этой части зависит от понимания тестером интеграции системы. Например, если тестировщик знает, что какие-то данные текут из системы A в систему B, то он должен сделать это как часть дымового теста (любое значение 1). Это также делается для того, чтобы система не сломалась ни в одной из этих точек интеграции.
6) Добавить / изменить / удалить: данные всегда сохраняются в базе данных. Три основных операции в базе данных: добавление записи, редактирование записи и удаление записи. Таким образом, чтобы обеспечить надлежащее соединение с базой данных, в рамках дымового теста необходимо попытаться создать, отредактировать и удалить запись, которая применима в тестируемой системе.
7) Общая навигация: последняя часть - общая навигация. То есть нужно пройти через приложение, попытаться коснуться часто используемых функций и страниц, чтобы убедиться, что вся навигация работает должным образом.
Разработка тест-кейса
Тест-кейс — набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определённой цели или тестового условия, таких как выполнения определённого пути программы или же для проверки соответствия определённому требованию.
Определение тест-кейса языком обывателя:
Тест-кейс — это чёткое описание действий, которые необходимо выполнить, для того чтобы проверить работу программы (поля для ввода, кнопки и т.д.). Данное описание содержит: действия, которые надо выполнить до начала проверки — предусловия; действия, которые надо выполнить для проверки — шаги; описание того, что должно произойти, после выполнения действий для проверки — ожидаемый результат.
Правила написания тест-кейсов
Заголовок:
- должен быть чётким, кратким, понятным и однозначно характеризующим суть тест-кейса;
- не может содержать выполняемые шаги и ожидаемый результат.
Предусловие:
- может содержать полную информацию о состоянии системы или объекта, необходимом для начала выполнения шагов тест-кейса;
- может содержать ссылки на информационные источники, которые необходимо изучить перед прохождением тест-кейса (инструкции, описание систем…);
- не может содержать ссылки на тестируемый ресурс, если у информационной системы более одной среды (прод, тест, препрод…), данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать данные для авторизации, данная информация должна быть вынесена в инструкцию, и ссылка приложена в предусловии;
- не может содержать выполняемые шаги и ожидаемый результат, если нам нужно, чтобы до выполнения шагов проверки у нас была открыта главная страница, то мы в предусловии указываем «открыта главная страница сайта»;
- не может содержать ожидаемый результат.
Шаги проверки:
- должны быть чёткими, понятными и последовательными;
- следует избегать излишней детализации шагов. Правильно: «ввести в поле число 12».
- Неправильно: «нажать на клавиатуре на цифру ‘1’, следующим шагом нажать на клавиатуре на цифру ‘2’»;
- должны использоваться безличные глаголы.
- Правильно: нажать, ввести, перейти.
- Неправильно: нажмите, введите, идите;
- не должно быть комментариев и пояснений, если есть необходимость привести мини-инструкцию, то оформляем инструкции в базе-знаний и в предусловии ссылаемся на неё;
- не должно быть жёстко прописанных статических данных (логины, пароли, имена файлов) и примеров, для исключения эффекта пестицида.
Ожидаемый результат:
- должен быть у каждого шага проверки;
- должно быть кратко и понятно описано состояние системы или объекта, наступающее после выполнения соответствующего шага;
- не должно быть избыточного описания.
Общие требования к тест-кейсам:
- язык описания тест-кейсов должен быть понятен широкому кругу пользователей, а не узкой группе лиц;
- тест-кейс должен быть максимально независим от других тест-кейсов и не ссылаться на другие тест-кейсы (лучшая практика, когда зависимостей нет вообще);
- тест-кейсы группируются в функциональные блоки по их назначению;
- в тест-кейсах проверяющих работу функционала скриншотов быть не должно, иначе вы будете посвящать сотни часов на изменение всех скриншотов в тысячах тест-кейсах при изменении интерфейса тестируемой программы. Скриншоты могут быть добавлены только в тест-кейсы проверяющие отображение страниц и форм.
На самом деле правила простые, однако их не так-то просто соблюдать. Если же придерживаться данных правил, то тест-кейсы будут легко поддерживаемыми, легко читаемыми, не будут вызывать отторжения и могут быть использованы всеми участниками команды в процессе разработки программного обеспечения.
Источники:
