— Итак, поступило новое дело: в нашем распоряжении 10 дней для поиска места тестировщика в Scrum разработке. Необходимо понять, что же это такое Scrum, что входит в это понятие, кто вовлечен в этот процесс, и что именно необходимо делать тестировщику.
— Шеф, так что же такое Scrum?
— Все элементарно, коллега. Scrum – это набор принципов, на которых строится процесс разработки, позволяющий в установленные небольшие промежутки времени предоставлять заказчику (конечному пользователю) наделенное наибольшим приоритетом работающее ПО с новыми возможностями.
— И из чего состоит этот процесс?
— Из принципов, скоупа задач, определенных при планировании, и ограниченных (четко оговоренных и определенных) сроков. Учитывается и то, что качество не должно пострадать из-за скорости или установленных временных рамок.
— Шеф, и с чего начнем?
— А начнем с того, что рассмотрим наиболее простую и понятную схему для Scrum процесса: двухнедельная итерация (10 рабочих дней). При этом мы имеем определенно важный спринт, сплоченную команду разработки и тестирования, минимум документации, четкие требования к проекту и лаконичное описание требуемых разрабатываемых фич.
— И где же в этой схеме место тестировщика?
— А в этом нам предстоит разобраться, коллега!)
День первый. Под кодовым названием «Планирование и создание бэклога спринта»
Главными персонажами в начале процесса выступают заказчик и бизнес-аналитик, которые определяют объем работ (список задач) для дальнейшего планирования. User-story, выбранные для реализации в течение данного спринта, составляют Бэклог спринта (Sprint backlog).
Здесь важно отметить то, что в Scrum процессе значимое место (до 30% от всего времени) отводится для митингов, обсуждений UserStory и уточнения требований (Planning Poker), многие видят в этом существенный минус.
— Шеф, так это проблема?
— Или проблема, или одно из двух. Нужно понять и принять: планирование – это не только обсуждение фич, требований или технических вопросов, но также и выявление слабых сторон бизнес-логики некоторых задач, обсуждение и определение приоритетов и выявление технических аспектов и сторон спринта.
— И здесь мы можем найти следы тестировщика?
— Конечно, коллега! Ведь если разработчик обсуждает техническую сторону вопроса, то ему важно услышать и мнение тестировщика, учесть в планировании данный объем работ и понять, какая часть времени уйдет на проверку, и какие возможные проблемы и заминки могут повлиять на процесс. Тестировщик может указать на некоторые недочеты, пропущенные аналитиками или разработчиками. Будет огромной ошибкой не учитывать необходимость проведения интеграционных и регрессионных тестов, на которые может уйти много времени. А если фича будет-таки сделана, но ресурсов не хватит на полную ее проверку, – она не войдет в релиз и не будет засчитана в Story-point за спринт.
— Шеф, ничего не понимаю, а что означает Story-point ?
— Story-point, коллега, – это метрика. Другими словами, это относительная оценка объема работы в методологии Scrum. Должен сказать, использование этой метрики не обязательно, но все-таки желательно и довольно удобно. Поэтому в планировании очень важно участвовать всей команде, в том числе и тестировщикам. Необходимо задавать вопросы аналитикам и разработчикам, и тогда на дальнейших этапах тестировщики будут понимать требования к поставленным задачам, смогут определять затраты времени и получат возможность сразу же приступить к написанию сценариев тестирования, не дожидаясь того критического момента, когда задача поступит в тестирование со сроком выполнения «вчера».
День второй-третий-четвертый. Под кодовым названием «Работа над спринтом. Scrum meetings»
Может показаться, что это самые спокойные дни, но на самом деле вся основная работа как раз кипит в это время.
— Шеф, мы и здесь тоже находим следы тестировщиков?
— Конечно, коллега! Именно здесь происходит написание самых важных тестовых сценариев для тестирования фич. При достаточном количестве времени на этом этапе также пишут тест-план и тест-кейсы/smoke-тесты. И очень важно понимать, что в процессе скрама тестирование является непрерывным.
— Шеф, я кое-что нашел! Это какая-то таблица?
— А это очень удобный инструмент, коллега. О нем стоит упомянуть, ибо в нем есть следы тестировщика, и этот инструмент достаточно наглядно позволяет увидеть ход Scrum-процесса, отследить стадии работы и степень готовности задач. После начала работы над определенной задачей ее стикер перемещается из поля «Запланировано» в область «В работе», затем – в поле «Тестирование», а при успешном выполнении проверки – в поле «Готово». Расположив истории в соответствии с их важностью, можно получить представление о текущем состоянии проекта:
Из личного опыта могу сказать, что данная таблица приживается в команде довольно быстро, и если изначально может возникнуть некий скептицизм в ее применении, то со временем она становится просто незаменимой.
— Это же просто и гениально, шеф!)
— Но не забывайте, что след тестировщика ведет к ежедневным совещаниям (Scrum meetings), цель которых – дать команде полную и достоверную информацию о текущей стадии процесса разработки и тестирования. Во время совещания каждый участник скрам-команды сообщает, какая задача им выполнена, какая будет выполняться, какая готова к фича-тестингу, и какие возникли трудности во время работы или проверки.
День пятый-шестой. Под кодовым названием: «Автоматизируем, тестируем, фиксим»
При отработанном процессе Scrum-а тестирование имеет уже беспрерывный цикл. Для ускорения процесса зачастую используют автоматизацию, что значительно оптимизирует проверку задач, ведь даже при проверке отдельной фичи необходимо максимально проверить (покрыть) продукт, а это довольно времязатратная процедура. Если на каждой фиче искать слабые места вручную, то даже двухнедельной итерации будет катастрофически мало для того, чтобы включить ее в текущий спринт, особенно при необходимости исправления ошибок (bug-fix).
— Шеф, да здесь тестировщики изрядно наследили!!
— Согласен! На данном этапе они оставили чек-листы, тест-кейсы, метрики, документацию. Также следует помнить, что при нахождении ошибки или бага тестировщику недостаточно просто указать на них разработчику. Для дальнейшего покрытия этой фичи и избежания подобных ошибок важно все: и хорошо написанный баг, и достаточно полный комментарий к задаче, и подготовленный тест-кейс.
День семь-восемь-девять. Под кодовым названием «От интеграционного до регрессионного»
— Шеф, сроки на исходе. Еще обнаружены какие-либо следы тестировщика?
— Коллега, они практически прямо перед вами! На данном этапе тестирование отдельных задач прекращается. Здесь идет общая сборка всех задач и компонентов для их интеграционного тестирования. Здесь могут всплыть как небольшие недочеты, не столь критичные для спринта, так и большие баги, которые могут быть вынесены в следующий спринт или исправлены на текущей сборке. Важно отметить, что на данном этапе работа тестировщиков с документацией, написание тест-кейсов или матриц прекращается; начинается процесс собственно регрессионного тестирования.
День десятый. Под кодовым названием «Приемочное тестирование»
— Получается, что мы определили и нашли роль тестировщика в Scrum-процессе, шеф?
— Еще не совсем, коллега. Осталось совсем немного. В любом процессе завершающий этап также очень важен. Не следует забывать и приемочное тестирование: финальные проверки на готовом стенде или тестовой среде с готовым билдом. Как правило, на этой стадии написаны и автоматизированы все необходимые тест-кейсы на тот функционал, который был включен в текущий спринт.
Наступая на пятки. Или кодовое название «Демо»
На этом этапе демонстрируется готовый выпускаемый продукт; исходя из того, что вошло в текущий спринт, определяется планирование следующего. На Демо приходит вся команда, поэтому следы тестировщика мы отчетливо видим и на этом шаге.
— А почему приходят все, шеф?
— Все просто, коллега! Каждый участник может показать владельцу продукта результаты своего труда и получить от него уточнения требований или вопросы по сделанному.
Расследование завершено. Или кодовое название «Ретроспектива»
— Подведем итог, коллега. Scrum – это гибкий процесс. Исходя из спринтов и работы над ошибками, этот процесс видоизменяется, улучшается и подстраивается под те правила и условия, которые будут наиболее удобны для каждой отдельно взятой команды.
После каждого спринта следует отмечать положительные стороны, это позволит сохранить и улучшить их. Необходимо обязательно сделать выводы по отрицательным показателям и факторам для того, чтобы исправить ошибки и не допустить в дальнейшем.
Конечно, основные правила Scrum-процесса, его шаги и границы будут сохраняться и определять некоторые заявленные рамки как по времени, так и в планировании. В этом процессе также очень большую роль играют ежедневные митинги. Конечно, они занимают некоторое время, но в конечном итоге играют положительную роль в процессе, выявляя то, что мешает работе команды. На ежедневных митингах в Scrum-процессе определяются приоритеты и выявляются слабые стороны, обсуждаются story-point, прогнозируются сроки и объемы работ. Нужно, чтобы каждый, от аналитика до тестировщика, принимал участие в обсуждении и четко понимал процессы на всех этапах работы над задачей.
Хорошо бы не забывать и про визуализацию процесса с помощью доски и стикеров. Иногда они являются неплохим напоминанием и наглядным показателем скорости выполнения задач.
И если сначала Scrum может вызвать некоторое отторжение, то со временем он становится привычным и способствует комплексному пониманию процесса.
— Итак, шеф, участие тестировщика доказано?
— Коллега, я считаю, дело можно считать закрытым!)
