«Конечно отдельно!», — ответит б.
О большинство читателей.
Этот ответ вписывается в их картину мира, потому что «всегда так было».
Так они всегда работали.
Эта фраза обычно означает наличие продукта, который уже находится в производстве или только готовится к выпуску, но был написан без модульных и интеграционных тестов.
Без системы безопасности в виде тестирования изменения происходят медленно, дорого и полны новых ошибок.
В мире разработки такой проект обычно называют «наследием».
Компания понимает, что без подстраховки обойтись невозможно, поэтому создается отдел контроля качества, который обычно не обеспечивает качество продукта, а лишь контролирует его.
Имея отдел QA, разработчик может смело заниматься любимым делом — писать код, ведь за качество теперь отвечает выделенный отдел! Происходит классический «переброс кода через стену» в отдел тестирования: 
Отдел контроля качества пишет сотни тест-кейсов «черного ящика» для готового функционала, который необходимо пройти в ходе регрессии.
А также, если продукт продолжит развиваться, сотни тест-кейсов для нового функционала, которые позже добавляются в регрессию.
Каждый тестовый пример заполняется вручную, поэтому процесс тестирования занимает много времени.
Количество тест-кейсов в регрессии постоянно растет по естественным причинам, и принимается решение о создании команды автоматизации внутри отдела QA. Поскольку вновь сформированная команда была набрана из-за необходимости ускорить регрессионный цикл, состоящий из тестов «черного ящика», автоматизация происходит на уровне «черного ящика»: через GUI или API. Автоматизация через GUI — самая болезненная и дорогая из-за хрупкости и низкой скорости тестов, но зачастую люди именно с этого и начинают. Между тем факт создания новой команды никак не влияет на команду разработчиков: она продолжает отправлять на тестирование некачественные продукты, игнорируя написание модульных и интеграционных тестов.
Учитывая огромное количество скриптов «черного ящика», стоящих в очереди на автоматизацию, мы получаем антипаттерн тестирования «Конус мороженого», в котором количество самых медленных и самых дорогих GUI-автотестов значительно превышает количество дешевых и быстрых.
модульные и интеграционные тесты.
С каждым релизом появляется все больше нестабильных и медленных автотестов GUI, а значит на их поддержку тратится больше ресурсов, что приводит к расширению команды автоматизации.
Отдел обеспечения качества растет, но не обеспечивает должного роста качества продукта.
Вы действительно хотите работать так вечно?
В чем проблема?
Одной из основных причин описанной выше ситуации является отсутствие культуры разработки, при которой каждый разработчик несет ответственность за написанный им код. И даже минимальная ответственность подразумевает необходимость убедиться в работоспособности кода, прежде чем радостно воскликнуть: «Моя работа готова!» Eye Driven Development — это самый простой способ убедиться, что ваш код работает, но он не самый оптимальный.Этот метод прост тем, что не предполагает практически никакой интеллектуальной работы: тестируем приложение, сервис, класс и т.д. руками.
с точки зрения конечного пользователя, без учета граничных значений, классов эквивалентности, негативных сценариев, сценариев с разными уровнями разрешений и т. д. Этот метод не обеспечивает быструю обратную связь при разработке, не позволяет протестировать сущность на разнородной выборке данных, занимает много времени и не улучшает качество продукта.
Самый оптимальный способ — написать автотесты для разрабатываемого кода.
Говоря об ответственности за код, не имеет значения, когда пишутся автотесты: до или после самого кода.
Главное, что дает этот метод, — это уверенность в том, что работа действительно завершена и можно переходить к другой задаче.
Учитывая другие преимущества, такие как быстрая обратная связь, возможность тестирования объекта на большой выборке и высокая скорость, автотесты, написанные разработчиками, являются отличным инструментом для улучшения качества продукта.
Мы не работаем так, как всегда.
Предлагаю мысленно смоделировать возможное развитие событий в команде, члены которой отвечают за написанный код. У нас есть продукт, который уже находится в производстве или вот-вот выйдет в свет, который покрыт модульными и интеграционными тестами.
Код постоянно совершенствуется, и добавляется новый функционал, не опасаясь сломать уже существующие.
Чтобы убедиться в том, что разрабатываемый функционал работает, вам больше не нужно «перекидывать код через стену» в отдел тестирования и тратить время на ожидание вердикта, а затем повторять итерацию снова и снова.
Отдел контроля качества уже создан и активно участвует в процессе разработки, действительно обеспечивая качество выпускаемого продукта.
Говоря об обеспечении качества, мне кажется, удобно руководствоваться Квадрантами Тестирования: 
Используя квадранты тестирования, тестирование можно разделить на 4 категории.
Первая категория — это тестирование реализации продукта, которое создает систему безопасности для команды разработчиков.
Эта категория отвечает за низкоуровневое тестирование с использованием модульных и интеграционных тестов и позволяет разработчикам понять, что с технической точки зрения они все делают правильно (Do Things Right).
Очевидно, что низкоуровневые тесты полностью автоматизированы и пишутся командой разработчиков, так как находятся в их области интересов.
Вторая категория — тестирование бизнес-функциональности продукта, создание подстраховки команды разработчиков.
Здесь речь идет о таких видах тестирования, как Примеры, Исторические тесты и других, направленных, прежде всего, на создание корректной коммуникации между бизнесом и командой разработчиков, и позволяющих команде понять, что она делает правильные вещи (Do Right Things), которые бизнесу это действительно нужно.
Примеры автоматизации или Story Tests — это End-to-End тесты, которые проверяют не сложные сценарии использования интерфейса, а только бизнес-логику, но через интерфейс, доступный конечному пользователю.
Поскольку эта категория тестирования пока находится в сфере интересов разработчиков, автоматизация ложится на плечи команды разработчиков.
Третья категория — это тестирование бизнес-функций продукта, которые имеют решающее значение для восприятия конечным пользователем качества продукта.
В эту категорию входят исследовательское тестирование, тестирование сложных вариантов использования продукта, тестирование удобства использования, альфа- и бета-тестирование.
Тесты этой категории полностью лежат на плечах команды QA, и их автоматизация невозможна или слишком сложна.
Если говорить непосредственно об исследовательском тестировании и тестировании сложных скриптов, способных находить функциональные ошибки, то стоит отметить, что любая найденная ошибка является ошибкой в коде и может быть перекрыта соответствующими модульными или интеграционными тестами.
Об этом хорошо написал Мартин Фаулер, и я позволил себе вольность с переводом:
Я всегда утверждаю, что тесты высокого уровня служат второй линией тестовой защиты.Четвертая категория — это тестирование реализации продукта, которое имеет решающее значение для восприятия конечным пользователем качества продукта.Если вы получили сбой в тесте высокого уровня, это означает не только ошибку в вашем функциональном коде, но и отсутствие или неправильный модульный тест. Поэтому я советую, прежде чем исправлять ошибку, обнаруженную в ходе высокоуровневого теста, вам следует воспроизвести ошибку с помощью модульного теста.
Затем модульный тест гарантирует, что ошибка останется мертвой.
Я утверждаю, что тестирование высокого уровня — это всего лишь вторая линия защиты.
Неудачный высокоуровневый тест означает не только ошибку в коде продукта, но и отсутствие соответствующего модульного теста или ошибку в существующем.
Мой вам совет: прежде чем исправлять ошибку, обнаруженную высокоуровневым тестом, воспроизведите ее с помощью юнит-теста и вы навсегда попрощаетесь с ошибкой.
В эту категорию обычно попадают нагрузочное тестирование, тестирование производительности, а также тестирование безопасности и надежности системы.
Такое тестирование проводится с помощью специальных инструментов, часто написанных под нужды конкретного проекта.
По-хорошему, отдел DevOps отвечает за инфраструктуру для проведения таких тестов, а разработка соответствующих инструментов — задача.
отдельная команда.
Более того, инструменты должны позволять проводить тестирование по требованию (Тестирование как услуга).
Поскольку созданный отдел обеспечения качества теперь отвечает не только за контроль качества продукции, но и за обеспечение качества, в его обязанности входит:
- Помощь разработчикам в написании тестов из первой категории
- Участие в формировании Примеров и Историй-Тестов при общении команды разработчиков и представителей бизнеса.
- Проведение исследовательского тестирования и комплексного сценарного тестирования.
- Проведение юзабилити-тестирования и работа с обратной связью от пользователей.
В этом случае формируем правильное соотношение тестов или, как его принято называть, «пирамиду тестирования»: 
Увеличение количества ручных регрессионных тестов минимально; автоматизация на уровне модульных, интеграционных и GUI-тестов осуществляется командой разработчиков.
Более того, количество тестов GUI невелико; они описывают не сложные сценарии использования GUI, а работу бизнес-логики через пользовательский интерфейс, а значит, они менее хрупкие и дешевле в поддержке.
Отдел обеспечения качества действительно занимается обеспечением качества, получая отзывы пользователей и работая с ними, проводя предварительное тестирование, тестируя новые функции с использованием сложных сценариев и помогая разработчикам взаимодействовать с бизнесом.
Тестирование в проекте было автоматизировано эффективнее, чем в первом случае, но команда автоматизации в составе отдела QA так и не появилась.
И повторю вопрос: «А Automation QA — это отдельная командаЭ» Теги: #тестирование #qa #культура программирования #автоматизация тестирования #тестирование ИТ-систем #Идеальный код
-
Шифрование В Mysql: Ротация Мастер-Ключа
19 Oct, 24 -
Что Такое Вмс?
19 Oct, 24
