Последнее десятилетие бросило QA новый вызов: тестирование программного обеспечения должно проходить еще быстрее. Компании увеличивают штат QA-инженеров, обучают разработчиков техникам тестирования, но случается, что это дает обратный эффект и выход ПО на рынок замедляется. Почему так происходит и как можно повысить эффективность QA?
Эту тему мы обсудили с Дилипом Марвеем – опытным тестировщиком, который уже более 17 лет вносит свой вклад в развитие QA-комьюнити. Сегодня Дилип руководит QA-отделом в медиакомпании The Economist Group – долгосрочном партнере компании «Точка качества».
Все чаще компании переходят на agile для управления процессом разработки по и, конечно же, внедряют тестирование. Допускают ли они при этом ошибки?
Индустрия развития ПО меняется очень быстро и не позволяет выпускать на рынок некачественные продукты. Ко всем приходит понимание того, что QA-практики – это уже давно не тренд, а обязательное условие для любого бизнеса, который стремится стать лучше конкурентов.
На мой взгляд, самая распространенная ошибка – это полное перекладывание всей ответственности за качество программных продуктов на QA-специалистов. На самом деле, ответственность за качество должна лежать на всей команде. А QA-инженеры должны научить разработчиков заботиться о качестве создаваемого продукта.
Поэтому самое главное – это смена парадигмы мышления ИТ-специалистов. Очень важно, чтобы все (и топ-менеджеры в том числе) понимали, насколько важно выделять время и ресурсы процессу обеспечения качества.
Автоматизация тестирования – неоспоримый тренд в тестировании ПО. Как вы думаете, почему она до сих пор полностью не заменила ручное тестирование?
Зачем? Ведь есть сценарии, когда без ручного тестирования не обойтись. При тестировании элементов интерфейса пользователя, пользовательского опыта, или UX, например.
Но я бы хотел отметить следующее. Для меня тестировщики не делятся на ручных специалистов и автоматизаторов. Будь то инженер по
тестированию производительности или специалист по автоматизированному тестированию, он все равно должен уметь читать программный код.
Также важно поддерживать желание всех членов команды развиваться, приобретать новые навыки, становиться профи в своей области. Все участники проекта должны содействовать достижению общей цели и работать с полной отдачей делу. Когда релиз продукта срывается из-за того, что команда сильно зависит от какого-то одного навыка, – это недопустимо.
Кроме того, нужно понимать, что нельзя автоматизировать все подряд, гонясь за тенденцией «автоматизируйте как можно больше». Куда важнее делать это правильно и в нужных объемах, принося максимум пользы проекту и бизнесу.
Кто ответственен за качество программного обеспечения в компании и почему?
За качество отвечает каждый участник проекта. Вся команда должна преследовать общую цель – выпустить на рынок первоклассный программный продукт.
Такой подход создает спокойную, комфортную для всех атмосферу в коллективе. Когда все участники проявляют уважение к коллегам, демонстрируют проактивность, не боятся пошутить и получают удовольствие от процесса – все это значительно улучшает общий результат работы команды.
Как методология agile изменила отношение ит-специалистов к процессу обеспечения качества?
Результатом внедрения практик Agile стало использование принципа shift left. Основная идея принципа shift left в тестировании состоит в том, чтобы выявлять и исправлять проблемы на ранней стадии разработки. Такой подход позволяет существенно сократить затраты на исправление ошибок в более поздние фазы разработки, где они могут обнаруживаться более сложными и дорогостоящими способами. Это необратимо повлияло на мир QA.
Непрерывная доставка ценного продукта сменила собой медленные процессы разработки, а QA помогает выпускать качественное ПО в условиях высоких скоростей. И это тоже заслуга Agile.
В чем преимущества и недостатки концепции shift left?
Основное преимущество раннего привлечения тестировщиков к проекту – это более быстрая доставка ИТ-решения на рынок. Ведь чем раньше начинается тестирование, тем ниже вероятность того, что ошибки, допущенные на ранних этапах разработки, сорвут релиз продукта.
Но не стоит забывать и о сложностях. Очень важно тщательно планировать процесс тестирования и разработки. Также нужно готовить команду разработки к тому, что они тоже должны вносить вклад в процесс QA. Здесь я имею в виду качественное проведение тестирования кода и участие в автоматизации тестирования.
Как непрерывное тестирование помогает улучшить качество и повысить скорость выпуска продуктов на рынок?
Основной инструмент непрерывного тестирования – это автоматизация.
Автоматизированные проверки на каждом этапе жизненного цикла ПО позволяют без лишних сложностей оценить бизнес-риски в каждой версии продукта. А значит, найти и исправить дефекты в нужное время.
С помощью современных технологий (ИИ, машинное обучение, предсказательная аналитика) автоматизацию можно сделать «умнее».
А тест-кейсы нужно актуализировать и поддерживать в таком состоянии, чтобы каждый член команды понимал:
- Если все тесты прошли успешно, можно начинать сборку.
- Если какой-то тест провалился, вероятнее всего, дефект есть в системе, а не в тестовом скрипте, и проблему нужно исправить.
Такой подход позволяет непрерывно выпускать продукты на рынок, а главное – сделает качество ответственностью всей команды.
Какие сходства и различия можно выделить, сравнивая подходы непрерывного тестирования и shift left?
Оба принципа необходимы для эффективного процесса QA. Если сравнивать их, то, по-моему, они имеют больше сходств, чем различий.
Непрерывное тестирование включает в себя все процессы, начиная с раннего подключения тестирования к проекту, то есть shift left. Внедряя их правильно, можно запустить очень сильный программный продукт в разы быстрее.
Говоря о различиях, shift left акцентирует внимание на проверках, проводимых на самых ранних стадиях создания программного продукта. Непрерывное тестирование имеет дело с уже частично разработанной версией ПО и осуществляется на каждом этапе разработки.
Таким образом, проблемы, которые обнаруживаются в результате непрерывных проверок и тестирования shift left, могут быть абсолютно разными.
Как компаниям объединить концепции непрерывного тестирования и shift left?
Для начала ответьте на два вопроса:
- Почему они должны быть объединены?
- Какова цель этого объединения?
Ответив на них, начинайте обучать разработчиков обеспечивать качество продукта на уровне кода. При этом каждый разработчик должен знать, что за его спиной есть QA-инженер.
Позвольте каждому члену проектной команды заботиться о качестве, и пусть все участники вносят свой вклад в автоматизацию процесса.
Дилип, спасибо, что поделились своим мнением!
