Роли
Если мы не отойдем от устаревших традиций в разработке и от традиционной роли, которую играет тестировщик в классической команде — тестировщик будет лишним в скрам-команде. Сдвиг влево приблизил тестировщиков к разработчикам, но это всё чего удалось добиться, а в некоторых командах ситуация даже ухудшилась.
Ощущения, которые заставляют меня подозревать, что иногда происходит что-то неправильное:
Разные оценки ситуации у участников
- И кодеры, и тестировщики оценивают трудозатраты в story points отдельно для каждой user story. Затем эти оценки каким-то образом усредняются, в результате чего получается итоговая оценка, которая, как правило, завышена.
- В рабочем процессе есть этап «Ожидание тестирования» и/или «Выполняется тестирование».
Рабочий процесс с этапами тестирования
В чем проблема
Из этих двух ощущений становится очевидным, что для кодера качество становится второстепенной задачей, а единственная обязанность тестировщика — просто находить любые дефекты, чтобы в будущем их исправить (если найдут).
Задача тестировщика — усердно искать дефекты в коде, регистрировать их и отправлять кодерам.
Менталитет водопадной модели вообще-то остался всё тем же, с той лишь разницей, что теперь кодеры чувствуют себя неуютно, испытывают давление, заставляющее их исправлять дефекты быстрее (тем самым, возможно, создавать еще больше дефектов), и кодеры оказываются заложниками тестировщиков, потому что те служат привратниками качества.
Что касается тестировщиков, то они чувствуют себя тоже неуютно, потому что, как правило, ощущают давление в конце спринта, когда вся работа превращается в «Ожидание тестирования» в последний день спринта.
В конце концов, владелец продукта начинает раздражаться из-за того, что ему приходится ждать до последней минуты спринта, чтобы узнать, есть ли у этого спринта шансы на успешное завершение.
Кодер перебрасывает код тестеру
И на этом проблемы не заканчиваются.
В командах, где затраты труда на написание кода и на тестирование оцениваются независимо, наблюдаются серьезные проблемы.
- Качество, как правило, не является общей ответственностью всех команд.
- Автоматизация практически отсутствует.
- Длительность цикла очень велика.
- Срезание углов (отсутствие тестов например) является общепринятым методом ускорения проекта.
- И на выходе получаем плохой продукт.
- Злые клиенты.
Как не нужно делать
Не нужно оценивать трудозатраты тестирования отдельно от кодирования, а вместо этого нужно активнее привлекать тестировщиков к сотрудничеству с остальными членами команды — и рассматривать тестирование как неотъемлемую часть разработки.
Реальный сдвиг влево: меньше QC, больше QA
Чтобы извлечь максимум пользы из сдвига влево, потребуется изменить майндсет: тестировщики будут меньше заняты контролем качества (QC), например меньше искать дефекты в уже написанном коде, а больше заниматься обеспечением качества (QA), фокусируясь на деятельности, которая предотвращает появление дефектов.
Для кодеров это будет означать, что в их обязанности будет понемногу входить обеспечение качества, которое (должно быть) присуще им как бы по умолчанию.
Три важные вещи
Сотрудничество
Тестировщики и кодеры должны «выйти» из своих закрытых команд и начать плотнее сотрудничать, и это касается всего: доработки, планирование и проектирование, разработки и релиза функций. Кодеры думают о happy path функции, тестировщики — о негативных сценариях: неправильный ввод, неправильные шаги пользователя, и другие негативные сценарии.
Со временем этот майндсет естественным образом распространится в команде, и кодеры начнут проактивно предвидеть негативные сценарии.
Парное программирование (и тестирование) также является отличным методом заставить тестировщика работать в тесном контакте с разработчиком. Если кодер будет писать тесты для сценариев, о которых подумал тестировщик, это избавит его от необходимости думать о задаче «Готово к тестированию/тестирование», а значит устранит задержки, которые влияют на цикл, и позволит быстрее получить DONE.
Автоматизация
Трудно работать быстро, если каждый раз, когда что-то добавляется/удаляется из кода, тестировщику приходится вручную запускать все свои тестовые сценарии, чтобы проверить, что то, что работало вчера, работает и сегодня.
Автоматизация необходима, чтобы минимизировать эти моменты.
И тестировщики, и кодеры должны научиться и писать, и поддерживать наборы автотестов. Было бы идеально с точки зрения скрама, если бы те, кто чаще всего «ломает» тесты, были и теми, кто их исправляет — то есть кодерами.
Сейчас существует масса инструментов для автоматизации QA, некоторые из них не требуют навыков кодирования (или требуют очень мало), но другие требуют, поэтому постоянно повышается уровень хард-скиллов у тестировщиков.
Непрерывная интеграция и доставка
Скрам-команды эффективны, когда они создают один или несколько инкрементов DONE, и даже не ожидается, что команды будут ждать окончания спринта, чтобы иметь возможность развернуть или даже выпустить билд для пользователей.
Но это возможно только при включении в процесс множества различных типов тестов (рисунок ниже), непосредственно встроенных в CI/CD-пайплайн, что приводит к сокращению объемов ручного тестирования.
Непрерывное означает «очень частое», для некоторых команд это «частое» может быть несколько раз в день или один раз в день (как минимум). И в момент интеграции код должен быть протестирован, чтобы убедиться, что проблем нет, а если они возникли, то они должны быть быстро исправлены или изменения отменены. Потому что тестирование — это тоже непрерывная деятельность, а не что-то эпизодическое, происходящее только после больших изменений. Тестировщик в скрам-команде играет важнейшую роль в этот момент.
Квадранты Agile Testing — Лиза Криспин
На начальном этапе менеджеру проекта придется потратиться на повышение квалификации, внедрение инструментов, и исправление неизбежных ошибок (обучаясь на этих ошибках). Но в долгосрочной перспективе команды, в которых тестировщики работают так, как описано выше, будут эффективными и более конкурентными.
