Современный мир стремительно меняется и подбрасывает нам всё новые вызовы. Кажется, что ландшафт современного IT изменится кардинально. Не зря же вся мировая AI тусовка написала письмо с просьбой «немедленно приостановить» обучение систем ИИ, «более мощных, чем GPT-4».

Я провел небольшое исследование и спросил всех до кого смог дотянуться следующее:

Я пишу обзорную статью для Хабра об инструментах AI. Интересуют реальные кейсы применения в работе этих инструментов. Если ты использовал\использовала его и есть желание поделится со мной, то прошу это сделать.

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

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

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

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

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

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

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

Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.

К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.

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

Издержки и преимущества автоматизации тестирования

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

Создатели инструментов заявляют о 1000-кратном увеличении производительности. Альтернативный взгляд и несколько важных советов при изучении применения инструментов автоматизации тестирования AI/ML.

Невероятно оптимистичные заявления о преимуществах AI/ML инструментов автоматизации трудно игнорировать: пишите автоматические тесты в 3 раза быстрее! На 90% дешевле! Получите повышение производительности в 1000 раз! (да, в тысячу)

Несмотря на то, что маркетологи всегда преувеличивают, улучшения, заявленные разработчиками инструментов AI / ML, кажутся беспрецедентными. Если бы эти заявления были правдой, ни один руководитель не смог бы закрыть на это глаза.

Почему это «токсично» и как сформулировать вопрос правильно.

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

На следующий день те же самые менеджеры, ещё не оправившиеся после вчерашнего допроса, обращаются к своим тестировщикам и спрашивают: «Почему вы не нашли этот баг?»