Привет, Хабр. На прошедшей BackendConf Антон Олиевский, наш руководитель отдела тестирования и контроля качества программного обеспечения, рассказал про самое, пожалуй, важное — осознанное отношение к работе.

Дело вот в чём. Скорость реализации бизнес-идей стала ключевым фактором. Эту скорость в SJ оценивают средним временем прохода задачи. В компании это время было равно 65 дням. Да, 2 месяца от создания задачи до её отправки пользователю.

Антон говорит, что им удалось ускорить процессы в 3 раза благодаря осознанному тестированию. Сейчас расскажем, что это такое и как именно.

Как было раньше?

Процесс был такой:

• 5 тестировщиков на 40 разработчиков;

• Каждая задача тестируется отдельно;

• Готовые задачи сливаются в релизную ветку;

• На релизе проводится приемочное тестирование;
  Затем интеграционное.
  

При успешном исходе релиз отправлялся пользователям, а на доске постоянно висели 50-60 задач, ожидающие тестирования.

Как работали с задачей:

• Из разработки задача приходила в тестирование и терялась в бездонном списке других ожидающих;

• В списке она могла провисеть от пары дней до месяца;

• Затем задача проверялась тестировщиком, по ней заводились баги и она отправлялась обратно в разработку;

• Программист фиксил баги и возвращал задачу снова на тест.

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

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

Почему нет?

Потому что надо не баги фиксить, а помогать бизнесу, поэтому Антон пошёл к продакту Диме, чтобы разобраться с ситуацией. Там они порешали, что главное — скорость выпуска фич. Дело в том, что бизнесу не нравится терять деньги на разработку и фиксы проектов, которые непонятно, принесут ли пользу. Поэтому лучше выпустить неидеальный проект и по итогам его успешности решить, доводить его до идеала или сворачивать. Тестировщики собрались и попытались понять, как увеличить скорость выпуска. Оказалось, всё очевидно.

В SJ есть приёмочное (набор кейсов по главным областям функционала, для проверки продукта в целом, например, авторизация пользователя, размещение вакансии и т.д), которое состоит из 150 кейсов и занимает 1,5 дня тестировщика. Это слишком долго.

Серьёзно, это примерно 1,5 дня ручных проверок 2 раза в неделю. А что нужно делать с повторяющимися ручными проверками? Автоматизировать.

Автоматизировать получилось 100 кейсов. Не покрытыми остались невыгодные для автоматизации кейсы по шарингам, по рассылке писем, получению СМС. Тестировщики были в восторге, так как стало меньше регулярных затрат на тестирование релизов — 3 часа, вместо 1,5 дней. Во-вторых, автотесты дают быструю обратную связь, стоит ли вообще начинать смотреть релиз и позволяют отлавливать баги ещё до попадания задачи в релиз.
Почти всё порешали, но потом пришёл CTO.

Что ещё не так?

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

Что с интеграционным. Короче, была ситуация, когда отправили релиз и прибежал продакт Дима возмущаться тем, что на бой не приехала задача, которую они пообещали. Стали разбираться, куда она подевалась. Оказалось, что при смерживании задач в релизную ветку какой-то коммит затерялся и задача визуально пропала для пользователей.

Девопсы стали фиксить скрипты сборки, а тестировщики перепроверять на релизе кейсы на каждую задачу, чтобы убедиться, что все собралось успешно и все задачи на месте. Вроде бы, что сложного в том, чтобы проверить задачи, которые уже посмотрел. Но получилось, что примерно 5 задач каждого тестировщика в релизе, а ещё попадаются сложные кейсы, типа изменить что-то в базке, запустить скрипт, проверить полученное письмо. Весь этот этап занимал много времени: от 2 до 10 часов работы всех тестировщиков.

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

Теперь ок?

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

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

А все знают, что если в разработку приходит Дима, то жди срочняка. Такие набеги порядком надоели девопсам и тестировщикам. Это ли не повод снова пойти в переговорку?! Заперлись там все вместе и порешали, что бизнесу нужно релизиться чаще, поэтому нужно автоматизироваться ещё больше, проверять релиз за три часа, автоматизировать ежедневную сборку релиза и настроить на релизе запуск автотестов и проводить приёмочное каждый день.

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

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

И как оно?

Экономия времени —12 часов в неделю для проверки новых задач, меньше демотивации на однообразных проверках. Из минусов — баги могут жить до 5 дней со дня появления. Многое было успешно сделано для ускорения, но при этом ребята слабо повлияли на самое главное — среднее время прохода задачи на продакшн.

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

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

Остались только непосредственно связанные с деньгами пункты и критичные вещи для пользователей.

Короче, из списка в 300 пунктов осталось лишь 50.

С этим уже можно работать. Кстати, какие бонусы даёт разработка веба?

• Возможность быстрого реагирования на баги, обнаруженные на бою;

• Онлайн-мониторинги проблем;

• Техническая поддержка на связи с пользователями.

Теперь самое важное. Да, книжки по тестированию учат всё проверять, но все обстоятельства говорили Антону о том, что тестировать нужно далеко не всё. Как говорит Антон, эти три дня раздумий он ощущал себя Гамлетом со своим вопросом «Быть или не быть».

Собрав всю волю в кулак, он решил, что быть. И отказался от тестирования неважного функционала. Тестировщики стали вливать задачи по тем 250 пунктам после разработки сразу в релиз. Серьёзно.

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

Отказ от тестирования — ответственный и опасных шаг.

Если хотите также, нужно сделать вот что:

• Список критичного функционала общедоступным, чтобы разработчики могли к нему обращаться;

• Для оценки нового подхода добавить в Jira связь «порождён в => породил». Так можно отслеживать, много ли багов проходит в нетестируемых задачах;

• Так как не тестировать большую часть задач дико стрёмно— проверять в них пару основных кейсов, но уже в релизе, чтобы не тормозить выливку;

• Критичный функционал тестировать по старой схеме.

Что изменится?

• Большинство задач перестанут буксовать на этапе тестирования;

• Тестировщики займутся только важными для бизнеса задачами;

• Важное быстрее берётся в тестирование, так как неважное теперь не мешается на доске.

Что плохого?

• Реальные пользователи чаще сталкиваются с мелкими ошибками;

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

Было больно?

Все описанные шаги ребята выполнили в течение полугода. Да, было больно, но на выходе получились такие результаты:

Среднее время прохода задачи сократилось до 19 дней и оно постоянно уменьшается;
Поток задач на тестирование снижается. Тестировщики начали готовиться к тестированию важных фич параллельно с разработкой;
Продакт Дима совсем перестал заходить к Антону.

Вместо выводов

Не применяйте наш подход в медицине и самолетостроении. В ситуациях, которые не связаны с риском для жизни — тестируйте свои решения и подходы.

Не верьте книжкам и перестаньте тестировать ради тестирования, просто потому, что так где-то написано.

Спрашивайте себя, отвечаете ли вы ожиданиям бизнеса и действительно ли каждый пункт из списка ваших дел приносит реальную пользу.

С вами был SuperJob. Всем осознанности!