Привет! Меня зовут Таня, я куратор в SM Lab. В этом посте я расскажу вам о нашем пути оптимизации тестирования — узнаете, какие на нашем продукте были проблемы в процессах тестирования, как мы их решали, почему не надо отвлекать тестировщиков и в чём польза интуитивного тестирования.
Для того чтобы понять суть процессных изменений, нужно знать, как же мы работали до них.
Итак, основа.
У нас есть две доски в Jira. Первая отвечает непосредственно за релизные задачи и хотфиксы, вторая — за задачи сопровождения и инциденты. Рассмотрим подробнее первую доску с задачами и хотфиксами.
На ней есть три колонки, с которыми и работают тестировщики:
Проверка постановки
Очередь на тестирование
Сама задача в тестировании, над которой прямо сейчас работает тестировщик.
В сопровождении чуток попроще, там две колонки:
Очередь на тестирование
Задачи, взятые в тестирование.
Вроде бы, всё понятно и доступно. А теперь представьте такую ситуацию. На Первой релизной доске в очереди на тестирование — 4 задачи (1 хотфикс и 3 релизных), в проверке постановки висит ещё одна задача, а на Второй доске сопровождения — прилетает одна. Тестировщик берет в работу первую попавшуюся задачу.
А потом оказывается, что задача, которую он взял, была не такой уж и срочной, могла бы себе спокойно подождать. Проверка Постановки горит, надо срочно выпускать хотфиксы, двигать дальше постановку. Что делает тестировщик? Бросает задачу, которую делал, берет в работу супер-критичную, тестит её, в это время (ну а как иначе) ему прилетают ещё какие-то критичные задачи. В итоге к своей первой задаче он возвращается лишь спустя какое-то время.
И получается, что эту бедную задачу начинают тестировать с нуля — надо заново «въезжать» в неё, перечитать, погрузиться в контекст, вспомнить, что уже потестил, а что — только планировал. В общем, проще заново начать.
Ситуация печальная, такого хотелось бы избегать. Поэтому мы решили использовать приоритизацию задач.
Как у нас всё работает
Вот как мы расставили приоритеты.
Первый — всегда задачи с доски сопровождения + хотфиксовые задачи. Тут всё понятно — такие задачи быстро катятся на прод, чтобы исправить какой-то баг или дополнить функции.
Второй — задачи текущего релиза. Помимо прочего, текущий релиз у нас еще и делится на проверку постановки, и непосредственно сами задачи в тестировании.
Проверка постановки у нас стоит первым приоритетом, так как если ты не двинешь быстрее задачу в работу, то она, в принципе, до тестирования и не дойдет. Ещё у нас учитываются переоценки важности задач в том или ином сегменте.
Приоритизация привела к тому, что истории с бросанием и откладыванием тех или иных задач в разы уменьшились. Понятное дело, что всегда есть какие-то редкие случаи, когда действительно нужно что-то экстренно протестить, мы же не с розовыми единорогами живём. Но в целом мы наладили систематизацию того, как мы берем эти задачи, что позволило нам неплохо сэкономить время.
По итогу, мы вроде бы приоритизировали, все прекрасно, даже процесс начал налаживаться. Но смотришь на доску — и понятно, что ничего не понятно.
Задачи вроде двигаются, но не так, как хотелось бы.
Когда мы копнули глубже, то поняли, что на самом деле есть еще очень много отвлечений.
Наш продукт взаимодействует с огромным количеством команд, и к нам очень часто поступают запросы на создание каких-то дополнительных тестовых данных, просят помочь потестировать, где-то что-то подчеркнуть, написать, перепроверить. Увы, вся эта история раньше проходила мимоходом, где-то внутри, в чатиках. кажется мелочью, но в действительности порой на это тратилось около половины дня рабочего дня.
Что мы с этим сделали
Мы ввели регламент постановки задач на тестирование от смежных команд.
Что вообще в принципе это значит и к чему ведет?
Теперь все запросы на какое-то глобальное или комплексное тестирование (а не мелочь) идут через PL. То есть все ребята приходят с запросом, мол, нам нужна помощь вот в этих штуках. Затем PL создаёт задачу и приоритезирует её. Дальше она ставится на меня, и я уже раскидываю с условием наличия задачи и этого приоритета в тот или иной интервал, в который нам необходимо эту задачу закрыть.
Поработали так и выяснили забавную вещь — около 50 процентов задач были не особо срочными и не сильно важными :) Они смело ждали и день, и два, так что можно было сидеть и спокойно делать свои задачи, не отвлекаясь на «срочные» в чатиках и личных переписках.
Ещё нам помог пересмотр нашего отношения к багам. Теперь все баги, которые мы находим, мы заводим. Раньше кто-то где-то с кем-то что-то обсуждал, это в кулуарах решалось, фиксилось и все продвигалось. А теперь у нас есть чёткое правило — всё, что мы находим, всё фиксируем.
Почему это важно? Допустим, где-то в кулуарах с разработчиком вы решили, что этот баг исправлять не будете. А потом другой тестировщик столкнется с этой же проблемой, пойдет снова в кулуарах решать, что мы это не будем фиксить. А так как команда у нас немаленькая, то подобный круговорот мог происходить чаще, чем хотелось бы. Поэтому мы всё заводим и отображаем на доске — Jira помнит всё, и в случае чего через поиск можно найти какой-то баг и посмотреть, что с ним решили делать. Или не делать.
Написание тест-кейсов
После того как мы более или менее наладили процесс приоритизации, тестирования, мы поняли, что на самом деле отчасти у нас остается время на покрытие документацией. Раньше у нас тест-кейсы мануально писались, но очень-очень редко.
Сейчас мы покрываем мануальным тест-кейсами все задачи в потоке. Порядка 80 процентов всех задач в спринте мы успеваем покрыть. Естественно, бывают какие-то задержки, тогда это просто переносится в следующий спринт как техдолг, но в любом случае мы покрываем всё.
Прежде чем начать всё покрывать, мы для себя продумали план того, как вообще мы будем с этим работать и что и где мы будем писать. Это правда важно для больших команд, иначе вы всё будете писать в формате «кто в лес, кто по дрова».
Во-первых, будет нечитабельно, непонятно, нет структуры, нет понимания того, что мы ждем на выходе и с чем мы это будем есть. Поэтому первое, что мы сделали — определили то, как мы в принципе будем писать эти тест-кейсы.
Как пример, мы используем теги и issue link: в тегах мы всегда указываем номер задачи, positive или negative тест-кейс, есть если интеграция, то еще и указываем тег интеграция. И непосредственно линк на сам таск, к которому писалась данная документация, данный тест-кейс.
Теги и issue link помогают в работе — очень удобно открыть саму задачу в Jira. Мы привыкли, нам так удобно, для себя мы определили данный формат и в принципе успешно его используем.
К чему это привело?
Да, сейчас у нас три разных модуля, но при этом написание всех тест-кейсов у нас выглядит единым цельным продуктом, то есть единым цельным компонентом, который описан именно так, как мы и договаривались. Помимо прочего, мы определились с жизненным циклом тестового кейса, вообще, а как с ним работать и что с ним делать.
Использование статусов
Статус draft, наверное, для всех понятен: это тест-кейс в процессе написания, или он устарел, в общем, тест еще не готов к запуску.
Следующий статус — review.
Мы ввели следующую практику — у нас ревьюятся абсолютно все написанные мануальные тест-кейсы. Мы сделали отдельный чатик в Teams, где все тестировщики по мере тестирования своих задач скидывают линк на задачу и линк на тест-кейсы к ней.
Дальше ревьюятся тест-кейсы. Если все хорошо и никаких проблем нет, то ревьюер переносит этот статус из review в active, что говорит о том, что кейс полностью готов, запускается, рабочий и вообще всё круто.
Если ревьюер находит какие-то недочеты или еще что-то, то есть он у нас в канале пишет те или иные замечания. Затем мы просто их обсуждаем, кейс остается в статусе review до того момента, пока все замечания не будут исправлены. После этого он повторно в чатике отправляется на ревью, и уже если все хорошо, он опять же переходит в статус active, и его можно с ним работать.
Четвертый наш статус — outdated. Это очень-очень редкий статус, который используется только в тех случаях, когда тест-кейс устарел. Это, к примеру, выпилена функциональность, и больше он никогда не будет использоваться.
Что тут важно заметить — с active всегда можно уйти обратно в draft. Потому что есть кейс, который необходимо обновить в силу изменения той или иной функциональности, и он, в принципе, возвращается в draft и идет по стандартной цепочке. Точно так же, как через review и обратно в active.
Проверка постановки
После того как мы систематизировали процесс тестирования, приоритизацию и написание тест-кейсов, мы поняли, что есть еще одна проблема — с постановками задач.
Если конкретнее, проблема в том, что очень часто приходится разбираться, что где-то чего-то не хватает, и смотреть дополнительные источники.
Обращу ваше внимание на то, что у нас в постановках сейчас обязательно написание кейсов. Но это не ситуация, когда аналитик сидит и пишет все тест-кейсы, которые нужны при тестировании, а тестировщик просто по ним проходится. Нет, мы описываем только бизнес-кейс и юзер-кейс, то есть кейс, по которому в дальнейшем будет происходить непосредственная приемка самой задачи. Стараемся делать это во всех задачах. Естественно, бывают и откровенно минорные задачи — переименовать что-то и подобное. Тут, наверное, будет глупо писать какой-то бизнес-кейс. Поэтому стараемся, чтобы было во всех задачах, но пока есть не везде.
В чем плюс этой истории?
На первых этапах аналитикам на самом деле намного сложнее, потому что им приходится подумать и потратить побольше времени на написание этого кейса. Понятное дело, не все хотят брать на себя больше работы.
Но профитов тут намного больше.
Во-первых, когда аналитик пишет постановку и описывает кейс о приемке, он все-таки смотрит более обширно и, возможно, что-то вспоминает, что могли бы и не учесть.
Во-вторых, это очень сильно помогает при тестировании, потому что мы точно знаем, что есть базовый кейс, что вообще хочет бизнес и как должны работать нужные функции. Дальше от этого базового теста можно отталкиваться и проверять все возможные вариации.
Есть ещё и третья, не менее важная проблема. За 3 дня до релиза аналитики приступают к приемке задач.
А теперь представьте себе ситуацию, когда аналитик составил постановку полтора месяца назад. За эти полтора месяца через аналитика успело пройти 20+ задач, он уже что-то другое анализирует, и вот к нему наконец пришла эта задача на приемку. И он заново читает все критерии приёмки, вспоминает, чего тут вообще делать надо было и зачем. Это плохая история, потому что тратит время впустую.
Хорошая же история — когда уже написан как раз-таки тот самый кейс, где аналитик знает, что и как должно быть. То есть по факту так аналитики активно упрощают жизнь, в том числе — самим себе. Да, сначала это незаметно, но потом это играет важную роль.
С требованиями мы определились, они стали чище, и на тестировании полегче стало, потому что теперь есть, от чего отталкиваться.
Автоматизированное тестирование
У нас три автоматизатора на проекте, и каждый день у нас приходит отчет о результатах выполнения тестов — сколько тестов прошло, сколько упало, ну и вся остальная информация.
Представим ситуацию — пришёл отчёт, допустим, упало 20 кейсов. Все ребята увидели, все побежали экстренно чинить и разбираться с этим. Всё классно, всё починили, только на это потратили х3 времени. История плохая на самом деле, потому что вроде бы все хорошо и теперь там ноль упавших тестов, но потратили на это столько, сколько не надо было.
Что мы решили сделать?
У нас теперь есть календарь, который отвечает за то, кто у нас сегодня ответственный за отчетность. Отчетность в этом случае — это как раз-таки отчетность по пройденным тестам, либо упавшим, но лучше говорить пройденным.
Так вот у нас расставлено дежурство. Дежурство у нас понедельное. Каждую неделю ребята смотрят все упавшие тесты. Если есть какие-то упавшие тесты (помним, что у продукта три модуля), то смотрим, к какому именно модулю они упали. Ответственный за отчетность распределяет упавшие тесты на ответственного за тот или иной модуль.
В чем профит?
Что теперь одновременно все не бегут и не бросаются чинить всё, что есть. Время тратится меньше, распределение планомерное, да и более логично.
Регрессионное тестирование
За регрессионное тестирование у нас отвечает автоматизация. Поэтому как таковое мануальное регрессионное тестирование мы не проводим.
Но у нас есть ad-hoc тестирование — это свободное, интуитивно импровизированное тестирование. Ad-hoc тестирование мы проводим только на UI, на самом десктопном приложении. Это полностью неформальный подход. Для него не требуется никаких тест-кейсов, сценариев, чек-листов или чего-либо еще. Тут по факту тестировщик полностью импровизирует и опирается на свою интуицию.
Цели данного тестирования — найти критические проблемы до момента выпуска, найти какие-то краши приложения, какие-то хитрые дефекты, которые нельзя найти, используя стандартный сценарий проверок.
Вот как у нас всё устроено.
За несколько дней до начала ad-hoc тестирования (оно проводится за один день до релиза) я анализирую абсолютно все задачи, которые у нас были на протяжении спринта, и составляю какие-то n-ные отправные точки, в зависимости от того, что и где у нас было изменено с точки зрения UI.
Пишу эти все отправные точки в задачи, завожу ее, и в день X ребята, отталкиваясь от своего модуля (у нас на ad-hoc тестировании есть и мануальные тестировщики, и автоматизаторы) уже идут, куда им вздумается.
Если говорить о пользе такого подхода — пока мы собираем результаты, ad-hoc тестирования у нас применяются пока что 4 спринта, по которым мы, так сказать, собрали все сливки, поэтому было действительно достаточно большое количество багов в каждом прогоне. Но в целом сейчас это порядка 7-8 дефектов за день. Из которых, конечно, не все критичные и важные, и мы не чиним их в ту же секунду.
Но, подведя итог, это действительно хорошо помогает нам «подчистить» приложение и выявить критикалы.