Тестирование принято считать точкой входа в мир IT. Мы не согласны. Контроль качества заслуживает большего внимания: поэтому мы пробуем новые подходы к процессу. Стараемся найти самый эффективный: такой, чтобы не пропустить ни одного бага и не задерживать проект.
Мы поняли, что в разных контекстах нужно по-разному моделировать процесс тестирования.
В рамках спринта
Проводим тестирование каждой фичи по отдельности.. Выгружаем о сборки и тестируем по предварительно составленным чек-листам в таком порядке:
I.Создание/редактирование тест-кейсов и автотестов
Тест-кейсы – описания действий пользователей в процессе использования разных функций приложения. Нужны для того, чтобы проверить, как работает система при всех возможных действиях пользователя.
Автотесты – это код, который пишет разработчик, чтобы проверить работоспособность программы. Они здорово экономят время на исправление багов. Показывают, в какой конкретно строчке кода ошибка.
II. Тестирование новых функций
В основном это ручное тестирование, которое проходит в несколько этапов:
1. Дымовое тестирование
Тестирование основных функций по заранее продуманному поведению пользователя. Это делается для подтверждения того, что программа выполняет основные функции.
Сначала проводим позитивное тестирование: так, будто бы мы просто стараемся выполнить целевое действие (скажем, добавить товар в корзину). Затем негативное тестирование: пытаемся “обмануть” программу, нажимаем на разные кнопки и смотрим, как она реагирует на это.
По результатам дымового тестирования можем судить, есть ли смысл переходить на следующий этап или нет. Если дымовое не пройдено — программа отправляется на доработку. Все найденные баги описываем в баг-репортах и назначаем задачу на исправление. Ждем, когда баг исправят.
Если тестирование прошло успешно — переходим на второй этап.
2. Регрессионное тестирование
Проверяем, исправлены ли баги и повлияли ли изменения на работу других частей приложения.
3. Полное тестирование по тест-кейсам
Проверяем все описанные в тест-кейсах функции.
В рамках проекта
Допустим, в проекте 5 спринтов. Тогда ближе к концу проекта (здесь это 4 спринт) QA проводит тестирование всех изменений.
На этом этапе проводим все то же регрессионное тестирование, но заостряем внимание на тестировании взаимодействия.
Проверяем, что все компоненты системы исправно работают вместе. В рамках спринта проверяем работу отдельных частей, которые отвечают за конкретную функцию продукта. Теперь собираем их вместе и смотрим, нет ли неполадок.
Самый ответственный спринт
Но есть особенный спринт — предрелизный. Последний перед тем, как приложение увидят пользователи.
Мы сначала проводим регрессионное тестирование. Строим процесс разработки так, чтобы на предрелизный спринт оставались самые мелкие функции, неисправность которых можно быстро пофиксить. Это не отразится на остальных частях продукта. В этом случае регрессионное тестирование ограничивается проверкой любых изменений в коде с прошлого спринта.
Тестирование внедренных багфиксов. Багфиксы — исправленные баги. Проверяем исправленные после регрессионного тестирования недочеты.
Тестирование интеграции патча. Патч – это код, который внедрили разработчики, чтобы устранить ошибки. Т.е. результат двух предыдущих этапов. QA смотрит, хорошо ли он вписался в систему, не повлиял ли на остальную часть программы. Если в систему были внедрены любые другие изменения, они проверяются тоже. Для этого используем юнит-тесты.
Юнит-тест — это автотест для небольшой части кода, отвечающей за конкретную функцию. Они подают значения, и если программа обрабатывает их неверно (не так, как было задумано) — юнит-тест не пройден. Разработчики видят, какая часть кода неисправна и устраняют ошибки.
Эти же юнит-тесты спасают нас, когда после наката обновлений появляются баги. Возвращаться к старому коду = тратить время на его разбор, а юнит-тест сразу покажет, где проблема. Баг фиксят в разы быстрее.
Финальное тестирование. Проверка всех функций приложения в соответствии со спецификацией, согласованной с заказчиком.
Тестирование на поддержке
Этот этап проходит после релиза. В процессе работы приложения заказчик часто хочет добавить новые возможности приложению, разработать новый функционал и просто иметь команду, которая будет заниматься обслуживанием продукта, если что-то пойдет не так. Это называется «работа на поддержке».
В таких случаях после обновления тестируют сборку. Это проверка работы основного функционала приложения после обновления. Если обнаружены баги, мы возвращаемся к схеме «в рамках спринта».
Результаты такой стандартизации процесса: оптимизация работы QA-отдела. Мы расставили приоритеты, выработали отдельную методологию для каждой из ситуаций, сэкономили время сотрудников, упростили разработку. Мы за грамотный менеджмент везде: в рабочих процессах, проектах, разработке и тестировании.
