Тестирование 2.0

Тестирование многообразно. Несмотря на то, что основные цели везде одинаковы, от проекта к проекту существует множество различий: разные стеки, технологии, процессы и подходы. Анализируя процессы во многих командах, Qameta Software обнаружила одну проблему. Эта проблема – неэффективность. В настоящее время тестирование является одним из самых неоптимизированных процессов в жизненном цикле разработки.

Сегодня мы попытаемся понять, как это произошло и что мы можем с этим сделать.

С чего все началось?

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

Отлично! Проблема возникает, когда менеджер продолжает работать в том же духе и в итоге пропускает критическую ошибку. В этот момент члены проекта принимают решение, что менеджер (как носитель сакрального знания о продукте) должен тестировать новую функциональность и не тратить время на скучные регрессионные тесты. Так у нас появился первый ручной тестировщик. Почему ручной? Потому что у разработки пока нет экспертизы в создании правильной автоматизации регрессии, а менеджер, что гораздо проще и спокойнее, доверяет человеку, а не коду. Теперь у нас есть команда, и трудностей не возникает: менеджер тестирует новый функционал и возможности, а тестировщик гоняет регрессию. Просто и понятно. Но в тот момент, когда критический баг прокрадывается в продакшн, начинается неразбериха. Команда идет к тестировщику и спрашивает:

– Почему у нас есть ошибка в производстве, как это произошло? Как вы его пропустили? На что наш специалист честно ответит
– Но его там не было. Я обязательно проверил это место! Скорее всего, разработчики вмешались в код уже после моего тестирования!
Очевидно, что, проанализировав ситуацию в ретроспективе, руководитель решает формализовать тестирование и ввести в тестирование чек-листы. Независимо от того, будут ли чек-листы простыми или сложными, на основе обычного специализированного программного обеспечения или в Excel, они будут четко показывать, что тестировалось, в какое время и каков был результат. Используя этот инструмент, команда сможет точно понять, пропустил ли тестировщик ошибку или нерадивые разработчики выкатили функцию без тестирования после пробного запуска. И так мы живем.

Продукт растет, обрастает функциями, количество чек-листов увеличивается, наш тестировщик набирается опыта и авторитета, а его время на тестирование заканчивается.

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

В команде появляется первая система управления тестированием (далее TMS), потому что теперь, помимо стандартных полей “шаг, статус, время”, нам нужно документировать кучу данных из головы тестировщика: ссылки, логины, пароли, какие-то дополнительные шаги или обход старых известных мелочей. Таким образом, у нас есть тестовые случаи, которые позволяют нам:

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

Однако есть и недостатки: в отличие от чек-листов, тест-кейсы требуют постоянного обновления и правильной организации. И если обновление – это вопрос скрупулезности и процесса, то организация тест-кейсов – сложный вопрос. Проблема возникает в тот момент, когда в процессе естественного роста инфраструктуры тестирования появляется тестовый сервер или стейджинг. До этого момента тестовая документация включает все детали, необходимые для запуска: ссылки, логины и пароли, кэши и cookies и т.д. Но с введением предпроизводственной тестовой среды все эти детали придется заблокировать и параметризовать, поскольку они не будут совпадать в производстве и на тестовом сервере. И тогда команде тестирования придется потратить в два раза больше усилий на поддержку всего этого.

Продукт продолжает расти и обрастать новыми функциями; количество тестовых случаев продолжает расти; наш тестировщик становится ведущим.

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

Автоматизация!

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

Мясо человека – яд для робота! Автоматизированный тест – это не человек. Автоматические тесты тупы, они не умеют продумывать шаги и выходить из сценариев. Поэтому классический подход к “переводу” тест-кейсов на язык фреймворка – это анти-паттерн, который приведет к ложным отказам или пропущенным ошибкам.

Представьте, что в 100 тестах есть фрагмент, где нужно войти в систему, сгенерировать документ и скачать его в PDF. Если что-то слегка изменилось, человек пройдет дальше, отметив, что неплохо бы обновить документацию. А если это робот, то вы получите 100 красных тестов.

Что делают тестировщики, когда видят 100 красных тестов? Правильно, они думают, что тесты сломаны и неправильные!

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

Документация сама себя не напишет

