Рассказ о проблемах в тестировании на проекте или всегда ли виноват тестировщик

Молодцов Александр

Старший специалист по тестированию

Привет, Хабр! Я Александр Молодцов, старший специалист по тестированию в ГК «Юзтех».
В самом начале хотелось бы выделить одну важную мысль: ситуация, разобранная в статье, не является хрестоматийной – примеры решения проблем, которые в ней затронуты, являются лишь частными примерами, не более того.  Все имена вымышлены и совпадения случайны. 

Рассказ пойдёт об одном из моих старых проектов. В один из хороших летних дней ко мне пришёл запрос от моего руководителя: помочь разобраться с процессом тестирования на одном из моих «бывших» проектов. Первоначальные симптомы: в релиз начало попадать большое количество багов, сроки тестирования срывались и ещё что-то, чего я уже не помню. Важно в начале понимать, что необходимо было провести скрининг ситуации и выработать набор решений выявленных причин проблем. Да-да, именно причин, так как если тушить пожар, то нужно всегда начинать с источника огня. Пропущенные баги и упущенные сроки – это только видимая часть айсберга. 

Что касается самого проекта – это очень интересный объект для исследования. По сути это комплексный набор программных решений, который  в своём составе имеет мобильное приложение для iOS и Андроид устройств, веб-сайт с ограниченным функционалом для пользователя, а также несколько админок, реализованных в вебе. Не самый простой проект, но очень интересный. Одно время я мечтал на него попасть и задержаться на нём. Это просто клад для развития навыков начинающего тестировщика. Здесь тебе и фронт пощупать можно, и бек, и мобилки с разных сторон. Не проект, а мечта :) 

Но у любой мечты есть обратная сторона медали – различные процессы разработки, которые применяются при работе в команде. А команда не маленькая была на тот момент: 5 разработчиков на мобилки, 3 разработчика бека, 1 разработчик фронта + верстальщик, аналитик, проектный менеджер и один тестировщик на всё. Справедливости ради могу сказать, что проект сезонный, и такой состав в полном объёме работал именно в пик разработки. И вот на этот пик попал я как внешний сотрудник, который пришёл помочь тестировщику разобраться в узких местах тестирования на проекте. Именно помочь, так как на тот момент тестировщик, привлечённый на проект, был не очень опытный. Поделиться опытом было моей задачей.

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

С чего началась локализация проблем на проекте? Конечно же с дейликов. На ежедневных встречах можно всегда быстро влиться в проект, даже если ты не принимаешь участие в тестировании непосредственно. Меня привлекали к проекту не для того, чтобы я тестированием занимался. Поэтому именно с утренних встреч команды я начал своё небольшое расследование, а где же у нас действительно есть проблемы? Кто-то из команды рассказывал о бурной деятельности, у кого-то же не было задач. Но только не у тестирования: у нас проседала работа по выполнению ретеста багов текущего релиза, да ещё и нужно было регрессы запланированные на мобилках проводить да новые баг-репорты заводить.

На дейлик сходили. Что же дальше? А дальше пошли посмотреть на доску в баг-трекере. Сколько всего интересного там можно раскопать, правильно настраивая фильтры сортировки. Первоначально нужно было разобраться с нашими задачами и багами. В какую сторону решили копать? Так как задач много, а релиз не резиновый, то начали с приоритизации. Нужно было понять, что из текущего пула задач является более важным. Пока общался с тестировщиком, удалось выявить два следующих интересных фактора:

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

2. Второй момент – баги также линкуются к основной задаче, в рамках которой они были выявлены. Очень хорошая практика, часто её наблюдал на крупных проектах. Но только тогда она полезна, когда процессы передачи доработанных задач работают корректно, а не как на нашем проекте. Но об этом дальше)

Начнём с багов. При первоначальной оценке оказалось, что на нашем тестировщике висело много родительских задач в тестировании. Важных задач, крупных. Но при более детальной оценке выясняется, что не все прилинкованные задачи и баги закрыты. Часть из них висит на разработчиках. И получается, что закрыть задачу нельзя только потому, что не протестирована доработка, которая висит на разработчике. “Непорядок” — подумал я, “Это норма” - сказал тестировщик. В дальнейшем пошли к нашему ПМу с вопросами, когда будут доработки по родительским задачам. По итогу задачи из тестирования обратно ушли в этап разработки, с переназначением родительских задач на разработчиков. Негоже повозку везти, коли коня не впрягли в неё. Активное тестирование продукта нужно начинать тогда, когда закончен этап разработки. Да, писать тестовую документацию нужно на основе технической, но тестировать недоработанный продукт – ни в коем случае нельзя. У нас задачи минус, повеселевший тестировщик плюс – поехали дальше.

После разбора завалов был выявлен скоуп задач, которые были не сложны в разработке, часть была переведена в тестирование, но при этом они почему-то уже висели 2 спринта. В чём проблема, спросите вы? А вот и не догадаетесь) При тщательных расспросах тестировщика выяснилось, что у них недавно был редизайн. И как раз из-за него стало непонятно, что с этими задачами делать. Опять пошли к ПМу для актуализации этих задач. По итогу большую часть закрыли ввиду неактуальности, поставили основную родительскую задачу на тестирование редизайна (или она уже была, точно сказать не могу) и оставшиеся задачи отправили в неё. Снова задачи минус. Замечу, что ничего сверхъестественного мы снова не сделали, просто сухо подошли к своей работе.

