«В одном IT-царстве жила-была себе команда тестировщиков: Алеша Попович, Добрыня Никитич, Любава и Гай Юлий. Были в том царстве и разработчики – Змей Горыныч, Илья Муромец и Тихон. Ну и, конечно же, присутствовал тим-менеджер Царь. Все они, такие разные, творили одно доброе дело и корпели над одним общим заданием: укрепить и облегчить жизнь мирскую и не пропустить ни одного Бага. Объединяло их общее желание и стремление, а посему и решили они – будем работать вместе».
Работа над проектом – это командный процесс. В любом коллективе значительную роль играет человеческий фактор. Оставлять его без внимания нельзя – напротив, всегда нужно предвидеть и учитывать возможные сложности. Все мы разные, у всех у нас свой склад характера, взгляд на вещи и отношение к работе. Очень важно найти правильный подход к каждому сотруднику для того, чтобы не просто объединить коллектив общим проектом, но и создать комфортные условия работы. Помочь в этом может соблюдение основных принципов, которые делают коллективный труд продуктивным и результативным:
внедрение в сознание всех сотрудников постулата «общее дело объединяет»;
установление дружелюбных, искренних и налаженных коллективных отношений;
достижение сплоченности как важного фактора эффективности;
понимание того, что любой человек в команде – важное звено;
налаживание взаимодействия каждого участника со всеми остальными;
учет мотивации каждого конкретного сотрудника в зависимости от его выявленных целей и желаний.
Я постоянно помогаю людям. Звучит, будто я хвастаюсь, потому что помощь другим – это хорошее дело, не правда ли? По моему опыту, позитивная помощь при работе с ПО приносит неплохие дивиденды, однако недавно я узнала, что чересчур ответственный тест-менеджер фактически подрывает качество релиза.
Присоединившись к проекту, я беру на себя личную высокую ответственность за выпуск пользователям качественного продукта. Когда я исследую различные риски качества, мне нужно больше знать о процессах разработки и релиза ПО в компании. Когда я разговариваю с другими менеджерами об их роли в релизе продукта, мы часто находим множество важных продуктовых проблем. Две из них я встречала в нескольких компаниях:
Автоматизированные юнит-тесты не проверяются неделями или месяцами.
Релизы для тестирования и для прода выполняются разными командами.
Это серьезные риски для качества продукта, которые тест-менеджер не может игнорировать. Я работала с выдающимися людьми в индустрии разработки ПО. Их тоже волновали эти риски, но ограничения по времени, ресурсам и бюджетам не позволяли им внедрять решения этих проблем. Каждый раз я соглашалась (и зачастую вызывалась сама) брать эти задачи на себя вместо того, чтобы принять их как данность.
Мы отобрали доклады с конференции SQA Days 21, посвященные вопросам управления людьми в тестировании.
1. Делимся опытом: как мы оптимизировали тестирование крупного проекта за 3 месяца, Наталья Руколь, Quality Lab., Москва, Олег Грабко, Quality Lab., Нижний Новгород
2. Тестирование в крупных стартапах или как упорядочить хаос, Александр Мешков, Performance Lab, Москва
3. Бизнес-ориентированное тестирование eCommerce приложений, Игорь Бондаренко, Neklo, Минск
Если вы тест-менеджер, на вас ложится ответственность организовать рабочий процесс в своей команде. И в идеале так, чтобы всем сотрудникам было комфортно. Задача не простая. Но спикеры, приглашенные на конференцию COMAQA Spring 2017, попытались с ней разобраться.
Если у вас уже есть команда, с которой вы сотрудничаете не первый год, возможно, в решении многих вопросов вам поможет правильных подход к мотивации сотрудников.
Если вы назначены тест-менеджером в уже сформировавшийся коллектив, важно найти точки соприкосновения, поближе познакомиться с коллегами, понять их проблемы, услышать их вопросы.
Если вы создаете команду с нуля, от вас требуется подобрать персонал, обладающий навыками, которые необходимы на конкретном проекте.
Ниже представляем записи докладов, где были озвучены эти и другие интересные тест-менеджеру вопросы:
Давным-давно, когда деревья были большими, солнце светило ярче, а телефоны не работали без проводов, программисты делали все сами. Сами выясняли, что хочет заказчик, сами писали программу, сами ее тестировали. Прошли годы, отрасль расширилась, и появились первые специализации. Аналитик стал выяснять и описывать требования, дизайнер – продумывать внешний вид, разработчик – писать код, тестировщик – проверять, правильно ли все работает. В наше время тенденция увеличения численности команд тестирования поставила перед руководителями новый вопрос, который пока еще не имеет однозначного ответа: нужна ли специализация тестировщиков внутри одной команды?
Специализация: когда она работает на нас, а когда – против?
Для начала отметим некие общие принципы, которые нужно учесть.
Итак, специализация явно нужна в следующих случаях:
тестируется критичное ПО, ошибки в котором могут затрагивать жизнь и здоровье людей, а также крупные финансовые потоки;
специализированные тестировщики одних направлений на вашем рынке дороже тестировщиков других направлений, а также существенно дороже широкопрофильных специалистов (нет смысла тратить «дорогой» труд на «дешевые» задачи и нет смысла учить тестировщиков на специалистов – выучась, они продолжат работать за прежнюю зарплату лишь до первого интересного предложения в LinkedIn);
узкопрофильный тестировщик может обслуживать более одного проекта в вашей компании (например, автоматизаторы или юзабилисты часто работают сразу на нескольких проектах);
вы решили отдать на аутсорс некоторые задачи – простые или сложные разовые (типа полной автоматизации устоявшегося регресса или юзабилити-оценку).
На тест-менеджере всегда лежит большая ответственность: решить возникающие на проекте проблемы, организовать процесс работы в команде так, чтобы результат был положительным.
Вопрос в том, как это лучше сделать: полностью пересмотреть процесс управления, или просто внести небольшие корректировки в работу?
Ниже мы публикуем видеозаписи выступлений наших коллег на конференции CEE SECR “Разработка ПО”, где они делятся опытом работы со своей командой: Длинный путь к DevOps? Михаила Громова и Проблемы процесса разработки с точки зрения тестирования Никиты Сыскова.
В ноябре на форуме software-testing.ru был опрос про то хотят ли тестировщики стать руководителями. На вопросы ответили почти 80 человек. Ниже результаты
Четверть опрошенных не хотят даже пробовать для себя функции руководства. Еще четырнадцать процентов попробовали и поняли, что это не для них. В любой момент готовы перейти в управление двадцать пять процентов и одиннадцать планируют для себя подобный переход в ближайшие три года.
Выступление Юлии Абрамовой на онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.
«Как может править царством тот, кто не умеет играть в шахматы?» Сасанидский царь царей, Хосров II Парвиз Около 600 г. н.э.
Что общего у тестирования и шахмат? Это и комплексность входных факторов, и необходимая практическая подготовка, и огромная вариативность правильных ходов. Чему может научиться тест-менеджер у кандидата в мастера спорта по шахматам? Стратегии и тактике в борьбе с ошибками, комбинациям в ресурсах и жизни в постоянном цейтноте!
В своём докладе я расскажу про 10 параллелей игры в шахматы и построения процессов тестирования на трёх этапах:
Выступление Елены Саламахи (Test Lead, Luxoft UA) на онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.
Перед многими тест-менеджерами, работающими в аджайл-практиках, стоят следующие задачи:
Как избежать непредвиденных багов?
Как избежать недопонимания и разночтения требований?
Как избежать рутинной ручной и, часто лишней, работы?
Как поддерживать стабильный уровень качества в условиях частых поставок?
Как не потеряться в постоянных изменениях?
Для решения этих проблем, в своём докладе я расскажу вам о простых и эффективных практиках, накопленных поколениями аджайлистов – трёх основных концепциях построения тестирования в Agile:
1. В битве побеждает тот, кто в ней не участвует.
Техники предотвращения появления дефектов.
2. Железная гибкость.
Автоматизация, Непрерывная интеграция.
3. Путь в тысячу шагов начинается с одного шага.
Концепция постоянного улучшения, «гибкого внедрения гибкости».
+1 бонус-концепция, которая призвана сделать жизнь существенно проще.
Каждый мужчина должен построить дом, посадить дерево и воспитать сына... Задача каждого менеджера подготовить себе замену, но сказать и сделать - не одно и то же.
Как выбрать подходящего кандидата, как подойти к его обучению, какие навыки развивать, как представить замену клиенту, сколько времени потребуется, где найти на это время, зачем все это нужно?
Ответы на эти и другие вопросы, необходимые для подготовки управленца, который с легкостью заменит вас на проекте, освещены в этом докладе.
Если вы тест-менеджер, на вас ложится ответственность организовать рабочий процесс в своей команде. И в идеале так, чтобы всем сотрудникам было комфортно. Задача не простая. Но спикеры, приглашенные на конференцию COMAQA Spring 2017, попытались с ней разобраться.
