Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Сомнительные подходы к тестированию в Agile-разработке.
У Agile-разработки программного обеспечения много разновидностей, потому дать полноценное определение данному понятию крайне сложно. Недобросовестные Agile-мастера зачастую этим пользуются. Ведь можно продать собственный продукт или обучить клиента, как быть «более agile (гибким)», заработав при этом.
Тест реализуют специально отбираемые тестировщики
Кто такие тестировщики? Джоэл Спольски писал, что это дешевый ресурс, нанимаемый для того, чтобы тестированием не занимались разработчики. Данное мнение – анафема в Agile-тестировании. Если вы нанимаете дешевый ресурс для проведения тестов, то ни о какой гибкости в мышлении речи идти не может.
Тестирование – это не просто процесс, а вид деятельности. Им должен заниматься каждый член команды Даже если есть собственный тестировщик, это не значит, что он становится последней инстанцией при проверке качества продукта.
Если кто-то высказывает мнение «Разработчики не могут тестировать собственный код!», то оно в корне неверное. Да, кодер не должен быть единственным при проверке своего творения. Обязательно нужно иметь стороннее мнение. Но никто лучше автора не знает, как планировалось и что получилось в итоге.
Существует и альтернативное мнение: Разработчики не могут тестировать, потому что мыслят иначе!». Его я так же не разделяю. Да, возможно, программисты несколько предвзяты, поскольку знают изначально, как работает система, но это совершенно не мешает им тестировать продукт с должным профессионализмом. На самом деле, тестирование, деструктивное мышление, поиск пограничных случаев и т.д. – все это критически важные навыки, которыми стоит овладеть каждому разработчику ПО.
Я могу позволить себе сказать, что настоящее глубокое тестирование, коим его назвали Джеймс Бах и Майкл Болтон, – это навыки, который следует развивать и практиковать всем членам команды. Недопустимо проведение жесткой границы между разработкой и тестированием за счет возложения этого процесса на целенаправленно выделенную группу тестеров, работающих в системе каскадной разработки ПО. Подобный подход несовместим с методологией agile.
Вы НЕ устраняете большую часть багов сразу
При рабочей бизнес таске в спринте обнаруживается проблема. Что вы с ней делаете? Многие команды разработки до сих пор говорят, что нужно «заявить о дефекте». Однако лишь при каскадном подходе к разработке тестировщики сразу получают новую сборку с полноценным функционалом и исправлениями. После этого начинается дневной, недельный или месячный цикл проверки. При этом каждый из обнаруженных дефектов и время, затрачиваемое на его исправление, должны документироваться.
В случае с гибким подходом к разработке не нужно тратить время на составление такой документации. При обнаружении проблемы должна быть налажена прямая связь с разработчиками, чтобы дефект устраняли здесь и сейчас, либо в рамках одного спринта (текущего). Баг-репорт при этом можно закреплять на исходной задаче, не составляя дополнительной документации.
По сути, есть две причины, которые могут заставить вас в рамках agile-тестирования создать отчет о баге:
Если найденная проблема касается ранее выполненной работы, либо чего-то, что не привязано ни к одной конкретной задаче. Такая проблема регистрируется как баг с высоким приоритетом.
Проблема обнаружена в самой таске, а владелец считает, что можно пренебречь этим дефектом в угоду продолжения теста. В этом случае, опять же, записывается баг, который должен быть исправлен в будущем. Сама задача получает статус «Готово».
Создание бага на каждую проблему, обнаруженную в процессе проверки, – это пережиток прошлого, как и каскадное тестирование в целом.
P.S. Это все касается и багов, спрятанных в подзадачи.
Для каждой задачи находится большое количество багов
Для каскадной разработки характерен следующий принцип взаимодействия: «разработчики создают, тестировщики проверяют». По этой причине всегда ожидается появление значительного количества проблем, которые будут обнаружены при передаче новой задачи команде тестирования.
Во многих случаях этот принцип просочился и в agile-разработку. Для нее же ненормальной является цикличность, когда реализуемая задача передается QA, обнаруживаются проблемы и их отдают обратно с целью исправления.
Наличие значительных дефектов в рамках решаемой задачи указывает на то, что процесс тестирования все еще воспринимается, как процесс, который может выполняться только после разработки. Хотя в идеале он должен осуществляться по мере выполнения таски. Жизненный цикл задач в рамках agile-разработки нужно превратить в процесс с постоянным ростом уверенности. Если же серьезные проблемы обнаруживаются ближе к финальной стадии разработки, то первопричины нужно искать где-то на ранних этапах. Внесите соответствующие коррективы в процесс теста, чтобы предотвращать появление дефектов, а не делайте из двухнедельного спринта бесконечный цикл проверок и возвратов на исправление.
Вы исчерпывающе перечисляете test cases в TSM
При передаче большого количества фич группе ручного тестирования, было бы хорошо иметь четкий план выполнения тестов. Пока разработчики занимаются первой сборкой, тестерам нечего делать. Это ненормально – тест-планы должны быть обширными и понятными.
При этом agile баг-репорт не должен быть большим, согласно мнемонике INVEST, созданной Биллом Уэйком. На проверку одного бага разрабатывать полноценный тест-план или описывать все тестовые случаи нецелесообразно.
Значит ли это, что agile-тестирование полностью исключает документацию? Конечно же, нет. По-прежнему в истории необходимо документировать:
Что протестировали?
Какая требовалась тестовая инфраструктура?
С какими проблемами столкнулись в процессе тестирования? и т.д.
Если это действительно важная информация, то для управления историей теста можно использовать внешние инструменты (Zephyr, TestRail, и т.д.). Однако зачастую их применение ведет команду обратно к принципам каскадной разработки.
Планирование теста, документирование проблем, подходов к проверке и т.д. – все это важно при agile-тестировании. Однако полноценное описание каждого из test cases – устаревший подход.
Вы автоматизируете test cases
Исчерпывающее перечисление test cases – действие, негативно влияющее на эффективность работы, а их автоматизация – вдвойне плохо. Кто-то может отнестись к данному заявлению скептически, сказав, что «Автоматизация необходима в agile!». Да, это так, но она не должна касаться тест-кейсов.
Если, например, взять 152 кейса, из которых состоит тестовый план, и превратить их в идентичное количество новых автоматизированных тестов, то набор проверок увеличится двукратно. Это приведет к появлению перевёрнутой тестовой пирамиды, создавать которые плохо.
Проблема с тест-кейсами заключается в том, что они являются высокоуровневыми, а для проекта важна автоматизация на самом низком уровне. Правильный результат – из кучки багов, определяемых во время одного спринта, должно быть написано несколько сотен (или даже тысяч) низкоуровневых юнит-тестов, сотни компонентных или API-тестов, а также, возможно, несколько новых автоматизированных e2e-тестов. Причем e2e-тестов должно быть в разы меньше, чем созданных тест-кейсов.
Agile-командам нужно активно оценивать полноценность своей автоматизации – от юнит-тестов до e2e. Это позволяет убедиться в том, что собранная база тестов обеспечивает необходимый охват и уверенность в новых фичах. Команды должны стремиться к сокращению тестового набора, устраняя избыточные проверки или опуская их вниз по пирамиде.
Когда кто-то хвастается количеством автоматизированных e2e-тестов, которые реализованы в рамках методологии Agile-разработки, – верный признак того, что речи о гибком мышлении не идет.
Еще один отличный показатель чрезмерно автоматизированных тестовых кейсов – запускать наборы тестов приходится одновременно для получения обратной связи в течение дня. Автоматизированные пакеты на 12 часов были хороши, когда мы разворачивали их два раза в год, но их польза имеет обратный эффект, когда разворачивать тестовые прогоны нужно пару раз в час.
Вам требуется серьезное регрессионное тестирование перед деплоем продукта
Спринт закончен! Баги успешно закрыты! Владелец продукта хочет развернуть его в рабочей среде! Вы можете это реализовать? Если нужен «регрессивный спринт», прежде чем вы будете готовы перейти к продакшену, тестирование не является agile. Чем большее количество тестов требуется, тем меньше гибкости.
Из-за требований безопасности или бюрократии предприятия не всегда возможно деплоить по запросу (например, CI/CD), не говоря уже о завершении каждого спринта. Тем не менее цель agile-тестов всегда должна состоять в том, чтобы подготовить завершенную работу к продакшену, сделав этот процесс частью истории тестирования. Чем больше временной интервал между завершенными задачами и их готовностью к внедрению в работу, тем меньше ваше тестирование соответствует принципам гибкости.
Вы отделяете спринты тестирования от спринтов разработки
Разработчики создают кучу задач (в сотрудничестве с QA), но по итогам спринта все равно остаются невыполненные таски, связанные с тестированием или автоматизацией. Вместо устранения основной проблемы (размер задачи, оценка, сотрудничество dev-QA и т.д.) команда выбирает стратегию «последующих» тестовых спринтов. Фактически разработка разводится с тестированием и автоматизацией в разные этапы.
Проведение дополнительных тестовых спринтов – это признание неудачи. Они вызывают регресс, изолируя и разделяя рабочий процесс по разработке и тестированию. Если вы воспринимаете дополнительные тестовые спринты как должное, – это безумие. Мне жаль разработчиков, которым приходится думать над задачей, сданной несколько недель назад. Обычно я не могу вспомнить, что делал вчера.
Вы точно не agile, если соответствуете хотя бы нескольким из этих принципов. Даже если не согласны с чем-то, надеюсь, осознание гибкого мышления побуждает задуматься о том, как ваш подход вписывается в экосистему agile-тестирования.
Первоначально переведено для тг канала QA team
