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

Процесс производства программного обеспечения, по хорошему, должен подчиняться жизненному циклу SDLC, и не важно какая модель используется Watefall, V-model, Agile и т.д. SDLC - это процесс производства программного обеспечения, который на систематической основе обеспечивает соответствие качества и "правильности" программного обеспечения стандартам, установленным компанией и отраслью. SDLC в основном состоит из 6 этапов.

• Этап 1. Сбор и анализ требований. На данном этапе нужно получить ответ на вопрос - Какие проблемы требуют решений? Получить максимально подробное описание того, что надо реализовать (фичи, userstory, поведение системы и т.д.). Нужно в голове держать одну простую истину. Если есть требование, оно должно проходить проверку (тестирование). Каждый пройденный тест - это спецификация того, как работает система.

• Этап 2. Дизайн - Как мы добьемся наших целей? Один из важных этапов (все этапы важны, если честно). На данном этапе обсуждаются технические детали дизайна с заинтересованными сторонами, и рассматриваются различные параметры, такие как риски, используемые технологии, возможности команды, ограничения проекта, время и бюджет, а затем выбирается лучший подход к дизайну для продукта.Решения, которые принимаются на этом этапе в отношении технологии, фреймворков, конфигурации, внедрения и управления изменениями, обеспечивают прочную основу для проекта.

• Этап 3. Разработка - регулирует процесс создания продукта. Основная цель этапа разработки - преобразовать прототип системы, созданный на этапе дизайна, в рабочую информационную систему, отвечающую всем задокументированным системным требованиям.

• Этап 4. Тестирование - регулирует обеспечение качественной работы продукта.В большинстве случаев тестирование остается неотъемлемой частью на протяжении всего SDLC. Следовательно, он всегда так или иначе участвует в SDLC, независимо от того, на каком этапе вы сейчас находитесь. Основная цель процедур тестирования - составлять отчеты, отслеживать, разрешать и повторно тестировать программные компоненты до тех пор, пока они не достигнут стандартов качества, установленным компанией и отраслью.

• Этап 5. Внедрение и Этап 6. Обслуживание -  регулирует процессы внедрение продукта и ипользование финального продукта соответственно. На данных этапах идет сбор обратной связи. Полученные данные запускают SDLC с первого этапа.

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

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

• Этап 2. Планирование тестов. Планирование тестирования в STLC - это этап, на котором команда по обеспечению качества определяет стратегию тестирования вместе с усилиями и оценками затрат по проекту. Кроме того, также определяются ресурсы, среда тестирования, ограничения тестирования и график тестирования. План тестирования готовится и дорабатывается на том же этапе.

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

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

• Этап 5. Выполнение тестов. На этом этапе работают тестировщики, которое тестируют сборку программного обеспечения на основе подготовленных планов тестирования и тест кейсов.

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

SDLC и STLC работают параллельно и в этих процессах участвуют все и не только разработчики и тестировщики. Чтобы вся команда работала над встраиванием качества в процессы, в продукт, надо работать с мышлением и менять его. Команда должна понимать, что качественное тестирование очень важно для бизнеса, так как цена исправления пропущенных и обнаруженных ошибок на продуктивных средах может оказаться катастрофически высока (такие ошибки могут ударить не только по финансам, но и по репутации).

Очень важен выбор типов тестирования. Существует как минимум 105 видов тестирования программного обеспечения. Но, естественно, все применять на продукте и в процессах не надо. Наоборот, список функциональных и не функциональных типов тестирования надо формировать обдуманно. Список должен включать в себя 4 категории тестов

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

• Тесты ориентированные на бизнес и/или технологии. Написанные с использованием бизнес-терминологии, бизнес-тесты должны быть понятны пользователю. Написанные на языке разработчика, технологические тесты используются для оценки того, обеспечивает ли система поведение, задуманное разработчиком.

• Тесты критикующие решение путем оценки системы на соответствие требованиям пользователя, чтобы найти дефекты или отсутствующие (нереализованные) фичи.

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

Важно поменять у команды мышление и отношение к обеспечению качества. Существует такое понятие, подход как Test-First Thinking. Давайте ответим на простой вопрос. Для чего вообще тестирование? Для того, чтобы получить некую обратную связь по тому что было сделано, реализовано.

В традиционной V-модели, когда вначале описывается фича, потом userstory, потом пишется код. А после этого начинается тестирование кода, тестирование userstory, тестирование фичи.

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

C подходом Test-First Thinking и Shift left testing ситуация меняется. Мы получаем очень быструю обратную связь. Как только появляется достаточно реализации, можно запускать тесты для проверки написанного кода, для проверки userstory и фичи. То есть тестирование идёт постоянно! Как результат быстрая обратная связь. Подход Test-First Thinking для кода означает, что ни строчки кода, пока не написан тест и не тестировать код, а кодировать для теста. А для фич и userstory Test-First Thinking реализуется BDD.

Что интересно, Test-First Thinking естественным путем создает правильную пирамиду тестирования. Пирамида тестирования выступает за сбалансированный набор тестов с большим количеством небольших автоматизированных тестов низкого уровня (дешевых) и меньшим количеством крупных ручных тестов (дорогих). Также существует анти-паттерн пирамиды тестирования - инвертированная пирамида тестирования, у которой набор тестов с меньшим количеством небольших автоматизированных тестов низкого уровня и большим количеством крупных ручных тестов. И, если на продукте инвертированная пирамида, то ситуация плачевная. Так как это замедляет разработку и получение обратной связи.

Резюмируя скажу, что первый шаг на пути к встраиванию качества в процессы, начинается с работы по смене мышления у команды, и конечно же, аудита тех тестов, которые есть на продукте. Аудит покажет реальную картину с пирамидой тестирования, далее внедрять концепцию Test-First Thinking и Shift left testing.

Продолжение следует...