Чтобы как-то контролировать автоматизацию тестирования, руководитель QA решает объединить автоматизированные и ручные тесты в единый процесс. И вот три варианта того, как это сделать:

• Интегрировать автоматизацию тестирования с TMS. Почти все системы управления тестированием имеют API, благодаря которому команды могут передавать результаты тестирования в систему для получения агрегированных отчетов. Проблема здесь проста: результаты автоматизации обычно собираются без метаданных и подробностей, и все, что команда тестирования может узнать из отчета, это то, что N автотестов не прошли. Почему? Приходится копаться в кишках теста и выяснять это самостоятельно.
• Отдельный прогон автотестов с последующей ручной регрессией. Этот вариант, несмотря на то, что является “старой школой”, более эффективен с точки зрения обнаружения ошибок. Сложность здесь заключается в том, что команде тестирования придется работать в двух интерфейсах: иметь дело с отчетами автоматизации в одном инструменте, а с ручным прогоном – в другом. Допустим, тестировщики создают прогон и запускают его из своего интерфейса; после этого автоматизаторы запускают свои тесты и отдают отчет Allure ручным тестировщикам. Если в отчетах есть ошибки, команде приходится разбираться с Allure, а затем они также пытаются передать обнаруженные ошибки в ручную TMS. А затем в JIRA. Это требует больших усилий.
• Автоматизация становится полностью независимой услугой. Как только тест автоматизирован, он удаляется из реестра ручного тестирования. Зачем связывать ручное тестирование с автоматизацией, если можно выделить автоматизаторов в отдельный департамент и получить от них “сертификат зеленого трубопровода”? Это, пожалуй, самый опасный путь, поскольку он делает одно подразделение полностью зависимым от другого, а такие связи часто заканчиваются конфликтами и путаницей в ретроспективе, если что-то пойдет не так на пересечении.

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

Когда автоматизированных тестов десять, эффект непостижим, когда сто – заметен. И каждый день инженеры будут расширять покрытие и делать автотесты все более удобными для работы: более атомарными, более стабильными, более информативными. Разве не этого мы ждали? В этот момент можно подумать, что автоматизация пришла, и дальше будет только лучше. Как бы не так!

Проблемы роста

Как только автоматизированное тестирование начнет расти, появится куча новых проблем, и эти проблемы будут гораздо ближе к разработке, чем к существующему тестированию. И если ваши разработчики и тестировщики не наладили тесное сотрудничество и обмен опытом, решение каждой из этих сложностей потребует времени и усилий. Так что же нас ждет?

Стабильность тестового сервера

Тестовая среда обязательно появится. Она окажется в конвейере группы поддержки проекта эксплуатации (Ops), и тестирование, скорее всего, не будет иметь к ней управляющего доступа.

Как правило, в качестве тестового сервера используется не очень производительная машина, и когда тестов или запусков становится больше, она начинает задыхаться. Это часто приводит к задержкам в отправке результатов прогона и “шелушению” тестов (в данном случае это означает тесты, которые не работают из-за нарушения распараллеливания или таймаутов), что подливает масла в огонь и без того слабой веры в автоматизацию со стороны как ручного тестирования, так и разработки/операции.

Автоматизация выпадает из процессов

В результате такого прогресса даже самый компетентный автоматизатор замыкается на своих собственных задачах:

• Ручное тестирование активно общается с командой, рассказывая о результатах тестирования и ошибках. Из-за трудностей, упомянутых выше, автоматизированное тестирование остается внутренним артефактом в команде QA, что не дает инженеру по автоматизации возможности “глотнуть свежего воздуха” от производственной команды.
• Обычно трудно добавить что-либо в автоматизированные тесты команды разработки с метаданными (ID, например) из-за того, что инженеры по автоматизации считаются менее квалифицированными в плане кодирования, чем средний разработчик, поэтому они получают жесткое увольнение.
• Пробел в компетенциях также стоит на пути к команде ops; в результате администраторы отвергают предложенную помощь, говоря: “У нас нет времени вас учить, мы сами все настроим, а вы пользуйтесь этим дома”. Или “вы хотите кластер Selenoid? не спешите, у нас нет докера в наших конвейерах!”.

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

