Почему тестировать должны не только QA. Распределяем тест-кейсы между Dev, Analyst и QA

Привет, меня зовут Виталий Корж, я Dev Lead из Luxoft. Занимаюсь бэкенд-разработкой уже более 10 лет, за это время мне приходилось работать на разных позициях и побывать в разных ролях, что позволило взглянуть на процесс разработки с разных углов.

В первую очередь в глаза бросается кластеризация и сегрегация специалистов. Один из примеров — перегруженность QA и нежелание других участников вникать в причины такой ситуации. Ее усугубляет часто пренебрежительное отношение к этому других специалистов. А ведь мы все в равной степени двигаем прогресс!

Этот материал будет полезен всем QA, Dev, Analysts Junior- и Middle-уровней. В данной статье рассмотрим потенциал роли тестировщика в специализированном домене и поговорим, как извлечь максимальную выгоду от вовлечения в процесс разработки.

Люди-комбайны

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

Представим условные три группы специалистов и соответствующие зоны ответственности:

• Analyst, работа с требованиями к продукту;
• Dev, создание приложения согласно требованиям;
• QA, проверка результата.

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

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

Данное представление можно упростить до двух ролей (требования — исполнение), но для наглядности рассмотрим предложенный вариант:

Распределение компетенций

Различные роли стараются не ассоциировать себя с представителями «чужого лагеря», но в то же время в их ответственность могут входить задачи, не свойственные их должности напрямую. Так, например, обязанность разработчика — написание качественного, документированного, покрытого тестами кода, хотя и написание тестов, и документирование могут сделать другие специалисты.

Возникает вопрос: в какой момент девелопер перестает быть девелопером, а QA становится разработчиком? Если написание самого кода не является гарантией того, что он работает как следует, а хорошо составленные тест-кейсы не дают на выходе работающее приложение? В итоге программисты вынуждены договариваться с QA и подстраиваться под критерии, определенные аналитиками. Никакие требования не гарантируют, что все будут им следовать, и количество и качество написанных тестов может варьироваться в зависимости от разработчика, в некоторых случаях это отнимает много времени и сил у всей команды.

Тренд на универсальность

Если по завершении работ над задачей посмотреть на потраченное на разработку время и увидеть, что на написание тестов разработчик потратил 60% процентов времени, какие выводы можно сделать? Считается ли такой разработчик тестировщиком? Возможно, если заменить такого специалиста на QA-ориентированного, тесты будут написаны быстрее и больше времени пойдет на разработку.

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

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

Изменение компетенций со временем

Что если QA — это способ мышления, где во главе стола ставится гарантия качества и желание покрывать код все большим количеством тестов, перестраховки ради? Где провести границу в ответственности?

Взглянем на продукт, состоящий из серверной и клиентской части, при наличии автоматического и ручного тестирования. Команды распределим по зонам ответственности Server, Client, QA. Данная разбивка позволит гипертрофировано взглянуть на проблему восприятия работ над продуктом.

Server-команда создает API продукта, Client-команда — пользовательское приложения, используя предложенное API, QA проверяют приложение на соответствие согласованным требованиям, которые могут меняться в процессе работы. У каждой из команд будет свой набор задач, план с разбиением на фичи, которые могут состоять из нескольких компонентов.

Путь разработчика

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

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

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

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

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

Распределение тестов

Сцена QA

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

Ручному тестированию подлежат любые шаги, которые могут быть автоматизированы, и любая автоматизация непременно начинается с него. Минимальным юнитом в данном случае выступают мануал тест-кейсы, которые, объединяясь в последовательности, формируют чек-листы и тест-планы. Количество тест-кейсов может увеличиваться со временем через рост продукта, что неизбежно ведет к увеличению трудозатрат на выполнение регрессии.

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

Собираем винегрет

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

Это приводит к несовместимости и излишнему дублированию функционала в зонах пересечения ответственности различных участников. Наиболее страдает от такой «заботы» интеграционный слой, так как каждая из команд будет стремиться максимально проверить возможные неполадки, не полагаясь на чужие наработки. Над всеми тестами растет и список QA-требований к продукту. Как следствие, общий результат начинает приобретать формы, отличные от оптимальных, что может приводить к увеличению инвестиций в дальнейшее развитие продукта. Если вовремя не реагировать на постоянно растущую разницу в подходах, есть риск упустить момент, когда все еще можно исправить. Чтобы держать руку на пульсе, нужно регулярно пересматривать сценарии и правила, которым следуют тесты.

Ретроспектива процесса

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

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

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

«Тестовые кубки». Распределение тестов может приобретать причудливые формы, отличные от «оптимальных»

Выводы

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

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

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

Облако тестов

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

И помните, что проекты погибают в тишине.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU