Сервис белых ворон…

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

1. Вы можете выполнять работу своих коллег по скрам команде?
2. Вы пишите код?
3. Вы фиксите баги?
4. Вы пишите модульные и интеграционные тесты?

Если все ответы «Да», то эта статья не про вас. Если хоть где-то вы ответили «НЕТ», то вы «Белая Ворона». Вы не такой как все, вы - «слабое звено». По необходимости, вы не можете заменить своего коллегу, чтобы помочь команде.

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

Удачный спринт

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

Неудачный спринт

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

И тут вспоминается статья Джеймса Баха: «Test Jumpers: One Vision of Agile Testing», которая делает намек на то, что тестировщиков вообще не нужно жестко закреплять за командами. Их как лекарство нужно дозировано вводить в нужное время и в нужное место. Получается что-то на подобии тест сервиса. Нужен тестировщик – вот вам он. Нужно 2 - пожалуйста, если они есть в наличии. Возможно, это будет требовать больше менеджмента, но как по мне это лучше чем, когда кто-то сидит и ничего не делает, пока другие вкалывают за двоих.

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

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