Skip to content

Latest commit

 

History

History
201 lines (124 loc) · 50.7 KB

obshee.md

File metadata and controls

201 lines (124 loc) · 50.7 KB
Raw

Общее

  • Автоматизация тестирования (test automation): Использование программного обеспечения для осуществления или помощи в проведении определенных тестовых процессов, например, управление тестированием, проектирование тестов, выполнение тестов и проверка результатов. (ISTQB)
  • Автоматизация выполнения тестов (test execution automation): Использование программного обеспечения (например, средств захвата/воспроизведения) для контроля выполнения тестов, сравнения полученных результатов с эталонными, установки предусловий тестов и других функций контроля тестирования и организации отчетов. (ISTQB)
  • Автоматизированное тестирование (scripted testing): Выполнение тестов, реализуемое при помощи заранее записанной последовательности тестов. (ISTQB)
  • Автоматизированное тестовое обеспечение (automated testware): Тестовое обеспечение, используемое в автоматизированном тестировании, например, инструментальные сценарии. (ISTQB)
  • Автоматизированный сценарий тестирования (test script): Обычно используется как синоним спецификации процедуры тестирования, как правило, автоматизированной. (ISTQB)

Автоматизированное тестирование (automated testing, test automation) - набор техник, подходов и инструментальных средств, позволяющий исключить человека из выполнения некоторых задач в процессе тестирования.

Многие задачи и действия, описанные в ИСО/МЭК/ИИЭР 29119-2 как процессы Менеджмента Тестирования и Динамического Тестирования, а также многие аспекты методов тестирования, представленные в ИСО/МЭК/ИИЭР 29119-4, могут быть автоматизированы. Автоматизация тестирования требует использования программного обеспечения, обычно называемого инструментами тестирования.

