Home

Автор: Джеспер Оттосен (Jesper Ottosen)
Оригинал статьи
Перевод: Ольга Алифанова

Если тестирование можно интегрировать в разработку, то кто тестирует, если кода еще нет? Должен ли код существовать для того, чтобы существовало тестирование, и в какой момент тестирование можно начинать?

Нынче появился новый тип бизнес-приложений – продукты "Мало кода / без кода". Например, это платформа WordPress, при помощи которой я это пишу. Еще пример более высокоуровневого решения - AirTable, позволяющий пользователю быстро и без кода организовать и автоматизировать информацию. Схожий тренд наблюдается в пространстве тест-инструментов вроде Cypress и Mabl, тест-кейсы и сценарии напрямую присоединяются к end-to-end бизнес-цели, а не к технологиям. Инструменты "низкого кода" – это новый тип бизнес-решений для "кастомизации" и "конфигурации".

Эволюция и группы продуктов (ось Х Wardley Maps)

Это явный тренд, который возник довольно давно.

"Низкий код/No-code разрушит весь паттерн по мере того, как организации осознают, что могут еще успешнее внедрять цифровую трансформацию, вообще отказавшись от ручного кодирования и вместо этого используя низкий код/No-code. "No-code уже здесь, и ему наплевать на повышение эффективности вашей IT-организации", объясняет Э. Скотт Ментер, ведущий стратегический директор BP Logix. "Его единственная задача – превратить ваш бизнес в технически трансформированный, игнорирующий аудит, устойчивый к барьерам объект желаний потребителей".

(Из статьи The Low-Code/No-Code Movement: More Disruptive Than You Realize)

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

(Из статьи No-code Revolution. Why Now?)

Ось Y Wardley Mapping: Близость к пользователю / Требуемый код

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

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

Карта Wardley: Низкий код развивается и выигрывает у "высокого кода"

Один из способов увидеть этот тренд: в то время, как существует "Robot Framework" и другие веб-фреймворки с открытым исходным кодом, похожие на RPA, подход к стандартным тест-решениям склоняется к низкому коду:

• Automating Complex End-to-End Tests (SalesForce / Testim)
• What to look for in a SAP test automation tool (SAP / LeapWork)

Возможно, инструменты RPA и схожие инструменты низкого кода можно сравнить с макросом If This Then That, где вы можете автоматизировать нудные повторяющиеся задачи – тоже инструмент вашего бизнес-арсенала. Но даже в случае с инструментами низкого кода сложность скриптов может превратить это в кошмар, а визуальные скрипты нуждаются в хороших практиках программирования.

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

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

Простая иллюстрация модели пионеров, поселенцев и градостроителей

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

Код для осуществления тестирования не нужен.

Обсудить в форуме