Эта история из моей практики показывает, насколько сложно поднять качественное тестирование с чистого листа. Я хочу поделиться своим опытом, который может пригодиться тем, кто рискнёт отправиться в подобное путешествие.
Немного контекста
Продукт, которым я занимался, существует уже более трёх-четырех лет. Его использовали для обработки больших объёмов данных, их хранения в разных слоях (кратковременном, аналитическом и долговременном), визуализации данных, анализа логов и обработки метрик. Тестовые артефакты отсутствовали, единственным ориентиром была документация.
При этом мой уровень квалификации оставлял желать лучшего: всего лишь год опыта в тестировании, но меня поддерживали коллеги и руководство, доверившие амбициозному специалисту столь важное задание.
Первые шаги на «Пути самурая»
«Подготовка к битве»
Перед мной стояла сложная задача: с нуля организовать качественное тестирование. И я понимал, что крайне важно всё тщательно спланировать, ведь продукт представлял собой сложный кросс-платформенный инструмент, предназначенный для анализа и хранения огромных массивов данных.
Основные усилия я сосредоточил на создании иерархии приоритетов:
Определение основной функциональности администраторов и пользователей.
Разделение второстепенных функций между двумя ролями.
Это помогло упорядочить гигантские объёмы работы и обеспечить методический подход к решению задач. Покрытие каждого этапа потребовало огромного количества времени и сил, поскольку документация была далеко не полной. К тому же этапы часто пересекались, что замедляло прогресс.
Первоначально я тщательно проанализировал требования к продукту и существующие технические документы. Несмотря на отсутствие официальных артефактов тестирования, я смог определить ключевые направления, используя имеющуюся документацию. Это позволило сформулировать базовую карту рисков и подготовить первый черновой вариант матрицы тестирования (Test Matrix, TM). Первоначально она содержала лишь наиболее важные элементы интерфейса и базы данных.
Затем я интенсивно изучал особенности системы, экспериментально проверял отдельные компоненты и процессы. Я регулярно общался с командами разработчиков и сопровождением, запрашивал дополнительную информацию и проводил собственные исследования для заполнения пробелов в знаниях.
Главная трудность заключалась в отсутствии полноценной технической документации. Большинство важных аспектов функционирования продукта оставалось неясным, что затрудняло принятие решений и оценку потенциальных рисков. Некоторые функциональные области могли казаться простыми, но любое изменение настройки могло привести к изменению работы всей системы.
Задачу по созданию качественной документации я решил довольно простым, но трудоёмким образом. Во-первых, я активно собирал всю доступную информацию, формируя собственную базу знаний. Через общение с коллегами и изучение текущих результатов работы я создал собственную версию документации, отражающую реальные особенности системы. Эти записи легли в основу дальнейшего развития TM.
Во-вторых, я использовал методы прогнозирования возможных ошибок и предыдущий опыт команды сопровождения. Такое сочетание интуиции и практических наблюдений значительно повысило качество анализа рисков и способствовало формированию зрелой матрицы тестирования.
В результате я создал первую версию матрицы, позволяющей уверенно планировать дальнейшую деятельность. Матрица содержала описания базовых элементов и их взаимосвязей, помогая выявлять потенциальные уязвимости и сосредотачиваться на важнейших аспектах продукта.
Примечание. Описание ключевых функций существовало, однако малейшие отклонения приводили к провалу. Поэтому первую матрицу тестирования я формировал эмпирически.
Следующий шаг: настройка API-тестирования
«Выстраивание защиты»
Второй этап был связан с настройкой API-тестирования. Понимая важность проверок взаимодействия с внешним миром через API-интерфейсы, я приступил к подготовке необходимых инструментов и процедур. Прежде всего нужно было стабильно запускать API-запросы и отслеживать их успешность.
План действий состоял из трёх шагов:
Выбор подходящего инструмента для API-тестирования.
Анализ существующей инфраструктуры API.
Создание прототипа API-прогонов для оценки работоспособности решения.
Сначала я выбрал инструмент для организации API-тестирования — Insomnia. Он позволял эффективно формулировать запросы и отслеживать их выполнение. Я провёл ряд экспериментов, создавая шаблоны для регулярных запросов, настраивая взаимодействие с системой и изучая возможные сценарии отказов.
Далее начал готовить реальную среду для регулярного запуска API-тестов. Создал профили конфигурации, определил критерии успеха и неудачи, подготовил отчёты по результатам прогонов.
Основной задачей стала нехватка полного понимания структуры API-продукта. Часто необходимая информация оказывалась недостаточно точной или устаревшей, что мешало успешной интеграции и запуску тестов.
Ещё одним фактором риска оказалась зависимость от внешней команды сопровождения, которую мне пришлось преодолевать самостоятельно, сталкиваясь с задержками и недостатком обратной связи.
Для преодоления этих трудностей я разработал следующую тактику:
Регулярные встречи с представителями команды разработки и сопровождения для выявления и устранения недостатков API-документации.
Учился самостоятельно искать необходимую информацию, обходить ограничения и строить собственные модели поведения API.
Постоянно адаптировал сценарии тестирования к изменениям в инфраструктуре продукта.
Результатом второго этапа стала надёжная инфраструктура API-тестирования на основе Insomnia. Система успешно регулярно мониторила API, обеспечивая стабильность и предсказуемость работы продукта. Теперь команда была уверена в правильности внедрения новых фич и бесперебойности выпуска обновлений.
Третья задача: создание инструмента автоматического прогона тестов
«Укрепление обороны»
Чтобы облегчить запуск тестов API, я решил автоматизировать этот процесс в рамках Insomnia. Однако каждый новый релиз вынуждал практически заново переписывать значительную часть настроек. Время, потраченное на ручную настройку, могло стать катализатором третьей сложности: нехватки ресурсов и рабочей силы. Поэтому цель состояла в том, чтобы минимизировать влияние человеческого фактора на процесс тестирования и повысить скорость и точность проверок. Для этого я выбрал следующие технологии:
Jenkins для непрерывной интеграции;
Selenium для автоматизации веб-тестов;
REST Assured для API-автоматизации.
Я потратил много времени на изучение и освоение этих технологий, определяя оптимальные подходы к реализации автоматизированных тестов.
Первая задача заключалась в разработке базовой архитектуры автоматизированных тестов. Я сделал систему, состоящую из набора автоматизированных скриптов, которые благодаря Jenkins автоматически запускались после каждого изменения исходного кода, а я в реальном времени получал отчёт о результатах. Кроме того, я разработал специальные сценарии для проверки конкретных частей продукта. Каждый сценарий адаптировал к конкретной задаче, чтобы выявлять большинство багов ещё до релиза.
Автоматизированное тестирование оказалось сложной задачей. Основная сложность заключалась в нестабильной среде тестирования, которая часто ломалась из-за изменений в продукте. Новые компоненты, обновления сторонних сервисов и внутренняя логика программы нарушали работу тестов, делая результаты недостоверными.
Второй вызов заключался в подборе команды. Коллеги зачастую предпочитали традиционные методы тестирования, что осложняло распространение идей автоматизации среди остальных членов команды.
Я боролся с этими задачами в основном с помощью гибких подходов к автоматизации. Вместо жёсткой привязки тестов к определённому состоянию системы я предпочитал динамическое определение условий тестирования. Такая методика позволила избежать поломок тестов при изменении продукта.
Другим направлением работы стало активное участие членов команды. Я помог организовать обучение и мотивирование людей, чтобы повысить осведомлённость о преимуществах автоматизированного тестирования. Постепенно культура тестирования изменилась, и многие сотрудники стали сами предлагать идеи по улучшению тестов.
Результатом третьего этапа стало функционирование надёжной системы автоматизированного тестирования. Она позволяла оперативно выявлять баги и улучшать качество продукта, снижая нагрузку на команду ручного тестирования. Теперь люди могли сосредоточиться на сложных ситуациях, оставляя повторяющиеся задачи автоматизированным системам.
Четвёртая задача: отсутствие поддержки
«Обретение мудрости»
Один человек способен выиграть бой, но для победы в войне требуется целая армия. Четвёртый этап я посвятил взаимодействию с заказчиками. Нехватка времени и ресурсов вынудили меня придумать приоритизацию заданий в зависимости от приближающихся сроков. Релизы становились настоящим испытанием на выносливость, но успех зависел исключительно от личной мотивации. Ожидания зачастую превышали возможности текущего уровня тестирования, что ставило передо мной серьёзные задачи. Нужно было объяснить клиенту суть происходящего и оправдать высокие стандарты качества, обещанные проектом.
Прежде всего, я постарался наладить открытый диалог с клиентами:
Активно обсуждал потребности клиентов и собирал обратную связь.
Разрабатывал методики измерения качества продукта.
Регулярно встречался с клиентами и отправлял им отчёты.
Начал собирать статистику неисправностей дефектов и формировать рекомендации по улучшению продуктов.
Благодаря такому системному подходу клиенты получили прозрачное представление о ходе тестирования и стали лучше ориентироваться в процессах.
Задачу по отработке ожиданий клиентов я решил введением понятной системы отчётности. Это помогло снизить напряжённость во взаимодействии с заказчиками и выстроить конструктивный диалог.
Особое внимание уделяли повышению квалификации сотрудников и обучению новым технологиям.
Завершив четвёртый этап, я добился значительного прогресса в коммуникации с заказчиками. Клиенты получили ясное представление о состоянии продукта и качестве тестирования. Качество работы заметно выросло, на 12 % уменьшилось количество пропускаемых неисправностей, а атмосфера в команде стабилизировалась.
Финальный аккорд: переход к Java-автоматизации
Наша стратегия стала отличной возможностью для роста. Она позволила команде быстро освоить ключевые инструменты Java-автоматизации (Maven, JUnit, Rest Assured, Selenium) и получить бесценный практический опыт. Мы эффективно использовали этот этап для обучения, что помогло нам стабилизировать процесс, нарастить компетенции и создать надёжную систему. Теперь мы находим и исправляем дефекты быстрее, что значительно повышает качество продукта и оптимизирует рабочие процессы.
Из этого этапа я вынес два главных урока:
Дедлайн нельзя игнорировать, потребуется дисциплина и умение управлять своим временем.
Заказчик не всегда доволен качеством вашего труда, но стремление удовлетворить его потребности важно и должно учитываться.
Итоги путешествия
Что нам дала эта авантюра:
Мы с нуля создали матрицу тестирования.
Разработали систему автопрогона API.
Реализовали первые автоматизированные тесты на Java.
Получили признание заказчика.
Я вынес такие уроки:
Нужно начинать с покрытия критичных функциональных областей и постепенно расширять охват.
Инструменты типа Insomnia или Postman подходят для быстрого начала, но в долгосрочной перспективе нужны инвестиции в полноценную автоматизацию.
Не принимать близко к сердцу недовольство заказчиков в начале пути, нужно сосредоточиться на постепенном улучшении качества.