Области применения автоматизации:

  • Регрессионное тестирование: необходимость выполнять вручную тесты, количество которых неуклонно растет с каждым билдом, но вся суть которых сводится к проверке того факта, что ранее работавшая функциональность продолжает работать корректно.
  • Инсталляционное тестирование и настройка тестового окружения: множество часто повторяющихся рутинных операций по проверке работы инсталлятора, размещения файлов в файловой системе, содержимого конфигурационных файлов, реестра и т.д. Подготовка приложения в заданной среде и с заданными настройками для проведения основного тестирования.
  • Конфигурационное тестирование и тестирование совместимости: выполнение одних и тех же тест-кейсов на большом множестве входных данных, под разными платформами и в разных условиях. Классический пример: есть файл настроек, в нём сто параметров, каждый может принимать сто значений: существует 100^100 вариантов конфигурационного файла - все их нужно проверить.
  • Использование комбинаторных техник тестирования (в т.ч. доменного тестирования): генерация комбинаций значений и многократное выполнение тест-кейсов с использованием этих сгенерированных комбинаций в качестве входных данных.
  • Модульное тестирование: проверка корректности работы атомарных участков кода и элементарных взаимодействий таких участков кода - практически невыполнимая для человека задача при условии, что нужно выполнить тысячи таких проверок и нигде не ошибиться.
  • Интеграционное тестирование: глубокая проверка взаимодействия компонентов в ситуации, когда человеку почти нечего наблюдать, т.к. все представляющие интерес и подвергаемые тестированию процессы проходят на уровнях более глубоких, чем пользовательский интерфейс.
  • Тестирование безопасности: необходимость проверки прав доступа, паролей по умолчанию, открытых портов, уязвимостей текущих версий ПО и т.д., т.е. быстрое выполнение очень большого количества проверок, в процессе которого нельзя что-то пропустить, забыть или «не так понять».
  • Тестирование производительности: создание нагрузки с интенсивностью и точностью, недоступной человеку. Сбор с высокой скоростью большого набора параметров работы приложения. Анализ большого объема данных из журналов работы системы автоматизации.
  • Дымовой тест для крупных систем: выполнение при получении каждого билда большого количества достаточно простых для автоматизации тест-кейсов.
  • Приложения (или их части) без графического интерфейса: проверка консольных приложений на больших наборах значений параметров командной строки (и их комбинаций). Проверка приложений и их компонентов, вообще не предназначенных для взаимодействия с человеком (веб-сервисы, серверы, библиотеки и т.д.).
  • Длительные, рутинные, утомительные для человека и/или требующие повышенного внимания операции: проверки, требующие сравнения больших объёмов данных, высокой точности вычислений, обработки большого количества размещенных по всему дереву каталогов файлов, ощутимо большого времени выполнения и т.д. Особенно, когда такие проверки повторяются очень часто.
  • Проверка «внутренней функциональности» веб приложений (ссылок, доступности страниц и т.д.): автоматизация предельно рутинных действий (например, проверить все 30’000+ ссылок на предмет того, что все они ведут на реально существующие страницы). Автоматизация здесь упрощается в силу стандартности задачи - существует много готовых решений.
  • Стандартная, однотипная для многих проектов функциональность: даже высокая сложность при первичной автоматизации в таком случае окупится за счёт простоты многократного использования полученных решений в разных проектах.
  • “Технические задачи”: проверки корректности протоколирования, работы с базами данных, корректности поиска, файловых операций, корректности форматов и содержимого генерируемых документов и т.д.

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

  • Скорость выполнения тест-кейсов может в разы и на порядки превосходить возможности человека. Если представить, что человеку придётся вручную сверять несколько файлов размером в несколько десятков мегабайт каждый, оценка времени ручного выполнения становится пугающей: месяцы или даже годы. При этом 36 проверок, реализуемых в рамках дымового тестирования командными скриптами, выполняются менее чем за пять секунд и требуют от тестировщика только одного действия - запустить скрипт;
  • Отсутствует влияние человеческого фактора в процессе выполнения тест кейсов (усталости, невнимательности и т.д.). Продолжим пример из предыдущего пункта: какова вероятность, что человек ошибется, сравнивая (посимвольно!) даже два обычных текста размером в 100 страниц каждый? А если таких текстов 10? 20? И проверки нужно повторять раз за разом? Можно смело утверждать, что человек ошибется гарантированно. Автоматика не ошибется;
  • Средства автоматизации способны выполнить тест-кейсы, в принципе непосильные для человека в силу своей сложности, скорости или иных факторов. И снова наш пример со сравнением больших текстов является актуальным: мы не можем позволить себе потратить годы, раз за разом выполняя крайне сложную рутинную операцию, в которой мы к тому же будем гарантированно допускать ошибки. Другим прекрасным примером непосильных для человека тест-кейсов является исследование производительности, в рамках которого необходимо с высокой скоростью выполнять определённые действия, а также фиксировать значения широкого набора параметров. Сможет ли человек, например, сто раз в секунду измерять и записывать объем оперативной памяти, занимаемой приложением? Нет. Автоматика сможет;
  • Средства автоматизации способны собирать, сохранять, анализировать, агрегировать и представлять в удобной для восприятия человеком форме колоссальные объемы данных. В нашем примере с дымовым тестированием «Конвертера файлов» объем данных, полученный в результате тестирования, невелик - его вполне можно обработать вручную. Но если обратиться к реальным проектным ситуациям, журналы работы систем автоматизированного тестирования могут занимать десятки гигабайт по каждой итерации. Логично, что человек не в состоянии вручную проанализировать такие объёмы данных, но правильно настроенная среда автоматизации сделает это сама, предоставив на выход аккуратные отчеты в 2-3 страницы, удобные графики и таблицы, а также возможность погружаться в детали, переходя от агрегированных данных к подробностям, если в этом возникнет необходимость;
  • Средства автоматизации способны выполнять низкоуровневые действия с приложением, операционной системой, каналами передачи данных и т.д. В одном из предыдущих пунктов мы упоминали такую задачу, как «сто раз в секунду измерить и записать объем оперативной памяти, занимаемой приложением». Подобная задача сбора информации об используемых приложением ресурсах является классическим примером. Однако средства автоматизации могут не только собирать подобную информацию, но и воздействовать на среду исполнения приложения или само приложение, эмулируя типичные события (например, нехватку оперативной памяти или процессорного времени) и фиксируя реакцию приложения. Даже если у тестировщика будет достаточно квалификации, чтобы самостоятельно выполнить подобные операции, ему всё равно понадобится то или иное инструментальное средство - так почему не решить эту задачу сразу на уровне автоматизации тестирования?

