Тестировщики против тестирования

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

    SuperJob.ru

    75,77

    Интернет-сервис для поиска работы

    Поделиться публикацией

    Похожие публикации

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

          «нужно ли тратить гигантское количество времени (а следовательно и денег), чтобы найти вообще все баги, если от одного МЕЛКОГО бага урона не будет?»
          Вообще-то, нет. В конце концов они перестали тестировать фичи вообще, типа как-то работает, ну и ладно.
            0
            Сейчас прочитал подробнее… вы правы, тестируют только критичные функции.
            В таком случае, чтобы давать оценку таком решению, нужно знать статистику о количестве багов в новых фичах, может их действительно очень мало и связаны они с очень специфическими ситуациями у пользователя.
            В любом случае обе крайности «Нафиг тесты» и «Тестируем даже функцию c одним return 1;» плохи, везде нужен баланс.
        +1
        на хорошее.it его
          0
          Хм, спасибо, интересный взгляд на IT индустрию изнутри.
          0
          переименуйте статью и измените вводную — очень хочется минусануть до того, как прочитаются аргументы: слишком провоцирующее начало, вызывает кучу негативных эмоций в вводной
            0
            А так куча негативных эмоций становится меньше?
              0
              Если рассмотреть гипотетическую ситуацию, в которой компания требует полный цикл тестирования на каждую небольшую фичу, не умеет оптимизировать процесс тестирования и автоматизировать тестирование — то тестирование для этой компании зло: приносит мало пользы, но потребляет много ресурсов. Насколько я понял, в этой компании именно такая ситуация. И здорово, что они осознали это, озаботились тем, чтобы решить эту проблему, выделить критичные направления и всё ещё тестируют (основные user-case) для минорных фич. Да, меньше становится негативных эмоций.
              Освободившиеся ресурсы они теперь могут направить на автоматизацию тестирования, например, и в итоге будут тестировать в перспективе качественнее, чем до «отказа от тестирования» и меньшими ресурсами.
            0
            Что имеем в итоге: «Продакт Дима совсем перестал заходить к Антону.»

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

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

                0

                На самом деле поиск QA вёлся параллельно всем нововведениям. Однако найти хорошего тестировщика оказалось задачей не быстрой — за последний год мы набрали 3 человека. Да и аппетит растёт во время еды, разработчиков тоже набирали и сейчас отношение 8 к 60.
                Насчет планирования "хотфиксов" — Вы правы, в этом направлении тоже ведётся работа, но к данной статье она не относится.


                надо быть полным дятлом чтобы фиксить абсолютно все баги

                а какие баги фиксите Вы?

                0
                Вобщем подход вполне разумный. Тестировать то, что важно и срочно — сейчас, а то, что важно, но не срочно — потом.

                matvey_travkin Тут немного не понял:
                Потом к Антону пришла тестировщик Юля и сказала, что задолбалась. Типа, делай, что хочешь, но она не может больше каждый день проводить приёмочное, учитывая тот факт, что по основному функционалу редко что-то меняется и багов она не находит. Поэтому Юля предложила проводить приёмочное раз в неделю.
                Почему тесты по основному функционалу не автоматизированы? Это те которые тяжело автоматизируются? Ведь тест базового функционала не дает вам тестировать новое и срочное. Даже если это раз в неделю. Еще если новый функционал при тестировании захватывает базовый функционал можно было бы отказаться от тестирования базового функционала так как он был бы и так протестирован. Может переписать сценарии так чтобы каждый тест нового подхватывал немного старого? Каждый тест станет на 1-3 шага длиннее, но зато у вас будет что-то вроде интеграционного теста, и небходимость отдельного тестирования базового функционала отпадет совсем.
                  0
                  Спасибо за коммент!
                  Совершенно верно, не автоматизированны остались сложные для автоматизации кейсы (получение СМС/E-mail, шаринги и админка). В этом направлении ведутся работы — разработчики обещали помочь с частью «сложных» кейсов.
                  Насчет проверки базового функционала параллельно с тестированием задач — интересная идея, спасибо. Сейчас у нас не очень прозрачно — тот, кто проводит приёмочное не знает, что из него было уже проверено в рамках тестирования других задач. Ну и конечно же всегда есть риск, что последняя задача всё переломает (мыж тестировщики суеверные :))

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое