[Перевод] Миф: наличие тестировщиков в Agile-команде необязательно
В этой статье я постараюсь развеять один из самых распространенных мифов о разработке по Agile: «Необязательно иметь в команде тестировщиков. Разработчики могут тестировать сами». Я думаю, такой подход возможен в некоторых «особых» сценариях, но в любом случае это было бы не очень эффективно…
В начале своего пути в качестве разработчика я однажды подумал: «Зачем нам нужен тестировщик, если сам тестирую свою работу, а тестировщик просто… тестирует?» Поэтому эта роль привлекла мое внимание, и в конечном итоге мне стало интересно разобраться в мире QA подробнее. Со временем я понял, что тестирование — это нечто больше, чем просто «ломать вещи». Позвольте рассказать, почему.
Во-первых, команда разработки — это группа, состоящая из различных типов личности и ролей. Они вместе работают над созданием программного обеспечения, которое должно соответствовать потребностям и ожиданиям клиентов. Поэтому в команде каждый отвечает за обеспечение качества, постоянно взаимодействуя с другими, порой терпя неудачи и таким образом становясь лучше вместе.
Вкратце о тестировании в Agile
В начале итерации разработчики начинают кодить, а тестировщики — писать тест-кейсы, используя критерии приемки пользовательских историй. Как только разработчики передают готовый модуль тестировщикам, они выполняют тестирование по ранее созданным тестовым сценариям, проводят исследовательское тестирование или, при необходимости, регрессионное тестирование — которое можно автоматизировать, поскольку тест-кейсы иногда повторяются. Кроме того, некоторые истории могут потребовать тестирования производительности или надежности — например, выполнение теста не должно превышать определенного предельного времени или заданное количество операций может завершиться неудачей менее определенного количества раз.
QA-инженер привносит в команду уникальную точку зрения и передает знания о тестировании и продукте всей команде, тесно сотрудничая с:
Разработчиками: совместно согласовывая наилучшую стратегию тестирования того, что можно или нельзя тестировать, предоставляя постоянную обратную связь и выявляя потенциальные дефекты до разработки решения. Это помогает снизить риски за счет устранения дефектов на ранних этапах SDLC.
Заинтересованными сторонами бизнеса, помогая им создавать приемочные тесты и сообщая о начале этапа приемочного пользовательского тестирования. Тестировщики доводят до их сведения информацию о том, почему их участие является ключевым перед релизом продукта.
Обратная связь, которую команда получает в каждой итерации, очень важна, поскольку она способствует созданию ценного продукта. Итак, давайте подытожим, как все члены команды предоставляют полезные выводы о качестве продукта, ведь оно зависит не только от QA-инженера.
В экстремальном программировании лучшие практики тестирования включают TDD, ATDD или BDD, которые могут быть очень полезны для проведения тестирования на разных уровнях. Преимущество этих подходов в том, что они предусматривают выполнение тестов на ранних этапах (до начала написания кода) и пользователь тоже может легко принять в этом участие.
В Scrum отличным подходом (и одним из моих любимых) является парное тестирование или совместные обзоры. Два члена команды просто собираются вместе для выполнения теста (тестировщик + разработчик, или два тестировщика, или тестировщик + владелец продукта и т. д.) и выявляют проблемы или возможности для улучшений. Еще один подход — mind-mapping. Он полезен для описания тестовых данных, создания интуитивных планов тестирования, а также во время онбординга нового тестировщика в середине текущего проекта.
Теперь, когда мы находимся в контексте разновидности Scrum, давайте копнем немного глубже.
Как сказано в Руководстве по Scrum:
«Scrum не признает никаких титулов для членов команды разработки, независимо от того, какую работу они выполняют».
Scrum-команда — это самоорганизующаяся команда, в которой есть один или несколько тестировщиков. Они должны «сидеть вместе» с разработчиками/дизайнерами/скрам-мастером/владельцем продукта и постоянно сообщать о ходе тестирования, а также о его результатах или препятствиях. В результате команда сможет реагировать на любой риск или адаптироваться к любым изменениям, что способствует прозрачности и смелости.
Почему важно, чтобы в команде был тестировщик?
«Лучший тестировщик — это не тот, кто находит больше всего багов, а тот, кому удается больше всего багов исправить»— Джем Канер.
Тестировщик должен задавать вопросы и оценивать поведение и характеристики продукта в соответствии с ожиданиями клиентов. А если применимо, то также с помощью стандартов качества ISO.
Отличный тестировщик может изменить ситуацию. Если вы новичок в тестировании и любознательность — один из ваших сильных навыков, узнайте больше о самообучении ISTQB, перейдя по этой ссылке.
Будучи тестировщиком, вы должны быть готовы высказаться. Тестировщики участвуют в работе с самого первого дня и не должны бояться задавать вопросы по типу: как к этому отнесется конечный пользователь? Как можно улучшить опыт пользователя?
Будьте уверены: мы знаем, что и зачем мы делаем.
Тестирование — это нечто большее, чем просто выполнение тестов с целью убедиться, что все работает. Оно включает в себя ядро и всю экосистему приложения, а также полное понимание того, как каждая фича взаимодействует с целым для удовлетворения потребности бизнеса.
Команда QA не может быть изолирована для достижения своей цели, а разработчики очень заняты реализацией наилучшего решения бизнес-потребностей, так что тогда? Обе стороны синхронизируются, чтобы эффективно обеспечивать качество. Это непростая задача, но усилия, которые требуются на ее решение, окупаются.
Перед тем, как передать собранный модуль тестировщикам, разработчики создают и проводят юнит-тесты с определенным тестовым покрытием, чтобы убедиться, что этот модуль собран правильно. Для этого используются парное программирование, TDD, первичное ревью и непрерывная интеграция. Эти техники позволяют быстрее получать обратную связь, изолировать и решать проблемы на ранних этапах.
Команда QA следит за тем, чтобы все созданные изолированные модули работали вместе, отвечая потребностям бизнеса и ожиданиям пользователей.
Причины, по которым тестировщик не нужен в вашей команде
Есть несколько специфических случаев, когда тестировщик может быть необязательным. Лично я рассматриваю следующие:
Перед тем, как включить тестировщика в свою команду, нужно определиться, какие навыки требуются для данного профиля. Ведь не во всех проектах требуется только ручное или автоматизированное тестирование. В некоторых из них в приоритете будет юзабилити-тестирование или тестирование производительности. Поэтому будьте внимательны к тому, какого QA-специалиста вы ищете. Если не учитывать этот момент, тестировщики и разработчики могут столкнуться с задержками в поставках из-за высокой кривой обучения или отсутствия единства взглядов.
Я думаю, что тестирование больших данных в Agile-командах — это довольно сложная задача, потому что бывает очень трудно вписать операции тестирования в короткие итерации разработки, характерные для agile-процессов. В то же время тестировщики и их навыки являются критическим фактором для успешного закрытия бизнес-потребностей. Поэтому необходимо инвестировать в эксперта в предметной области или же обойтись без тестировщика.
Бюджетные ограничения могут стать весомой причиной отказа от тестировщика — в основном тогда, когда выполнение тестов более специализированно, как в тестировании надежности.
Даже если в команде нет тестировщиков, при релизе продукт столкнется с реальными тестировщиками (вашими клиентами) — и вам решать, хотите ли вы получать сообщения о багах и плохие отзывы непосредственно от них. Лично я предпочитаю сначала ловить баги собственными силами.
Заключение
Спасибо, что прочитали статью. Ниже я делюсь дополнительными ресурсами о важности тестирования в реальной жизни, потому что контроль качества касается не только программного обеспечения. Ваш автомобиль, iPhone и самолет, на котором вы отправитесь в путешествие, тестируются QA-специалистами (и, конечно, тестировщики, как и все люди, допускают ошибки, это просто входит в комплект поставки).
В завершение приглашаем всех желающих на открытые занятия в OTUS по всем IT-направлениям, в том числе тестированию и управлению разработкой, на которых мы рассматриваем актуальные инструменты, методы и техники, а также разбираем рабочие кейсы. Выбирайте интересные темы в календаре и записывайтесь.
