Полное руководство по жизненному циклу тестирования программного обеспечения (STLC)

Тестирование - более сложная и важная задача, чем может показаться на первый взгляд. Жизненный цикл тестирования программного обеспечения (STLC) - это всеобъемлющий подход, который гарантирует полноценное и эффективное тестирование программного обеспечения на протяжении всего процесса разработки ПО. В этом руководстве вы узнаете, что такое жизненный цикл тестирования ПО, его компоненты и альтернативы. Мы также объясним, почему этот трудоемкий и кропотливый подход является неотъемлемой частью процесса разработки программного обеспечения. Кроме того, мы поделимся опытом выбора моделей STLC, преодоления возможных трудностей и организации работ по тестированию.

STLC как компонент SDLC

Термин "жизненный цикл разработки программного обеспечения" (SDLC) описывает весь процесс разработки. Однако он существенно отличается от жизненного цикла тестирования ПО, или STLC. Чтобы избежать путаницы, давайте подробно рассмотрим, чем они отличаются и в чем пересекаются.

Жизненный цикл разработки программного обеспечения

Жизненный цикл разработки программного обеспечения - это способ организации всех этапов создания продукта, начиная с создания MVP и заканчивая расширением продукта после его выпуска. Типичный SDLC включает в себя следующие этапы:

Планирование. На этом этапе вы и ваша команда исследователей изучаете целевую аудиторию, формируете идею продукта, составляете бизнес-план разработки приложения, выбираете модель монетизации и находите технического партнера - это может быть как соучредитель, так и аутсорсинговая команда, если вы решили воспользоваться офшорной разработкой.
Выяснение требований. На этом этапе создается документ с требованиями к программному обеспечению. Ваша команда определяет функциональность продукта и оценивает возможные риски и ограничения, создавая руководство по воплощению вашей идеи в жизнь и по тому, как должен выглядеть конечный продукт.
Дизайн. На этом этапе специалисты UI/UX работают над интерфейсом продукта, создавая прототип программного обеспечения в соответствии с техническим заданием.
Разработка и тестирование. На этом этапе разработчики реализуют все необходимые функции и интеграции, а специалисты QA тестируют исходный код и весь продукт, чтобы обеспечить бесперебойную работу конечных пользователей.
Развертывание. Это процесс выпуска программного обеспечения в производственную среду, где оно будет доступно конечным пользователям.
Сопровождение. Это заключительный этап разработки продукта. После запуска продукта в эксплуатацию все усилия направляются на наблюдение за работой системы, выявление и устранение ошибок, внедрение новой функциональности и другие улучшения проекта.

Жизненный цикл тестирования программного обеспечения

Жизненный цикл тестирования программного обеспечения (STLC) определяет набор этапов тестирования продукта. Он позволяет проверить масштабируемость, работоспособность и производительность продукта. Кроме того, он помогает уменьшить количество ошибок перед внедрением. Другими словами, SDLC охватывает все процессы разработки ПО, а STLC - только те, которые связаны с тестированием ПО: формирование требований к тестам, разработка тестовых примеров и оценка результатов тестирования.

Важно помнить, что жизненный цикл тестирования ПО начинается не после разработки, а на этапе планирования и сбора требований. Таким образом, управление качеством может быть хорошо спланировано и структурировано, что позволит исключить проблемы на начальном этапе разработки и сэкономить средства и ресурсы на их решение. Аналогичным образом, жизненный цикл тестирования программного обеспечения (STLC) не заканчивается после выпуска продукта. Он продолжается на этапе сопровождения, обеспечивая нормальное функционирование программного обеспечения после выпуска новых функций, исправления ошибок или изменения кодовой базы.

Заинтересованные стороны, участвующие в STLC

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

Каких специалистов следует привлекать к тестированию программного обеспечения? Состав заинтересованных сторон может меняться в зависимости от структуры команды разработчиков ПО, но, как правило, в STLC участвуют следующие роли:

