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

Переведено с QA's Dead: Where Do We Go From Here?,автор Kenn Hussey Ambassador Лаборатории. Переводчик также недавно разговаривал со старшим тестировщиком (многие корпоративные тесты принадлежат QA) и почувствовал, что позиционирование тестирования становится все более неудобным.

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

Если нас беспокоит «QA Оно умирает?？”В этом вопросе используетсяЗакон о титулах Беттериджаметод,Неизбежный ответ – нет. контроль качества Оно не мертво; оно мертво. Такая смерть имеет QA Команда произвела огромное впечатление. Однако произошла трансформация, которая в конечном итоге повысила важность качества в жизненном цикле разработки программного обеспечения.

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

Почему контроль качества изменился

Традиционный контроль качества выглядит так:

• дизайн: проектировщики, архитекторы и специалисты по развитию определяют требования к продукту и разрабатывают первоначальную архитектуру.
• развитие: развивать люди пишут коды в соответствии с потребностями и дизайном.
• тест: команда контроля качества получает готовый код.,Создавайте планы тестирования и варианты использования,И выполните ручное/автоматическое тестирование для различных сценариев. Они сообщают об ошибке команде разработчиков.
• Исправлена ​​ошибка: сотрудники индустрии получают отчеты об ошибках.,исправить проблему,и передайте код обратно в отдел контроля качества.
• Повторное тестирование: отдел контроля качества проверяет исправления и, возможно, выполняет еще один раунд регрессий.
• Опубликовано: Один раз QA утвердить,программное обеспечение поступит в производство.

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

Во-первых, все изолированы. Команды разработки и тестирования работают независимо, что приводит к пробелам в общении и несоответствию ожиданий. Такое разделение может привести к созданию отличного продукта, но оно приводит к огромным накладным расходам.

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

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

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

Переход к ответственности за качество

Исторически команда контроля качества была арбитром качества в организации. Теперь эта ответственность перешла к разработчикам. Этот сдвиг — не просто небольшая корректировка; это фундаментальное переосмысление вашего подхода к качеству программного обеспечения.

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

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

Этого можно достичь посредством двух инициатив.

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

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

Как это выглядит на практике?

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

• API-дизайн：развивать Теперь люди могут быстро создавать стандартизированные OpenAPI спецификация. Это позволяет им приступить к программированию практически сразу, не тратя целый спринт на создание первоначального проекта.
• насмешка над API：с помощью соответствующегоинструмент,Интеллектуальные люди могут создавать динамичные модели, которыми можно делиться. Это устраняет необходимость вручную писать и поддерживать код моделирования.,Это обеспечивает быструю проверку и итерацию.
• генерация кода：AI управляемая генерация кодинструмент теперь может работать как на стороне клиента, так и на стороне сервера. API Большая часть шаблонного кода. Это позволяет развивающему персоналу сосредоточиться на API Уникальные аспекты реализации.
• Тестирование и отладка：Современные платформы предоставляют общедоступные URL Используется, чтобы дать возможность разработчикам запускать свой код в производственной среде. Они напрямую связаны с IDE Интеграция, которая позволяет инженерному персоналу устанавливать точки останова и эффективно отлаживать, сводя к минимуму вероятность попадания ошибок в производственную среду.
• развертывать：Сейчас есть хостинг、Контейнерныйтест Относящийся к окружающей средеинструмент。Это позволяет легко прогрессировать и повторятьтест,Без необходимости постоянной перенастройки.

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

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

Будущее контроля качества?

Что же это значит для обеспечения качества?

Нет больше дома? Вроде того, но не совсем! Точнее, теперь у них несколько домов. Обеспечение качества может стать более стратегическим или более техническим, перемещаясь вверх или вниз по стеку.

Первая возможность — спуститься вниз по стеку и занять более техническую роль. Специалисты по обеспечению качества могут использовать свое ориентированное на качество мышление, чтобы стать экспертами по автоматизации или инженерами DevOps. Их опыт в комплексном тестировании имеет решающее значение для разработки надежных и надежных наборов автоматизированных тестов. Концепция «ненадежные тесты хуже, чем отсутствие тестов» становится еще более важной, когда тестирование — единственное, что мешает организации выпускать некачественный код.

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

Вторая возможность — подняться вверх по стеку и занять стратегическую роль. Тестирование теперь является неотъемлемой частью жизненного цикла разработки и требует обдумывания. Специалисты по обеспечению качества могут стать специалистами по стратегии качества, сосредоточившись на разработке комплексных стратегий тестирования, охватывающих весь жизненный цикл программного обеспечения.

QA теперь находится в руках отдельных людей и их инструментов.

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

«Смерть» QA в конечном итоге связана не с его упадком, а с его интеграцией во все аспекты разработки программного обеспечения. Задача организаций будет заключаться в развитии культуры, в которой качество является обязанностью каждого, при этом ценя и используя опыт, который привносят специалисты по обеспечению качества. Используйте инструменты, которые могут обеспечить проверку качества и дать возможность вашим разработчикам надеть свою собственную шляпу по обеспечению качества.