Зачем нужна автоматизация тестирования

Для чего нужна автоматизация тестирования

Ни один IT-продукт или ПО не может выйти на рынок, не подвергаясь тщательному тестированию. На сегодняшний день существует две разновидности тестирования: ручное, которым занимаются QA manual, и автоматизированное, выполняемое специалистами SDET.

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

Грамотно выстроенный курс автоматизации тестирования и команда профессионалов позволяют ускорить процесс вывода ПО на рынок, а также сэкономить время и бюджетные средства разработчика.

Как выбрать курсы по автоматизации тестирования?

Профессия автоматизированного тестировщика или SDET — одна из самых популярных и востребованных специализаций практически во всем мире. Мировые гиганты, такие, как Google, Meta, Amazon принимают в свою команду специалистов QA, FullStack и SDET на регулярной основе.

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

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

Что включает в себя курс автоматизации тестирования от Test Pro

Школа тестировщиков Test Pro проводит набор студентов по специальностям QA Engineer, SDET-автоматизатор, FullStack-разработчик. Наши курсы по автоматизации тестирования входят в перечень лучших образовательных IT-курсов.

Курс «автоматизация тестирования» от Test Pro включает в себя 3 основных этапа:

• Изучение основной теоретической базы: технологий SDLC и STLC, методов работы с документами, специфики тестирования, особенностей архитектуры приложений (мобильных и веб-приложений) и т.д;
• Изучение продуктов и функционала, языка Java;
• Освоение Selenium WebDriver.

Всего за 2,5 месяца интенсивного обучения вы освоите самую востребованную профессию современности. Ознакомиться с программой курсов и выбрать наиболее подходящий вариант на пути к развитию своей карьеры можно онлайн на нашем сайте, а также обратившись к специалисту Test Pro через формы Apply или Book a call. Также приглашаем вас на наш официальный YouTube канал.

Часто задаваемые вопросы

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

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

Наши курсы входят в ТОП мировых образовательных программ. Мы гарантируем, что курсы “Автоматизация тестирования” позволят Вам в течении короткого срока получить и усвоить полный багаж знаний, который позволит выйти на новый уровень дохода.

У нас доступны курсы QA, SDET, FULLSTACK. Ознакомиться с каждым из них и сделать свой выбор можно самостоятельно или после консультации с нашим менеджером.

Зачем нужно автоматизировать?

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

Преимущества автоматизации тестирования:

• Повторяемость – все написанные тесты всегда будут выполняться однообразно, то есть исключен «человеческий фактор». Тестировщик не пропустит тест по неосторожности и ничего не напутает в результатах.
• Быстрое выполнение – автоматизированному скрипту не нужно сверяться с инструкциями и документациями, это сильно экономит время выполнения.
• Меньшие затраты на поддержку – когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную.
• Отчеты – автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.
• Выполнение без вмешательства – во время выполнения тестов инженер-тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время (этот метод предпочтительнее, так как нагрузка на локальные сети ночью снижена).

Недостатки автоматизации тестирования (их тоже немало):

• Повторяемость – все написанные тесты всегда будут выполняться однообразно. Это одновременно является и недостатком, так как тестировщик, выполняя тест вручную, может обратить внимание на некоторые детали и, проведя несколько дополнительных операций, найти дефект. Скрипт этого сделать не может.
• Затраты на поддержку – несмотря на то, что в случае автоматизированных тестов они меньше, чем затраты на ручное тестирование того же функционала – они все же есть. Чем чаще изменяется приложение, тем они выше.
• Большие затраты на разработку – разработка автоматизированных тестов это сложный процесс, так как фактически идет разработка приложения, которое тестирует другое приложение. В сложных автоматизированных тестах также есть фреймворки, утилиты, библиотеки и прочее. Естественно, все это нужно тестировать и отлаживать, а это требует времени.
• Стоимость инструмента для автоматизации – в случае если используется лицензионное ПО, его стоимость может быть достаточно высока. Свободно распространяемые инструменты как правило отличаются более скромным функционалом и меньшим удобством работы.
• Пропуск мелких ошибок — автоматический скрипт может пропускать мелкие ошибки на проверку которых он не запрограммирован. Это могут быть неточности в позиционировании окон, ошибки в надписях, которые не проверяются, ошибки контролов и форм с которыми не осуществляется взаимодействие во время выполнения скрипта.

Для того чтобы принять решение о целесообразности автоматизации приложения нужно ответить на вопрос «перевешивают ли в нашем случае преимущества?» — хотя бы для некоторой функциональности нашего приложения. Если вы не можете найти таких частей, либо недостатки в вашем случае неприемлемы – от автоматизации стоит воздержаться.

