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

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

Коротко:

  • Покрытие кода 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. Спасибо, что дочитали статью до конца. Появились вопросы? Задавайте, будет интересно отвечать!