Владелец продукта (Product owner, PO) - принимает ключевые решения и следит за распределением ресурсов на протяжении всего процесса.
Менеджер проекта (PM) - занимается организацией и выполнением проекта, обеспечивая соответствие каждого шага целям проекта
Бизнес-аналитик (BA) - анализирует потребности бизнеса, выявляет проблемы и формирует требования к программному обеспечению (функциональные и нефункциональные)
Дизайнеры - тесно сотрудничают с разработчиками и тестировщиками, чтобы убедиться, что все разработанные элементы соответствуют требованиям проекта и ожиданиям пользователей
Разработчики - создают сам продукт, тесно сотрудничая с командой тестирования, дают понимание технических аспектов программного обеспечения другим членам команды, устраняют проблемы, выявленные в ходе тестирования
Команда обеспечения качества (QA) - отвечает за разработку и проведение тестов, документирование проблем и результатов тестирования, а также за обеспечение соответствия программного обеспечения требованиям и стандартам качества
Конечные пользователи - взаимодействуют с продуктом в реальных условиях, что делает их отзывы и участие критичными для понимания удобства использования ПО и проверки соответствия ПО потребностям пользователей.

Это типичный список заинтересованных сторон. В некоторых случаях могут быть привлечены дополнительные специалисты. Например, в проектах, связанных со здравоохранением или недвижимостью, могут привлекаться специалисты по правовым вопросам. Они могут помочь определить приоритетность конкретных функций и проверить их на соответствие нормативным требованиям. Аналогично при разработке FinTech-продуктов (которые всегда требуют участия специалистов по безопасности) необходимо контролировать риски, связанные с защитой конфиденциальных данных.

Этапы STLC

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

Анализ требований
Планирование тестирования
Разработка тестовых примеров
Создание тестовой среды
Выполнение тестов
Управление дефектами
Завершение тестового цикла
Оценка тестового цикла

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

1. Анализ требований

Жизненный цикл тестирования начинается с определения ключевых критериев тестирования, что совпадает с началом этапа спецификации требований к программному обеспечению (SRS) в SDLC. Какие критерии следует установить для тестирования? Требования к различным этапам тестирования принято разделять на критерии входа и критерии выхода.

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

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

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

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

2. Планирование

После того как вы поняли критерии входа и выхода из цикла тестирования, наступает время для этапа планирования. На этом этапе важно учесть различные аспекты тестирования: подготовить необходимые устройства и инструменты, собрать команду специалистов нужной квалификации, оценить объем работ, определить сроки.

Для разработки продуманного STLC, отвечающего всем требованиям, сформированным на предыдущем этапе, необходимо выполнить следующие шаги:

Оценить объем работ с учетом ключевых требований, сформированных на предыдущем этапе, чтобы убедиться в возможности соблюдения сроков и бюджета проекта.
Определить цели тестирования. Четко сформулированные цели процесса тестирования служат ориентирами для оценки качества и эффективности ПО. Как правило, они включают в себя поиск дефектов, обеспечение функциональности, оценку производительности, обеспечение безопасности и повышение удобства использования. Определив цели тестирования, команда может согласовать свои усилия и сосредоточиться на конкретных областях для достижения желаемых результатов на этапе тестирования.
Выбирать методы тестирования в соответствии со спецификой проекта. Например, тестирование производительности может не иметь решающего значения для заказных CRM-систем с ограниченным и точно известным числом пользователей (например, для чартерных авиакомпаний или небольших логистических компаний), но оно необходимо для приложений электронной коммерции, финансовых или игровых приложений, работающих с огромными объемами данных и обрабатывающих множество действий пользователей. Вот, например, некоторые приемы, которые мы часто используем в наших проектах:
- Юнит-тестирование - это проверка фрагмента кодовой базы после его разработки.
- Интеграционное тестирование позволяет убедиться в том, что все модули или элементы приложения могут согласованно работать друг с другом
- Функциональное тестирование подразумевает проверку каждой функции в отдельности и в сочетании с другими.
- Регрессионное тестирование предполагает повторное тестирование всего приложения или его подмножества, чтобы убедиться, что после внесения изменений или обновлений оно продолжает работать так, как задумано.
Рассмотрите возможность автоматизации. Автоматизация тестирования дает множество преимуществ, в том числе следующие:
- Ускоренное выполнение тестов. Автоматизация позволяет ускорить выполнение тестовых примеров и сократить общее время тестирования.
- Улучшение тестового покрытия. Автоматизированные тесты могут охватывать более широкий спектр сценариев, что увеличивает охват тестируемого ПО.
- Повышенная надежность. Автоматизированные тесты дают последовательные и надежные результаты, сводя к минимуму риск человеческой ошибки.
- Сокращение ручного труда. Автоматизация устраняет необходимость ручного выполнения повторяющихся тестовых примеров, что экономит время и силы специалистов QA.

