Простые ошибки могут быть фатальными для вашего сайта – особенно если Вы – SaaS (eng. Software as a Service) компания, как мы. Если пользователь заходит на Ваш сайт и не может справиться с простым заданием, таким как зарегистрироваться или сбросить свой забытый пароль, Вы рискуете потерять этого пользователя навсегда.
Мы испытали это на своей собственной шкуре. Безусловно, иметь своих людей в команде, которые тестируют приложение и ищут баги – это важно, но не всегда уместно или недостаточно тщательно. В этой статье, мы хотим представить Вам, гуманитариям, мир smoke-тестов.
Если все же у Вас останутся вопросы – восполнить пробелы вы сможете, посетив курсы тестировщиков в Минске
Smoke-тестирование первоначально было придумано, чтобы объяснить как инженеры-электротехники проверяли работает ли их прибор – включали его и если дым шел…
Подождите, как это может быть применимо к приложениям?
Важность (и рентабельность) smoke-тестов, как правило, неизвестна для менеджеров-гуманитариев и соучредителей. Систематические smoke-тесты могут рассматриваться как неотъемлемая часть для предотвращения роста вероятности взлома. Они минимизируют вероятность того, что в Вашем веб-приложении или приложении для телефона произойдет сбой – и как все мы знаем, только одна неудача и вы можете потерять клиента навсегда.
Это вводное руководство о том, что это такое, как это может быть реализовано, какие ресурсы используются для его проведения и примеры, направляющие читателей.
Smoke-тесты созданы для того, чтобы проверить основную функциональность и должны быть неотъемлемой частью Вашего процесса тестирования. Они могут включать что-то простое, типа “Могу ли я зарегистрироваться?”.
Smoke-тестирование помогает убедиться, что ни одна из основных и очевидных неудач не оставлена на волю случая. Не следует проводить более глубокий тест, пока вы не выполнили smoke-тесты на 100%, потому что они очищают программное обеспечение от фундаментальных ошибок.
Шаг 1: Решите, что надо тестировать
Определите, что Ваше приложение стремится достичь. Каковы наиболее очевидные “детские” шаги, которые необходимы, чтобы в него попасть? Каковы минимальные жизненно важные требования и в какой логической последовательности Вы их перечислите?
Создайте набор тестов. Набор тестов – это сгруппированная совокупность тест-кейсов (тестовых случаев), связанная определенным образом (например, по функциональности).
Smoke-тестирование не будет включать в себя переменные или вопросы вида “что если?”. Оно предполагает только ответы да/нет, но прежде чем переходить к более подробному тестированию, все тест-кейсы должны быть пройдены с положительным результатом.
Давайте возьмем для примера создание интерактивного форума. Для того, чтобы он работал я должен:
- зарегистрироваться.
- создать Имя пользователя.
- загрузить фото на аватарку.
- писать сообщения.
- отвечать на сообщения.
Шаг 2: Записываем результаты в таблицу
Изображение выше – пример от нашей команды. Вы можете найти шаблон тут. Это необходимо для того, чтобы сохранить записи того, что у нас работает, а что нет – базовая организация сэкономит кучу времени в дальнейшем. Мы разделили наши результаты на пройдено, частично и провалено.
- Пройдено: все работает идеально.
- Частично: изначально вы можете не понимать, что некоторые действия могут быть еще подразделены, и поэтому одна часть работает, а другая – нет.
- Провалено: не работает.
Мы описали точные шаги, которые мы хотели воспроизвести, а затем, в следующей графе, добавили краткое описание того, что мы ожидаем на выходе. Пример:
|
Action |
Expected |
|
Создать запись, используя имя новой команды |
Проверить, что запись создана с соответствующими заголовками |
Шаг 3: Автоматизируем smoke-тесты
Очень важно не принимать за аксиому то, что если какое-либо действие было пройдено один раз, оно будет всегда с положительным исходом. Smoke-тесты позволяют постоянно проверять, что основные функции не пострадали с течением времени или не были поломаны в течение долгого периода.
Не прекращай smoke-тестирование. Никогда.
Когда Ваш набор тест-кейсов для smoke-тестирования завершается с успешным исходом на 100%, подумайте об их автоматизации. Рекомендуемая частота проведения smoke-тестов – каждый день, если Ваша компания занимается разработкой каждый день.
Минимальная необходимость – проводите прогон smoke-тестов перед каждым релизом и после каждого патча.
Эмпирическое правило для smoke-теста:
- Минимальное время: 30 минут.
- Максимальное время: 60 минут.
В дальнейшей перспективе автоматизация smoke-тестов экономит время, но при прогоне одних и тех же тестов снова и снова человеческий глаз может перестать замечать детали, а машина нет.
Ресурсы для тестирования:
- Менеджмент тестов (когда Ваша компания становится больше)
- Inflectra
- SeleniumHQ (Web apps)
- Наш шаблон
Что после smoke-тестирования? Санитарное тестирование!
Перевод статьи Smoke-testing your apps 101: A guide for the non-techie co-founder
Запишитесь прямо сейчас или закажите звонок с бесплатной консультацией!
Записаться сейчас / Бесплатная консультация