Автор: Эмили О’Коннор (Emily O’Connor)
Оригинал статьи
Перевод: Ольга Алифанова

Меня зовут Эмили, я ведущий инженер по тестированию, и я считаю, что пришло время попрощаться с написанием трудоёмких актов сдачи дел и поприветствовать тестирование, которое эффективно, даже когда вы в отпуске или отсутствуете на работе.

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

Многочисленные ловушки актов сдачи дел

В этом году, прежде чем я включу режим «не в офисе» на основной работе и отправлюсь в Афины на пляжную встречу Ministry of Testing, я НЕ буду писать акт сдачи дел для команд разработки, с которыми работаю.

Если вам кажется, что это странное решение, позвольте рассказать, почему я к нему пришла и как вам последовать моему примеру.

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

Я тратила большую часть дня на создание документа с номерами тикетов и описаниями задач. Я подробно расписывала, какую часть набора автотестов нужно дополнить, обновить или прогнать, и давала инструкции по связыванию результатов пайплайна с тестируемыми тикетами. Затем я расписывала подробные тест-кейсы и детальные инструкции по выполнению тестирования: через API, через UI и на различных устройствах.

Результат?

Два узких места по цене одного

Разработчики следовали документу как чек-листу и отмечали фичи как «pass» или «fail». Код всех фич при этом оставался в тестовом окружении до моего возвращения, чтобы я могла провести финальную приёмку и почувствовать, что полностью в курсе происходящего.

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

Очевидно, это решение далеко от идеального. Но какова моя альтернатива? Нет тестировщика — нет тестирования? Очевидно, не тестировать, пока тестировщик отсутствует, — плохая идея. Но и писать акт сдачи дел и отдельно проговаривать его с техлидом перед уходом в отпуск — тоже не лучший вариант.

Последствия изолированной экспертизы в тестировании

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

Я всегда думала, что если оставить команду разработки в покое, они просто скажут: «Нам не нужны тестировщики», — и качество продукта снизится, а мне придётся делать ещё больше работы или, как минимум, возвращаться к бэклогу задач после отпуска.

Но совсем не писать акт сдачи дел…?

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

Дайте команде возможность эффективно тестировать в любое время

Представим, что акт сдачи дел описывает вот такой тест-кейс: как студент, я могу видеть оценки, выставленные мне преподавателями. Для проверки этого сценария я документирую шаги тестирования: войти в тестовое окружение под ролью преподавателя и убедиться, что преподаватель может выставлять оценки всем студентам. Затем войти под ролью студента и убедиться, что на портале результатов отображается только оценка текущего пользователя, а выставленные и полученные оценки совпадают.

Такая документация становится ограничивающей, и команда разработки следует сценарию буквально. Часто разработчики не исследуют новые фичи за пределами заскриптованного теста и упускают UI / UX-баги.

В этом примере акт сдачи дел — это парадокс качества: разработчики настолько строго следуют направляющим, что не могут эффективно протестировать систему.

Не пишите акт сдачи дел — убедитесь, что вся команда умеет мыслить как тестировщик

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

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

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

Не пишите акт сдачи дел — убедитесь, что за качество отвечают все

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

Если шоу James May’s Toy Stories (британская передача о сложных крупномасштабных проектах, основанных на известных игрушках) чему-то меня и научило, так это тому, что отказ от стандартных инструкций в пользу другого подхода приводит к лучшему решению задач и формирует более сильное чувство креативности, ответственности и понимания. Поэтому, не занимаясь актом сдачи дел, вы развиваете общее чувство ответственности внутри команды.

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

Не пишите акт сдачи дел — убедитесь, что документация ведётся регулярно

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

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

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

Не пишите акт сдачи дел — обеспечьте команде уверенность в релизе

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

Убедитесь, что команда понимает: вы не финальная проверка качества, и задержки релизов в ожидании вас лишь замедляют цикл разработки. Дайте команде уверенность, регулярно практикуя небольшие откаты. Например, если карточка вносит слишком много багов в тестовое окружение, используйте её, чтобы отработать откат изменений, а не исправление вперёд с помощью pull request’ов с багфиксами.

В качестве бонуса вся команда разработки начнёт формировать собственное понимание допустимых рисков при выкладке в разные окружения (тестовое, UAT, stage или production). Чтобы поддержать такой подход, просите команду выделять более рискованные области, которым может потребоваться дополнительное тестирование.

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

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

Через несколько дней, быстро внося дополнительные UI-улучшения, разработчик выложил кнопки с отступами 5rem вместо 0.5rem. Это заметно усложнило работу с тестовым окружением для всех. Все стейкхолдеры быстро перестали пользоваться тестовым сайтом из-за раздражения. Это стало отличной возможностью отработать откат конкретных коммитов из тестового окружения и научить команду оценивать допустимые риски.

Не пишите акт сдачи дел — показывайте работу внутренним стейкхолдерам для UAT

После того как команда разработки выкладывает изменения в подходящее окружение, часто бывает, что фичи проходят пользовательское приёмочное тестирование или процентные A/B-тесты, прежде чем попасть ко всем пользователям.

Чтобы упростить UAT и избавиться от необходимости отпускного handover, поощряйте команду вести wiki с описанием пользовательских сценариев, включая ключевые наблюдения и изображения или GIF’ы с демонстрацией функциональности системы. Так более широкий круг людей сможет разобраться в контексте системы и указать на баги или допущения, которые команда разработки могла сделать. К моменту моего возвращения к работе более широкая группа людей из команды разработки и UAT уже протестировала фичи без моего участия.

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

В заключение

Ни одно из этих изменений не происходит мгновенно, и простым не будет.

Если команда понимает, какие виды тестирования требуются и какие вопросы я обычно задаю, каждый участник команды начинает мыслить как тестировщик. Поэтому мне не нужно описывать это в акте сдачи дел на время отсутствия.

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

Я не хочу возвращаться к бэклогу тикетов в колонке «Готово к тестированию», поэтому, когда за качество отвечают все, а работа показывается внутренним стейкхолдерам для UAT, мне не нужно писать подробный акт сдачи дел на время отпуска.

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

Поэтому, возвращаясь к работе, я с нетерпением жду более компактную колонку «Готово к тестированию» на нашей поддерживаемой доске, чтобы сразу влиться в процесс. Хотя, возможно, я ещё на день оставлю out-of-office статус, чтобы спокойно втянуться, попарно потестировать с разработчиками и показать всем фотографии из отпуска!

Дополнительная информация

• An introduction to continuous quality, Stuart Day
• Better Software, Faster: A Tester’s Report On The Quality Assistance Model, Nataliia Burmei
• A Really Useful List For Exploratory Testers, Simon Tomes