Когда ошибка достигает рабочей среды, причина часто не в том, что кто-то забыл запустить тест. Это то, что требование никогда не подвергалось сомнению, данные испытаний были неверными или никто не соглашался с тем, что означает «готово». Жизненный цикл тестирования программного обеспечения решает эти проблемы, предоставляя тестированию четкую структуру от первого требования до окончательного отчета.

В этом руководстве объясняется каждый этап, а затем рассматривается одна иллюстративная функция для всех из них: страница входа, которая блокирует учетную запись после пяти неудачных попыток. Источники не полностью сходятся во мнении о количестве фаз. Вы увидите модели с семью или восемью, но в большинстве случаев они по-разному разделяют одну и ту же работу. Мы используем широко распространенную шестифазную версию.

Что такое ГТЛК?

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

Преимущества практичны. Тестировщики подключаются к работе на ранних стадиях, когда исправить дефекты дешевле. Усилия идут на высочайший риск. И когда менеджер спрашивает: «Готовы ли мы выпустить?», команда может ответить доказательствами.

Шесть этапов STLC: краткий обзор

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

Этап 1: Анализ требований

Тестировщики изучают требования, чтобы выяснить, что можно протестировать, а что неясно. Часто это самый дешевый способ предотвратить ошибку, поскольку вопрос стоит гораздо меньше, чем производственное исправление.

• Запись: доступны документы с требованиями или истории пользователей.
• Деятельность: выявляйте функциональные и нефункциональные потребности, задавайте вопросы, оценивайте риски и решайте, что можно автоматизировать.
• Выход: даны ответы на открытые вопросы и запускается матрица прослеживаемости требований (RTM).
• Результаты: список тестируемых требований и RTM.

Пример входа в систему. В статье говорится: «Заблокируйте аккаунт после пяти неудачных попыток». Хороший тестировщик спрашивает: пять за какой период? Как он разблокируется? Успешный вход в систему сбрасывает счетчик? Какое сообщение отображается? Каждый ответ становится чем-то проверяемым.

Этап 2: Планирование тестирования

Команда определяет объем, подход, людей, инструменты, график и риски. Этот этап обычно принадлежит руководителю тестирования.

• Вступление: проанализированы требования и первоначальная оценка рисков.
• Действия: определение масштаба, оценка усилий, выбор инструментов, назначение ролей и установка критериев выхода для последующих этапов.
• Выход: план тестирования рассмотрен и утвержден.
• Результаты: план тестирования и оценка усилий.

Пример входа в систему. В области: правила блокировки, сброс и сообщения об ошибках в Интернете и на мобильных устройствах. За пределами области действия: единый вход, выполняемый другой командой. Самый большой риск — это блокировка реальных пользователей, поэтому этому уделяется больше всего внимания. Если вы не уверены, чем план отличается от стратегии, прочтите план тестирования и стратегия тестирования.

Этап 3: Разработка тестового примера

Здесь тестировщики пишут подробные тестовые примеры, сценарии автоматизации и тестовые данные.

• Вступление: утвержденный план тестирования и стабильные требования.
• Деятельность: написание и проверка тестовых примеров, подготовка данных, создание сценариев автоматических проверок и обновление RTM.
• Выход: тестовые примеры и данные проверены и готовы.
• Результаты: тестовые примеры, сценарии и тестовые данные.

Обратите внимание, что TC-01 и TC-02 проверяют обе стороны предела, который вытекает непосредственно из анализа граничных значений. Подробнее о том, как правильно их писать, см. в разделе как писать тестовые примеры.

Этап 4. Настройка тестовой среды

Для проведения тестов необходимо реалистичное место: правильные серверы, данные, учетные записи, браузеры и доступ к сети. Этот этап часто выполняется параллельно с этапом 3 и может выполняться разработчиками или командой DevOps.

• Вступление: план тестирования, обзор архитектуры и требования к среде.
• Действия: настройка оборудования или контейнеров, загрузка данных, настройка доступа и установка сборки.
• Выход: среда готова, дымовая проверка пройдена.
• Результаты: рабочая среда и результаты дымового теста.