Недостатки автоматизации:

  • Необходимость наличия высококвалифицированного персонала в силу того факта, что автоматизация - это «проект внутри проекта» (со своими требованиями, планами, кодом и т.д.). Даже если забыть на мгновение про «проект внутри проекта», техническая квалификация сотрудников, занимающихся автоматизацией, как правило, должна быть ощутимо выше, чем у их коллег, занимающихся ручным тестированием.
  • Разработка и сопровождение как самих автоматизированных тест-кейсов, так и всей необходимой инфраструктуры занимает очень много времени. Ситуация усугубляется тем, что в некоторых случаях (при серьёзных изменениях в проекте или в случае ошибок в стратегии) всю соответствующую работу приходится выполнять заново с нуля: в случае ощутимого изменения требований, смены технологического домена, переработки интерфейсов (как пользовательских, так и программных) многие тест-кейсы становятся безнадежно устаревшими и требуют создания заново.
  • Автоматизация требует более тщательного планирования и управления рисками, т.к. в противном случае проекту может быть нанесен серьезный ущерб (см. предыдущий пункт про переделку с нуля всех наработок).
  • Коммерческие средства автоматизации стоят ощутимо дорого, а имеющиеся бесплатные аналоги не всегда позволяют эффективно решать поставленные задачи. И здесь мы снова вынуждены вернуться к вопросу ошибок в планировании: если изначально набор технологий и средств автоматизации был выбран неверно, придётся не только переделывать всю работу, но и покупать новые средства автоматизации.
  • Средств автоматизации крайне много, что усложняет проблему выбора того или иного средства, затрудняет планирование и определение стратегии тестирования, может повлечь за собой дополнительные временные и финансовые затраты, а также необходимость обучения персонала или найма соответствующих специалистов.

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

  • Планирование, разработка тест-кейсов, написание отчетов о дефектах, анализ результатов тестирования и отчётность: компьютер пока не научился думать;
  • Функциональность, которую нужно (достаточно) проверить всего несколько раз, тест-кейсы, которые нужно выполнить всего несколько раз (если человек может их выполнить): затраты на автоматизацию не окупятся;
  • Низкий уровень абстракции в имеющихся инструментах автоматизации: придётся писать очень много кода, что не только сложно и долго, но и приводит к появлению множества ошибок в самих тест-кейсах.
  • Слабые возможности средства автоматизации по протоколированию процесса тестирования и сбору технических данных о приложении и окружении: есть риск получить данные в виде «что-то где-то сломалось», что не помогает в диагностике проблемы.
  • Низкая стабильность требований: придётся очень многое переделывать, что в случае автоматизации обходится дороже, чем в случае ручного тестирования.
  • Сложные комбинации большого количества технологий: высокая сложность автоматизации, низкая надёжность тест-кейсов, высокая сложность оценки трудозатрат и прогнозирования рисков.
  • Проблемы с планированием и ручным тестированием: автоматизация хаоса приводит к появлению автоматизированного хаоса, но при этом ещё и требует трудозатрат. Сначала стоит решить имеющиеся проблемы, а потом включаться в автоматизацию.
  • Нехватка времени и угроза срыва сроков: автоматизация не приносит мгновенных результатов. Поначалу она лишь потребляет ресурсы команды (в том числе время). Также есть универсальный афоризм: «лучше руками протестировать хоть что-то, чем автоматизированно протестировать ничего».
  • Области тестирования, требующие оценки ситуации человеком (тестирование удобства использования, тестирование доступности и т.д.): в принципе, можно разработать некие алгоритмы, оценивающие ситуацию так, как её мог бы оценить человек. Но на практике живой человек может сделать это быстрее, проще, надёжнее и дешевле.

Далее копипаста различных вопросов-ответов из цикла статей на хабре.

Зачем нужна автоматизация, если наши ручные тестировщики и так справляются?

Действительно, прежде чем вводить автоматизацию на проекте, потому что это “стильно, модно, молодежно”, и у всех оно есть, стоит учесть следующие факторы:

  • Как долго будет жить проект, каков его масштаб, насколько сильно и часто он меняется;
  • Оценить, насколько трудозатратно будет писать автотесты в каждом конкретном случае. Возможно, что автоматизировать ваш функционал будет гораздо сложнее, дольше и дороже, чем тестировать его руками;
  • Также, если на проекте ожидается “выпиливаем всё старое и пишем новое с нуля”, время автотестов еще не пришло.

Но если ваш проект:

  • стабильно развивается и растет;
  • увеличивается количество разработчиков;
  • приложение начинает обрастать новым функционалом.

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

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

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

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

Можно ли начать писать автотесты за один день?

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

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

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

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

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

Но вполне возможно, что у вашей команды не будет времени помогать вам с автотестами. К сожалению, такое возможно, и не стоит их за это винить. Если вы попали в такую ситуацию, не отчаивайтесь! В интернете очень мощное комьюнити тестировщиков. В том же самом телеграме есть чаты, где 24/7 вам ответят на все вопросы и помогут разобраться.

Можно ли заставить разработчиков писать автотесты?

В теории, конечно можно. Но скорее всего они будут не сильно этому рады, да и вряд ли кто-то будет рад в принципе.

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

Во-вторых, это дорого.

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

