О тесте печальном

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

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

    Тестер за работойКоротко:
    • Покрытие кода unit-tests
    • Selenium
    • Автоматическое тестирование
    • Подробное декларирование каждой ошибки
    • Еженедельный анализ и оценка обнаруженных багов
    • Синхронизация с Acunote




    Ищем и находим


    Для поиска багов мы используем unit-tests, плагин Selenium для FireFox, ручное тестирование интерфейса.

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

    В отличие от «стандартных» unit-tests, мы покрываем тестом не конкретную функцию в коде, а некое действие пользователя. Есть тест, проверяющий создание дружбы между пользователями. При его запуске он последовательно проходит все возможные случаи — пользователи уже друзья, пользователи не могут стать друзьями, так как не выполнены какие-то условия и так далее. Тест содержит в себе мини-ТЗ на логику работы приложения. Количество тестов растет с внедрением нового функционала. Обвязку для тестов писали сами, из сторонних источников с удовольствием воспользовались только PHPUnit_assert.

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

    Мы приняли за аксиому, что перехватить все ошибки, которые отслеживают unit-тесты нельзя — бывают случаи, когда необходимо в срочном порядке выложить обновление на сайт. Для этого на основном сервере каждые 6 часов в автоматическом режиме запускаются тесты. Результат выполнения уходит в лог файл, провальные тесты отсылаются на e-mail мне и руководителю разработки, отправляются СМС.

    Среди инструментов для Front-end тестирования мы выбрали плагин Selenium IDE для FireFox. Плагин используется для тестирования форм ввода, появления спиннеров, появления всплывающих окон и тому подобных вещей. Как пример, регистрацию пользователя вручную тестировать очень неудобно, а с помощью Selenium-теста проверка занимает всего несколько секунд.

    Новый функционал в первую очередь тестируется вручную. Я стараюсь перепробовать все возможные варианты. Например, интерфейс добавления места должен отрабатывать не только поэтапное заполнение всей информации о месте (на нашем сайте этот интерфейс разбит на 4 экрана), но и ситуации, когда пользователь в один момент передумал добавлять место, не полностью заполнил необходимую форму или попробовал перескочить один из шагов. В таком случае необходимо как минимум показать сообщение об ошибке. Позже по результатам ручного тестирования пишутся Selenium-тесты.

    Декларируем


    Чаще всего, ошибка не может быть исправлена в тот же момент, после ее обнаружения, а значит их необходимо где-то хранить. Для этих целей мы выбрали Гугл документы, где создали таблицу со следующими полями:
    • Номер бага (удобнее оперировать при общении с разработчиками)
    • Кто его обнаружил (автор, тот, кому можно задать дополнительные вопросы)
    • Место, где обнаружили
    • Тип
    • Условие возникновения (если кто-то захочет повторить)
    • Описание (что конкретно не устраивает)
    • Должно появиться (что в результате необходимо увидеть)
    • Комментарии (на всякий случай, скриншот приложить например)
    • Даты (открытие, закрытие)
    • Исполнитель (кто исправил)
    • Приоритет
    Их мы уже нашли
    Картинка кликабельна.

    Поле приоритет имеет несколько вариантов заполнения:
    • P0 — баги высокого приоритета, которые необходимо решить прямо сейчас. Чаще всего это ошибки, касающиеся наших партнеров или ошибки основного функционала сервиса
    • P1 — необходимо решить сегодня
    • P2 — решаем за текущий спринт
    • P3 — решаем за текущий спринт, если остается время
    • P4 — мелкие баги, опечатки
    Приоритет полностью синхронизирован с приоритетами задач в Acunote.

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

    В результате жизненный цикл найденной ошибки выглядит примерно так:
    1. Баг найден и внесен в таблицу;
    2. Если багу присвоен приоритет P0 или P1, он уходит в текущий спринт как незапланированная задача;
    3. Программист исправляет баг, при закрытии я об этом узнаю;
    4. Я проверяю исправление — этот этап пропускать нельзя — и актуализирую таблицу.

    Планируем


    Перед началом каждого спринта я и Product Owner, составляем список ошибок, которые должны быть исправлены в следующем спринте. Как правило в список входит не больше 10 багов требующих анализа, выявления проблемы и правки кода. Чаще всего, в список попадают незакрытые P2. Удобнее было бы сразу добавлять все новые баги в Aconote — тогда необходимость в документе с багами отпадает, но видеть по итогам спринта пул незакрытых задач по багам — не лучший вариант.



    Анализируем



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

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

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

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

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

    P.S. Спасибо, что дочитали статью до конца. Появились вопросы? Задавайте, будет интересно отвечать!
    AlterGeo
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +1
      Я правильно понял, что системой баг-трекинга у вас выступает гуглодок? Чем существующие решения не подошли?
      А функциональные тесты вы запускаете только в FF? А как же кросс-браузерность? И, насколько я знаю, ваше приложение тесто связано с мобильным клиентом, если какая-нибудь автоматизации тестирования его?
      А пользуетесь ли какой-нибудь системой CI для запуска тестов каждые 6 часов или это делается нехитрым скриптом?
      Заранее спасибо за ответы!:)
        0
        Да, поняли правильно.
        • По факту, таблицей пользуется 2 человека
        • В таблице работать быстрее и удобнее
        • Очень гибкая конфигурация таблицы
        • Возможность собирать абсолютно любую статистику, какую захотим
        Функциональность и кроссбраузерность — это разные вещи. Тестирование верстки не автоматизировано.
        Мобильные клиенты взаимодействуют с кодом, который покрывается unit-test'ами, но мы также смотрим в сторону автотестов мобильных приложений.
        Тесты запускает нехитрый скрипт на cron'e.
          0
          А как программисты узнают о багах которые нужно решить прямо сейчас и прямо сегодня не заглядывая в таблицу? Или об этом им сообщает Acunote?

          Кроссбраузерность это не только вёрстка, это ещё и, например, js, который может преподнести сюрприз в опере или ие.

          А не расскажите сколько у вас программистов и тестировщиков?
            0
            В скайпе организован общий чат, куда я сообщаю о P0 багах, там же ведется «текущая» общая переписка.

            Да, согласен, сюрпризы случаются.

            6 веб — разработчиков и 2 тестера.
              +2
              Вообще «таблица и чат» — это какая-то дичь в стиле середины 90-ых. Как-можно скорее установите нормальный багтрекер. Вам понравится.
                0
                Спасибо, не обещаю, но мы попробуем.
                  0
                  А еще попробуйте организовать полноценный continious integration, например на базе Jenkins или Hudson вместо того скриптика, в комбинации с правильной поддержкой версионности кода вам это тоже понравится, гарантирую.
                  Для затравки ;)
                  В одной из контор, где я раньше работал, видел в живую как Jenkins прогоняет Selenium тесты.
                  Кроме того, я надеюсь, вы конечно используете какую-нибудь SCM, Jenkins умеет отправлять отчеты об упавших билдах всем, кто коммитился с момента последнего успешного билда.
                  Можно организовать процесс так, что любой QA сможет в любой момент времени запустить билд проекта на Jenkins, немного подождать, и получить бегущий продукт на каком-нибудь тестовом environment.
                  О интеграции с таск-трекерами я вообще молчу, вам нужно для начала попробовать что это такое, вместо таблички :)
              0
              > А как программисты узнают о багах которые нужно решить прямо сейчас и прямо сегодня не заглядывая в таблицу? Или об этом им сообщает Acunote?

              Да. По багу, который надо закрыть создается задача в Acunote с соответствующим приоритетом. Таблицу программисты не используют.

              Часть багов так же озвучивается в общем чате команды — но не с целью постановки задач, а с целью либо уточнения причин бага (кто только что работал с XXX.YYY?), либо информирования разработчиков о баге. Мы считаем правильным, когда каждый разработчик в курсе, что происходит во всем проекте.
              0
              Подождите-подождите! Вы говорите, что работать с таблицей Вам быстро и удобно? А Вы видели реальные системы багтрекинга (тфс, багзилла, мантис, редмайн)?
            0
            Selenium IDE очень ограниченный инструмент, почему же вы не используете полноценный Webdriver или Watir к примеру? Не хватает квалификации тестировщиков?
              0
              Решили начать с самого простого Selenium IDE, про Webdriver знаем и надеемся перейти на него.

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

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