1. Мы не знаем, сколько автотестов написано и запущено.
2. Непонятно, какая функциональность охвачена автоматизированным тестированием, а какая нет.
3. Нет понимания, где тесты уместны, а где нет.
4. Нет ясности в том, как эти тесты могут быть запущены.
5. Необходимо выяснить, где и как хранить результаты тестирования. В итоге мы имеем ручное тестирование, которое занимается регрессией и не масштабируется. А команда автоматизации, созданная для решения проблем масштабирования, оказывается бесправной и, оставшись без поддержки коллег, порождает сложности инфраструктуры и процессов. Тестирование становится неэффективным.

Что же делать? Тестирование 2.0

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

Некоторые говорят: “Тестирование не нужно – разработка сама напишет тесты, а канареечное развертывание проверит все остальное”, но это не совсем так. И вот в чем разница:

• Разработчики пишут оптимистичные тесты 90% времени. Тесты, которые проверяют счастливый путь: когда вы вводите правильные данные, вы получаете правильный результат; база данных точно хранит и обновляет данные; структуры данных и алгоритмы выполняются правильно.
• Тестировщики, напротив, тестируют с деструктивной парадигмой. Их задача – найти уязвимости как в базовых, так и в неожиданных сценариях. Найти их, несмотря на то, что обычно все работает нормально.

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

Автоматизация во главе!

Давайте перевернем парадигму! Сейчас доверие к командам разработчиков практически в любом бизнесе феноменально (слава DevOps!):

• У разработки есть компетенции для оценки кода и того, как он тестируется.
• Разработка пользуется огромным доверием.
• Разработка имеет тесные отношения с руководством и операционной командой.

Если внимательно посмотреть на этот список, то можно отметить, что каждый пункт позволяет устранить соответствующий источник проблем автоматизации тестирования. Давайте представим, что произойдет, если в момент прихода QA-автоматизатора он станет не шестеренкой в отделе ручного тестирования, а возглавит движение всей команды в сторону автоматизации. Это несколько изменит весь вектор его ответственности и задач с самого начала пути. На наших радарах было как минимум три громких истории, когда “смена власти” происходит революционным образом благодаря классной команде и волевому решению о примате автоматизации на уровне руководства.

Второй вариант подходит для команд, где нет суперквалифицированной команды тестировщиков, а тестированием занимаются сами разработчики. Решение однозначно – отдать автоматизатора в команду Dev. У таких разработчиков культура обмена опытом и культура тестирования достаточно высока, поэтому нашим инженерам будет чему поучиться и кому показать код на проверку.

• Вам не нужно беспокоиться о компетентности. Эти разработчики будут рады помочь автотестеру разобраться с кучей новых технологий, до которых у нас не дошли руки в предыдущем сценарии: Docker, git, CI/CD pipelines.
• Разработчики не любят писать автоматизированные тесты. Для них написание тестов для функции – это рутина, которая нужна только для того, чтобы pull-request прошел проверку кода. Но для инженера по автоматизации это отличная задача. Он может и с функцией разобраться, и написать более интересные тесты. Только представьте, как здорово было бы освободить до 20-25 % времени разработчика для разработки новой функциональности.
• Кроме того, команда разработчиков чаще всего лучше общается с операционной командой. Если внезапно тесты начинают давать сбои, администраторы помогут вам разобраться с этим или выделят больше CPU/RAM. Почему? Потому что если тестирование в процессе разработки замедляет выпуск релизов, это проблема для всех участников процесса.

Конечно, в долгосрочной перспективе это повлечет за собой серьезные организационные изменения. Мы ставим автоматизацию во главу угла тестирования, а не делаем ее инструментом ручного тестирования. Ручное тестирование станет инструментом для автоматизированного тестирования!

Вы когда-нибудь видели что-то подобное? Но подумайте, действительно ли нам нужны ручные тестировщики, чтобы запускать регрессию вручную? Они должны создавать новые сценарии и передавать их автоматизации, по умолчанию отвечая за исследовательское тестирование и обладая опытом фундаментального тестирования для обеспечения максимального качества и покрытия. FTW!

Пожалуйста, дайте мне знать, был ли этот пост содержательным или, по крайней мере, приятным для чтения! Если да, то я буду продолжать знакомить удивительное сообщество DEV.to с лучшими постами из блога Qameta Software testing automation!

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