Мне кажется, что у нас всегда были отношения любви и ненависти с концепцией тестирования. Несомненно, тестирование всего, что вы создаете, помогает избежать того, чтобы клиенты сообщали о тех же открытиях. Это и есть любовная часть отношений.
Самое неприятное, когда из-за сроков проекта тестирование становится менее приоритетным… часто до такой степени, что оно превращается в пункт списка пожеланий бэклога, который редко появляется в текущем спринте. Это почти гарантирует, что клиенты будут обращаться к вам с неожиданными результатами.
С развитием жизненного цикла разработки программного обеспечения (SDLC) тестирование стало проще, позволяя разработчикам создавать модульные тесты, которые полностью покрывают проверяемый аспект. Использование ChatGPT или GitHub Co-Pilot дошло до того, что такие юнит-тесты можно генерировать автоматически. Инструментальные решения для непрерывной интеграции (CI) стали более совершенными, чтобы обеспечить высокий уровень покрытия кода до слияния любого запроса на притяжение (PR). Это позволяет командам сдвинуться влево при разработке, заставляя решать проблемы на этапе разработки и снижая стоимость функций на этом этапе.
Такой подход отлично подходит для традиционных API и веб-фреймворков, но тестирование мобильных приложений часто требует от команд ручного тестирования – выполнения опубликованного списка шагов на максимально возможном количестве различных типов устройств.
Я хотел посмотреть, смогу ли я найти способ, с помощью которого мобильная разработка и тестирование могут использовать концепцию shift-left.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Чего не хватает в мобильном тестировании
На высоком уровне пространство мобильных приложений должно иметь возможность тестировать функции и функциональность так же, как сегодня тестируются API и веб-фреймворки. Это означает, что необходимо отказаться от ручного выполнения тестов с помощью физических устройств или эмуляторов.
В идеале мобильное тестирование должно быть ориентировано на пользовательский интерфейс, чтобы избежать написания криптографических тестов, ориентированных на действия пользователя. Такой подход может расширить инструментарий для внутренних потребителей или владельцев продуктов, которые хотят подтвердить свое видение в реальности.
Как и традиционные модульные или интеграционные тесты, возможность внедрения модулей позволяет проверять небольшие аспекты мобильного приложения и использовать их в качестве строительных блоков для более крупных потоков. При этом команды смогут оставаться “сухими” (не повторяться) и избегать дублирования работы.
Наконец, эти тесты должны быть способны стать частью конвейера CI/CD, несмотря на то, что управляются графическим пользовательским интерфейсом.
В этом идеальном случае инженеры, занимающиеся разработкой и тестированием мобильного программного обеспечения, могут эффективно переключиться влево.
Что такое “сдвиг влево”?
Неплохо бы уточнить, что я имею в виду, когда говорю о “сдвиге влево” для мобильного тестирования.
Википедия определяет сдвиг влево для тестирования, как указано ниже:
“Тестирование со сдвигом влево” – это подход к тестированию программного обеспечения и систем, при котором тестирование выполняется на более ранних этапах жизненного цикла (т.е. сдвигается влево на временной шкале проекта). Это первая половина максимы “тестировать рано и часто”. Ее придумал Ларри Смит в 2001 году“.
Простое использование левого сдвига позволяет выявлять дефекты на этапе разработки. Это важно, поскольку проблему можно решить, пока функция еще свежа в памяти инженера (инженеров), сосредоточенного на источнике.
Вот некоторые из преимуществ перехода на левый флаг:
- Сокращение затрат на доставку функций за счет поиска и устранения проблем на этапе разработки.
- Повышение эффективности за счет сокращения времени, необходимого для повторного рассмотрения решений в течение длительного времени после поставки.
- Более высокое качество благодаря тому, что на этапе разработки приходится полностью покрывать и проверять.
В конечном итоге левая концепция приведет к конкурентному преимуществу, когда потребителям будут доступны проверенные и работающие в соответствии с ожиданиями решения.
О Tosca
В прошлом году я исследовал возможности использования Tricentis Testim в своей статье “Улучшение качества приложений для клиентов с помощью Tricentis Testim“. Я был впечатлен тем, как легко было проверить мое решение Magic 8 Ball с помощью RESTful API на базе GO и веб-клиента на базе Vue.js. Я хотел узнать, есть ли у Tricentis решение, которое позволило бы командам сдвинуться влево для мобильного тестирования.
Оказалось, что у них есть продукт под названием Tosca.
Продукт Tosca обеспечивает генерацию тестов без кода, позволяя создавать небольшие модули, которые можно повторно использовать и автоматизировать. Эти модули можно представить как блоки Lego, которые можно соединять между собой по мере необходимости благодаря использованию стандартизированного контракта между ними. Tosca делает еще один шаг навстречу традиционному жизненному циклу разработки, предоставляя возможность использовать искусственный интеллект для создания мобильных тестов для ваших функций.
Tosca также использует возможности проекта Appium с открытым исходным кодом без тяжелой кривой обучения с помощью мобильного агента Tricentis. Это позволяет использовать все возможности, описанные в моей предыдущей статье, при переходе к мобильной разработке.
В результате Tosca позволяет тестировать нативные, гибридные и веб-приложения на реальных устройствах iPhone, Android, мобильных телефонах и планшетах, не имея в своем распоряжении этих устройств.
Как и продукт Testim, решение Tosca обеспечивает возможность выполнения тестов в рамках конвейеров CI/CD, что позволяет внедрять “сдвиг влево”.
Вы можете использовать Tosca для тестирования на телефонах с iOS или Android напрямую, а также с помощью эмуляторов или симуляторов, доступных через IDE, например Android Studio. С помощью Tosca можно отсканировать приложение и создать тестовые примеры:
После того как Tosca создала тестовые примеры, вы также можете создать собственные тестовые примеры.
Одно из преимуществ Tosca заключается в том, что она позволяет писать тесты без необходимости писать код. Это возможно благодаря библиотеке модулей, которые могут имитировать практически любое действие, включая открытие браузера или заполнение формы.
В этом примере мы использовали три модуля для нашего тестового случая Tosca для мобильных устройств. Мы тестируем:
- Открываем браузер и переходим на конечную точку нашего приложения
- Выбор конкретного типа автомобиля
- Заполнение формы о конкретном автомобиле
Обратите внимание, что все, что нам нужно было сделать, – это предоставить образцы входных данных (на скриншоте мы делаем это для шага 3, выделенного выше). После завершения теста вы получите отчет о диагностике Tosca.
Сдвиг влево для мобильного тестирования
Используя такой продукт, как Tosca, инженеры-программисты, занимающиеся мобильной разработкой, получают конкурентное преимущество, применяя для тестирования мобильных устройств “левое дерьмо”:
- Мобильные функции проверяются на этапе разработки, как и сервисы и веб-фреймворки.
- Тесты проводятся на основе пользовательского интерфейса, который может быть расширен для внутренних потребителей и владельцев продукта, чтобы помочь укрепить их видение.
- Набор тестов может быть построен из набора “сухих” модулей, которые структурированы таким образом, чтобы полностью охватить новые возможности и функциональность.
- Тесты можно выполнять на исчерпывающем перечне мобильных устройств, не владея ими и не обслуживая их.
- Прежде чем внедрять новые функции в основную ветку кода, связанный с ней PR должен был вызвать генерируемые UI-тесты так же, как выполняются модульные или интеграционные тесты в CI/CD конвейерах API или веб-фреймворков.
Заключение
Мои читатели, возможно, помнят, что я сосредоточился на следующей формулировке миссии, которая, как мне кажется, может быть применима к любому ИТ-специалисту:
“Сосредоточьте свое время на создании возможностей/функциональности, которые повышают ценность вашей интеллектуальной собственности. Для всего остального используйте фреймворки, продукты и сервисы”.
– J. Vester
Чтобы достичь максимальной производительности, инженеры-программисты, занимающиеся мобильной разработкой, должны использовать левый сдвиг для мобильного тестирования. Однако при выборе идеального варианта следует учитывать все связанные с этим кривые обучения и возможности поддержки при поиске решений.
Продукт Tosca соответствует моей личной миссии, позволяя командам достичь состояния shift-left без дополнительного исходного кода для поддержки и сопровождения. Продукт также позволяет неинженерам участвовать в разработке тестов, что дает командам преимущество в обеспечении соответствия дизайна ожиданиям.
Я лично применяю подход “сдвиг влево” уже несколько лет и ценю опыт каждый раз, когда удается избежать дефектов благодаря простому следованию процессу. Пришло время и мобильной разработке использовать концепцию сдвига влево.
Желаю вам отличного дня!
Перевод статьи «Why You Need to Shift-left with Mobile Testing».