При принятии решения стоит помнить, что альтернатива – это ручное тестирование, у которого есть свои недостатки.

В поиске эффективных мест для автоматизации вам может помочь глава «Что необходимо автоматизировать».

Автоматизация тестирования: как избежать распространенных ошибок

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

Быть или не быть

Вам гарантированно нужна автоматизация тестирования, если:

• У вас проект длительностью в год или больше. Количество тестов, которые нужно прогонять в рамках регрессии, стремительно растет, а рутину нужно искоренять в первую очередь. Тестировщики должны тестировать, а не проходить тест-кейсы.
• У вас распределенная команда разработки либо в команде больше двух разработчиков. Разработчик должен быть уверен, что его изменения не сломают чужой код. Без авто-тестов он узнает об этом в лучшем случае через день-два, в худшем — от пользователей.
• Вы поддерживаете несколько версий продукта и выпускаете патчи и сервиспаки под каждую из них. Тут все очевидно: тестирование на разных конфигурациях — это рутина, а рутину надо искоренять.
• Вы разрабатываете сервис, основная задача которого — обработка и трансформация всевозможных данных. Заниматься ручным вбиванием в систему данных и визуальным анализом результатов или отправкой запросов и анализом ответов — это вообще не то, чем должны заниматься живые люди каждый день.
• У вас аджайл с короткими итерациями и частыми релизами. Времени на ручной прогон регрессии в рамках спринта катастрофически нет, а знать, что всё в порядке в тех местах, куда не лазили тестировщики, необходимо.

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

Зачем вообще нужны авто-тесты

Любая автоматизация нужна, чтобы избавить человека от рутинной работы. Автоматизация тестирования — в том числе. Однако существует также ошибочное мнение, что авто-тесты должны полностью вытеснить труд ручного тестировщика, и тестировать продукт должны скрипты. Это, конечно же, ерунда. Никакой скрипт пока не в силах заменить живого человека. Никакой скрипт пока что не умеет тестировать. Всё что умеет скрипт — это повторять запрограммированные человеком действия и сигнализировать, что что-то пошло не так, то есть делать простые проверки. И скрипт умеет делать это быстро и без участия человека.

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

Почему ожидания не оправдываются

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

Управленческие решения — это тема для отдельной статьи, а пока я просто выделю самые вредные ошибки без объяснений:

• Попытка сэкономить на найме специалистов в области автоматизации. Если менеджер считает, что он может отправить своих тестировщиков на курсы по Selenium и они ему сделают автоматизацию, то он не прав.
• Попытка внедрить автоматизацию без грамотно продуманной стратегии и планирования, типа «Давайте будем внедрять, а там посмотрим». Или чего хуже — автоматизация ради автоматизации: «У соседа есть, и мне нужно; зачем не ясно, но нужно».
• Слишком поздний старт: тесты начинают автоматизировать только тогда, когда тестировщики уже совсем загибаются.
• Убеждение, что дешевле нанять студентов, которые будут кликать регрессию руками (то есть вообще не делать автоматизацию, притом что присутствуют все признаки проекта, которому нужна автоматизация).

Под инженерными решениями я понимаю те решения, которые принимают инженеры при разработке и внедрении стратегии автоматизации. Это выбор инструментов, видов тестирования, фреймворков и т.п.

Пройдемся по некоторым моментам с инженерной точки зрения.

Почему автоматизация только UI-тестов — зло

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

UI-тесты — это то, что делают тестировщики, это естественный путь тестирования приложения. Более того, это симуляция того, как пользователи будут взаимодействовать с приложением. Казалось бы, это идеальный и единственно верный вариант, и именно его надо применять в автоматизации в первую очередь. Но есть, как говорится, нюанс:
— UI-тесты нестабильны;
— UI-тесты медленные.

Нестабильны они потому, что тесты зависят от «верстки» интерфейса приложения. При изменении порядка следования кнопок на экране или добавлении/удалении какого-то элемента тесты могут сломаться. Инструмент автоматизации не может найти нужный элемент либо может нажать совершенно не ту кнопку, и логика теста изменится.

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

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

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

Что же делать

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

Первое, что нужно в общем случае — это договориться с разработчиками, чтобы они не забывали прописывать для элементов уникальные атрибуты, по которым инструмент автоматизации может их однозначно идентифицировать. То есть, нужно по максимуму отказаться от пятиэтажных xPath-выражений или CSS-селекторов, и, по возможности, везде использовать уникальные id, name и т.п. Это должно быть явно прописано в девелопмент-гайдах и выступать одним из пунктов в definition of done для разработчиков. Тогда даже в случае капитального переколбаса пользовательского интерфейса у вас есть шанс отделаться легким испугом.

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

