Каждое успешное взаимодействие, которое происходит между вами и вашим любимым приложением, является результатом совместных усилий членов команды обеспечения качества (QA). Эти неутомимые охотники за проблемами следят за тем, чтобы каждый аспект приложений, от которых зависят повседневные нужды пользователей мобильных устройств во всем мире, работал без заминок во всех релизах и со всеми обновлениями, пишет на портале The New Stack Саид Хамид, генеральный директор и основатель Sofy, автоматизированной no-code-платформы тестирования мобильных приложений.

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

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

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

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

Давайте вспомним, как мы дошли до этого.

1980-е: ручное тестирование

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

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

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

1990-е — 2010-е: автоматизация тестирования с кодированием

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

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

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

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

2020-е: автоматизация тестирования без кодирования

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

Но затем наступило неизбежное. Благодаря принципу абстракции — когда представления, основанные на интерфейсе, перекрыли невероятную сложность процессов (представьте, например, единицы и нули, скрывающиеся за статьей, которую вы сейчас читаете). Многие специалисты уже давно предвещали появление нового уровня абстракции, «No-Code Revolution», и в последние несколько лет это действительно произошло.

Появилось несколько платформ, позволяющих использовать решения без кодирования (no-code) в самых разных отраслях. Одним из наиболее заметных примеров является популярность WYSIWYG-редакторов веб-сайтов (вспомните Squarespace или Wix). И даже в гораздо менее заметной области тестирования ПО уже доступна платформа, которая обеспечивает тестирование мобильных приложений без кодирования.

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

2025? По-настоящему интеллектуальное самотестирующееся ПО

Тем не менее, революция no-code — это всего лишь еще один шаг вперед, и следующим шагом в тестировании ПО будет ПО, которое само себя тестирует. Учитывая темпы изменений и развития технологий, вполне можно представить, что к 2025 г. интеллектуальная автоматизация тестирования (то есть самотестирующееся ПО), когда тестирующий ИИ работает без вмешательства человека, значительно расширится.

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

ИИ и МО используют алгоритмы глубокого обучения для доступа к данным и обучения на их основе путем извлечения закономерностей для более эффективной отладки и принятия решений. Благодаря этой технологии команды QA могут выполнять множество тестов на самых разных устройствах различных форм-факторов.

Не за дни, а за часы. Вот это революция!

No-code не значит отсутствие людей, а люди — не машины: они совершают ошибки. Даже при значительно сократившемся объеме кодирования человеческий фактор остается фактором, из-за которого все еще могут возникать серьезные проблемы. Примите также во внимание чрезмерное использование ресурсов, времени и усилий при тестировании с участием человека.

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

  1. Обучение на основе человеческого поведения. Когда машина тестирует, она должна действовать как человек. Она должна узнать, что нужно и чего хочет человек, и как он ведет себя с устройством. Это может быть трудно предсказать, и, как мы уже говорили, сложное приложение означает сложные сценарии и модели тестирования. Машина должна понимать и действовать с этой точки зрения.
  2. Обучение на основе данных о реальном использовании продукта. Важно, чтобы машина понимала, как приложение используется в различных средах. Это включает в себя понимание того, какие устройства могут использоваться, какой язык установлен на устройстве, а также потоков использования, включая использование меню, экранов и действия.
  3. Данные для обучения. Как и в случае с автономными транспортными средствами (орешек, который до сих пор не расколот), МО требует данных для обучения, которые помогают определить шаблоны ПО.

Эти три элемента должны быть освоены и тщательно протестированы для каждого изменения кода. Они должны быть объединены и приоритизированы органично и разумно. В этом нет ничего сложного, но каждый из этих этапов должен быть завершен, прежде чем мы сможем двигаться дальше. Но это только вопрос времени.

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