Большая QA-команда зачастую занята тестированием пропорционально большого продукта и решением сложных задач.
В большой команде становится сложнее управлять стандартами качества и обменом знаний, а также справляться с проблемой централизации экспертизы. Позвольте мне пояснить суть трудностей на более глубоком уровне и предложить возможные решения. Хотя большая часть моих идей является результатом моего собственного опыта управления, внедрение методов, о которых я расскажу, может помочь как начинающим, так и опытным специалистам, а также командам любого размера.
Проблема №1: Поддержание высокого качества на протяжении длительного времени.
Суть проблемы: Кто из нас сталкивался на своем опыте с тем, что задача обеспечения высокого качества продукта усложняется по мере роста команды?
Решение: Причина в том, что мы все обладаем разным набором навыков, имеем сильные стороны в разных областях и разные таланты, разный накопленный опыт, а также используем разные подходы к тестированию. Эти различия важны, потому что очень непросто научить людей тестировать или убедить их тестировать определенным образом. Это непросто, потому что на процесс тестирования влияет то, насколько широко и креативно человек способен думать.
Остановка чьего-то мыслительного процесса и перенаправление его на что-то другое не всегда будет срабатывать, и не стоит этого делать, пока в этом нет реальной потребности. Ментор/лид должен прикладывать здесь усилия для поддержания хороших отношений с каждым тестировщиком.
Возвращаясь к реальной проблеме — как следствие вышеописанных различий, при тестировании определенных функциональностей не все члены команды могут обнаружить все дефекты. Количество найденных дефектов, их качество и затраченное время также будут отличаться.
В таких случаях возможны следующие исходы:
Проблемы в выпущенных модулях;
Неспособность продумать все негативные сценарии во время написания тест-кейсов или тест-сценариев;
Трата излишне большого количества времени и сил на негативные кейсы, в то время как позитивные остаются без должного внимания;
Некоторые члены команды остаются не уверены в проделанной работе;
Повторные тестовые циклы с целью обрести утраченную уверенность.
Проблема №2: Централизация знаний и экспертизы
Суть проблемы: знаниями и экспертизой по конкретному модулю или типу тестирования обладают всего несколько членов команды.
Например: Иван, Олег и Сергей работают в одной команде. Иван хорош в тестировании безопасности, Олег обладает глубоким познанием модуля «Рабочий процесс», а Сергей незаменим, когда дело касается тестирования производительности и работы с модулем «Оплата».
Наличие в команде экспертов по модулям или типам тестирования помогает менеджерам в краткосрочной перспективе, поскольку им просто можно назначить новые задачи сотрудникам по тем сегментам, где они профи, а менеджеры могут расслабиться, зная, что получат наилучший результат.
Однако в долгосрочной перспективе это способствует развитию сложной в управлении зависимости. Недоступность ключевого ресурса может привести к проблеме и даже полной остановке релиза. Недоступность сотрудника может быть вызвана многими причинами вроде незапланированного отпуска, болезни, декрета, внутренних перемещений, увольнения и так далее.
Что насчет обмена знаниями?
Продолжим вышеупомянутый пример: разве не поможет Олегу знание о том, над какой частью продукта работает Сергей? Не поможет ли Сергею знание модуля рабочего процесса, которым обладает Олег? Не поможет ли им всем троим понимание новых разработок в продукте и предположения об их влиянии на прошлые и настоящие результаты? Не поможет ли каждому из них общее знание всего продукта при работе над будущими задачами?
Я слышу ваш утвердительный ответ.
Решение: Теперь, когда мы обозначили первые две трудности, давайте я расскажу о том, как работает и преодолевает проблемы моя команда.
Мы придерживаемся в своей работе двух правил, о которых, я уверен, вы уже сто раз слышали:
Люди важнее процессов.
Сотрудничество важнее документации.
Вот как проходит работа в нашем случае, шаг за шагом:
Сбор требований: история/фича XYZ готова к обсуждению со стороны бизнес-аналитика.
Обсуждение пользовательских историй: если новое требование является сложным, оно сначала обсуждается на уровне лида; где бизнес-аналитик, тимлид и QA-лид готовят пользовательские истории к грумингу (обсуждение требований с командой). Цель этого процесса — проработать возможные пробелы и снять сомнения в истории заранее и так их детализировать, чтобы сэкономить время команды.
Груминг-сессия: это сессия, на которой бизнес-аналитик проводит команду через все требования с функциональной точки зрения. Тестировщик (давайте с этого момента называть его владельцем истории), получает здесь около 90% ясности о работе над своим участком.
Когда я говорю о ясности в этом контексте, я имею в виду, что почти все тест-сценарии/тест-кейсы в голове тестировщика формируются уже здесь. Ну и плюс 5-10%, которые появятся позже.
Мозговой штурм: после груминга разработчики и тестировщики встречаются для обсуждения требований с более технической, нежели функциональной точки зрения: обсуждается влияние на существующие фичи, необходимость исправления существующих данных, скрытые сценарии и усилия.
Чтобы внести вклад в список сценариев, в этой сессии стараются принять участие максимальное количество участников команды тестирования. Это также помогает приумножить их собственные знания. Таким образом, мы получаем множество тестирующих умов вместо одного.
Как в нашем примере, даже если Иван владеет какой-то конкретной историей, Олег и Сергей помогут ему поразмышлять над ней.
Затем владелец истории добавляет все обсуждаемые сценарии в список, полученный на груминг-сессии. В идеальном случае, на этой сессии покрывается почти все, кроме тех немногочисленных рандомных багов, которые можно обнаружить только с помощью исследовательского тестирования.
Преобразование в тест-кейсы: владелец истории начинает преобразование требований и сценариев, которые он собрал на предыдущих этапах, в тест-кейсы. В это же самое время разработчики начинают писать код для новых фичей. После написания тест-кейсов владелец истории передает их своим коллегам из департамента на ознакомление.
Тестирование с помощью тест-кейсов и переход к исследованию: как только командой разработки история помечается готовой, владелец истории заканчивает тестирование по написанным тест-кейсам и проводит исследовательское тестирование, во время которого удается протестировать множество других вещей. Как только удается достичь желаемого уровня качества (на основании решений о покрытии тестами, количестве открытых баг-репортов и уверенности владельца истории), история помечается готовой со стороны QC.
Подстраховочные сессии*: после того, как завершена работа со стороны команды QC, владелец истории проводит небольшую обзорную сессию (до поставки релиза) для новой фичи, на которой он объясняет функциональность и проведенное тестирование. Мы называем ее “Подстраховочная сессия”. Присутствие на ней обязательно для всех тестировщиков, в отличие от мозгового штурма. Участники могут поразмышлять, возможно ли влияние этой истории на их историю тестирования и наоборот; также они могут задать владельцу истории интересующие их вопросы.
Подстраховочный этап тестирования*: важный, но необязательный шаг, выполняемый любым тестировщиком, кроме владельца истории, обычно за время не более часа.
«Подстраховочный» тестировщик продумывает только неочевидные негативные кейсы, предполагая, что остальные более-менее очевидные уже протестированы. Это как второе мнение перед выкаткой релиза.
Возможно, в вашей команде уже налажены процессы, которые охватывают большую часть вышеназванного. В нашем случае каждый шаг важен, но реальным отличием от остального мира являются три шага, обозначенные звездочкой*.
Я перечислю их еще раз, потому что они генерируют высокий ROI:
Мозговой штурм
Подстраховочная сессия
Подстраховочный этап тестирования
Мне, как менеджеру, это облегчает работу по поддержанию качества на максимально возможном высоком уровне и способствует бесперебойной передаче полезной информации всем членам команды.
Более того, даже больше чем мне, эти методы помогают моей команде. Это не мои слова, а слова моей команды из более 25 человек, которая каждый раз говорит мне об этом в ответ на мой вопрос о том, что на их взгляд мы делаем хорошо, что им помогает в работе и что стоит продолжать делать и дальше.
Проблема №3: Работа должна вызывать интерес
Суть проблемы: Вы думаете, что я просто заставляю свою команду работать безо всяких интересных захватывающих задач и возможностей для личного развития? Для любого хорошего лидера это было бы преступлением. Если вы просто забрасываете людей работой и на этом все, то в конце концов они совсем устанут, заскучают и разочаруются в работе.
Решение: У нас очень дружелюбная обстановка не только внутри команды, но и во всей организации. Что касается команды, то мы больше похожи на друзей, чем на менеджеров-подчиненных.
Вот что мы делаем дополнительно:
Каждую среду мы все (все тестировщики всех продуктов) встречаемся на пару часов. Мы называем это Q&A сессией.
Вот что мы там делаем:
Любой может задать вопрос о чем угодно, не только о тестировании, и другие могут ответить.
Любой может поделиться идеей, мыслями по улучшениям процессов, своими достижениями с другими. Поделиться можно чем угодно.
Каждый в мире тестирования в процессе работы приходит к каким-то интересным идеям/вещам, о которых другие могут не знать. Это шанс расширить базу знаний.
Все еще выглядит, как работа? Ну хорошо, тогда сыграем в какую-нибудь игру. Например, больше всего мы любим мафию.
Проблема №4: Распределение и назначение задач
Суть проблемы: распределение работы среди членов команды. Если вы просто назначаете таски по своему выбору, это может закончиться следующими сценариями:
Кто-то снова и снова получает задачи одинаковой сложности, что ведет к ограничению профессионального роста.
Кому-то из раза в раз для тестирования достаются одни и те же модули, что со временем начинает вызывать чувства скуки и неудовлетворенности.
Вы, естественно, назначаете конкретный модуль соответствующему эксперту, чтобы получить наилучший результат. В итоге рождается проблема централизации экспертизы, о которой мы упоминали ранее.
У команды появляется чувство, что они, словно роботы, просто подчиняются приказам и не чувствуют, что их мнение и выбор ценны.
Решение: В качестве решения члены нашей команды сами выбирают себе задачи. Да, за планирование релиза мы садимся вместе, и с помощью релиз-дашборда, включающего все пользовательские истории, команда сама распределяет между собой задачи.
Поступая так, все вышеназванные проблемы автоматически решаются, поскольку балом правит команда, а не менеджер. Очень редко случается, когда я перераспределяю ставки, держа в фокусе качество продукта и сроки релизов. Безусловно, после разъяснения команде причин.
Проблема №5: Выражение признания и мотивация
Суть проблемы: вы можете каждого своего члена команды отнести к одной из категорий сотрудников: «звезда», сильный исполнитель, слабый исполнитель.
Парадоксально, но реальные проблемы случаются тогда, когда есть много звезд и сильных исполнителей, но совсем нет слабых исполнителей. А все потому, что внезапно такая ситуация заставляет сильных исполнителей выглядеть слабыми исполнителями по сравнению со звездами.
Решение: что ж, решение начинается с принятия того факта, что не могут в команде все быть звездами. Каждый обладает своими талантами, отличается разной скоростью обучения и разными стилями работы. Как лидеру, вам следует относиться к этому с пониманием.
Вы можете помочь сильному исполнителю стать звездой, но не в одиночку. Вам нужно будет сначала определить лидеров (это могут быть неформальные лидеры) в своей команде и затем вовлечь их в это дело. Будучи менеджером/лидером, вы не сможете уделять одинаковое количество времени каждому в команде. Вам придется делегировать ответственность правильно выбранному неформальному лидеру, раскрыв ему свое видение.
Я это уже сделал и могу с гордостью сказать, что из года в год каждый лидер в моей команде получается больше 4.5 из 5 баллов в отзывах подчиненных.
Вы можете налаживать связи с максимумом количеством людей, но вам нужно постоянно разговаривать с вашими лидерами, направлять их, ценить их усилия и делиться видением. Они же в свою очередь сделают оставшуюся часть работы, которую мы сможете просто проконтролировать.
Конечно, что-то вы будете делать всегда: писать поощряющие письма, выступать на встречах с мотивирующими речами, публично хвалить свою команду.
В заключение напомню о следующем принципе: «Коллективный ум сильнее индивидуального». Поэтому используйте свою силу, которая заключается в том, чтобы быть командой и покоряйте новые вершины вместе.
Материал подготовлен в преддверии старта курса "QA Lead".
Всех желающих приглашаем на бесплатное demo-занятие «Формирование стратегии тестирования». На занятии разберемся:
- Что является стратегией тестирования?
- Из каких элементов она состоит и зачем она нужна?
- Разберем конкретные примеры стратегий и как они зависят от архитектуры ПО.
А также рассмотрим такие инструменты формирования стратегии, как квадранты тестирования и пирамида тестирования. Если интересно, записаться можно здесь.