Повышайте качество, включив тестировщиков в Scrum-команду

Повышайте качество, включив тестировщиков в Scrum-команду

О, я уже слышу эти возражения:

«Но это же очевидно! Scrum-команды должны быть кросс-функциональными!»

«В Scrum-команде не должно быть выделенных ролей! У нас не может быть человека, занимающегося только тестированием!»

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

Разработчики достаточно часто бывают отвратительными тестировщиками. Особенно, когда они тестируют свой собственный код.

Тестировщик - это «последняя инстанция».

Кроме того, что тестировщик - обычный член команды, он ещё и выполняет очень важную функцию. Он — человек, за которым всегда «последнее слово». Ничто не может считаться готовым в спринте, пока он не подтвердит, что это действительно так. Я обнаружил, что разработчики часто говорят, что что-то готово, хотя в действительности это не так. Даже, если у вас имеется очень чёткое определение критерия готовности (которое у вас должно быть, см. стр. 29 «Критерий готовности»), в большинстве случаев, разработчики будут часто его забывать. Мы, программисты, люди очень нетерпеливые и стремимся перейти к следующему пункту списка как можно быстрее.

Так как же мистер Т (наш тестировщик) узнает, что что-то действительно готово? Ну, прежде всего, он может это (сюрприз!) протестировать! В большинстве случаев оказывается, что то, что разработчик считает готовым, на самом деле даже невозможно протестировать! Либо по причине того, что оно не было зафиксировано в репозитории, либо не установлено на сервер, либо не может быть запущено, или ещё что-нибудь. Как только мистер Т завершил тестирование, первым делом он должен пройтись по критериям готовности (если таковые у вас имеются) и, желательно, вместе с разработчиком. К примеру, если критерий готовности требует наличия заметок к релизу, то мистер Т проверяет их наличие. Если же необходима более формальная спецификация функционала (хотя это бывает редко), мистер Т проверяет и это тоже. И так далее.

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

Качество сервиса

Из книги автора

Качество сервиса В большинстве случаев средства маршрутизации Linux обрабатывают пакеты по принципу "первый пришёл/первый обработан" (first-come/first-served). Такая процедура дает хорошие результаты в тех случаях, когда пропускная способность линий достаточна для передачи всех


Лекция 1. Качество ПО

Из книги автора

Лекция 1. Качество ПО Качество - это цель инженерной деятельности; построение качественного ПО (software) - цель программной инженерии (software engineering). В данной книге рассматриваются средства и технические приемы, позволяющие значительно улучшить качество ПО. Прежде чем


Усадите команду вместе

Из книги автора

Усадите команду вместе Когда приходит время расставить столы и рассадить команду, есть одно правило, которое сложно переоценить.Усадите команду вместе!Чуть поясню, что я имею в виду:Усадите команду вместе!Людям не нравится переезжать. По крайней мере, в тех компаниях, в


Как мы сочетаем Scrum с XP

Из книги автора

Как мы сочетаем Scrum с XP То, что Scrum и XP (eXtreme Programming) могут быть эффективно объединены, не вызывает сомнений. Большинство рассуждений в интернете поддерживают это предположение, и я не хочу тратить время на дополнительные обоснования.Тем не менее, одну вещь я всё-таки должен


Повышайте качество - делайте меньше за спринт!

Из книги автора

Повышайте качество - делайте меньше за спринт! Это решается ещё на планировании спринта. Проще говоря, не пытайтесь сделать как можно больше историй за спринт. Если у вас существуют проблемы с качеством или вам приходится тратить слишком много времени на приёмочное


Как мы проводим Scrum-of-Scrums

Из книги автора

Как мы проводим Scrum-of-Scrums Scrum-of-scrums - это регулярные встречи, цель которых - обсуждение различных вопросов между Scrum-мастерами.Как-то мы работали над четырьмя продуктами. Над тремя из них работало по одной Scrum-команде, а над четвёртым - 25 человек, которые были разделены на


Scrum-of-Scrums уровня продукта

Из книги автора

Scrum-of-Scrums уровня продукта Эта встреча была очень важной. Мы проводили её не реже одного раза в неделю. Мы обсуждали проблемы интеграции, балансировки команд, подготовку к следующему планированию спринта и т.д. Мы выделяли на это 30 минут, но часто нам их не хватало. В качестве


Качество света

Из книги автора

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