Рассвет TestOps

Как самые хорошо финансируемые, сложные команды тестирования программного обеспечения на планете проверяют все? — они этого не делают! Существует новый способ тестирования, который обеспечивает отличное покрытие, раннее обнаружение важных ошибок и гарантирует, что основная функциональность работает в каждом новом выпуске. Этот новый способ не очень хорошо описан, потому что он кажется капитуляцией для некоторых, но это прямой ответ на поставку высококачественного программного обеспечения, которое поставляется каждый месяц, неделю, даже каждый день. Ключ к поставке современного программного обеспечения с новыми функциями и не нарушая существующую функциональность - это "TestOps".

TestOps, как и DevOps, - это конвергенция тестирования с операциями и разработкой. Мы знаем, что большинство тестов сегодня слишком медленные и ненадежные, чтобы идти в ногу с развитием и операциями — даже в самых лучших ситуациях. Да, DevOps часто занимается тестированием API и модульные тестированием, которые быстро проверяют изолированные части программы. Тем не менее, все мы сталкиваемся с серьезными ошибками и регрессиями в производственном программном обеспечении. Чего не хватало, так это быстрого, автоматизированного, e2e тестирования, когда тестируется весь продукт, чтобы убедиться, что все это работает вместе и для конечного пользователя.

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

Принципы TestOps:

1. Автоматизируйте только самые простые, надежные и важные тесты.
2. Выполняйте их как можно чаще.
3. Будьте внимательны к любым сбоям.

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

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

Ушли в прошлое дни традиционных панелей результатов тестирования — ни у кого нет времени смотреть на них. Даже тестировщики не хотят пялиться на сетки зеленых и красных квадратов с диаграммами пончиков и бессмысленными % - ными итогами прохождения тестов. Люди только хотят знать, что сломалось, что гарантирует блокировку следующего выпуска. Поскольку TestOps тестирует только ключевые функциональные возможности, по определению, когда эти тесты терпят неудачу, команды разработки и эксплуатации должны немедленно узнать об этом. Если тест проваливается, но не гарантирует отправки текстового сообщения руководителю разработки или пробуждения некоторых сотрудников по операциям, тест недостаточно важен, чтобы быть включенным в TestOps. Сбои TestOps должны передаваться в режиме реального времени с помощью пользовательских электронных писем, текстовых сообщений или более формальных эскалаций с помощью таких инструментов, как PagerDuty.

TestOps только сейчас стал реалистичным вариантом благодаря внедрению ИИ в мир тестирования. Большинство команд TestOps используют ИИ для разработки тестов, выполнения тестов или проверки тестов. Традиционная автоматизация тестирования часто жестко привязана к конкретным элементам пользовательского интерфейса или конкретным пользовательским потокам. Но эти тестовые сценарии хрупки и ломаются всякий раз, когда меняется внешний вид или поток приложения. Более того, почти каждая команда развертывается на нескольких платформах, таких как iOS, Android, Desktop, Web, даже встроенные устройства, — для этого требуется другой сценарий для каждой платформы и повышенная сложность для каждого тестового случая. ИИ меняет все это с помощью возможности сделать более устойчивым выполнение тестовых случаев на разных платформах, изменения UX, даже различия между промежуточными местоположениями и полетами A/B. Более того, ИИ позволяет людям, которые не потратили годы на отладку кода JAVA или Python и изучение фреймворков, писать гораздо более надежные тесты и быстрее. Трудно получить тесты, достаточно надежные для выполнения в мире TestOps с традиционными инструментами — ИИ позволяет использовать новый и более умный тип тестирования.

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

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

Примечание: test.ai выпускает версию нашей системы обучения на основе искусственного интеллекта для TestOps, разработанную сообществом. Присоединяйтесь к сообществу и технологии, чтобы принести TestOps в вашу команду: https://www.test.ai/product/aitf

Оригинал статьи