Что делает тестировщик в первый день спринта?
Свой ответ на этот вопрос дает Крис Бёрнс (Chris Burns) – продакт-менеджер в компании «352».
Крис называет себя “прагматиком по жизни и специалистом по решению проблем”. Ему нравится улучшать старые продукты и создавать новые с нуля.
"Вы когда-нибудь задумывались, каково было бы иметь в вашей Agile-команде штатного специалиста по контролю качества? Если да, то вы, вероятно, сразу же задались вопросом, что этот человек будет делать в первый день спринта.
Поскольку мне нравится бороться за то, чтобы получить как можно больше ресурсов для контроля качества (QA), это стало частой темой для разговоров в нашем офисе в Гейнсвилле (Флорида).
На прошлой неделе я был на технологическом митапе, и кто-то спросил меня: «Зачем вам штатный специалист по контролю качества в составе вашей scrum-команды? Что он делает в первой части спринта?»
Это действительно хороший вопрос, и я спросил своего scrum-тренера Тома Меллора, как занять QA-членов моей команды в первый день спринта. Он посмотрел на меня пустым взглядом. Вы знаете: слегка приоткрытый рот, который сопровождает недосказанное: «Сынок, ты глупый или просто болван?»
Я предпочитаю верить, что это был не самый глупый вопрос, который он когда-либо слышал, но после того, как он собрался, он ответил еще одним простым вопросом:
«Как может быть, что в первый день спринта один из членов вашей команды уже не работает?»
Любой рациональный человек ответил бы: «В первые 10 секунд любого спринта невозможно, чтобы какие-либо истории были уже завершены и отправлены в QA, поэтому специалист QA не останется без работы, но он или она еще и не получили ничего для работы». Правильно? Мне это показалось довольно логичным.
Не так QA должен начинать спринт.
Это действительно верно, но здесь упускается важный момент. Мы говорим о Scrum! Нам повезло, что у нас есть Руководство по Scrum, которое помогает нам ориентироваться в этих вопросах, и мы все регулярно его просматриваем (будем надеяться!). Но на всякий случай, если вы в последнее время немного отвлеклись, давайте вместе посмотрим. Эти отрывки являются прямым копированием / вставкой из Руководства по Scrum. Я не выдумываю.
Scrum не признает никаких названий для членов команды разработчиков, кроме названия “разработчик”, независимо от выполняемой человеком работы; из этого правила нет исключений. - Руководство по Scrum
Для простоты я перечислю здесь все разрешенные названия для членов команды:
1. Разработчик.
Обратите внимание, насколько исчерпывающим является список? Был ли в нем QA? Итак, почему у вас вообще есть назначенный QA-специалист? Каждый является разработчиком и вносит свой вклад в развитие проекта. Просто.
Scrum не признает подгрупп в команде разработчиков, независимо от конкретных областей, которые можно определить как тестирование или бизнес-анализ; из этого правила нет исключений. - Руководство по Scrum.
Если первый пункт не был достаточно очевидным, здесь прямо говорится, что нет подгрупп, «ориентированных на тестирование»… что означает QA. Но что, если ваша команда QA - это хорошо обученная группа по поиску ошибок. Жаль, «без исключений», см. Руководство.
Теперь, когда мы все начинаем понимать друг друга, вы, вероятно, думаете: «Это нереально» или «Мы не можем этого сделать в нашей организации». Я здесь, чтобы сказать вам, что вы «можете и должны», а позже я дам вам несколько практических советов, чтобы это произошло. Но сначала еще одно замечание из руководства по Scrum...
Члены команды разработчиков могут обладать специальными навыками в различных областях, но ответственность лежит на команде разработчиков в целом. - Руководство по Scrum.
Ваша команда, возможно, состоит из людей, которые специализируются на создании красивых вещей, и других, которые отлично выполняют бумажную работу. Назову их «экспертами».
В целом все члены вашей команды в чем-то являются экспертами, но это не значит, что это единственное, что они умеют делать. Ваш художник может никогда не написать сложное совместное заявление, а ваш администратор базы данных не сможет никогда создать красивую кнопку, но в совокупности у них есть возможность повлиять на любую стори. Всегда. Даже если они будут просто сидеть рядом и обсуждать какую либо проблему (парное программирование, например). Они могут даже приобрести новые полезные навыки.
Если разработчики повышают свои навыки контроля качества, так почему же это не применимо к вашему аналитику по качеству? Никакие разрешения здесь не нужны. У вас, вероятно, есть эксперт по обеспечению качества в вашей организации, но если многие стори нуждаются в контроле качества, все остальные члены команды присоединятся, верно? Просто должны! Не только специалисты QA; каждый член команды несет ответственность за каждую стори на каждом этапе её завершения. Даже на финальном этапе контроля качества.
Цель - довести всё до уровня «Сделано».
Какой-то отдельный исполнитель может работать в 10 раз медленнее, но если у членов команды есть временной ресурс, им нужно просто добавить 10% эффективности и улучшить свои рабочие навыки.
«Это не моя работа» не существует в Scrum-команде.
Практическое применение
Теоретически всё просто, но как это реализовать на практике?
Решение не всегда очевидно. Итак, вот мои советы, которые помогут вашему эксперту по обеспечению качества получить пользу с первой минуты спринта:
Поощряйте своего специалиста по контролю качества развивать новые навыки, которые приблизят стори к QA. Варианты подготовки QA включают:
Scrum-команды кажутся действительно хорошими в том, чтобы сделать всех в команде равными... пока мы не говорим о контроле качества. У них либо есть «специалист по контролю качества», либо, что еще хуже, он находятся в совершенно отдельной службе QA.
Поскольку ваше определение «Сделано» должно включать прохождение QA (разумеется!), и вы не должны показывать что-либо на закрытии без QA, можно сказать, что, если у вас есть отдельная команда QA, вы просто делаете все неправильно.
Касательно QA, - помните, что у вас больше нет QA. У вас есть человек, который специализируется на контроле качества, но у него есть множество других талантов, которые будут полезными в первый день. Мой эксперт по контролю качества может писать HTML, изучает javascript и у него неплохая подача в теннисе."
Источник: https://www.threefivetwo.com/blog/what-does-qa-do-on-the-first-day-of-a-sprint
Крис называет себя “прагматиком по жизни и специалистом по решению проблем”. Ему нравится улучшать старые продукты и создавать новые с нуля.
"Вы когда-нибудь задумывались, каково было бы иметь в вашей Agile-команде штатного специалиста по контролю качества? Если да, то вы, вероятно, сразу же задались вопросом, что этот человек будет делать в первый день спринта.
Поскольку мне нравится бороться за то, чтобы получить как можно больше ресурсов для контроля качества (QA), это стало частой темой для разговоров в нашем офисе в Гейнсвилле (Флорида).
На прошлой неделе я был на технологическом митапе, и кто-то спросил меня: «Зачем вам штатный специалист по контролю качества в составе вашей scrum-команды? Что он делает в первой части спринта?»
Это действительно хороший вопрос, и я спросил своего scrum-тренера Тома Меллора, как занять QA-членов моей команды в первый день спринта. Он посмотрел на меня пустым взглядом. Вы знаете: слегка приоткрытый рот, который сопровождает недосказанное: «Сынок, ты глупый или просто болван?»
Я предпочитаю верить, что это был не самый глупый вопрос, который он когда-либо слышал, но после того, как он собрался, он ответил еще одним простым вопросом:
«Как может быть, что в первый день спринта один из членов вашей команды уже не работает?»
Любой рациональный человек ответил бы: «В первые 10 секунд любого спринта невозможно, чтобы какие-либо истории были уже завершены и отправлены в QA, поэтому специалист QA не останется без работы, но он или она еще и не получили ничего для работы». Правильно? Мне это показалось довольно логичным.
Не так QA должен начинать спринт.
Это действительно верно, но здесь упускается важный момент. Мы говорим о Scrum! Нам повезло, что у нас есть Руководство по Scrum, которое помогает нам ориентироваться в этих вопросах, и мы все регулярно его просматриваем (будем надеяться!). Но на всякий случай, если вы в последнее время немного отвлеклись, давайте вместе посмотрим. Эти отрывки являются прямым копированием / вставкой из Руководства по Scrum. Я не выдумываю.
Scrum не признает никаких названий для членов команды разработчиков, кроме названия “разработчик”, независимо от выполняемой человеком работы; из этого правила нет исключений. - Руководство по Scrum
Для простоты я перечислю здесь все разрешенные названия для членов команды:
1. Разработчик.
Обратите внимание, насколько исчерпывающим является список? Был ли в нем QA? Итак, почему у вас вообще есть назначенный QA-специалист? Каждый является разработчиком и вносит свой вклад в развитие проекта. Просто.
Scrum не признает подгрупп в команде разработчиков, независимо от конкретных областей, которые можно определить как тестирование или бизнес-анализ; из этого правила нет исключений. - Руководство по Scrum.
Если первый пункт не был достаточно очевидным, здесь прямо говорится, что нет подгрупп, «ориентированных на тестирование»… что означает QA. Но что, если ваша команда QA - это хорошо обученная группа по поиску ошибок. Жаль, «без исключений», см. Руководство.
Теперь, когда мы все начинаем понимать друг друга, вы, вероятно, думаете: «Это нереально» или «Мы не можем этого сделать в нашей организации». Я здесь, чтобы сказать вам, что вы «можете и должны», а позже я дам вам несколько практических советов, чтобы это произошло. Но сначала еще одно замечание из руководства по Scrum...
Члены команды разработчиков могут обладать специальными навыками в различных областях, но ответственность лежит на команде разработчиков в целом. - Руководство по Scrum.
Ваша команда, возможно, состоит из людей, которые специализируются на создании красивых вещей, и других, которые отлично выполняют бумажную работу. Назову их «экспертами».
В целом все члены вашей команды в чем-то являются экспертами, но это не значит, что это единственное, что они умеют делать. Ваш художник может никогда не написать сложное совместное заявление, а ваш администратор базы данных не сможет никогда создать красивую кнопку, но в совокупности у них есть возможность повлиять на любую стори. Всегда. Даже если они будут просто сидеть рядом и обсуждать какую либо проблему (парное программирование, например). Они могут даже приобрести новые полезные навыки.
Если разработчики повышают свои навыки контроля качества, так почему же это не применимо к вашему аналитику по качеству? Никакие разрешения здесь не нужны. У вас, вероятно, есть эксперт по обеспечению качества в вашей организации, но если многие стори нуждаются в контроле качества, все остальные члены команды присоединятся, верно? Просто должны! Не только специалисты QA; каждый член команды несет ответственность за каждую стори на каждом этапе её завершения. Даже на финальном этапе контроля качества.
Цель - довести всё до уровня «Сделано».
Какой-то отдельный исполнитель может работать в 10 раз медленнее, но если у членов команды есть временной ресурс, им нужно просто добавить 10% эффективности и улучшить свои рабочие навыки.
«Это не моя работа» не существует в Scrum-команде.
Практическое применение
Теоретически всё просто, но как это реализовать на практике?
Решение не всегда очевидно. Итак, вот мои советы, которые помогут вашему эксперту по обеспечению качества получить пользу с первой минуты спринта:
- Имейте пользовательские истории для создания автоматических и нагрузочных тестов. Они важны; обучите своего PO и включите его в бэклог.
- Убедитесь, что все истории действительно маленькие. Моя команда обычно готовит истории для QA в тот же день, когда планирует спринт.
- Если для завершения большой пользовательской истории требуется целый спринт, как, черт возьми, можно получить результаты контроля качества и исправить ее перед закрытием? Разбейте процедуру QA на части. И если нужно разбейте ещё раз.
Поощряйте своего специалиста по контролю качества развивать новые навыки, которые приблизят стори к QA. Варианты подготовки QA включают:
- приобретение навыков программирования
- выполнение некоторых дизайнерских работ
- проведение некоторых пользовательских тестов
- опыт в настройке и управлении сервером
- пусть помассирует шею (шутка!)
Scrum-команды кажутся действительно хорошими в том, чтобы сделать всех в команде равными... пока мы не говорим о контроле качества. У них либо есть «специалист по контролю качества», либо, что еще хуже, он находятся в совершенно отдельной службе QA.
Поскольку ваше определение «Сделано» должно включать прохождение QA (разумеется!), и вы не должны показывать что-либо на закрытии без QA, можно сказать, что, если у вас есть отдельная команда QA, вы просто делаете все неправильно.
Касательно QA, - помните, что у вас больше нет QA. У вас есть человек, который специализируется на контроле качества, но у него есть множество других талантов, которые будут полезными в первый день. Мой эксперт по контролю качества может писать HTML, изучает javascript и у него неплохая подача в теннисе."
Источник: https://www.threefivetwo.com/blog/what-does-qa-do-on-the-first-day-of-a-sprint
