Размышляя о новом наборе автотестов, вы наверняка начнете с вопроса, что именно вы собираетесь автоматизировать. Неважно, требует ли автоматизации ваш менеджер, или за нее боретесь вы – прежде чем выбирать инструмент, вам нужно разработать стратегию тестового покрытия.
На решение, что конкретно автоматизировать, влияет множество факторов. Если вы пытаетесь определить масштаб автоматизации изолированно, вы, возможно, наделаете ошибок. Ниже – ряд советов, которые помогут вам мыслить шире и вовлечь в такое обсуждение широкую аудиторию.
Я начал этот цикл статей с программирования, и сделал наиболее распространенную ошибку, которую делают все автоматизаторы – углубился в объяснения, как автоматизировать, вместо того, чтобы рассказать, почему это важно и выгодно для нас (спасибо Джиму Хейзену за то, что он обратил на это мое внимание).
На самом деле я рад, что все произошло именно так, потому что это лишняя демонстрация того, как люди, включая меня, подходят к автоматизации – они просто учатся программировать и ныряют в код, не зная, что они, черт возьми, делают. Делаем шаг назад, переосмысляем…
Еще несколько лет назад к организации автоматизированного тестирования предъявлялось, по сути, лишь одно требование — исключить из большинства рутинных проверок труд человека. Активнее всего автоматизацию внедряли крупные компании, для которых производительность и скорость прохождения тестов редко являлись критическими показателями. Они без особых проблем могли «залатать» деньгами любую дыру в структуре тестов, подключив несколько дополнительных мощных серверов или расширив парк тестовых устройств.
Но рынок быстро меняется: число профессиональных автоматизаторов растет с каждым днем, поэтому не удивительно, что у многих QA-компаний появились выгодные предложения для среднего и малого бизнеса. Сегодня заказать создание 100-200 автотестов могут позволить себе владельцы практически любого небольшого приложения или сервиса. А вот заставить их работать эффективно, не «проглатывая» дорогостоящие ресурсы и не тратя десятки часов на выполнение, — и есть настоящий вызов. В этой статье мы поделимся двумя историями из нашей борьбы за производительность, не упуская трудностей, с которыми столкнулись во время путешествия сквозь мрачный лес прожорливых автотестов.
«Как начать автоматизировать» - первая тема в серии статей. Так как я обещал, я разъясню как для себя, так и для читателей, то, что я знаю про автоматизацию как специфически направленную деятельность со своими целями, поддерживающую тестирование.
Эта серия статей будет:
Короткой, примерно 5 минут на чтение, хотя это очень сложно для меня.
Практической – без воды, только эмпирические, полезные советы.
Основанной на личном опыте и плохих решениях. Я думаю, это очень полезно.
Автор: доктор Vu Nguyen, преподаватель, директор Инженерной службы KMS Technology
Перевод: Колесникова Виктория, инженер-тестировщик компании Bercut, Telegram: t.me/lifeoftesting
Определяющий фактор для успешного применения автоматизации тестирования программного обеспечения - выбор и использование правильного набора средств автоматизации тестирования. Это сложная задача, особенно для тех, кто раньше не сталкивался с автоматизацией тестирования, поскольку на рынке существует очень много инструментов, каждый из которых имеет разные сильные и слабые стороны. Нет инструмента, который бы соответствовал всем требованиям автоматизированного тестирования. Это затрудняет поиск подходящего решения. Узнайте, как правильно выбрать средство автоматизации для вашего проекта из приведенного ниже подробного сравнения Katalon Studio с другими популярными инструментами для автоматизации тестирования на рынке.
В Твиттере широко обсуждалось, кто должен отвечать за создание кода автотестов. Судя по тому, что я читал, люди разбились на два лагеря:
Группа, выступающая за то, что разработчики должны отвечать за создание большей части (если не всего целиком) кода автоматизации. Их основной аргумент в том, что разработчики лучше знают, как программировать, больше знают о структуре кода и его внутренней кухне, и поэтому лучше всего разбираются, как подцепить к нему код автотестов (в отличие от слепых попыток сделать это через пользовательский интерфейс).
Группа, ратующая за то, что тест-автоматизация требует отдельных, занимающихся только этим, инженеров-автоматизаторов, особенно для тестов выше юнит-уровня. Аргументируют это они тем, что для создания и поддержки хороших автотестов нужны специфические навыки, простирающиеся дальше навыков разработки.
В конце позапрошлого года я опубликовал статью, посвященную примерно этой же тематике. Перечитывая ее, я все еще согласен с собственным же мнением (что, безусловно, хорошо). Но пока я размышлял об этом, читал об этом и обсуждал этот вопрос с другими, я выявил несколько тонких (и не только) нюансов – а это тема для отдельной статьи.
Тест-автоматизация очень много для меня значит. Я выбрал эту специальность из множества доступных в поле разработки ПО. Когда я вижу, что она неверно применяется, или когда люди просто не понимают, что это такое – меня это бесит. У меня много вопросов к плохим процессам автоматизации, и сейчас вы узнаете об этом все!
Говорить «Это просто тест-сценарии»
Автоматизация тестирования – это не просто набор тест-сценариев. Это целый арсенал технологий, требующий дизайна, интеграции, и опыта. Разработка тест-автоматизации – это отдельная область. Когда вы говорите, что это всего лишь набор тест-сценариев – вы унижаете и оскорбляете ее. Это обесценивает те усилия, которых требует автоматизация, ведет к плохому масштабированию работы и отношениям «они против нас» между разработкой и QA.
Код тестов должен разрабатываться согласно таким же высоким стандартам, как и код продукта, но про это зачастую забывают. Это серьезно меня беспокоит, и стоит значительных временных и финансовых затрат благодаря своим последствиям. У меня много вопросов к плохому коду автотестов, и сейчас вы узнаете про это все!
Копипаста
Дупликация кода – это его рак. Особенно он свирепствует в тест-автоматизации, потому что шаги тестов зачастую повторяются. Но это не причина дублировать код! Используйте лучшие практики при создании кода, или готовьтесь к тому, что я забракую ваш код на код-ревью!
Жесткое кодирование конфигурационных данных
Автотесты должны быть способны запускаться в любом окружении без проблем. Не кодируйте намертво ссылки, логины, пароли и другие специфичные для конфигурации штуки! Считывайте их как ввод или файлы конфигурации. Нет ничего более раздражающего, чем переключить окружения и обнаружить – сюрприз! – что тесты не запускаются, хотя все значения в нем верны.
Хотите качественно подготовить продукт к релизу? В данной статье команда компании A1QA расскажет, как при грамотном планировании автоматизация тестирования поможет значительно сократить количество ручных проверок, ускорить процесс выхода на рынок и увеличить прибыль в меньший промежуток времени.
Нередко внедрение автоматизации начинается с поиска профессиональной команды, которая подбирает инструменты, разрабатывает решение. Это шаг верный, но не он должен быть первым.
С самого начала нужно решить, для чего же стоит внедрять автоматизацию и в каком объеме.
Грамотно разработанная стратегия позволит вам прочувствовать все преимущества автоматизации тестирования, а именно:
Получение более быстрых результатов тестирования;
Эффективное распределение ресурсов, направленных на тестирование;
Оптимизация затрат на обеспечение качества продукта и тестирование;
Безошибочное тестирование: качественный тест не допустит ошибки, которую может допустить человек;
Возможность более тесной интеграции тестирования с существующими процессами разработки продукта.
НА КАКИЕ ФАКТОРЫ ОБРАТИТЬ ВНИМАНИЕ ПРИ ПРИНЯТИИ РЕШЕНИЯ О ВНЕДРЕНИИ АВТОМАТИЗАЦИИ?
В докладе автор расскажет, как был организован запуск автоматических тестов (appium/javascript) в gitlab CI для нативного Android приложения на каждый Merge Request. Опишет, как можно встроить автотесты в существующий процесс сборки, как правильно настроить запуск тестов в docker image (тесты бегут в TestObject облаке), как произошла интеграция с клаудом и какие результаты это принесло. Tech stack: Gitlab CI, kubernetes, android, appium, javascript, testobject.