Однако автоматизация также имеет ряд проблем и особенностей, которые необходимо учитывать:

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

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

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

Сочетание ручного и автоматизированного тестирования часто дает наилучший результат.

Выбор инструментов и инфраструктуры тестирования. К ним относятся инструменты для управления (Jira, TestRail, Zephyr), автоматизированного тестирования (Selenium, Postman, Jenkins, Travis CI, BrowserStack, Appium, JUnit, TestNG, Cucumber), тестирования производительности (Apache JMeter, LoadRunner, Gatling) и других сценариев использования.

3. Разработка тестовых примеров

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

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

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

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

4. Создание тестовой среды

На следующем этапе необходимо создать соответствующую тестовую среду. Для этого необходимо воссоздать операционную среду продукта, включающую аппаратную, программную и сетевую конфигурации. Тестовая среда может включать в себя определенные устройства, протоколы, IP-адреса, веб-адреса, шлюзы, версии операционных систем, барьеры безопасности (межсетевые экраны).

Также необходимо выбрать средства визуализации, такие как Docker, Vagrant и VirtualBox. Они позволяют хранить все необходимые зависимости, конфигурации и версии ПО для тестовой среды и, как следствие, без проблем воспроизводить тестовую среду на различных устройствах и серверах.

Еще один момент, который необходимо сделать на этом этапе, - дымовое тестирование, представляющее собой группу тестов, позволяющих быстро проверить основные возможности программного обеспечения. Цель дымового тестирования - определить, достаточно ли стабильно программное обеспечение, чтобы приступить к дальнейшему тестированию. Дымовое тестирование позволяет выявить основные ошибки на ранней стадии и избежать траты ресурсов на проверку нестабильного ПО.

5. Проведение тестирования

Когда все подготовительные работы завершены и тестировщики получили стабильную версию приложения, начинается основной этап жизненного цикла тестирования ПО (STLC) - выполнение тестов. Этот этап можно разделить на следующие шаги:

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

Для оптимизации ресурсов можно определить приоритетность дефектов в зависимости от их серьезности и влияния, а для критических дефектов провести экспертизу первопричин.

6. Отчетность по дефектам

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

7. Завершение тестового цикла и управление артефактами

Для завершения STLC необходимо сохранить и проанализировать результаты предыдущих этапов. Один из последних этапов - закрытие тестового цикла - включает в себя следующие шаги:

Архивирование тестовых артефактов. К ним относятся тестовые случаи, тестовые данные, тестовые сценарии и результаты тестирования. Важно правильно заархивировать их для последующего использования с помощью систем контроля версий (Git, SVN или TFS), облачных хранилищ (Google Drive, Dropbox или OneDrive) или средств управления тестированием (Jira, HP ALM или TestRail).
Подготовить сводные отчеты о тестировании. В этих отчетах должны быть отражены мероприятия и результаты тестирования, включая возникшие проблемы и их решение. В них также должны быть кратко описаны масштабы тестирования и даны рекомендации по дальнейшему тестированию.

8. Оценка цикла тестирования

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

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

Мы рассмотрели все этапы жизненного цикла тестирования ПО, их основные компоненты, инструменты и программное обеспечение, необходимое для тестирования, а также способы достижения лучших результатов. Далее мы рассмотрим, как различные подходы к разработке программного обеспечения могут влиять на STLC.

STLC в различных методологиях разработки ПО

STLC имеет определенный набор этапов, применимых ко всем проектам. Однако способы их реализации могут различаться в зависимости от методологии разработки - Agile или Waterfall. В данном контексте мы также можем называть эти методологии жизненным циклом тестирования ПО.

Рассмотрим подробнее две популярные модели - Waterfall и Agile - чтобы понять их влияние на организацию цикла тестирования.

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

Тестирование начинается только после