Распределение тестировщиков по командам, как один из этапов контроля качества в компании Узенцова Наталия Презентация будет переработана под формат конференции и под правила удобного донесения информации
План 1. Риски 2. Следствия 3. Критерии 4. Причины (паттерны) перевода тестировщика в другую команду   5. Описание паттернов
Риски Неправильно подобранная команда для тестировщика – это риски: Не качественно протестированный продукт – после поставки клиенты находят критичные баги; Срыв поставки продукта – вы не можете выпустить продукт в срок из-за того, что важные его части никак не могут быть до тестированы. Человек от вас в скором времени уйдет. Потеря экспертизы при переходе в другую команду
Риск 1 Не качественно протестированный продукт – это следствия того, что не правильно были выбраны подходы к тестированию: минорные баги находились и фиксились в начале; неполное покрытие первоприоритетных задач; то что могло быть протестировано методом А, тестировалось в 5 раз дольше методом В; и т. д. Причина: (банальна) не достаточная квалификация тестировщика для тестирования данного функционала. Джуниор – говорит, что всё протестировано.
Риск 2 Срыв поставки в большинстве случаев происходит тогда, когда на дату релиза тестировщик говорит, что не протестированы важные части функционала. Срыв поставки продукта не всегда является следствием не достаточной квалификации в самом тестировании продукта, следствием будет скорее неумение оптимизации применения своих хороших умений, либо попытка приобрести новые в короткий срок. Причина: (банальна) не достаточный контроль со стороны руководства команды активностями тестирования, иногда непонимание активностей тестирования Идеалист – зарывающийся в детали, паникующий при мысли, что, что-то будет упущено, считающий, что фичу быстрее автоматизировать, но не достаточно квалифицированный, чтобы сделать это быстро.
Риск 3 Уход человека, это следствие: Не интересных задач; Невозможности применения своих навыков; Не та команда, частью которой ему бы хотелось быть. Таким может быть просто Хороший тестировщик, знающий мат часть, что от него ждут, показывающий хорошие результаты Изначальная причина в том, что человек не на своем месте, не в той команде.
Риск 4 Риск потери части экспертизы при переходе в другую команду – риск неизбежный, если вы переводите хорошего тестировщика. Причина этого риска в том, что если у вас много разных проектов, невозможно сделать так чтобы каждый знал полностью все продукты.
Технические и не технические критерии, на которые стоит обратить внимание 1. Разное тестирование в разных проектах. 2. Может быть необходимость в знаниях автоматизированного тестирования, тестирования производительности, тестирование сервисов, тестирование безопасности. 3. Разные клиенты 4. Если код должен быть разработан весь, то качество от клиента к клиенту может отличаться. Некоторые клиенты тестируют меньше, некоторые больше. Пропущенная ошибка у одних, дороже чем у других 5. Разная скорость выпуска релизов. Кто способен жить в темпе ежедневных, недельных, двух недельных итераций, кто-то нет. 6. Разные виды работы с клиентами: саппорт, командировки, демо, грамотный ответ на письма. 7. Разный состав команды, команда вся говорит на иностранном языке, команда вся удаленная.
Рассмотрим причины (паттерны), которые ведут к переводу тестировщика в другую команду: 1. Необходимость бизнеса в определенном виде тестирования. 2. Не достаточно ресурсов тестирования. 3. Слишком много ресурсов в одной команде, необходимо распределить по другим командам. 4. Новый проект. 5. Необходимость во взаимозаменяемости, в приобретении новых знаний. 6. Неприязнь тестировщика к команде.
Паттерн 1. Необходимость бизнеса Клиентам срочно понадобилось нагрузочное тестирование. У вас такой тестировщик один. Возможно возникновения риска 2 и 3. Чтобы убрать риск два, очевидно, что нам необходимо перевести в команду тестировщика, обладающего навыками нагрузочного тестирования. Если возникает в этом случае риск три, необходимо его после выполнения необходимой части задач вернуть в комфортную ему среду.
Паттерн 2. Не достаточно ресурсов тестирования Если в команде уже работают успешно тестировщики, то они покроют риск 1 и 2, и в необходимый момент смогут их разрешить. Риск 3 в таком случае должен быть обдуман, и исключен на начальном этапе. Мы не можем себе позволить часто менять людей в команде, это снижает её производительность. Стоит выбрать человека, который будет способен по техническим и личным качествам наиболее подходить в команду. Я анализирую, к какому руководителю идет тестировщик, что от него ждут и насколько он способен этому соответствовать. Возможно, на его место придется назначить кого-то другого и это повлечет за собой цепочку перестановок, возможно возникновение риска 4. Следует всегда помнить о том, что спасая одну команду нельзя утопить другую.
Паттерн 3. Слишком много ресурсов в одной команде Такое случается, когда большая часть проекта разработана и начинается стадия поддержки. Это достаточно простой и безопасный паттерн, в первую очередь, конечно, стоит проанализировать загрузку других команд, есть ли у них необходимость в дополнительном тестировщике, важно чтобы он не простаивал или не отвлекал из-за своей неопытности других, тормозя эти важную поставку. Тут вы можете учитывать и желания в развитии, и желания относительно команды и, конечно, свои пожелания в какую сторону необходимо его развивать, чтобы развивался весь отдел.
Паттерн 4. Новый проект для компании, либо старый остался без тестировщика Чтобы избежать рисков, в этом паттерне вам стоит проанализировать всю команду в целом. Рассмотрим команду, которая состоит из аналитика, разработчиков и тестировщика + руководителя. По умолчанию будет считать, что руководитель грамотный. Я считаю, что для успешного проекта, хотя бы на 2 из 3х ролей были опытные специалисты (аналитик, разработчик и тестировщик). Проект умрет в багах, если и анализ и разработка будут хромать. Рассмотрим ситуацию, когда как минимум один из двух (аналитик, разработчик) является опытным специалистом Хороший разработчик + опытный тестировщик, вытянут проект, то же касается и тестировщика + аналитика. Вам стоит лишь разобраться в том, оба ли специалиста (разработчик, аналитик) являются высококвалифицированными или только один. Если оба высококвалифицированные, вы можете себе позволить отдать в команду джуниора, они его дотянут и воспитают. Если же кто-то из них не дотягивает, то тестировщик должен быть опытный, иначе вы ставить под угрозу весь проект. Так же стоит учитывать личную неприязнь. Бывает, что весь остальной проект разрабатывается сторонней командой говорящей на иностранном языке, в данном случае тестировщик должен быть коммуникабельным и командным игроком с хорошими навыками тестирования. Определите специфику клиента, ко всем нужен свой подход.
Паттерн 5. Необходимость во взаимозаменяемости, в приобретении новых знаний Применение этого паттерна необходимо для долгосрочного планирования. Он позволяет избежать рисков 1 и 2, уменьшить риск 4 в дальнейшем. Чтобы не возник риск 3 необходима правильна я мотивация.
Паттерн 6. Неприязнь тестировщика к команде Это прямой путь к риску 3. В этом случае вам необходимы доверительные отношения со своей командой, чтобы хотя бы узнать об этом. Ситуация должна быть оценена трезво с наличием определенных аргументов, если конфликт не решаем или вам в этом случае не сложно заменить людей, то человека стоит перевести в другую команду.