В предыдущей статье Как встроить качество в процессы производства ПО? мы коснулись основных понятий про качество, четырехуровневый процесса управления и обеспечения качества, увидели что требования и качества тесно связаны друг с другом.
Процесс производства программного обеспечения, по хорошему, должен подчиняться жизненному циклу SDLC, и не важно какая модель используется Watefall, V-model, Agile и т.д. SDLC — это процесс производства программного обеспечения, который на систематической основе обеспечивает соответствие качества и «правильности» программного обеспечения стандартам, установленным компанией и отраслью. SDLC в основном состоит из 6 этапов.
![](https://habrastorage.org/getpro/habr/upload_files/cd6/abc/8a6/cd6abc8a6430ca7e9eaef4b262d4c6ce.png)
-
Этап 1. Сбор и анализ требований. На данном этапе нужно получить ответ на вопрос — Какие проблемы требуют решений? Получить максимально подробное описание того, что надо реализовать (фичи, userstory, поведение системы и т.д.). Нужно в голове держать одну простую истину. Если есть требование, оно должно проходить проверку (тестирование). Каждый пройденный тест — это спецификация того, как работает система.
-
Этап 2. Дизайн — Как мы добьемся наших целей? Один из важных этапов (все этапы важны, если честно). На данном этапе обсуждаются технические детали дизайна с заинтересованными сторонами, и рассматриваются различные параметры, такие как риски, используемые технологии, возможности команды, ограничения проекта, время и бюджет, а затем выбирается лучший подход к дизайну для продукта.Решения, которые принимаются на этом этапе в отношении технологии, фреймворков, конфигурации, внедрения и управления изменениями, обеспечивают прочную основу для проекта.
-
Этап 3. Разработка — регулирует процесс создания продукта. Основная цель этапа разработки — преобразовать прототип системы, созданный на этапе дизайна, в рабочую информационную систему, отвечающую всем задокументированным системным требованиям.
-
Этап 4. Тестирование — регулирует обеспечение качественной работы продукта.В большинстве случаев тестирование остается неотъемлемой частью на протяжении всего SDLC. Следовательно, он всегда так или иначе участвует в SDLC, независимо от того, на каком этапе вы сейчас находитесь. Основная цель процедур тестирования — составлять отчеты, отслеживать, разрешать и повторно тестировать программные компоненты до тех пор, пока они не достигнут стандартов качества, установленным компанией и отраслью.
-
Этап 5. Внедрение и Этап 6. Обслуживание — регулирует процессы внедрение продукта и ипользование финального продукта соответственно. На данных этапах идет сбор обратной связи. Полученные данные запускают SDLC с первого этапа.
![STLC и SDLC живут параллельно STLC и SDLC живут параллельно](https://habrastorage.org/getpro/habr/upload_files/52a/c5f/88e/52ac5f88eecbf7637ffab4d628f2c24d.png)
Как составную часть SDLC можно рассмотреть STLC — жизненный цикл тестирования программного обеспечения — это последовательность различных действий, выполняемых в процессе тестирования программного обеспечения. Как и SDLC, STLC включает в себя несколько этапов.
-
Этап 1. Анализ требований. На данном этапе группа тестирования изучает требования с точки зрения тестирования, чтобы идентифицировать тестируемые требования, а группа QA может взаимодействовать с различными заинтересованными сторонами для детального понимания требований. Требования могут быть функциональными или нефункциональными. На этом этапе также выполняется технологическое и экономическое обоснование автоматизации тестирования.
-
Этап 2. Планирование тестов. Планирование тестирования в STLC — это этап, на котором команда по обеспечению качества определяет стратегию тестирования вместе с усилиями и оценками затрат по проекту. Кроме того, также определяются ресурсы, среда тестирования, ограничения тестирования и график тестирования. План тестирования готовится и дорабатывается на том же этапе.
-
Этап 3. Разработка тест кейсов. Этап разработки тест кейсов включает в себя создание, проверку и переработку тест кейсов и тестовых сценариев после того, как план тестирования будет готов. В первую очередь идентифицируются тестовые данные, затем создаются и проверяются, а затем переделываются на основе предварительных условий. Затем команда QA начинает процесс разработки тест кейсов для отдельных модулей.
-
Этап 4. Настройка тестовой среды. На данном этапе определяются программные и аппаратные условия, при которых продукт будет тестироваться. Это один из важнейших аспектов процесса тестирования, который может выполняться параллельно с этапом разработки тест кейсов.
-
Этап 5. Выполнение тестов. На этом этапе работают тестировщики, которое тестируют сборку программного обеспечения на основе подготовленных планов тестирования и тест кейсов.
-
Этап 6. Завершение тестового цикла. Этап закрытия цикла тестирования — это завершение выполнения теста, которое включает в себя несколько действий, таких как создание отчетов о завершении тестирования, сбор матриц тестирования и результатов тестирования. Команда тестирования проводит ретроспективу — обсуждает и анализирует артефакты тестирования, чтобы определить стратегии, которые необходимо реализовать в будущем, извлекая уроки из текущего цикла тестирования. Идея состоит в том, чтобы устранить узкие места в процессе для будущих циклов тестирования.
SDLC и STLC работают параллельно и в этих процессах участвуют все и не только разработчики и тестировщики. Чтобы вся команда работала над встраиванием качества в процессы, в продукт, надо работать с мышлением и менять его. Команда должна понимать, что качественное тестирование очень важно для бизнеса, так как цена исправления пропущенных и обнаруженных ошибок на продуктивных средах может оказаться катастрофически высока (такие ошибки могут ударить не только по финансам, но и по репутации).
![Относительная стоимость исправления ошибок в зависимости от времени и места обнаружения Относительная стоимость исправления ошибок в зависимости от времени и места обнаружения](https://habrastorage.org/getpro/habr/upload_files/321/695/142/3216951427af65aa79e239d16565b153.png)
Очень важен выбор типов тестирования. Существует как минимум 105 видов тестирования программного обеспечения. Но, естественно, все применять на продукте и в процессах не надо. Наоборот, список функциональных и не функциональных типов тестирования надо формировать обдуманно. Список должен включать в себя 4 категории тестов
-
Тесты, которые направляют разработку, заставляя команду разработчиков думать о том, как они будут тестировать story или фрагмент кода, прежде чем писать его.
-
Тесты ориентированные на бизнес и/или технологии. Написанные с использованием бизнес-терминологии, бизнес-тесты должны быть понятны пользователю. Написанные на языке разработчика, технологические тесты используются для оценки того, обеспечивает ли система поведение, задуманное разработчиком.
-
Тесты критикующие решение путем оценки системы на соответствие требованиям пользователя, чтобы найти дефекты или отсутствующие (нереализованные) фичи.
![Квадранты тестирования Квадранты тестирования](https://habrastorage.org/getpro/habr/upload_files/b41/a43/d4c/b41a43d4c4ba1358e5230404f957d78a.png)
Некоторые из этих тестов должны быть автоматизированы, некоторые должны запускаться при помощи разных тулзов, а некоторые должны быть ручными.
Важно поменять у команды мышление и отношение к обеспечению качества. Существует такое понятие, подход как Test-First Thinking. Давайте ответим на простой вопрос. Для чего вообще тестирование? Для того, чтобы получить некую обратную связь по тому что было сделано, реализовано.
В традиционной V-модели, когда вначале описывается фича, потом userstory, потом пишется код. А после этого начинается тестирование кода, тестирование userstory, тестирование фичи.
![Традиционная V-модель тестирования. Медленная ОС! Традиционная V-модель тестирования. Медленная ОС!](https://habrastorage.org/getpro/habr/upload_files/346/8c0/4c4/3468c04c4fdf3362f8c0ab7ebb07b5f1.png)
Как видно в такой модели очень медленная обратная связь. А медленная обратная связь тормозит весь процесс создания ценности для клиента. Последствия этого думаю описывать не надо.
C подходом Test-First Thinking и Shift left testing ситуация меняется. Мы получаем очень быструю обратную связь. Как только появляется достаточно реализации, можно запускать тесты для проверки написанного кода, для проверки userstory и фичи. То есть тестирование идёт постоянно! Как результат быстрая обратная связь. Подход Test-First Thinking для кода означает, что ни строчки кода, пока не написан тест и не тестировать код, а кодировать для теста. А для фич и userstory Test-First Thinking реализуется BDD.
![Быстрая ОС! Быстрая ОС!](https://habrastorage.org/getpro/habr/upload_files/74e/853/816/74e85381657aa92c2aaa3e93bde643e0.png)
Что интересно, Test-First Thinking естественным путем создает правильную пирамиду тестирования. Пирамида тестирования выступает за сбалансированный набор тестов с большим количеством небольших автоматизированных тестов низкого уровня (дешевых) и меньшим количеством крупных ручных тестов (дорогих). Также существует анти-паттерн пирамиды тестирования — инвертированная пирамида тестирования, у которой набор тестов с меньшим количеством небольших автоматизированных тестов низкого уровня и большим количеством крупных ручных тестов. И, если на продукте инвертированная пирамида, то ситуация плачевная. Так как это замедляет разработку и получение обратной связи.
![Пирамида тестирования и ее анти-паттерн Пирамида тестирования и ее анти-паттерн](https://habrastorage.org/getpro/habr/upload_files/d70/e6d/a8f/d70e6da8f70af8b56761eae934aad6a4.png)
Резюмируя скажу, что первый шаг на пути к встраиванию качества в процессы, начинается с работы по смене мышления у команды, и конечно же, аудита тех тестов, которые есть на продукте. Аудит покажет реальную картину с пирамидой тестирования, далее внедрять концепцию Test-First Thinking и Shift left testing.
Продолжение следует…
ссылка на оригинал статьи https://habr.com/ru/articles/591993/
Добавить комментарий