При написании статьи использовались материалы А.Смирновой, подготовленные в рамках конференции тестировщиков «Котэ»
Тестирование – очень динамичная сфера, которая постоянно развивается; каждый день появляются новые инструменты, материалы и подходы. Тестировщик – это «универсальный солдат», зачастую объединяющий в себе различные навыки: написание кода, управление ресурсами, владение основами дизайна и верстки, а также знания в более узких прикладных областях. Руководители проектных команд стараются повышать квалификацию своих ребят, отправляя их на всевозможные курсы и тренинги. Но как быть со стажерами, с «проектными новобранцами»? Как правильно, а главное, чему именно нужно научить стажеров (особенно в распределенной команде), чтобы у них не пропал интерес к профессии, и чтобы это обучение принесло пользу не только «новобранцу», но и всему проекту? Об этом мы и расскажем в нашей статье.
Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.
Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задач. При этом не всегда получается отказаться от старых обязанностей. Приходится совмещать две роли на проекте. Так и я, имея опыт в тестировании и аналитике, дополнительно стала получать задачи руководителя проекта. Со временем я полностью перешла в управление проектами.
В этой статье я делюсь наблюдениями и выводами. Как в одном человеке конфликтуют привычки тестировщика и обязанности руководителя проекта? С какими проблемами приходится сталкиваться? Какую пользу можно извлечь при таком переходе? Если хотите получить ответы на эти вопросы, добро пожаловать под кат.
Доводилось ли вам задумываться о том, кто такой "самый ценный тестировщик"? Какие показатели его работы отличаются от "простых смертных"? Что он делает по-другому, какие техники использует, какие задачи решает?
Заинтересовавшись этим вопросом, Олег провёл полноценное исследование среди различных участников процесса разработки. Полученная статистика наглядно демонстрирует ожидания от тестирования и даёт понимание, как стать лучше, ценнее, востребованнее.
Когда я впервые присоединяюсь к проекту и быстро пытаюсь сориентироваться в нем, я чувствую себя парашютистом, сброшенным в зону боевых действий под покровом ночи. У меня есть краткое описание моей миссии, но многое мне предстоит быстро выяснить на месте, чтобы сработать быстро, качественно, не отвлекаясь на ненужные задачи и фокусируясь на том, что важно, в том контексте, куда я попал. В своей статье я опишу свой опыт, свои мысли и использование эвристик, помогающих быстро сориентироваться в проекте, помочь моей миссии как тестировщика, и позднее стать частью моей тест-стратегии.
Начнем с ряда определений, которые я вынес из курса Rapid Software Testing Джеймса Баха и Майкла Болтона:
Миссия тестирования – результаты, которых от вас хотят заказчики. Покройте продукт тестами так, чтобы оценить риски, основанные на требованиях.
Тест-стратегия – набор идей, направляющих тест-дизайн и выполнение. Она описывает, как вы будете покрывать продукт, чтобы оценить его качество.
Распределенная команда – это возможность найти нужного специалиста без ограничений конкретной территории, а также сэкономить на рабочем месте. Конечно, в такой работе есть немало особенностей. Вот уже четвертый год я управляю распределенными командами. На это накладывается предыдущий опыт классической схемы «одна команда – один офис». За это время мной «собрано немало шишек» и подготовлено немало наработок.
Если вы уже стали руководителем распределенной команды, только задумываетесь над ее созданием или просто хотите узнать о нюансах работы в тесной связке на расстоянии – эта статья для вас. Я постараюсь разобрать вопросы организации работы, осветить распространенные проблемы и стандартные страшилки.
Теоретически команды разработки Agile работают совместно и используют кроссфункциональный, основанный на сотрудничестве подход, обеспечивающий непрерывную производительность. На практике я видела множество команд, где финальный результат ограничен масштабом работ, который способны выполнить их тестировщики.
Если тестировщики – единственные, кто тестирует, то это душит команду. Это происходит потому, что разработчики и люди бизнеса, участвующие в процессе разработки, не хотят заниматься тестированием. Это может также происходить потому, что тестировщик не хочет, чтобы кто-то еще тестировал. Я сталкивалась с обоими вариантами.
Материалов, помогающих тестировать тем, кто далек от тестирования, великое множество. Как по мне, куда меньше информации о том, как поддержать тестировщиков, чтобы они с радостью позволяли другим помогать себе. Я бы хотела разобрать три проблемы, препятствующие тестировщику в вовлечении других людей в свою работу.
У каждого руководителя рано или поздно появляется потребность в развитии команды. Но как молодые, так и опытные руководители не всегда могут понять, куда именно можно развиваться, и что для этого нужно сделать. Работая в тестировании с 2006-го года и побывав в различных командах, я могу с уверенностью сказать, что возможность для развития есть всегда. Главное – определить верное направление. Ниже будут рассмотрены шаги, с помощью которых это можно сделать.
Самый главный вопрос, на который нужно найти ответ: зачем расти команде, если не поступает никаких жалоб ни со стороны заказчика, ни со стороны сотрудников? Необходимо оценить возможности для развития, которыми обладает команда на текущий момент – это позволит нам определить инструменты и стратегию достижения положительного результата. Также важно знать ближайшие планы и цели компании или проекта.
Меня всегда интересовало, что именно мотивирует людей, и почему они делают то, что делают. Понимание мотивационных факторов очень помогает в работе, особенно если вы менеджер.
Дилемма немотивированных тестировщиков
Я часто сталкивалась с немотивированными тестировщиками, и вы, я думаю, тоже. Под немотивированными я имею в виду тех, кого вполне устраивают средненькие или даже посредственные результаты труда, тех, кто не пытается профессионально развиваться.
У меня немного эмпирических данных, но мне кажется, что немотивированных тестировщиков в мире куда больше, чем мотивированных (как минимум, так подсказывает мне мой личный опыт). В результате это создает проблемы для команды тестирования, потому что найти талантливых людей становится очень трудно. Правда, было бы здорово, если бы мы могли мотивировать этих незаинтересованных людей и помогли им стать лучше и вовлекаться в работу больше? Я пробовала, и это нелегкий труд.
Мотивация – это дорога с двусторонним движением: нельзя мотивировать тех, кто ничем не интересуется. Это важный момент, поэтому повторюсь: нельзя замотивировать тех, кто этого не хочет. Однако мы можем указать им путь, вдохновлять их личным примером и надеяться, что им захочется меняться.
Пару лет назад на просторах всемирной сети мне повстречалась интереснейшая история. К сожалению, я не помню ни автора, ни деталей, но суть ее в следующем. Как-то на одном предприятии все стало плохо: понизилась производительность, не выполнялся план, появилось много брака. Уже и зарплаты сотрудникам поднимали, и условия работы сделали на уровне – а предприятие, увы, терпит убытки. И как же тут быть? Выход оказался довольно неожиданным: проанализировав работу предприятия, выбрали работника с наилучшими показателями производительности, на общем собрании обсудили его работу, указали на все недочеты и недоработки, а потом… уволили за несоответствие занимаемой должности. Несправедливо? Жестоко? Возможно, но давайте посмотрим на результат.
Нет ничего страшнее в тестировании, чем отсутствие единого понимания особенностей продукта (проекта) участниками команды. Последствия разнообразия взглядов могут быть различными: от заведения бесполезных дефектов, напоминающих «белый шум», до пропуска проблем, критичных для пользователя.
К сожалению, наладить единство понимания бывает не очень просто, так как:
- руководители проектов, выступающие в роли заказчиков тестирования, не всегда делятся «очевидной» информацией; - специалисты по тестированию зачастую пытаются навязать проекту некое «правильное» (в их понимании) тестирование.
В этой статье я хочу рассказать о своём опыте руководства тестированием в аутсорсе и дать рекомендации о способах достижения одинакового понимания приоритетов и задач на проекте: какие вопросы для этого необходимо задавать и какую информацию анализировать.
Автор: Иван Бондарь, ведущий инженер по тестированию компании "Лаборатория качества"