По факту, этот вопрос равен “Зачем нам тестировщики, если можно попросить разработчиков самим проверять то, что они написали?”.

Не замедляют ли автотесты разработку?

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

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

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

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

Можно ли писать 1 автотест сразу на обе платформы?

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

В чем главные проблемы кроссплатформенных фреймворков?

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

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

Во-первых, всё “сэкономленное” время в последствии может уйти на поддержку такого автотеста для двух платформ. Это может стать проблемой из-за обновляемой специфики разных ОС. Кроме того, часто поведение одной и той же фичи или кнопки может различаться для iOS и Android.

Во-вторых, если при выборе между кроссплатформенным фреймворком и нативными, главным аргументом является “выучить один язык программирования проще, чем два”, не спешите принимать решение. Синтаксис языков Kotlin и Swift очень похожи (по-крайней мере, в вопросах написания автотестов). Написав автотест на одном из языков, вы без труда напишете точно такой же для второй платформы.

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

Ровно тогда, когда:

  • на вашем проекте будет настроена стабильная инфраструктура,
  • автотесты будут встроены в ваш CI/CD, а не запускаться локально у кого-то, когда об их существовании вспомнили,
  • автотесты будут падать приемлемое для вас количество раз, то есть не будут флаковать.

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

За сколько месяцев можно прийти к 100% покрытию?

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

Во-первых, стоит рассматривать покрытие каждой фичи отдельно.

Во-вторых, глобально ответ на вопрос “на сколько у тебя покрыта эта фича” будет основываться на опыте и знании продукта тестировщика.

Оценивая покрытие фичи, я рассуждаю следующим образом:

все позитивные проверки - это 60-70% от всего покрытия,

далее добавляем негативные проверки (всевозможные прерывания, сворачивания-разворачивания экранов, зероскрины и т.п.) - получаем 90%.

Оставшиеся 10% - это сложновоспроизводимые сценарии, зависимости от других фичей и т.д., которые покрывать либо вообще не стоит (подумайте, выдержит ли такую нагрузку ваш CI и стоит ли того время на поддержку таких автотестов), либо оставлять это на самую последнюю очередь. Также добавлю, что не все фичи в принципе нужно автоматизировать. Иногда трудозатраты на автоматизацию какой-то невероятно сложной проверки сильно преувеличивают возможность один раз перед релизом быстро проверить ее руками. Чтобы не оставлять вопрос менеджера без ответа - выявляем среди всей функциональности приложения наиболее критичный и в нём смотрим, какое количество позитивных и негативных проверок нам нужно автоматизировать в первую очередь, чтобы быть уверенными, что функционал работает. Далее смотрим какое количество тестировщиков сколько времени готовы уделять автоматизации и считаем, как долго мы будем это автоматизировать.

Сколько нужно тестировщиков, чтобы автоматизировать весь проект?

Расскажу историю об автоматизации мобильных приложений в hh.ru.

В разные периоды времени у нас было от 2 до 4 тестировщиков на всё мобильное направление. Примерно за год мы пришли к практически полному покрытию регрессов на обе платформы. И это с учетом того, что мы продолжали тестировать функционал руками и проводить ручные регрессы, а на андроид дважды переезжали на новый фреймворк. В итоге, кстати, мы остановились на Kaspresso, с которым тесты стали сильно стабильнее и проще в написании. Каждый переезд был большим объемным рефакторингом, так как до этого мы уже успели написать какое-то значительное количество автотестов. Но тем не менее, за один год регрессы были автоматизированы.

Иными словами, любым количеством тестировщиков можно автоматизировать проект, если выделить на это достаточно времени. Но возникает вопрос: как тестировщику успевать и руками тестировать, и автотесты писать? Иногда это действительно сложно. Особенно если идет большой поток нового функционала, который срочно нужно тестировать. Всем хочется успеть в релиз, и задачам ставят больший приоритет. Знакомая ситуация. Что делать? Садимся. Понимаем, что автотесты в недалеком будущем принесут нам максимум пользы и выделяем каждому тестировщику, например, один день в неделю под автоматизацию. Мы такое практикуем, когда у тестировщиков завал с ручным тестированием, и это работает. Для автоматизации можно выбрать день после релиза, когда уже ничего не горит, и тестировщик с чистой совестью может писать автотесты, не отвлекаясь на другие задачи.

Как вам живется с автоматизированными регрессами?

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

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

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

Много ли времени уходит на поддержку автотестов?

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

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

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

Насколько сложно найти мобильного автоматизатора?

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

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

Источники:

Доп. материал: