Сервис, который не должен останавливаться, и при этом динамично развивается, всегда находится между двух огней. В случае простоя финансовые и репутационные потери будут колоссальными. А если вспомнить про чрезвычайно сжатые сроки и меняющиеся требования в процессе разработки, то степень сложности продолжала повышаться. Поэтому перед отделом качества встала амбициозная задача выстроить тестирование продукта таким образом, чтобы оно было:
- Быстрым. У нас сжатые сроки, короткие спринты и мы не хотим ждать по нескольку дней, пока тестеры проведут регрессионное тестирование по чек-листам. В идеале — нужно получать ответ, какой регресс понесла система после каждого изменения кода.
- Полным. Быстрое осуществление тестов — не самоцель. Настоящая цель — быть уверенными, что если тесты прошли успешно, то наша система готова к обновлению. А значит тесты должны быть не только быстрыми, но и полностью охватывать функционал продукта.
- Гибким. Быстрые и полные тесты это прекрасно. Но если у заказчика есть новые требования, и изменения требуют полного переписывания тестов — это никуда не годится, потому что мы опять теряем скорость. Соответственно, тесты должны быть гибкими к изменениям.
- Дешевым. Ресурс тестировщика при большой скорости разработки всегда будет выходить на первый план, если нам нужно получить высокое качество. Поэтому всё, что описано выше, должно выполняться существующим количеством специалистов по тестированию. Мы здесь лишь подтвердили общее соотношение, когда на 3 разработчиков приходится 1 тестировщик.
В качестве основы автотестов был выбран Python вкупе с фреймворком py.test. Python — это быстрый (в плане разработки) и мощный язык, а py. test с его замечательной подсистемой фикстур и параметризации — гибкий инструмент, позволяющий широко переиспользовать код тестов.
В качестве агрегатора результатов: билд-сервер TeamCity с установленными плагинами для интерпретации итогов проверки от py.test.
Сами тесты пишутся максимально изолированно, выполнение каждого теста никак не зависит от результата выполнения остальных тестов. Если тесту нужно подключаться к БД системы и получать данные, значит, фикстура теста должна эти данные там обеспечить до выполнения теста. Если на тест может повлиять значение, лежащее в кэше, значит другая фикстура должна обнулить кэш до выполнения этого теста. Да, это привело к тому, что много времени потребовалось для разработки систематизированной сетки фикстур, но очень быстро эти инвестиции стали окупаться скоростью добавления новых тестов и, самое главное, стабильностью их результатов. Полный контроль над тестируемой системой означает минимум ложных срабатываний тестов.
Интеграция с сервером сборки TeamCity дала возможность просто нажать одну кнопку, чтобы тесты проверили все процессы платформы. При этом никаких приготовлений делать не нужно, а значит, это может сделать любой член команды. Отчет о тестировании в подробном и наглядном виде отображается на веб-интерфейсе build-сервера.
Не пожалели мы и о полном отказе от автоматизации тестов API через специализированные решения. Да, такие инструменты дают набор функциональности прямо из коробки. Но, во-первых, это недешево, во-вторых, нам всё равно нужно больше возможностей.
К примеру, в определенных тест-кейсах нашего API было нужно получать СМС-код подтверждения на операцию, пробрасывать его в тесты и наблюдать за поведением системы. Вот здесь и выходит на первый план мощь coded тестов, пусть их разрабатывать и дороже, чем, к примеру, собрать test-step'ы в SoapUI.
В итоге, сейчас процесс построен таким образом, что Postman или тот же SoapUI используется тестировщиками только на этапе первичной проверки. В конечном итоге процесс всё равно должен быть покрыт автотестами на Python и внедрен в общий репозиторий. Это закон.
Ни одно изменение функционала системы не обходится у нас без тестирования вообще и без автотестов в частности. Story просто не считается выполненной, пока она не покрыта автотестами. Такой подход требует высокой самодисциплины от команды и производительности от тестировщиков, но результат того стоит: если на билд-машине тесты зеленые, мы уверены в качестве своей системы.
Сейчас количество функциональных тестов перевалило за 2500 и продолжает расти. Выполнение занимает 25 минут.
Правильный выбор инструментов и полное покрытие автотестами с ранних этапов разработки позволило нам поддерживать высокую скорость внедрения новых функций на всем протяжении проекта, оставаться гибкими к изменениям требований, и при этом не жертвовать качеством продукта.