Пример входа в систему. Staging получает тестовые учетные записи в известных состояниях, а также сокращает таймер блокировки, чтобы тестировщикам не приходилось ждать. Быстрый дым-тест подтверждает, что вход в систему загружается вообще до начала полного запуска. Контейнеры помогают поддерживать согласованность среды, как показано в нашем руководстве по Docker Compose.

Этап 5: Выполнение теста

Тестировщики запускают запланированные тесты, сравнивают фактические и ожидаемые результаты и сообщают о дефектах. Исправленные ошибки проходят повторное тестирование, а связанные области проходят регрессионное тестирование.

• Запись: тестовые примеры готовы, среда работает, сборка доставлена.
• Деятельность: запускать тесты, записывать результаты, регистрировать дефекты, повторно тестировать исправления и обновлять RTM.
• Выход: запланированные тесты выполняются, дефекты исправляются или официально принимаются.
• Результаты: результаты испытаний и отчеты о дефектах.

Пример входа. TC-04 не работает: при использовании двух браузеров счетчик достигает только четырех. Тестировщик регистрирует ошибку с четкими шагами и доказательствами, как описано в как написать отчет об ошибке. Как только проблема будет устранена, TC-04 запускается повторно, а соответствующие проверки входа проходят через контрольный список регрессии.

Этап 6: Завершение теста

Этот этап обычно пропускают, и это досадно, поскольку именно благодаря ему команда становится лучше. Команда оценивает цикл, архивирует свою работу и записывает полученные знания.

• Запись: выполнение завершено и статус дефекта известен.
• Деятельность: проверка критериев выхода, анализ тенденций дефектов, архивирование тестовых ресурсов и проведение ретроспективы.
• Выход: отчет о закрытии подписан.
• Результаты: отчет о закрытии и извлеченные уроки.

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

STLC против SDLC

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

Анализ требований в SDLC обеспечивает анализ требований в STLC, а разработка обеспечивает сборку для выполнения тестов. Тестированию не нужно ждать, пока закончится кодирование. Ранний старт — это то, что люди подразумевают под «сдвигом влево».

STLC в Agile и DevOps

Фазы могут показаться длительным односторонним процессом, но это не обязательно так. В Agile одни и те же действия сокращаются и повторяются в каждом спринте, часто в течение нескольких часов, а не недель:

• Анализ требований происходит при уточнении невыполненной работы с помощью вопросов по пользовательской истории.
• Планирование происходит при планировании спринта, где вместо длинных документов используются легкие заметки.
• Проектирование тестов происходит параллельно с кодированием, часто в качестве критериев приемки и автоматических тестов.
• Настройка среды автоматизируется с помощью контейнеров и инфраструктуры в виде кода.
• Выполнение выполняется непрерывно в конвейере CI/CD.
• Завершение становится частью обзора и ретроспективы спринта.

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

Распространенные ошибки

• Привлечение тестировщиков поздно. Ошибки, обнаруженные в требованиях, обходятся гораздо дешевле, чем те, которые были обнаружены после выпуска.
• Неясные критерии выхода. Без них сроки будут принимать решение за вас.
• Тестирование в плохой среде. Сбои, вызванные неверными данными или конфигурацией, приводят к потере времени и подрывают доверие.
• Пропуск завершения. Затем команда повторяет те же ошибки в следующем цикле.
• Слишком жесткое следование этому принципу. STLC является ориентиром. Тяжелые документы не означают автоматически лучшее качество.

Итоги

Жизненный цикл тестирования программного обеспечения — это просто дисциплинированный ответ на шесть вопросов: что мы тестируем, как, в каких случаях, где, что произошло и чему мы научились? Посмотрите на свою следующую функцию и проверьте, какой из этих вопросов ваша команда обычно пропускает. Устранение этого одного пробела, скорее всего, принесет вам наибольшую выгоду.

Часто задаваемые вопросы

Продолжайте учиться