Не могу не упомянуть про моё любимое на проекте при передаче его от одного тестировщика другому. Я называю это «наследством китайского императора». Старые задачи, которые так и остались висеть на других тестировщиках, но не переназначенные на текущего. И наш проект не стал исключением. За проектом я следил, и кто на нём работал в определённые периоды - тоже знал. У ПМа эти задачи тоже были видны. А вот у моего тестировщика не хватило сноровки и времени, чтобы поковыряться в этом наследии проекта. Тоже потратили какое-то время, чтобы проанализировать эти задачи. Часть из них закрыли как дубликаты, часть быстро протестировали и закрыли, а часть из-за редизайна стала неактуальной. Обожаю редизайн за такой карт-бланш! Главное им сильно не увлекаться. А то все огрехи можно будет на него списать.

Ну вот мы оценили задачи, разгребли старый хлам из наших чуланов и по итогу увидели реальную картину всего бедствия. Кроме задач из актуального спринта над нами навис призрак регрессов на мобилках и вебе, который съедал довольно большое количество рабочего времени. Нагрузка была оценена объективно и никак не радовала ни тестировщика, ни проектного менеджера. В нашем случае было принято очень простое стратегическое решение - привлечение новых членов команды тестирования на период около 1 месяца для помощи в стабилизации релиза. В команду взяли сотрудников текущего уровня тестировщика. Это помогло передать регрессы по мобилкам и текущие мелкие задачи новым членам команды, а более серьёзные задачи забрать в тестирование основному тестировщику проекта.

И самое важное, что хотелось бы отметить при работе на любом проекте – никогда не молчите, если видите различные проблемы как в самом продукте, так и в проекте в целом. Если увеличивается нагрузка, то нужно трезво оценивать свои силы и вовремя сообщать об этом команде. Увы, на проекте получилось так, что тестировщик не вовремя подсветил команде, что нагрузка увеличилась довольно сильно, некоторые процессы по работе с задачами нарушились, ну и ещё что-то по мелочи. Всё это скопилось на большой снежный ком, который по итогу удалось разгрести, но не без труда и с привлечением более опытного сотрудника.

Давайте перейдём к кратким выводам:

• Важно проводить первоначальное планирование по задачам текущего релиза. Всегда есть срочные задачи, которые даже делегировать не получится. Напротив, при грамотном планировании может выясниться, что часть задач даже не нужно выполнять, а можно закрыть ввиду их неактуальности. Редизайн проекта - яркое тому подтверждение.

• Если вижу баги от прошлого тестировщика - обязательно либо отрабатываю, либо закрываю их. Негоже балласту болтаться между спринтами. Смотрим внимательно прошлый пункт – часть из них может быть неактуальной ввиду определённых причин.

• Редизайн - очень важный этап в жизни любого приложения. Сразу вспоминаю абстрактную гиперболизированную ситуацию, когда просто перекрасили кнопочку, а блокируется работа всего приложения. Нужно обязательно ставить основную родительскую задачу на тестирование, при этом линкуя найденные баги. Это поможет нам не упустить все недочёты вёрстки приложения и оптимизировать работу.

• Важно проводить анализ текущих задач на принцип тестируемости в текущей версии продукта. Нельзя брать в тестирование то, что не до конца разработано. Времени затрачивается не так много, но польза при этом колоссальна. Это поможет не только вам, но и проектному менеджеру трезво оценить нагрузку на команду тестирования в частности, и на всю команду разработки в целом. Ведь именно тестировщик может рассказать не только о качестве разрабатываемого продукта, но и о качестве процессов внутри команды.

• Объём работы должен соответствовать команде. При большом объёме работы и грамотной оценке трудозатрат важно привлекать дополнительные силы. Конечно, только при одобрении проектной команды. Из воздуха по щелчку пальцев помощь не придёт. 

• Не молчим о проблемах. Важно подсвечивать проблемы команде и не стесняться говорить о текущей ситуации на проекте, в том числе и про процессы тестирования. Никогда не молчите о проблемах на проекте. Чем раньше команда о них узнает, тем быстрее сможет стабилизировать свои процессы. Это как с этапами выявления багов - дешевле всего устранить их на этапе написания документации, чем устранять последствия разработки по некорректной постановке.

И в качестве заключения хочу сказать, что если системно подходить к решению проблем, то всегда можно прийти к хорошему результату. В итоге мы стабилизировали работу команды тестирования и улучшили качество релизов. Напомню, что ситуация, разобранная в моём докладе, не является хрестоматийной – примеры решения проблем, которые в нём затронуты, являются лишь частными примерами, не более того. Но, когда в процессах тестирования происходят сбои, нужно обязательно задавать вопрос: «Всегда ли виноват тестировщик?» Может стоит попробовать копнуть немного глубже?