Привет, Хабр. На прошедшей 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. Всем осознанности!

Комментарии (11)


  1. Daemonis
    01.06.2018 17:23
    +6

    Вот он, кровавый капитализм — пусть за вас тестируют пользователи, все равно они никуда не денутся :)


    1. Alozar
      01.06.2018 17:49

      Причём здесь кровавый капитализм?
      Насколько я понял статью после прочитки по диагонали, Антон Олиевский поднимает довольно щепитильный в некоторых кругах вопрос: «А нужно ли тратить гигантское количество времени (а следовательно и денег), чтобы найти вообще все баги, если от одного МЕЛКОГО бага урона не будет?»


      1. Daemonis
        01.06.2018 17:55
        +2

        «Причём здесь кровавый капитализм?»
        Ну, во-первых, там смайл. Во-вторых, капитализм там при том, что компания экономит деньги на тестировании, по сути, перекладывая его на плечи пользователей.

        «нужно ли тратить гигантское количество времени (а следовательно и денег), чтобы найти вообще все баги, если от одного МЕЛКОГО бага урона не будет?»
        Вообще-то, нет. В конце концов они перестали тестировать фичи вообще, типа как-то работает, ну и ладно.


        1. Alozar
          01.06.2018 18:01

          Сейчас прочитал подробнее… вы правы, тестируют только критичные функции.
          В таком случае, чтобы давать оценку таком решению, нужно знать статистику о количестве багов в новых фичах, может их действительно очень мало и связаны они с очень специфическими ситуациями у пользователя.
          В любом случае обе крайности «Нафиг тесты» и «Тестируем даже функцию c одним return 1;» плохи, везде нужен баланс.


  1. xakepmega
    01.06.2018 17:45
    +1

    на хорошее.it его


    1. BSW
      02.06.2018 22:08

      Хм, спасибо, интересный взгляд на IT индустрию изнутри.


  1. knstqq
    01.06.2018 20:24

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


    1. matvey_travkin Автор
      01.06.2018 20:43

      А так куча негативных эмоций становится меньше?


      1. knstqq
        01.06.2018 20:48

        Если рассмотреть гипотетическую ситуацию, в которой компания требует полный цикл тестирования на каждую небольшую фичу, не умеет оптимизировать процесс тестирования и автоматизировать тестирование — то тестирование для этой компании зло: приносит мало пользы, но потребляет много ресурсов. Насколько я понял, в этой компании именно такая ситуация. И здорово, что они осознали это, озаботились тем, чтобы решить эту проблему, выделить критичные направления и всё ещё тестируют (основные user-case) для минорных фич. Да, меньше становится негативных эмоций.
        Освободившиеся ресурсы они теперь могут направить на автоматизацию тестирования, например, и в итоге будут тестировать в перспективе качественнее, чем до «отказа от тестирования» и меньшими ресурсами.


  1. Bazis007
    02.06.2018 22:08

    Что имеем в итоге: «Продакт Дима совсем перестал заходить к Антону.»

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


  1. Nordosten
    02.06.2018 22:29

    История полна фейспалмов. В книжках не написано, что тестировать надо всё — это называется exhaustive testing. И надо быть полным дятлом чтобы фиксить абсолютно все баги. 60 багов/задач ожидающие проверки? Вы бы лучше больше функционала автоматизировали и наняли больше QA. А вместо того, чтобы релизить как вы называете хотфиксы каждый день стоит лучше планировать. Про стоимость исправления ошибки на разных этапах разработки я вообще молчу — тут наглядно видно http://www.karlgroves.com/wp-content/uploads/2016/01/boehm-curve.jpg