«Следствие ведут тестировщики» или место тестировщика в Scrum разработке

— Итак, поступило новое дело: в нашем распоряжении 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 может вызвать некоторое отторжение, то со временем он становится привычным и способствует комплексному пониманию процесса.

— Итак, шеф, участие тестировщика доказано?
— Коллега, я считаю, дело можно считать закрытым!)

Об авторе

Окончила Харьковский Национальный Университет Радиоэлектроники по специальности «Инженер-радиотехник». Работает в сфере IT с 2012 года. Пришла в «Лабораторию качества» в 2016 году на должность тестировщика. На данный момент занимает позицию тест менеджера.

Поиск
Облако меток
api (5)kpi (1)kpi в тестировании (1)postman (1)rest api (2)scrum (1)scrumban (1)soap api (1)sqa days (1)TDD (1)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)ПОИНТ (2)Приёмочное тестирование (1)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (1)баги (4)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (1)ежемесячный отчет (12)интернет-магазин (1)исследовательское тестирование (2)коммуникации (3)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (19)лайф-хаки (3)локализация (1)международные проекты (1)метрики (2)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (7)обучение (6)оптимизация тестирования (13)поздравление (1)поздравления (2)пользовательские истории (1)пример (1)проблемы (1)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (5)разработчики (1)распределенная команда (3)решения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (44)тестирование безопасности (2)тестирование мобильных приложений (1)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (2)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (2)
Получите совет