Тестирование до релиза и после: когда пора менять стратегию

Сергей Трофимов

Старший инженер по автоматизированному тестированию

Вступление.

Хабр, привет! Я Сергей Трофимов, старший инженер по автоматизированному тестированию в «Юзтех». В этой статье мы не будем говорить о том, как правильно и неправильно тестировать, на эту тему уже написано множество шпаргалок, инфографик, статей и книг, да и промышленных стандартов «правильной» разработки существует, наверное, с 10 тысяч. Вместо этого мы разберёмся, одно ли и то же — тестирование до релиза и после него. Точнее: должен ли корабль идти изначально намеченным курсом, или всё же стоит менять направление? И как научиться вовремя привносить полезное и отказываться от уже ненужного — пусть даже когда‑то хорошо работавшего. Ответы на эти вопросы мы и попробуем найти.

Часть 1. Начало

Даже если вам не пришлось прийти в проект на старте активной разработки, вы наверняка уже задумывались, что было изначально. В этой части я на личном опыте попытаюсь описать, чем заняться на первом этапе, когда даже кода нет. Это важный этап, который сильно сократит работу в будущем, если вы будете успешны.

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

Сразу отметем худший вариант — худшее, что можно сделать в этой ситуации — включить режим «ждуна» до «настоящей работы». Вы уже наняты, и настоящая работа уже начата. Стоит отметить, что большинство любят делать, а вот переделывать энтузиастов нет. И на первом этапе у нас будут задачи, которые лучше сделать сразу под ключ, чтобы не возвращаться к ним потом.

Задачи:

1. Инфраструктура автотестов.

Как я и говорил, в моем случае, это было не пустое место, что сокращало список одних проблем и порождало другие. Уже написанный в определенном стиле фреймворк, запуск тестов, отчетность, окружения. Все поднято и готово, осталось просто встроиться своими тестами в общую структуру. Задача не такая простая, как кажется, например, в моем случае никто не рассчитывал изначально что одним проектом автотестов будут пользоваться и пополнять две команды. И как это организовать особенно, не пихаясь локтями тема отдельной статьи. В общем, могу сказать, что в этом случае придется искать баланс между «как привык», «как уже есть» и «как хотелось бы».

2. Знакомство с соседями. Тут важно понимать, что, приходя в уже работающий бизнес со своими особенностями и процессами не надо влетать «с ноги» пытаясь улучшить все «как было на моем прошлом проекте». Изначально нужно познакомиться со всеми, понять, кто какую роль занимает, изучить процессы. Кажущиеся неудачными или плохими моменты лучше уточнить — почему именно так. Зачастую бывает, что выбирать приходится из нескольких вариантов, каждый из которых неудачен по‑своему. Обязательно познакомься с тестировщиками из сервисов, с которыми вы будете интегрироваться. Хорошо выстроенная коммуникация снимет множество проблем в будущем.

3. Аудит требований: ищем баги в текстах, а не в коде

Требования тоже тестируются и сейчас об этом рассказывают на любых приличных курсах QA. Тестирование на бумаге — это важный и нужный сейчас навык. Мало того, требования — это важный источник для тебя и твоих автотестов. Обычно любой проект вертится вокруг 2–3 базовых бизнес‑сущностей и их жизненных циклах. На этом этапе важно и нужно понять какие они и что с ними происходит.

В любом случае базовый CRUD никто не отменял и, возможно, это станет первыми и основными тестами.

4. Договорись о процессах. Лучше сразу понять как у вас будет выстроен процесс разработки и релизов. Все движется к максимально быстрой поставке и скорее всего команда будет двигаться к уменьшению TTM метрики. Но вначале надо выяснить какие этапы должны пройти до версии 1.0 или до первого релиза. Что будет включать в себя MVP, как продукт увидит своих первых пользователей (ограниченное тестирование (бета тест) или сразу выкладка в стор).

Это очень важно, именно эта точка станет отправной для будущей метаморфозы вашего тестирования.

5. Онбординг, знакомство с командой. Почти каждую неделю к вам будут присоединятся несколько человек. Среди них будут твои будущие коллеги. Обязательно соберитесь вместе и договоритесь о том, как вы будете взаимодействовать друг с другом. А еще по поводу понимания текущего момента. Это поможет избежать большинства возможных недопониманий в будущем.

