Тестирование в Scrum. Кросс-функциональные команды

Один из вариантов изображения Scrum’а

Всем привет! Давно меня тут не было, пора наверстывать упущенное. За прошедшее время команда в которой я работаю претерпела некоторые изменения, в частности мы начали работать по Scrum.

Scrum: A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Scrum guide

В моем случае переход на Scrum был довольно резким, но в то же время с нами провели тренинг — Scrum мастер 2 дня разбирал с нами Agile, Scrum и все вопросы которые попутно появлялись. На мой взгляд это был один из самых правильных способов дать команде понять, что это за framework и с чем его едят.

Те из вас, кто знаком со Scrum наверняка знают, что в Scrum выделяют 3 составляющие команды:

  • Product Owner или владелец продукта — человек, отвечающий за управление бэклогом продукта;
  • Scrum Master — человек, отвечающий за поддержание Scrum команды и помощи ей с освоением его;
  • Development Team — команда из 3-9 человек, отвечающая за создание инкремента продукта в ходе спринта.

Сегодня я буду говорить именно про Development Team и о роли тестировщика в команде. Все что будет расписано дальше является исключительно моим мнением, и конечно же не истина в последней инстанции. Замечания как обычно приветствуются.

Я тестировщик, я не умею писать код, но в Development Team все разработчики, я там не нужен? Это самый первый вопрос который возник у тестировщиков, когда мы были на тренинге, и ответ найдем в одной из характеристик команды разработки из Scrum guide.
Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment. Значит, согласно гайду, мы часть кросс-функциональной команды, которая по результату итерации должна предоставить полностью функционирующий инкремент. Из этого мы можем сделать вывод, что в ходе спринта тестирование так же важно, как и разработка, и не нужно думать как-то иначе.

Хорошо, но код я все равно не умею писать, как быть? Тут мы подходим к двум другим терминам, называются они I-shape и T-shape. I-shape называют человека, имеющего узкую специализацию в определенной области — тестирование, аналитика, frontend разработка, backend разработка и т.д. Не трудно догадаться, что T-shape в свою очередь называют человека который помимо профильных компетенций, имеет компетенции и в других областях. Пусть эти компетенции и будут далеки от идеальных, но человек вполне может выполнять простые задачи — писать тест-кейсы на небольшой функционал, разрабатывать его или писать на него аналитику. Если ты конкретно не умеешь писать код, но хочешь — можешь договориться с коллегами и сесть рядом чтобы понаблюдать за работой разработчика, автоматизатора, поучаствовать в парном программировании. Это выльется не только в интересный опыт, но так же ты сможешь подтолкнуть разработчика к добавлению заведомо известных тебе проверок. А тут ты на пустое значение проверяешь? А если я тебе вот сюда такую структуру данных отправлю, что будет? А посмотрев на работу автотестера можешь и подхватить ее, и развить одно из своих «плеч» в фигуре T-shape. Так же можно помогать и аналитику, а он поможет тебе, все просто.

Definition of Done (DoD). Кому-то же наверняка знакомы три этих слова? Это ряд требований, которые применяются к Story, и в случае, если по итогу спринта Story не соответствует им — она не считается завершенной. Тут то и должно появиться главное, ради чего тестировщик или автотестер должен присутствовать в dev-team — требования к тестам. Лично у нас в DoD так или иначе включены следующие пункты так или иначе относящиеся к тестированию:

  • Написаны Unit-тесты;
  • Написаны тест-кейсы;
  • Функциональность протестирована согласно написанным тест-кейсам;
  • Написаны автоматизированные API-тесты;
  • Написаны автоматизированные UI-тесты;
  • Заведены все найденные баги;
  • Все критичные баги исправлены.

Согласно этим пунктам мы имеем набор тест-кейсов, большая часть из которых автоматизирована, баги по которым заведены, а критичные баги при этом еще и исправлены. Критичность багов в данной ситуации определяет для себя PO. Если в конце спринта готовность Story не соответствует всем этим пунктам (и остальным, которые не относятся к тестированию) — Story считается не завершенной, и либо переносится в следующий спринт, либо кладется в Backlog. В итоге получается, что даже если эта задача не была протестирована — ее не закроют и о ней не забудут, и в какой-то момент она снова появится в спринте, и тут то тестировщики и вернуться к ее выполнению.

Мне кажется, это были основные моменты, которые стоит отразить в данной статье. Надеюсь кому-то из вас она была полезна. Спасибо за прочтение!)