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