Тестируемое приложение должно давать возможность себя протестировать. Если такой возможности нет, то приложение нужно либо модифицировать, либо выбросить.

Кроме того, не лишним будет, научить инструмент автоматизации грамотно ждать момента, когда элемент становится доступным для взаимодействия или изначально использовать что-то типа Selenide, где такой проблемы нет by design.

Ускоряемся. Если с нестабильностью всё достаточно просто, то проблема медленных тестов должна решаться комплексно, так как она влияет на процесс разработки в целом.

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

Второе, что нужно делать, — это изначально закладывать в тестовый фреймворк и дизайн тест-кейсов возможность независимого и параллельного запуска. Параллелизация тестовых запусков позволяет очень существенно сократить время исполнения. Правда, тут тоже есть ограничения. Во-первых, не всегда логика тестируемого приложения позволяет тестировать его в несколько потоков. Такие ситуации довольно специфичны и редки, но они бывают. Во-вторых, тут тоже всё упирается в железо: невозможно параллелить до бесконечности.

Третье и самое радикальное — создавать как можно меньше UI-тестов. Меньше тестов — раньше получаем результат их прогона.

Пирамида тестирования

Все помнят знаменитую пирамиду тестирования?

Если под маленькую пирамиду на ночь положить тупую бритву, то к утру она снова станет острой ©.

Пирамида — это очень удобная метафора, она наглядно показывает желаемое количество автоматизированных тестов относительно каждого из уровней архитектуры системы. Должно быть много низкоуровневых юнит-тестов и совсем мало высокоуровневых UI-тестов. Вопрос в том, почему именно так и почему все так носятся с этой пирамидой?

Тут всё просто. Вспомним, как обычно выглядит процесс нахождения и исправления проблемы в приложении, когда его тестируют вручную. Сначала разработчик вносит новые изменения в код. Тестировщик ждет сборку и деплой нового билда на тестовый стенд. Тестировщик проводит тестирование, находит проблему и заводит тикет в баг-трекинговой системе. Разработчик моментально реагирует на этот тикет и исправляет проблему. Это новые изменения в код, и потом снова билд, деплой, ретест. Если всё ок — тикет закрывается. Время от выявления проблемы до ее исправления составляет от нескольких часов до нескольких суток или даже недель.

Что происходит, когда тот же тест автоматизирован через UI? Всё так же надо ждать, пока соберется и задеплоится новая версия, потом ждать, пока завершатся тесты. Потом надо проанализировать результаты прогона. Если были проблемы — определить, где эти проблемы возникли: в самом тесте или в приложении. Потом нужно еще раз прогнать упавший тест руками, чтобы наверняка понять, в чем проблема. Завести тикет, подождать пока пофиксят, перезапустить тест, убедиться, что теперь тест зеленый, закрыть тикет. Опять же — от пары часов до пары дней/недель. Плюс только в том, что этот тест автоматический, и пока он работает, тестировщик тестирует что-то другое.

Другая история, когда есть автоматизированные тесты, которые используют API для общения с бек-эндом приложения. Тут уже есть вкусные варианты:

— Тесты гоняются на полностью задеплоенном приложении со всеми внешними системами. По сравнению с чистыми UI-тестами, сильно сокращается время выполнения и анализа результатов, так как тут гораздо меньше ложно-позитивных срабатываний. В остальном всё так же, как и в UI-тестах.

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

— Ну и конечно самая вкуснота — это юнит- и компонентные авто-тесты. Они не требуют сборки всего проекта, запускаются сразу после компиляции модуля без выхода из любимой IDEшки, отклик — мгновенный. Время от внесения изменений до исправления возможных проблем практически равно минутам.

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

Комплексный подход

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

UI-тесты же тестируют целостную систему, именно то, что будет использовать пользователь. Критически важно иметь такие тесты в наличии.

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

Test Driven Development — это уже даже не рекомендация, это должно исходить от разработчика по умолчанию. Только тогда можно избежать головняков при рефакторинге и типичных проблем разработки в больших командах.

На уровень API-тестов нужно опускать все функциональные тесты, которые тестировщики проводили на протяжении спринта. Негативные, позитивные, комбинаторные и т.п. Тем самым создается быстрый и стабильный пакет регрессионных тестов.

На уровень UI-тестов выносятся исключительно приемочные тесты, так называемые Happy Path или End-To-End сценарии, которые показываются во время демо. Это относится как к веб-, так и к мобильным приложениям.

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

Резюме

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

�� Подобається Сподобалось 1