Итого: на этом этапе тестирование наименее формализовано, ведь вы только собирайте будущее контуры процесса, который строится из многих факторов (наличие готового окружения, интеграций, наличия готовых процессов, дата релиза…)

Часть 2. Эпоха Хаоса

Как бы хорошо не готовились, эта эпоха непременно наступит. К сожалению, не все зависит от нас и как только мы начнем получать первые задачи и приступим непосредственно к тестированию, наши изначально разработанные концепции могут начать трещать по швам. Скорее всего это будет одним из самых сложных этапов в жизни продукта, так что да пребудет с вами сила. Я, как и многие люблю WH 40к и особенности 4ки богов хаоса на этом этапе вполне применимы.

Тзинч — или изменчивый бог. Его воздействия вы будете ощущать сразу. Хотите shift left, но требования и бизнес‑процесс исчезает на следующий день и рождается в новом виде, и вы можете не вылазить из анализа требований. Тестирование как раньше идет за разработкой, вы обнаруживайте что уже протестированная задача падает на регрессии, а в требованиях буквально вчера -2 старых и +1 новое требование. Вы хотите сразу наметить happy path, но он каждый раз стирается и приходится создавать новый, как навигатору после варп‑шторма.

Слаанеш — помимо прочего этот бог славился перфекционизмом. И тут желание сделать сразу и навсегда сыграют злую шутку. Если посмотреть на пункт выше, весь суперподробный энд‑ ту — энд будет жить очень недолго, а инвестиции времени, вложенные в него, не вернешь.

Нургл — разложение и распад. Разворачивается тут на полной и касается не только требований, тестов и ваших процессов, которые начинают быстро превращаться в вязкую, неудобную, всем мешающую массу. Если вы делайте код‑ревью, а код тестов уже не актуален — это оно. Если вы собирайте встречу, на которой 75% участников нечего сказать — тоже.

Кхорн — отвечал за ярость, и он может не проявится. Но обязательно появится, когда предыдущая тройка начнет критически душить проект. Его появление сильный маркер того, что многое пошло не так. Горящие дедлайны, желание все разрушить и начать с 0 и другие малоприятные вещи это все оно.

Но, это все абстракции. Как же мы пытаемся справляться с этим.

1. Выдели важное. Некоторые процессы будут меняться в деталях. Учитывай это в разработке тестов.

2. Сосредоточься на самом низу пирамиды тестирования. Твое основное поле сейчас это быстрые и легкие тесты, которые легко писать, поддерживать и править. Но не живи в иллюзиях, что этого достаточно — хорошо закрытый контракт не означает качественный сервис или приложение.

3. Меняйся сам — если чувствуйте, что какой‑то процесс вам мешает — меняйте сразу. Чем меньше заторов и пробуксовок возникнет на пути, тем меньшая вероятность наступления эры Кхорна.

4. Готовься жертвовать. Может так получится (и даже наверняка получится), что времени и ресурсов на все не хватит. Сразу обговорите, чем вы будете жертвовать, а главное возможно ли эта жертва вообще.

5. Закладывайте фундамент для будущего тестирования. То, что вы сейчас не тестируйте большие сценарии или UI, ничего не значит, это понадобится в ближайшем будущем, ведь цель продукта выполнять свою роль, зарабатывать деньги, а не висеть в производственном аду стараясь достигнуть совершенства. Поэтому задача минимум понимание того, что нужно для больших тестов и подготовка для их быстрой реализации.

Вывод: на этом этапе главное удержаться в заданной форме, но не сильно ее утягивать. Удушье на этом этапе проявляется быстро и разрушительно, приводит к пробуксовкам и потери драгоценного времени. Быстрое понимание что контракты, API более устойчивы к изменениям, а UI верстка и UX менее, позволило нам сконцентрироваться на этом и получить большое количество шустрых тестов. Это не только давало картину тестирования, но и позволяло нам отслеживать даже небольшие изменения (даже прежде, чем они до нас дошли в виде тикетов) и ставить нужные вопросы.

Часть 3. Точка перехода.

Главное не упустить этот момент. Продукт перешел на стадию бета‑теста и появился первый фидбек. И тут самая большая ошибка — это жить в прежней парадигме.

Да, картинка с 1000+ исправно проходящих тестов и работа над ростом их количества и поддержки — весьма заманчиво. Тестов может быть действительно много и дашборд не стыдно показать. Но, как говорилось выше, хорошо протестированные ручки и контракты — это вовсе не хорошо протестированный продукт. Люди пользуются продуктом, не дергая ручки через swagger а через привычные интерфейсы и заполненный низ пирамиды тестирования тут нам мало чем поможет.

