Тестирование и Тестировщик в scrum-команде

Запись на вэбинар!!!!!!!

Презентация

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

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

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

Предлагаю смоделировать одну итерацию, а это 2 недели или 10 рабочих дней за 30 минут.

По дефолту у нас спринт N, 10 дней , маленькая дружная команда разработки, отсутствие документации, бэклог с требованиями к проекту, описание фич в один абзац,

День 1ый: Планирование

Аналитиком и продуктоунером заранее определен список задач на планирование.

И т.к. вся команда должна быть ответственна за выпуск качественного среза продукта после каждой итерации,  во время митинга по планировании итерации (где присутствуют все члены команды) команда должна выбрать такой объём работы, который, она уверена, что сможет превратить в часть качественного продукта.

Собирается вся команда и начинается обсуждение, декомпозиция задач на UserStory, уточнение требований, конечно PlanningPoker. 

Как недавно выяснилось,  тестировщиков не всегда зовут на планирование.  А еще в ходе моей работы я узнала, что многие тестировщики считают, что  их мнение совершенно не нужно при оценке задач.  Есть еще одна группа, входят в неё те, которые считают сам процесс скрама крайне не эффективным, потому что у скрама есть проблема  – это большие издержки от обсуждений, встреч, большие потери времени на стыке спринтов, где из 2х недель, 3 дня, а это 30% времени тратится на поддержание самого процесса скрама.

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

Во первых планирование – это обсуждение не только новых фич и технической стороны вопроса, но и бизнес-логики некоторых задач, которые стоят перед командой. А ведь важно лучше понимать о чем речь, важно всегда быть в теме. Если девелоперы задают технические вопросы, тестеры думают по другому. Они должны находить недочеты в Бизнес-логике и нелогичности юзабилити приложения. Причем надо взглянуть на продукт не только с точки зрения клиента, который его купит для своих нужд , но и с точки зрения  компании- разработчика, которая хочет выгодно продать свои софт.

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

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

День 2,3,4

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

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

список дефектов. Перед тем, как забрать билд на тестирование, ты проводим smoke-тесты— просто проверить, что билд находится в рабочем состоянии, и что его можно тестировать, что там нет багов, которые являются show-stopper'ами для тестирования (т.е. могут остановить всю работу). Это может быть небольшой набор тестов в идеале, но реально это не всегда получается. Если не получается — имеет смысл выписать для этого отдельный тест-план и начинать с него. Первое тестирование — оно неполноценное, а только по какой-то части покрыто  smoke-тестами. Чтобы его можно было его делать за час — каждый день, проверять, что у основные вещи не отвалились.

День 5,6

Если во время планирования задачи были максимально декомпозированны, то как правило в тестирование падают какие то отдельные «недофичи», т.е. отдельные фрагменты ,которые потом складываются во что то «целое».

Тестирование — это процесс постоянный.. Потому что в конце

итерации должен быть полностью протестированный, в идеале, софт. То

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

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

Кроме описания в один абзац и слов разработчиков о проделанной ими работы, при появление новой функциональности используется метод свободного поиска, без него никуда, как бы не хотелось некоторым все автоматизировать. Вот так тыкаем-тыкаем и вдруг находим ошибку. Тут надо что? Воспроизвести баг, но к сожалению ничего не получается, поэтому бывалые тестировщики советуют для подобных тестов использовать системы «record&replay».

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

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

Например

Одним из самых распространенных вопросов, которые я задаю девелоперам является :

– Вань, тут баг, на тебя вешать?

– не не, ща пофиксим»

и фиксят на месте.

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

Еще документы и хорошо оформленные баги важны при внедрение в проект новых тестировщиков.

День 7,8,9

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

Предпочтение в эти последние дни отдается работающему приложению чем документации.

День 10

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

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

В идеале в конце спринта должны быть и документы и автотесты, но реально получается, что то одно, то это уже отлично. Над решением этих проблем можно поработать на ретроспективе.

Демо

Как я уже упоминала, что в скрам-команде все равны. Поэтому нет четких границ ответственности. За всё что мы делаем, отвечаем вместе.

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

Ретроспектива

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

Тут и тестировщику есть где разгуляться, можно например поднять настроение девелоперам, сказав «спасибо»  безбажные фичи.

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

А что бы сделать свою работу максимально комфортной любите свою команду и тогда она полюбит вас =)

Используемые материалы:

1.«QA в SCRUM» Алексей Кривицкий.

2.«Тестирование в Agile» (Подкаст)  Асхат Уразбаев, Илья Гаврилов, Алексей Лупан.

3.«Руководство по тестированию в Agile» Асхат Уразбаев.

4.«Проблемы тестирования это результаты тестирования» Майкл Болтон.

5.«Гибкое vs Формальное тестирование: успех не определяется инструментом!» Наталья Руколь.