До обраного В обраному 2

Что дает автоматизация тестирования

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

Одни компании ошибочно считают, что автоматизация – пустая трата времени и средств, другие – что это крутой тренд и «таблетка» от всех болезней. Рассмотрим, где золотая середина и в чем смысл автоматизации.

Зачем тестировать

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

Например, одна из знаменитых “аварий” финансового мира произошла в Первом национальном банке Чикаго в конце 90-х: в одночасье счета клиентов безосновательно выросли на 900 миллионов долларов. Тогда старший вице-президент банка Джеймс Ланкастер признал, что дело в «программной ошибке в компьютере» – которую, к счастью, никто не успел использовать.

Дорогостоящие ошибки бывают и в других отраслях, казалось бы, не связанных напрямую с IT. Известный пример – аварии при запуске космической техники, в частности, в 2017 году Роскосмос утратил спутник стоимостью 2,6 млрд рублей.

При работе с масштабными IT-решениями, например, системами дистанционного банковского обслуживания (ДБО), важно постоянно тестировать не только работу отдельных функциональностей, но и их взаимодействие. В условиях сжатых сроков, когда ведущие банки каждый месяц обновляют свои приложения, проверить все вручную невозможно – на это как минимум не хватит времени.

При создании IT-продуктов для бизнеса обычно сочетают два подхода:

• осуществляют проверки вручную, с помощью специалистов QA (Quality Assurance);
• комбинируют ручное тестирование и автоматизацию ключевых тест-кейсов, с помощью экспертов SDET (Software Development Engineer in Test).

Что дает автоматизация

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

1. решит все проблемы выпуска качественного ПО;
2. позволит отказаться от ручного тестирования;
3. необходима просто потому, что является «крутым трендом»;
4. ускорит выпуск релизов;
5. увеличит покрытие платформ и версий операционных систем при тестировании.

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

Когда автоматизация обязательна

• Масштабное приложение с большим количеством бизнес-функций
• Значительный срок жизни приложения (от 1 года и более)
• Внедрение CI/CD, регулярные релизы + небольшое количество QA специалистов

Задачи автоматизации

Как правило, мы привлекаем экспертов SDET для решения следующих задач:

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

Результаты

Автоматизация помогает выстроить баланс:

• проверять вручную то, что требует человеческого внимания (как правило, до 25% кейсов);
• автоматизировать остальные кейсы.

Кроме того, при необходимости можно ускорить релизы. Например, если в спринте разработки нужно проверить около 400 кейсов, то их ручная проверка займет до двух недель, а автотесты можно провести ночью и проанализировать за 4 часа.

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

Пример

Предположим, что на текущий момент в мобильном банке нужно проходить до 700 кейсов, каждый – от 70 до 100 раз в год. Ручной проверки требуют менее 25% кейсов, остальные 75% можно автоматизировать.

Затраты времени при ручной проверке:

Затраты времени при автоматизации:

Ночной прогон тестов занимает 8 часов, но без участия человека, поэтому не учитывается.

Прочие затраты времени:

• 8 часов на ручную проверку кейсов, которые нельзя покрыть автотестами (25%);
• 6 часов на анализ результатов, а также, если необходимо, на проверку отказов (до 10% тестов).

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

В среднем, автоматизация экономит от 30 до 50% времени как минимум, позволяя выделить больше времени, например, на развитие и улучшение продукта.

Как происходит автоматизация тестирования

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

Процесс тестирования начинается с разработки стратегии – тест-плана, основы для составления отдельных тест-кейсов. Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом – такие сценарии дают около 80% бизнес-ценности.

После этого мы создаем основу для дальнейших автотестов, настраиваем стенды и workflow по работе с ними, CI для регулярного запуска тестов на различных ветках. Мы выбираем, какие подходы к подготовке тестовых данных мы будем использовать (API, доступ к базам данных, генерация синтетических данных, использование данных с прода). Инженеры SDET пишут тесты, которые покрывают ключевые сценарии работы с продуктом, анализируют полученные результаты и необходимость дальнейшей автоматизации.

Мы разрабатываем автоматизированные тесты, используя все наиболее востребованные языки программирования – Java, Python, Kotlin и др. Наши основные инструменты и технологии – Appium, TestNG | JUnit, RobotFramework | Pytest, Selenium | Senenide, Allure, TeamCity, Jenkins, JMeter.

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

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

Подводя итоги

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

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

Спасибо за внимание!

Авторские материалы для QA- и SDET-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.

• SimbirSoft
• SDET
• QA
• автоматизация тестирования
• обеспечение качества
• тестирование

• Блог компании SimbirSoft
• Тестирование IT-систем