Home

Автор: Немкович Николай Владимирович

Меня зовут Коля и я QA. Хочу поделиться, как эволюционировал из существа, которое профессионально пьет кровушку разработчиков, доводит до нервного срыва дизайнеров и систематически портит настроение менеджменту, до человека, который помогает выводить на рынок качественные и продуманные продукты, страхует разработчиков и облегчает планирование продактам.

Об истоках противостояния

Конечно, рано или поздно мы все набираемся опыта, вырастаем из «коротких детских штанишек» эгоизма, предрассудков, стереотипов и начинаем работать сообща, помогая друг другу с профессиональным ростом и общими задачами. Но перед этим умудряемся набить энное количество шишек.

У меня эта трансформация заняла долгих пять лет. Я начинал путь в IT с глобальных модов и фриланса в геймдеве. Потом работал над несколькими проектами в сфере онлайн-образования, лекторием для МФТИ и, наконец, нашел свое место в Skyeng. За это время успел поругаться с одними работодателями, стать незаменимым сотрудником для других, снова станцевать танго на граблях и… Наконец, решил составить свой собственный топ известных мне проблем QA в компании и способов их решения.

Итак, давайте для начала определимся с тем, всё ли у вас хорошо с тестированием и насколько этот материал актуален для вас вообще. Согласны? Хорошо – тогда отложите надкушенный бутерброд, отодвиньте в сторону чашку кофе и давайте пробежимся по небольшому чек-листу, который я подготовил (оцените процессы в вашей команде по шкале от 1 до 10):

• понимание менеджментом процессов и методологии тестирования;
• понимание тестировщиками стоимости бага и приоритетов развития продукта;
• отношение разработки к тестировщикам и понимание их точки зрения;
• отношение QA к разработке и готовность учитывать их интересы;
• насколько метрики способствуют командной работе и дают обратную связь;
• общая синергия в команде.

Ответили? Если у вас по каждому пункту твёрдая 10, то можете закрывать вкладку и идти работать. Только предварительно напишите мне в личку, как вам это удается. Если же по ряду пунктов набрали меньше 10 – давайте разбираться.

Дальше я на примерах покажу известные причины конфликтов в триаде менеджер-разработчик-тестировщик с точки зрения 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-потока. Мне это отлично помогло заново втянуться в рабочий процесс именно внутри команды.

В общем, иногда полезно расслабиться. И, например, потратить пару часов рабочего времени на игру с отработкой командного взаимодействия. Проверено – работает.

На этом всё. Пожалуйста, рассказывайте про свои истории о конструктивных решениях рабочих конфликтов – для нашей общей пользы.

Обсудить в форуме