четверг, 22 января 2009 г.

Практика перераспределения задач

Есть мнение, что вы собираетесь


найти формальное решение там,


где его быть не может


Алексей Никулин



Дано:

  1. Несколько параллельных проектов по тестированию схожей тематики (или один большой проект из некоторого количества достаточно объемных модулей (по функционалу)).

  2. На этих проектах присутствует определенный объем ручного тестирования (функциональное и/или регрессионное).

  3. На каждом проекте (модуле) свой специалист по тестированию, входящий в проектную группу.

  4. Проекты достаточно продолжительные по времени.


После некоторого времени работы эти специалисты по тестированию становятся так называемыми гуру в данном проекте/модуле.

Проблемы:

  1. Страдает мотивация, человек начинает искать другую работу (да, да, очень мало людей просят перевести куда-нибудь, многие просто тихонько ищут другую работу). Думаю, не нужно объяснять стоимость ухода такого специалиста.

  2. Происходит некоторое "замыливание" взгляда: А в прошлом билде это работало, значит и сейчас будет. Ставим Passed на эти тесты и идем дальше.


В итоге:  или теряем специалиста по конкретному проекту/модулю, или теряем в качестве тестирования.

Для более эффективной работы команды тестирования необходимо время от времени перераспределять задачи между инженерами следующим образом:

  1. Пишет тестовую документацию один, тестирует - другой.

  2. На разных этапах тестирования один и тот же функционал тестируют разные специалисты.


Пример

Есть 6 модулей в продукте. За каждым модулем закреплен свой специалист по тестированию

1 - А, 2 - B, 3 - C, 4 - D, 5 - E, 6 - F

Проект длится не один месяц (по моим оценкам применять данную практику имеет смысл на проектах длиной от полугода).

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















































Тесты/проекты123456
НаписаниеABCDEF
Выполнение Этап 1BCDEFA
Выполнение Этап 2CDEFAB
Выполнение Этап 3DEFABC

Рассмотрим плюсы и минусы предлагаемого подхода:

Плюсы работникам:

  1. Переключение в новую область дает новые знания (Что само по себе плюс, но кроме этого может дать толчок для применения этих знаний о технологии, полученных при тестировании, для тестирования (и не только) другой подсистемы).

  2. Порождает некую соревновательность. (Возможность показать, что ты лучше, чем твой коллега ;) Главное, чтобы это не перешло в гонку вооружений).

  3. Понимание работником отношения к нему его руководства. (Про тебя помнят и следят за твоими успехами и неудачами).


Плюсы работодателю:

  1. Становится меньше (или вообще исчезают) "незаменимые люди".

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

  3. Одна голова хорошо, а две лучше.

  4. Если тестовую документацию пишет один человек (тест-кейзы, чек-листы итд), а тестирует по ним другой, то находятся проблемы не только в ПО, но и в тестах.

  5. Появляется более сбалансированная команда, где обучение происходит peer-to-peer, просто в процессе работы. Надо меньше тренингов, семинаров и т.д.

  6. Есть возможность получить "более хорошего" специалиста по тестированию для той или иной подсистемы не нанимая нового сотрудника.

  7. Переключение в новую область зачастую влечет повышение мотивации сотрудника без каких-либо материальных затрат (читай: не надо поднимать зарплату).

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

  9. Если на одном проекте временное затишье, то можно переключить сотрудников на другой проект не теряя время специалистов на изучение проекта/функционала с нуля.


Минусы:

  1. Тратится время на изучение новой области - меньшая отдача от сотрудника. (Сиюминутный минус - стратегический плюс).

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

  3. Необходимость более тонкого и чуткого распределения задач со стороны руководства. (Ну должны же ведь начальники доказать, что они не зря деньги получают, ага? :) ).

  4. Ну и самое, наверное, сложное, люди в команде должны быть правильными. Как раз чтобы избежать ситуаций, где все знают ничего обо всем, где кто-нибудь кому-нибудь завидует, где никто ничего не хочет. (А собеседования и испытательный срок зачем нужны?).


Когда и для каких людей будет работать данная практика?

Когда:

  1. Проект/проекты длиной от полугода или проекты по поддержке/доработке ранее разработанного ПО.

  2. Желание руководства возиться с перераспределением задач.

  3. Понимание руководством выгод данного подхода в будущем даже с учетом увеличенных затрат по времени сейчас.


В любом случае, как и для любой другой практики нужно считать эффективность ее применения.

Для каких людей:

Алексей Никулин вот в этом посте описал ограничение по применимости данной практики к специалистам по тестированию в зависимости от типа
Есть мнение, что вы собираетесь найти формальное решение там, где его быть не может. В данном случае все зависит от конкретного человека. Я бы предположил, что по отношению к тестируемому продукту можно выделить как минимум два типа тестировщиков:

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

  • "Это моя новая игрушка": сломя голову набрасывается на новый продукт, быстро осваивается в нем, находит серьезные проблемы, требует их немедленно исправить, пытается пилить бензопилой стальные балки; с уменьшением числа открытий успокаивается и теряет интерес. Глаз замыливается, внимание снижается, эффективность падает. "Заточение" на одном проекте считает личной драмой.


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

P.S. Данная практика нацелена на повышение квалификации всех специалистов по тестированию, повышение их мотивации и уменьшение рисков ухода сотрудников. Она ни в коем случае не предполагает формальное использование из разряда «делай раз, делай два» (см. цитату в начале статьи) и именно в таком ключе и надо ее воспринимать. Я сам применяю эту практику около 3-х лет и доволен результатами.

Статья написана по мотивам обсуждения на форуме it4business



В статье были использованы посты и замечания Алексея Лянгузова и Алексея Никулина.

2 комментария:

  1. Error 404 - Not Found для ссылки

    "...Алексей Никулин вот <> описал о..."

    ОтветитьУдалить