Почему тестировать должны не только 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 от монотонной работы и заменив ее творческим процессом поиска неисправностей, вы высвободите время для новых задач и дальнейшего роста специалистов.

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

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

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

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

👍НравитсяПонравилось3
В избранноеВ избранном7
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


20 комментариев

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

Все-таки какой-то туман в этой статье есть. В заголовке вы призываете разработчиков участвовать в подготовке тест-кейсов (которые обычно пишут автоматизаторы или QA). Но в разделе «Путь разработчика» про это ни слова. Здесь только про юнит- и интеграционные тесты.
Кто все-таки должен писать тест-кейсы с вашей точки зрения?

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

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

Подготовка тест-кейсов задача «QA», но вся команда должна принимать участие в конечном результате.
Каждый может подставить свое виденье. По моему мнению все зависит от умения и желания участников процесса, а значит и любой best-practice в итоге будет уникальным опытом команды.

Дякую за швидку відповідь.
Що таке кінцевий результат при підготовці тест-кейсів? Самі тест-кейси?

Для меня это алгоритм проверки на соответствие требованиям.

сегрегация специалистов

Что это такое, если вы не про расовую?

Подразумевается низкая культура коммуникации, никто никогда не знает какие проблемы решает коллега. Тем самым все группируются по доменам.

Знову ж. У вашій статті до кожного речення потрібні уточнюючі питання.
Мені особисто здається, що читаючи її, можна тільки ще більше заплутатися.

Если детальнее расписывать получается излишне нудно.

Вот оно как.
Предлагаете чтобы все девы делали работу за троих ( и свою и QA и analyst), а зарплату получать за одного.
А остальные двое соответственно — работу за 0 человек , а зарплату за одного.
Чего уж, интересная концепция ...

Бывает что даже мешают. Но в любом случае не будет лишним прояснить ожидания и возможности.

Стаття чудова. Приємно бачити, коли деви пірнають в такі важливі теми.
Нижче вкажу те, з чим я незовсім згідний або що, на мою думку, є спірним, чи неточним.

«Почему тестировать должны не только QA...».
— Звісно все залежить від методології розробки, їх доволі багато,
але якщо брати за основу якісь а-ля скрами, то стає очевидним, що по замовчуванню за результат роботи і за якість відповідає вся команда.
Відповідно, тестувати по завмочуванню не будуть лише QA і так. А якщо згадати асептенс тестінг клієнта/бізнес-аналітика, чи бета-тестерів, тоді ми розуміємо, що тестують всі і всюди й так.

«Такая практика позволит тестировщикам взять часть работ на себя и стать частью команды разработки»
— думаю, що малась на увазі «команда розробників», бо QA інженер і так є частиною «команди розробки».

«QA проверяют приложение на соответствие согласованным требованиям, которые могут меняться в процессе работы»
— це залежить від обраної метології і процесу. Далеко незавжди вимоги змінюються.

«Что если QA — это способ мышления, где во главе стола ставится гарантия качества»
— QA ніколи не можуть гарантувати відсутність проблем, відповідно і не можуть бути гарантом якості. Хіба що можуть бути гарантом того, що функціонал не має критичних і кричущих проблем, і що кількість можливих проблем мінімальна.
Тому гарнатія якості — лише ідеальний вектор руху.

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

«...так десятки пограничных значений для поля могут сразу уйти на юнит-уровень, тем самым разгрузив чек-листы QA.»
— очевидно, що мета юніт-тестів не в тому, щоб перевірити граничні значення, бо це вже сценарії, а суто в пересвідченні того, що функції/методи працюють.
Що в свою чергу вже оберігає цього ж розробника від сотні дефектів, котрі впадуть на нього в майбутньому. Але навіть якщо таке впровадити, то жоден поважаючий себе інженер з якості не скіпне такий тест в себе в перевірках.

Загалом, спасибі. Було дуже цікаво читати

Спасибо за комментарий. Добавлю немного контекста к замечаниям
Кому-то то это очевидно а у кого-то ворклайф баланс и ему за это не платят.
Часть команды, но иногда их время и труд как-то не верно оцениваются
-
Мысль в том что некоторые девелоперы используют тесты не по назначению, а как некоторое подобие ресерча
Иногда проект может не поспевать с автоматизацией и начинаются компромиссы, а стоило бы помочь и немного скорректировать план
Кейс и юнит как попытка найти аналогию, если чтото постоянно проверяют может стоит это как-то автоматизировать

Все мы люди и уважение неотъемлемая часть наше сотрудничества.

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

если в статье поменять QA на tester то всё станет на свои места

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

На картинке отсутствуют девы на горке(качели заняты), и тестировщик несущий мешок.

Хороший и свежий анализ, спасибо.
Спорить даже не с чем) Разве что выводы слабые — но я лучше не придумаю.

Вот описал, как работало мануальное тестирование на паре проектов dou.ua/...​rums/topic/32228/#2009085 Возможно, что-то прокомментируете о схеме — буду благодарен за взгляд со стороны.

Описаная схема стандартна, все работает пока нет.
есть недостаток при работе короткими итерациями в неравных фичах и накоплении релиз беклога, который приходится решать либо укрупнением релиза либо замедлением разработки (стоп ворлд). Долгий цикл скорее всего уже включает заморозку.
При коротких циклах часто возникает борьба за QA ресурсы, env. (хороший девопс и не/много денег)
Проблемой может быть сведение кода, особенно когда сорвались какие то договоренности.
Чем шире систем и чем больше людей тем сложнее все держать под контролем. Решается четко прописанными процедурами и личной ответственностью(координатор). Главное не переусердствовать потому, что сложные процедуры проще нарушать, чем соблюдать.

Подписаться на комментарии