Пришло время начать заполнять его уровни выше, вы ведь подготовились, не так ли?

Наша задачей на время до релиза:

1. Смещаем приоритеты — начинаем разработку UI тестов.

2. Держим в голове, что UI за это время продолжит меняться — ведь уже есть фидбек, но, скорее всего, это будут не коренные изменения.

3. Начинаем вводить тест‑анализ и писать документацию с DoD и прочими сопутствующими атрибутами.

4. Подготавливаем свои процессы для жизни в режиме от релиза до релиза. Тут конкретные рекомендации давать сложно, так как вариаций поставок в ИТ возникло достаточно много.

Ниже, в таблице я постарался собрать примерный сдвиг парадигмы тестирования.

Тут важно понимать, мы не отказываемся от работы, которую делали на этапе MVP, мы смещаем фокус и перераспределяем свое время в пользу новых активностей.

Уроки смены курса.

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

Ловушка «зеленого фонаря».
Мы пришли к релизу с достаточно большим количеством легкоподдерживаемых API тестов, запуски представляли собой красивую зеленую линию и стабильность бэкенда. Это, конечно, была очень обманчивая картинка достаточности. Работа была проделана большая, но ставить планы через полгода получить x2 количество тестов, окончательно бы увело нас к обрезанной пирамиде тестирования с крепким фундаментом и почти нулевым навершием. К сожалению, такая картинка может устраивать менеджмент и послужить аргументацией для определенных действий, донести менеджменту проблему смены парадигмы тоже задача QA.

Вывод: не надо заниматься самоуспокоением, высвечивая QA‑фонариком самую закрытую тестами часть продукта. Темная область станет все более темной и опасной, и, увы, гулять уже по ней предстоит пользователю.

Кейс «Взаимовыручка»

Наш сервис имел как веб версию, так и мобильное приложение. И в команде появился QA‑инженер, который занимался исключительно тестированием мобильного приложения. Мы «жили» в отдельных репозиториях и даже язык разработки автотестов у нас был разный. Можно было и дальше жить в этой раздельной концепции, делая вид что мы занимаемся параллельными направлениями, но мы сразу выбрали путь взаимной коммуникации и помощи. Мобильное направление на время частично покрыло наши потребности в тестировании бизнес‑сценариев, а наработки были использованы при разработке собственных тестов.

Вывод: разделяй и властвуй. Если есть возможность подобного делегирования, ей можно и нужно пользоваться, это инвестиция в экономию времени после перехода.

А теперь перейдем к общим выводам: До релиза вы бежите марафон на скорость, где баг — это просто тикет в таск трекере. После релиза вы удерживаете крепость, где баг — это финансовые и репутационные потери. Инструменты должны адаптироваться под эту задачу.

Заключение. Так куда плывет корабль?

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

Главный вывод, к которому приходишь, пройдя путь от голых требований до первых реальных пользователей — процессы в QA не высечены в камне.

• На этапе старта ваша цель — гибкость и планирование. Здесь вы «дружите» с соседями, страхуете контракты, выстраивайте приоритеты и сознательно жертвуете сложной автоматизацией.

• На этапе хаоса вы учитесь работать в условиях быстро меняющихся реальностей, пробуйте и меняйте процессы, но главное — стройте ваш фундамент (низ пирамиды тестирования).

• В точке перехода и после релиза фокус смещается на стабилизацию, UI/UX и долгосрочную поддержку, e2e тесты и вход в рутину.

• Всегда надо помнить что время — это самый ценный ресурс. Здоровая коммуникация в команде, взаимные договоренности внутри направлений тестирования помогут сэкономить время и избежать ненужного дублирования работы.

Хороший QA‑инженер — это не тот, кто один раз построил «идеальный» процесс по учебнику и слепо бьет по рукам каждого, кто пытается его изменить. Хороший QA понимает, что процессы, автоматизация, документация — это инструменты разного назначения, которые нужно применять (или не применять) в определенных ситуациях.

Не бойтесь хаоса и не держитесь за старые догмы. Меняется продукт — меняется и ваше тестирование. А умения жить, мыслить и творить в условиях быстрых перемен одна из главных прелестей нашей профессии.