Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет, Хабр! Меня зовут Коля и я QA. Хочу поделиться, как эволюционировал из существа, которое профессионально пьет кровушку разработчиков, доводит до нервного срыва дизайнеров и систематически портит настроение менеджменту, до человека, который помогает выводить на рынок качественные и продуманные продукты, страхует разработчиков и облегчает планирование продактам.
Об истоках противостояния
Конечно, рано или поздно мы все набираемся опыта, вырастаем из «коротких детских штанишек» эгоизма, предрассудков, стереотипов и начинаем работать сообща, помогая друг другу с профессиональным ростом и общими задачами. Но перед этим умудряемся набить энное количество шишек.
У меня эта трансформация заняла долгих пять лет. Я начинал путь в IT с глобальных модов и фриланса в геймдеве. Потом работал над несколькими проектами в сфере онлайн-образования, лекторием для МФТИ и, наконец, нашел свое место в Skyeng. За это время успел поругаться с одними работодателями, стать незаменимым сотрудником для других, снова станцевать танго на граблях и… Наконец, решил составить свой собственный топ известных мне проблем QA в компании и способов их решения.
Итак, давайте для начала определимся с тем, всё ли у вас хорошо с тестированием и насколько этот материал актуален для вас вообще. Согласны? Хорошо – тогда отложите надкушенный бутерброд, отодвиньте в сторону чашку кофе и давайте пробежимся по небольшому чек-листу, который я подготовил (оцените процессы в вашей команде по шкале от 1 до 10):
- понимание менеджментом процессов и методологии тестирования;
- понимание тестировщиками стоимости бага и приоритетов развития продукта;
- отношение разработки к тестировщикам и понимание их точки зрения;
- отношение QA к разработке и готовность учитывать их интересы;
- насколько метрики способствуют командной работе и дают обратную связь;
- общая синергия в команде.
Ответили? Если у вас по каждому пункту твёрдая 10, то можете закрывать вкладку
Чем это чревато
Вот есть команда, она худо-бедно (или хорошо и дорого) закрывает KPI, релизы идут в срок, багов не так уж и много. Периодически, конечно, возникают конфликты: кого-то увольняют, кто-то приходит новый со свежими силами и идеями, но у всех ведь так — это нормальный рабочий процесс. Зачем вообще что-то менять? Перегибы и косяки можно закрыть, например, расширением штата, эпизодической переработкой на выходных или выпустить пар на ретро. Но в долгосрочной перспективе тлеющие и неразрешенные конфликты без коренного изменения процессов и отношения к происходящему приводят к выгоранию сотрудников и увеличению убытков для компании.
Там, где раньше отделывались спорами в чате, со временем начинаются реальные конфликты и выяснения «кто виноват». Накапливается усталость. Это приводит к новым ошибкам, увеличению сроков доставки релизов на прод, нервотрепке, спешке и (в худшем случае) увольнениям. А для компании лавинообразно растет стоимость разработки, возникает необходимость в найме новых сотрудников и трате дополнительных ресурсов на их онбординг.
Там, где раньше отделывались спорами в чате, со временем начинаются реальные конфликты и выяснения «кто виноват». Накапливается усталость. Это приводит к новым ошибкам, увеличению сроков доставки релизов на прод, нервотрепке, спешке и (в худшем случае) увольнениям. А для компании лавинообразно растет стоимость разработки, возникает необходимость в найме новых сотрудников и трате дополнительных ресурсов на их онбординг.
Дальше я на примерах покажу известные причины конфликтов в триаде менеджер-разработчик-тестировщик с точки зрения QA. Надеюсь, вы пополните эту коллекцию эпик фейлами и историями успеха из вашего опыта в комментариях.
Зачем менеджеру разбираться в процессах тестирования (хотя бы на базовом уровне)
На что напоролись. На одной из прошлых работ я трудился под началом молодого менеджера с клиповым мышлением: парень делал в Jira эпики с user-stories, на основе которых нарезались задачи в разработку. А я их, соответственно, потом тестировал.
Задачи кодились долго, примерно столько же по времени тестировались. И каждый раз возникали конфликты — менеджер недоумевал, что я так долго делаю. У него был заложен (условно) один день на разработку + один час на прогон тестов по сценариям из user-stories. При этом понимания, что user-stories ≠ тест-кейсы и нужно ещё подготовить окружение, завести тестовых юзеров, написать тестовую документацию, проверить негативные сценарии и многое другое — у него не было.
Пользуясь админресурсом, менеджер потребовал сократить время на тестирования, а я согласился прогонять только основной сценарий. После чего на прод пролезло пару критичных багов. Конфликт ушел на новый виток с выяснениями, чья это ошибка.
Как можно было. Согласовать время на тестирование между всеми участниками заранее. Например, в моей команде на предыдущем проекте мы закладывали и оценивали примерное время на тестирование еще на первичном груминге задачи, где присутствовали на созвонах все заинтересованные стороны: продакты, разработчики и тестировщики. Это помогло, как минимум, адекватно заложить в сроки релиза время на тестирование.
А если по каким-то причинам столько времени на тестирование выделить нельзя, можно заранее проговорить возможные риски и зоны ответственности.
Зачем тестировщику понимать стоимость бага и приоритеты развития продукта
На что напоролся. На фрилансе я однажды тестировал поисковые формы для бронирования турпутевок. Их было примерно полсотни и они были установлены на сайтах многих туроператоров. Честно говоря, это была монотонная и скучная работа. И как-то раз, проверив новый дизайн для очередной (пятой за день) формы, я дал добро на релиз. После чего пошел шквал звонков с претензиями от разгневанных клиентов.
Чего я не знал и не учел, так это того, что это была основная форма, установленная у большинства туроператоров. И того, что менеджеры туроператоров заходили на свои сайты в Internet Explorer, а не в Chrome или Firefox, где все работало. В итоге, меня и разработчика оштрафовали, а компания потеряла несколько заказчиков.
Как можно было. Нет, я не стал сторонником конских штрафов: стоимость пропущенных багов не нужно вычитать из зарплаты (если только вы не решили угробить команду). Но с тех пор я уверен — у QA должно быть четкое понимание того, скольких пользователей заденет ошибка в функционале и к каким репутационным потерям для компании она может привести. Например, для QA-гильдии Skyeng информация о стоимости пропущенных багов является открытой и общедоступной. Кроме того, в моей группе разработки продакт регулярно публикует сводку о количестве клиентов и динамику платежей можно наблюдать в реальном времени.
Лично мне это здорово добавляет чувство ответственности и мотивирует работать лучше, когда ты понимаешь, что тестируешь не «вон ту фиговину, которую надо проверить до обеда», а функционал, который потом понадобится большому числу людей, из платежей которых формируется и твоя зарплата. А еще не хочется подводить всех этих классных ребят, которые постарались, потратили время на подготовку и презентации, рассказывая нам (линейным QA) на общих созвонах, куда мы движемся и почему это нужно и важно.
Зачем разработчику понимать точку зрения тестировщиков
Здесь я хочу поговорить о двух вещах: взаимоуважении и конфликте интересов.
Плохой пример, где неправы оба. Как-то мне «повезло» работать в паре с джуном, только что распустившимся с интернет-курсов типа «Сделаем из вас элитных PHP-разработчиков с нуля до лида за полгода». Общение не задалось сразу же. Товарищ искренне верил, что «QA — это такие monkey-тестеры», заменить которых может любой человек с улицы. А я не видел смысла что-то ему доказывать и просто заваливал его багами и reject-ами по поводу и без. В итоге, вместо того, чтобы работать сообща над задачей, мы большую часть времени проводили в бесконечных спорах в тредах.
Хороший пример. В конце 2020-го года наша команда сдавала крупный многолетний проект. Для усиления нам добавили на четвертый квартал двух тестировщиков на полставки. На одном из первых совместных созвонов расширенной команды QA-Dev после демо новая тестировщица сразу провела небольшую самопрезентацию, рассказав, на чем и как она писала код в своей предыдущей команде. Это сразу задало планку профессионального общения и сформировало уважительное отношение к новичкам.
Как можно улучшить. Сложно дружить и делать общее дело с человеком, когда у вас разные цели: грубо, когда у одного цель создать, а у другого — найти недостатки. Как-то раз я побывал «на другой стороне баррикад» — делал сборки модов для разных игр, а форумчане накидывали мне багов и негатива. Сказать «спасибо» им не хотелось, вот поверьте. С тех пор отлично понимаю: у разработчика голова кругом — он рефакторит, пишет unit-тесты, а потом (возможно) помогает QA с автотестами, деплоем, БД и ещё кучей вопросов. И если тестировщик просто возвращает задачу и разве что радостно не тычет носом в найденные баги — это не самые приятные ощущения.
Помните, что у вас есть общие точки соприкосновения и профессиональные интересы: QAA найдет, о чем поговорить с разработкой. Да и всегда можно обсудить доклад с конференции или статью с Хабра (можно мою).
Сразу задайте планку профессионального общения. Хорошо, когда разработчик и тестировщик примерно представляют уровень друг друга. Это позволяет адекватно оценивать ожидания и погасит часть претензий в зародыше.
А еще, ребята из разработки, если вы думаете, как тот джун
Поймите, что тестировщик – это не враг, а еще одна линия обороны, человек, благодаря которому у вас есть право на ошибку.
Зачем QA учитывать интересы разработки
Взглянем на предыдущий пункт – но уже с точки зрения тестировщика.
Поучительный (и печальный) пример. Я рос в профессиональном плане и находил всё больше багов. Ведь я читал на Хабре умные статьи по тест-дизайну, осваивал API, различные методы и виды тестирования. Но всё больше моих репортов закрывали с пометками cancelled, declined, rejected…
Росла обида. Я стараюсь, нахожу новые (иногда – откровенно упоротые) сценарии проверок, ломающие сайт, а всё даром. Эти баги никто чинить не собирается. Желание причинять добро и наносить радость разработчикам сменилось ощущением, что тестировщик – это такой Геракл нового времени, разгребающий авгиевы конюшни, куда разработка постоянно накидывает дурнопахнущую субстанцию. Закончилось естественно тем, что я вскоре расстался с той компанией.
Как можно было. Вскоре у меня состоялся разговор с хорошей подругой-психологом, которая подкинула интересную идею: именно ошибки разработчиков обеспечивают меня работой и дают почувствовать свою востребованность как специалиста.
После этого моё отношение к коллегам кардинально поменялось с позиции «я Дартаньян, а вы все — не очень», на «О, дружище, ты снова задачу с багами сделал — спасибо! Теперь моя эффективность видна наглядно». И рабочие отношения на новом месте сложились у меня по совершенно другому сценарию, основанному на взаимовыручке и уважении.
Почему нам всем важны правильные метрики
Знаю-знаю, что у многих «аллергия» на слова вроде «KPI» и «метрики».
Пример, как метрики могут стать яблоком раздора, которое похоронит отличную команду. Как-то я работал в госконторе. У нас была сработавшаяся команда: QA-лид беспокоилась о профессиональном росте своих подопечных и следила за настроениями в коллективе, а большинство разработчиков были профессионалами своего дела. Но затем у нас начали собирать отчёты и статистику по сделанным задачам, найденным и пропущенным багам.
Я был не в курсе точной формулы KPI для разработчиков, но понял, что она была каким-то образом завязана на количество найденных нами багов, а точнее, их отсутствия. Из-за этого попытка завести в баг-трекер новый дефект оборачивалась форменным цирком: полдня мы спорили о том, баг это или фича. В итоге разработчики предлагали заводить это не багами, а отдельными задачами на доработку или писали в личку, что не надо ничего делать – они сейчас быстренько хотфикс накатят. Ну, пока никто не заметил. Некоторые и вовсе задним числом меняли тип задачи с bug на improvement.
Это портило рабочую атмосферу и отнимало много времени и сил на бессмысленные споры. Страдали сроки, копилась усталость и раздражение. Предложения от HR на хэдхантере казались все более интересными. Так я и ушел с той работы. И так поступили многие.
Как можно было. Прежде чем внедрять ту или иную метрику или KPI в компании, стоит задаться вопросами: «Как она повлияет на командную работу и улучшит ли межкомандное взаимодействие?». Иногда хорошая теоретическая идея на практике превращает сплоченную команду в два враждующих лагеря.
Но в то же время я верю, что есть варианты, помогающие оценивать качество работы и уровень коллег. В Skyeng сейчас применяется метод оценки 360 градусов, когда сотруднику дают обратную связь со всех сторон: коллеги, лид, подчинённые (если есть), а также ты сам себя оцениваешь. Так можно получить объективную картину своих компетенций, сильных и слабых сторон, зон роста. После оценки строится PDP — персональный план развития, в который закладывают софт и хард скиллы и какими инструментами их укреплять, чтобы в следующий раз получить оценку на следующий грейд.
Короче, чтобы не было конфликтов, нам нужна синергия
Немного красивой теории: команда с хорошо отлаженным рабочим процессом, едиными ценностями и общей целью сможет достичь гораздо большего, чем просто сумма сотрудников, выполняющих такие же задачи. Вопрос практического толка – как этого достичь? Расскажу, что сработало в моей нынешней команде.
Не так давно мы выполняли большой межкомандный проект по интеграции нашего продукта в общую школу. Проблема была в том, что внутри команды мы до этого руководствовались гибкими принципами Kanban, а общие задачи нужно было делать по спринтам с жестко фиксированными дедлайнами. Поэтому нам пришлось перестроиться и несколько месяцев работать по Scrum.
После завершения межкомандного проекта мы вернулись к привычному формату работы. Не могу сказать за всех, но мне, уже втянувшемуся в спринтовые скачки, было сложно сходу перестроиться обратно. Здесь отлично сработало решение нашего лида – Артёма arasskosov Расскосова. В одну из пятниц мы вместо работы сели играть в Featureban в онлайне. Цель симуляции — разобраться, как использовать Kanban на командном уровне и напомнить базовые практики и метрики.
По механике игры все просто. Регистрируетесь командой на сайте, заходите. У вас есть набор условных тикетов на разработку, тестирование, дизайн. Вы распределяетесь по ролям и дальше решаете, что делать с тикетами — заниматься своими, помочь другому человеку. Смысл — наладить взаимодействие и координацию, чтобы без завалов, срывов сроков. В общем, войти в состояние Kanban-потока. Мне это отлично помогло заново втянуться в рабочий процесс именно внутри команды.
В общем, иногда полезно расслабиться. И, например, потратить пару часов рабочего времени на игру с отработкой командного взаимодействия. Проверено – работает.
На этом всё. Пожалуйста, рассказывайте про свои истории о конструктивных решениях рабочих конфликтов – для нашей общей пользы.
