О том, что тестировать — нужно, важно и полезно знают, кажется, все. В этом посте мне бы хотелось пробежаться по тем моментам, которые делают наше тестирование нужным, важным и полезным.
В силу того, что мы работаем с развивающимся веб-приложением, у которого есть множество партнеров, обновления и новый функционал приходится выкатывать часто и по-многу. Отсюда вытекает основной принцип нашего тестирования — как можно раньше отловить то, что сломалось, без ущерба для скорости разработки.
Коротко:
Для поиска багов мы используем unit-tests, плагин Selenium для FireFox, ручное тестирование интерфейса.
В необходимости unit-тестов для отслеживания багов я убеждался уже не раз и до сих пор верю в их силу. На текущий момент у нас написано несколько десятков unit-тестов, покрывающих, конечно не весь функционал, но солидную часть типичных действий пользователя: регистрацию, отметку, создание плана и так далее.
В отличие от «стандартных» unit-tests, мы покрываем тестом не конкретную функцию в коде, а некое действие пользователя. Есть тест, проверяющий создание дружбы между пользователями. При его запуске он последовательно проходит все возможные случаи — пользователи уже друзья, пользователи не могут стать друзьями, так как не выполнены какие-то условия и так далее. Тест содержит в себе мини-ТЗ на логику работы приложения. Количество тестов растет с внедрением нового функционала. Обвязку для тестов писали сами, из сторонних источников с удовольствием воспользовались только PHPUnit_assert.
После написания крупных правок, каждый из команды разработчиков на своем локальном сервере должен протестировать код, проверить, нарушают ли его правки основные алгоритмы социальной сети и так далее. Такой подход сокращает сроки разработки новых фич, и, конечно, минимизирует появление новых случайных ошибок.
Мы приняли за аксиому, что перехватить все ошибки, которые отслеживают unit-тесты нельзя — бывают случаи, когда необходимо в срочном порядке выложить обновление на сайт. Для этого на основном сервере каждые 6 часов в автоматическом режиме запускаются тесты. Результат выполнения уходит в лог файл, провальные тесты отсылаются на e-mail мне и руководителю разработки, отправляются СМС.
Среди инструментов для Front-end тестирования мы выбрали плагин Selenium IDE для FireFox. Плагин используется для тестирования форм ввода, появления спиннеров, появления всплывающих окон и тому подобных вещей. Как пример, регистрацию пользователя вручную тестировать очень неудобно, а с помощью Selenium-теста проверка занимает всего несколько секунд.
Новый функционал в первую очередь тестируется вручную. Я стараюсь перепробовать все возможные варианты. Например, интерфейс добавления места должен отрабатывать не только поэтапное заполнение всей информации о месте (на нашем сайте этот интерфейс разбит на 4 экрана), но и ситуации, когда пользователь в один момент передумал добавлять место, не полностью заполнил необходимую форму или попробовал перескочить один из шагов. В таком случае необходимо как минимум показать сообщение об ошибке. Позже по результатам ручного тестирования пишутся Selenium-тесты.
Чаще всего, ошибка не может быть исправлена в тот же момент, после ее обнаружения, а значит их необходимо где-то хранить. Для этих целей мы выбрали Гугл документы, где создали таблицу со следующими полями:
Картинка кликабельна.
Поле приоритет имеет несколько вариантов заполнения:
С этой таблицей большую часть времени работаю я и глава отдела разработки. Была попытка подключить разработчиков к добавлению новых записей и редактированию старых, но программистам неудобно работать в таблице. Если кто либо из команды находит ошибку, то сообщает мне о ней в Skype или по электронной почте.
В результате жизненный цикл найденной ошибки выглядит примерно так:
1. Баг найден и внесен в таблицу;
2. Если багу присвоен приоритет P0 или P1, он уходит в текущий спринт как незапланированная задача;
3. Программист исправляет баг, при закрытии я об этом узнаю;
4. Я проверяю исправление — этот этап пропускать нельзя — и актуализирую таблицу.
Перед началом каждого спринта я и Product Owner, составляем список ошибок, которые должны быть исправлены в следующем спринте. Как правило в список входит не больше 10 багов требующих анализа, выявления проблемы и правки кода. Чаще всего, в список попадают незакрытые P2. Удобнее было бы сразу добавлять все новые баги в Aconote — тогда необходимость в документе с багами отпадает, но видеть по итогам спринта пул незакрытых задач по багам — не лучший вариант.
Анализ позволяет обратить внимание команды разработки, на повторяющиеся или типичные ошибки кода, верстки, с целью их предупреждения и экономии времени на отладку.
По моему опыту замечу, баги чаще возникают из-за того, что поставленная задача не была достаточно подробно описана, либо не была разбита на подзадачи. Приведу пример, необходимо было составить список друзей из социальной сети Facebook, реализовать возможность приглашать их зарегистрироваться в нашем сервисе. Задача выполнена, но сама страница со списком не была доведена до ума, т.к. на ней же находился еще и поиск по друзьям. Программист не проявил инициативу и задачи по отладке поиска не стояло, в результате баг.
Второй же тип багов по популярности в нашей команде АльтерГео — это баги, находящиеся на стыке функционала. Например, добавление нового типа события. В этом случае баг вполне может проявиться в лентах событий на одной из платформ, будь это сайт, мобильная версия, либо одно из мобильных приложений.
Оценивать скорость появления и исправления багов позволяет удобная статистика, которую мы строим в той же таблице, только для удобства она вынесена в отдельную вкладку. Составленный нами график не только отражает общий тренд ошибок, но и тренды по каждому из приоритетов.
Подводя итоги, повторюсь. Наш подход к исправлению багов в приложении нацелен не на попытку исправить все ошибки. Вместо этого, мы хотим как можно раньше находить баги без потери темпов разработки. Что символично — после того, как мы признали, что разработчики всегда будут ошибаться и учли это в работе, качество приложения резко возросло.
P.S. Спасибо, что дочитали статью до конца. Появились вопросы? Задавайте, будет интересно отвечать!
В силу того, что мы работаем с развивающимся веб-приложением, у которого есть множество партнеров, обновления и новый функционал приходится выкатывать часто и по-многу. Отсюда вытекает основной принцип нашего тестирования — как можно раньше отловить то, что сломалось, без ущерба для скорости разработки.
Коротко:- Покрытие кода 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 — мелкие баги, опечатки
С этой таблицей большую часть времени работаю я и глава отдела разработки. Была попытка подключить разработчиков к добавлению новых записей и редактированию старых, но программистам неудобно работать в таблице. Если кто либо из команды находит ошибку, то сообщает мне о ней в Skype или по электронной почте.
В результате жизненный цикл найденной ошибки выглядит примерно так:
1. Баг найден и внесен в таблицу;
2. Если багу присвоен приоритет P0 или P1, он уходит в текущий спринт как незапланированная задача;
3. Программист исправляет баг, при закрытии я об этом узнаю;
4. Я проверяю исправление — этот этап пропускать нельзя — и актуализирую таблицу.
Планируем
Перед началом каждого спринта я и Product Owner, составляем список ошибок, которые должны быть исправлены в следующем спринте. Как правило в список входит не больше 10 багов требующих анализа, выявления проблемы и правки кода. Чаще всего, в список попадают незакрытые P2. Удобнее было бы сразу добавлять все новые баги в Aconote — тогда необходимость в документе с багами отпадает, но видеть по итогам спринта пул незакрытых задач по багам — не лучший вариант.
Анализируем
Анализ позволяет обратить внимание команды разработки, на повторяющиеся или типичные ошибки кода, верстки, с целью их предупреждения и экономии времени на отладку.
По моему опыту замечу, баги чаще возникают из-за того, что поставленная задача не была достаточно подробно описана, либо не была разбита на подзадачи. Приведу пример, необходимо было составить список друзей из социальной сети Facebook, реализовать возможность приглашать их зарегистрироваться в нашем сервисе. Задача выполнена, но сама страница со списком не была доведена до ума, т.к. на ней же находился еще и поиск по друзьям. Программист не проявил инициативу и задачи по отладке поиска не стояло, в результате баг.
Второй же тип багов по популярности в нашей команде АльтерГео — это баги, находящиеся на стыке функционала. Например, добавление нового типа события. В этом случае баг вполне может проявиться в лентах событий на одной из платформ, будь это сайт, мобильная версия, либо одно из мобильных приложений.
Оценивать скорость появления и исправления багов позволяет удобная статистика, которую мы строим в той же таблице, только для удобства она вынесена в отдельную вкладку. Составленный нами график не только отражает общий тренд ошибок, но и тренды по каждому из приоритетов.
Подводя итоги, повторюсь. Наш подход к исправлению багов в приложении нацелен не на попытку исправить все ошибки. Вместо этого, мы хотим как можно раньше находить баги без потери темпов разработки. Что символично — после того, как мы признали, что разработчики всегда будут ошибаться и учли это в работе, качество приложения резко возросло.
P.S. Спасибо, что дочитали статью до конца. Появились вопросы? Задавайте, будет интересно отвечать!