Home

Автор: Эран Кинсбрунер (Eran Kinsbruner)

Оригинал статьи: https://mobiletestingblog.com/2017/08/25/optimizing-mobile-test-automation-across-the-pipeline/

Перевод: Ольга Алифанова

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

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

Множество "хозяев" у одной и той же проблемы

Так как мы живем в мире Agile/DevQAOps, разработка кода автотестов – проблема не только QA, но и всех вообще. Тесты выполняются в процессе разработки, начиная от разработки как таковой и заканчивая интеграцией и пред/пострелизным тестированием.

Использование "умных меток" для ваших тестовых сценариев (авторизации), наборов тестов (приложение А) и типов (юнит, регресс) может быть хорошим шагом в сторону обретения контроля над вашими тестами.

Без понимания контекста, наличия четких процессов и постоянной структурированной валидации тестов поддерживать, анализировать и избавляться от багов в них будет со временем все сложнее – почти как найти ключик на картинке ниже.

Рекомендуемые практики

• Разрабатывайте тесты, не забывая про контекст, метки и правильные аннотации, которые будут иметь смысл для вас и вашей команды даже спустя год после начала разработки. Убедитесь, что ваши отчеты можно фильтровать по этим аннотациям – хотя бы для того, чтобы посмотреть на определенную функциональную область, платформу, и т. п.
• Сделайте так, чтобы возможности вашего тестируемого устройства соответствовали коду теста и приложению, которое тестируется. Убедитесь, что вы, к примеру, фокусируете тесты, в которых есть проверка отпечатка пальца, на устройствах, которые это поддерживают (API XX и выше).
• Выполняйте ревью кода автотестов каждый раз в заранее оговоренное время. В процессе ревью группируйте тесты, относящиеся к одной и той же функциональности, и старайтесь оптимизировать их, объединить, устранить ненадежности, определить пробелы в покрытии. Со временем заниматься этим все тяжелее, поэтому ставьте правильные цели в зависимости от частоты ваших релизов и развитости автоматизации. Чем больше ревью, тем лучше – это более быстрый и эффективный способ, так как дельта перемен между такими ревью будет меньше.
• Пусть объединенные решения разработки, тестирования, управления продуктом, маркетинга управляются данными. Если ваши автотесты позволяют получить анализ качества продукта, соберите всех задействованных лиц и проанализируйте результаты. Определите, какие тесты наиболее эффективны, можем ли мы сократить время между релизами, есть ли у нас пробелы в тестировании каких-то областей, не забагованы ли одни платформы больше других, какие тесты занимают максимум времени, и т. д.
• Оптимизируйте вашу непрерывную интеграцию и тестирование приемки сборки. Основываясь на вышеупомянутых данных, команда может принимать решение о том, что включать в непрерывную интеграцию. Тестирование в цикле разработки через CI должно быть быстрым, надежным, и без ложноположительных срабатываний. При качественных отчетах о тестировании вы можете отобрать наиболее ценные и быстрые тесты, которые нужно включить в CI-тестирование, и сократить общую длительность процесса, не рискуя покрытием.

Заключение

Автотест – это код, и нуждается в рефакторинге, поддержке, устранении и улучшении так же, как и код приложения. Убедитесь, что вы контролируете ваши тесты, и, следовательно, контролируете качество вашего продукта.

Удачного тестирования!

Обсудить в форуме