Инструменты разработки программных решений постоянно совершенствуются. Однако, несмотря на явный прогресс в развитии языков программирования и системного подхода к разработке, процесс тестирования продуктов изменятся медленно. Еще несколько лет назад ИТ-компании верили, что многочисленных тестировщиков вполне может заменить ИИ. Прошло время, но ИИ не оставил без работы специалистов по ручному тестированию. Мы спросили у экспертов почему так сложно заменить людей на ИИ на этапе тестирования.
Илья Демченко, ведущий специалист по автоматизированному тестированию Luxoft Training.
Люди для тестирования перестанут быть нужны тогда, когда программы научатся писать сами себя – и то такие программы тоже сначала нужно будет протестировать руками.
Если говорить широко в рамках обеспечения качества продукта, процесс тестирования зачастую проходит в условиях сжатых сроков и недостаточно формализованных требований. В частности, это заметно в проектах, работающих по гибким методологиям разработки: команда вынуждена жертвовать уровнем качества в угоду скорости поставки новых частей приложения. В таких условиях обязательной активностью тестировщика становится оценка рисков тестирования и постоянный анализ тестового покрытия. Ввиду того, что в каждом проекте свой набор приоритетов и критериев качества, совокупность рисков и соответствующих последствий для каждого проекта будет свой. Более того, со временем критерии имеют свойство меняться и требуют оперативной переоценки, и характер этих изменений сложно описать с помощью математической модели. Соответственно нужны люди, готовые взять на себя контроль за процессом.
Говоря о технической стороне тестирования как о процессе поиска ошибок в приложении, то нужно понимать, что источников таких ошибок несколько: требования, код и собственно само тестирование. При возникновении ошибок необходим внимательный анализ и поиск причин, которые зачастую неочевидны и требуют обсуждения в рамках проектной команды. Ошибки кода с точки зрения автоматизации тестирования выглядят как меньшее из зол. Их можно отлавливать и в рамках тестирования белого ящика. Но как быть с той частью ошибок, которая находится в аморфной области недосказанных требований заказчика, недостатка коммуникаций в команде и просто разного уровня компетенций членов команды? Такие дефекты находятся только с помощью здравого смысла и фантазии – методик избежать таких проблем нет, их можно исправить только постфактум. Собственно, этим и отличается хороший тестировщик от того, которого можно заменить автотестом.
Ярослав Шмулев, руководитель группы машинного обучения ИТ-компании «Инфосистемы Джет».
Широкого применения ИИ в сфере тестирования ПО пока не наблюдается. Технологические компании и стартапы говорят о такой возможности, но реальных кейсов очень мало.
Как вообще работает автоматизация тестирования? Есть инструкция на естественном языке о том, как должен проходить какой-то процесс, к ней пишется код и создается алгоритм, который этот код проверяет. Это автоматизация тестирования с помощью классических инструментов программирования, которые то относят к технологиям ИИ, то нет. Если с помощью классических алгоритмов это сделать не получается, здесь может помочь машинное обучение.
Сейчас в этой сфере в основном фигурируют сообщения о проектах, связанных с тестированием User Interface (UI). Вкратце, это использование алгоритмов и моделей машинного обучения для проверки визуальной части работы сайтов, связанной с картинками и текстом. В этом случае технологии ИИ используются для того, чтобы отслеживать ошибки, которые отражаются на его интерфейсе: лэндинг поехал, шрифты стали корявыми, нарушилась разметка или съехали колонки. Это вполне конкретная, четкая задача, где можно определить ряд дефектов UA, сделать выборку и научить модель эти ошибки отслеживать.
Почему автоматизированные системы тестирования еще не вытеснили ручное тестирование?
В этой сфере существуют значительные ограничения:
- Во-первых, технологии ИИ могут применяться только на узких задачах, — пока невозможно сделать такую модель машинного обучения, чтобы прогонять через нее любое ПО и получать сообщения о всех ошибках работы. Поэтому, узкая задача, для которой создают аналитическую модель, должна быть довольно масштабной и приносить ощутимую прибыль, чтобы работа команды дата-сайнтистов окупала себя.
- Во-вторых, работу модели-тестировщика в любом случае должен контролировать человек, поэтому о полной замене специалистов искусственным интеллектом речь не идет в принципе.
- В-третьих, применять технологии ИИ в тестировании ПО могут себе позволить только крупные компании со штатом своих или наемных дата-сайнтистов. Финансовые ограничения для среднего бизнеса играют важную роль.
Что дешевле — человек-тестировщик или адекватное ПО?
Один человек-тестировщик значительно дешевле, чем одна модель машинного обучения, созданная командой дата-сайнтистов. Но для процесса, который может выполнить один человек, ИИ не применяется. Речь идет о масштабных проектах с большим количеством данных и повторяющихся операций. Так что вопрос, кто более выгоден, человек или ИИ, решается множеством факторов. Здесь нет единой формулы.
Падает ли потребность в тестировщиках по мере развития современных инструментов разработки ПО?
По тем причинам, которые я указал выше, потребность в тестировщиках не падает, и вряд ли упадет в ближайшие несколько лет. Использование ИИ для тестирования — скорее исключение, чем правило.
Почему ручное и автоматизированное тестирование — это разные подходы к процессу устранению ошибок в ПО?
Подходы к тестированию похожие, меняется лишь инструмент. В первом случае — это люди и классические алгоритмы программирования, во втором — модели машинного обучения + люди, создающие их и проверяющие их работу. Преимущество моделей здесь в том, что человек в любом случае ошибается, и работа модели будет более точной в тех случаях, когда ее правильно применили на подходящем процессе.
Андрей Олейник, QA Automation Expert в DataArt.
Перспективы автоматизированного тестирования: когда ИИ вытеснит людей-тестировщиков и почему они сих пор еще нужны.
Это очень сильно зависит от области, для которой пишется приложение, и насколько ИИ будет эффективен в решении задач. Например, если тестировать нужно несложную офисную программу с простым пользовательским интерфейсом, прикручивать к Webdriver ИИ с компьютерным зрением и нейролингвистическим анализом текстов будет дорого и неэффективно. С другой стороны, если при тестировании необходимо вычислять оптимальный маршрут или делать автоматический анализ текста «Войны и мира», например, логично передать многие функции ИИ. При этом совсем необязательно, что это будет графовая глубокая нейронная сеть или что-то подобное. Можно использовать оптимизационный алгоритм без нейронных сетей, который известен достаточно давно.
При работе с графическим пользовательским интерфейсом некоторые проекты используют инструменты типа Tesseract, OpenCV и другие для валидации некоторых элементов, где сложно прочитать текст автоматически напрямую. Но это скорее исключение из правил, потому что легче разработчику сделать текст на элементе читаемым, чем усложнять тесты добавлением инструментов компьютерного зрения. О полной замене человека на ИИ в ближайшем будущем можно начать говорить, только когда и разработка будет полностью заменена на ИИ-разработку. При этом, специалисты тестирования и разработки будут тоже очень востребованы, но к их необходимым навыкам добавится владение ИИ и соответствующими инструментами. Пока мы не говорим о «T-800», после которого действительно многие профессии отомрут.
Почему автоматизированные системы тестирования еще не вытеснили ручное тестирование?
Тестирование всегда начинается с ручного. С самого начала нужно протестировать документацию и требования — на стадии, когда приложение еще не начали создавать или создали концепцию на стадии PoC (Proof of concept). Когда начинается основная разработка, автоматизаторы всегда должны вручную пройти пользовательские сценарии и проверки. При этом уже находится множество дефектов.
С каждой новой фичей в продукте все повторяется сначала — продукт первый раз проверяется вручную. Некоторые вещи, конечно, при этом могут быть сразу автоматизированы, но весь процесс в целом ручной. Когда специалист прощупал все шаги тестового сценария, встает вопрос: выгодно ли автоматическое тестирование или можно обойтись ручным? Если подойти к этому на стадии планирования проекта, необходимо сделать оценку трудозатрат на автоматическое, ручное или смешанное тестирование продукта. Для этого надо посчитать ROI автоматизации тестирования. Нередки случаи, когда автоматизация в тестировании или малоэффективна, или экономически невыгодна. И тут речь не о том, чтобы нанять дешевых низкоквалифицированных специалистов. Ведь и QA-инженер может иметь достаточно высокую квалификацию и достаточно высокую зарплату. Пример: разработка мобильного приложения, в которой нет или почти нет регрессионного тестирования.
Почему ручное и автоматизированное тестирование – это разные подходы к процессу устранению ошибок в ПО?
На мой взгляд, это один и тот же подход с вариациями. Автоматизированные инструменты используются уже десятки лет даже в ручном тестировании. Пишутся скрипты на bash или PowerShell, используются, в той или иной мере, инструменты для http-запросов типа Postman/SoapUI и т. д. В некоторых случаях ручное тестирование совершенно органично можно развить в автоматизированное без смены инструментов (один из примеров — Postman).
Падает ли потребность в тестировщиках по мере развития современных инструментов разработки ПО?
Исходя из количества вакансий тестировщиков, потребность только растет (особенно в последние несколько месяцев). Меняется только набор необходимых знаний и навыков. Очевидно, что он движется в сторону большего владения инструментами автоматизации тестирования и навыков DevOps-инженера.
Что дешевле – человек-тестировщик или адекватное ПО?
ПО как минимум последний десяток лет намного дешевле хороших специалистов. Оно также может быть и бесплатным (как Selenium Webdriver). Хороший специалист, мастерски владеющий инструментами и методиками тестирования — тот, кого сейчас не хватает, и за кем охотятся отряды рекрутеров.
Насколько среди разработчиков востребованы фирмы или сервисы, которые предоставляют услуги комплексного тестирования? Почему такие фирмы или сервисы не стали доминировать?
Если речь идет о компаниях, предоставляющих сервис полного комплексного тестирования на разных уровнях, в зависимости от потребностей заказчика (как DataArt, например), это довольно популярно в некоторых индустриях: в банковской сфере, в энтерпрайз-приложениях и других.
Если речь идет о специфических облачных сервисах, как BrowserStack или SouceLabs, которые предоставляет возможность тестирования приложений на широком спектре устройств, то они очень популярны в некоторых нишах. Например, компании-разработчику далеко не всегда выгодно или даже возможно иметь все устройства, на которых может работать приложение. А такие сервисы позволяют достаточно выгодно произвести проверки на очень разных устройствах с разными вариантами настроек и версий операционных систем.
Еще более широкий пример — облачные сервисы AWS, Azure и т. д. Эти сервисы не заменяют тестирование, но могут существенно упрощать разработку и тестирование в некоторых случаях. Облачные сервисы в корне изменили некоторые вещи в разработке ПО, в том числе, и технические подходы к тестированию.
Александра Мурзина, Positive Technologies.
Вне зависимости от типа – функциональное тестирование программных продуктов или тестирование на безопасность – тестирование может быть как ручным, так и с использованием инструментов, в том числе и для автоматизации действий.
В функциональном тестировании повсеместного использования ИИ пока не видится. Это связано с тем, что многие задачи не требуют сложных решений. Сделать хорошее решение основанное на ИИ – сложно и дорого. Поэтому чаще используются решения, основанные на традиционном подходе: привлечение экспертов для ручной проверки или автоматизация этой проверки.
Но есть и кейсы, для которых использование ИИ оказывается оправданным:
- генерация юнит-тестов по коду интересна многим исследователям, но пока что не решена достаточно хорошо. Нужно ли бояться специалистам по тестированию, что они лишатся этой работы? Только если написание юнит-тестов является их единственной задачей. Но обычно она лежит на разработчиках и является одним из самых нелюбимых этапов в создании ИТ-решений. Поэтому разработчики будут только рады автоматизировать нелюбимое им дело.
- анализ UI-методами Computer Vision. На рынке существует большое количество устройств, а технологии позволяют делать кросс-платформенные решения. Однако они требуют валидации на то, что все выглядит так как должно: никакой текст не уполз и пользователю удобно. Существуют как готовые инструменты, так и подходы, которые позволяют этот процесс автоматизировать и встроить в CI-процесс. В таком случае при новой сборке какого-то приложения, сразу есть возможность “проиграть” какие-то сценария использования, сохранить скрины, автоматически прогнать их через ИИ и получить вердикт все ли тексты влезли, а картинки правльно разместились или нет.
- использование ИИ для приоритезации багов в бэклоге, классификации – используется, в основном руководителями, для оценки, что не так с продуктом.
В тестировании на безопасность ситуация схожая. Однако все же есть инструменты, которые могут помочь как разработчику, так и исследователю.
- статические анализаторы кода, которые сочетают в себе классические методы и новые техники. Существуют как плагины для сред разработки, которые сразу при написании кода могут посоветовать разработчику, что в данном месте написанный код потенциально уязвим, так и большие продукты, которые могут выстроиться в CI/CD-процесс и анализировать весь код продукта целиком.
- интеллектуальный фаззинг – тестирование на безопасность путем генерации разных данных – корректных, некорректных и различных граничных случаев, и подачи их на вход приложению. Здесь возможно регулировать разные параметры, например, “умно” генерировать определенный тип данных. Или влиять на генерацию, анализируя ответную реакцию приложения.
Антон Фишман, технический директор RuSIEM.
Универсальных систем на основе ИИ, которые смогли бы протестировать все продукты, не существует. Это вопрос стоимости – экономически писать такую систему нет смысла. Есть разные виды тестирования – статический и динамический анализ, существуют разные методики тестирования – и их можно запрограммировать и без ИИ. Если что-то нужно алгоритмизировать – это можно делать менее ресурсоемкими, чем ИИ, средствами.
Первоначально дешевле использовать человека, но когда сложность тестируемой системы растет – есть смысл написать грамотное ПО. То есть, можно обойтись и без тестировщиков, и без ИИ”.
Артём Кострюков, менеджер по маркетингу в SNH MeisterSoft.
Часто ИИ воспринимается как серебряная пуля или волшебная палочка, и сегодня это утопично. При классическом понимании ИИ, с его помощью можно тестировать какие-то простые вещи типа API, если грамотно задокументировать требования на входе и на выходе. В этом случае ИИ будет самообучаться и проверять негативные сценарии и граничные значения и т.д. Получается автоматическое генерирование автотестов. И на рынке есть подобные предложения.
Если у вас небольшой и не сложный продукт, а релизы выходят раз в год, то вам нет нужды нанимать дорогого автоматизатора – дешевле и правильнее протестировать функциональность руками. По мере роста продукта растут требования, компоненты, окружения, в этом случае выгоднее нанять человека, который напишет код автотеста.
На мой взгляд, невозможно совершенно отказаться от ручного тестирования. Есть компании, которые утверждают, что у них нет ручных, а только автотесты, но они точно что-то упускают. Например, невозможно осуществить pen-test или проверить usability, UI/UX или локализацию только с помощью автотестов.
Дело в том, что ручное и автотестирование эксплуатирует разные подходы, которые дополняют друг друга, но не являются заменой. Ручное – это проактивный подход, когда ты предугадываешь дефекты, находишь новые изъяны. Автотестирование – это про то, что «мы знаем, где не должно быть изъянов», и больше проверяем стабильность системы. Автотесты зачастую находят меньше новых багов, чем ручные, и это нормально.
Что дешевле – человек-тестировщик или адекватное ПО? Философский вопрос. Что такое адекватное ПО – это рабочее относительно всего множества пользовательских сценариев и комбинаций ПО. Зачем нужны тестировщики? Проверять разработчиков и ПО. А почему разработчики сразу не могут написать идеальный рабочий код? Даже когда хорошие разработчики пишут код с первого раза, и он работает – это настораживает самого разработчика =) Современные технологии и системы настолько сложны, что просто невозможно с первого раза попасть в точку, используя тот или иной язык или архитектуру.
Насколько среди разработчиков востребованы фирмы или сервисы, которые предоставляют услуги комплексного тестирования?
Тут можно одновременно говорить о нескольких вещах: аутсорс, аутстаф или сервис, предоставляющий мощности, например, для нагрузочного тестирования. Если речь о тестовой среде – то это востребовано, так как не всегда у компании есть возможность своими силами настроить большое количество кластеров для многомиллионной нагрузки. Это в первую очередь очень дорого. Если речь об аутстафе – то построить собственный отдел тестирования также нелегкая задача с точки зрения финансовых, человеческих и временных ресурсов. Тот же pentest – это редкая и очень дорогая специальность, невероятно востребованная из-за повышенных требований к безопасности современных цифровых систем.
Виталий Гончарук, Lead Software Engineer.
На моей 8 летней практике участия в разработке многих продуктов я не видел чтоб ИИ применялся для тестирования. Даже если б такие системы существовали то была бы сложность передачи бизнесс правил в этот ИИ чтоб он понял что вообще делать нужно. Понятно что есть простые и рутинные задачи по тестированию, но там ИИ не нужен.
Автоматизированное тестирование это когда, тестирование проводится с помощью программ или специально написанного кода который имитирует действия пользователя или сервиса который обращается к программе которая тестируется. Автоматизированное тестирование не означает что применяется ИИ.
Почему автоматизированные системы тестирования еще не вытеснили ручное тестирование?
Системы атоматизации нужны для облегчения тестирования и уменьшения рутинной работы, они просто не могут вытеснить тестировщиков как специаллистов. Это как работать вручную вспихивая землю или на тракторе. Как вы думаете будет эффективнее?
Почему ручное и автоматизированное тестирование – это разные подходы к процессу устранению ошибок в ПО?
Тестирование не призвано устранить ощибки, а только их обнаружить. Так вот на старте проектов обычно применяют ручное тестирование, а когда проект разростается наступает переломный момент когда тестировщики в ручную не могут охватить тестирование всего функционала, особенно когда применяются глубокие изминения которые затрагивают все приложение.
Чтоб такого не случилось необходимо еще на старте проекта инвестировать время в построение атоматической системы тестирования, первые пол года это может казаться излишнем, но вот потом все будут аплодировать. Особенно когда старые знатоки уходят с проекта и приходят новые разработчики и тестировщики, в системе останутся правила тестирования которые в момент будет показывать что сломалось и её надо будет только дополнять.
Что дешевле – человек-тестировщик или адекватное ПО?
ПО не может само работать без человека, ведь им надо управлять. Возьмем пример с тактором приведенный выше, даже если ИИ научится управлять трактором то обслуживать его всеравно придется, более того нужно давать задание когда копать, когда сеять, когда поливать, когда удобрять и т.д.
– Насколько среди разработчиков востребованы фирмы или сервисы которые предоставляют услуги комплексного тестирования?
Зависит от того на сколько компетентен человек заведующий бюджетом и на сколько он прислушивается к команде разработки, ведь разработчики не заведуют бюджетом, они просто цифровые работяги. Всем управляет бизнесс, который дает деньги. Так вот бизнес мыслит категориями продуктов и начальство обычно не думает о том что необходимо еще инвестировать к примеру 20% в покрытие тестами или нанять толпу ручников. Это понимание приходит когда уходят ключевые разработчики и проект начинает разваливаться.
Почему такие фирмы или сервисы не стали доминировать?
Я считаю, это по тому, что между разработчиками и тестировщиками должна быть хорошая связь. Ведь то что тестировщик нашел ошибку не означает что разработчик её сможет воспроизвести и даже если тестировщик хорошо оформит отчет об ошибке всеравно может понадобится помощь при её воспроизведении у разработчика на локальном компютере чтоб продебажить.
К тому же в бизнесс проектах где разрабатываются внутренние системы нельзя просто взять толпу людей и начать тестировать, надо разобратся со спецификой бизнесса, описать сценарии, поварится в этом пол года хотяб, это не говоря о том, что необходимо предоставлять доступ к корпоративным системам и тайнам.
Дмитрий Бормотов, OnTarget Group, Inc, QA Engineer.
ИИ в тестировании ПО – достаточно интересная тема, о которой мало что известно на текущий момент. Большинство информации по данному направлению – это суждения/предположения о том, во что выливается данный сет. Дело в том, что чтобы разработать инструмент с поддержкой машинного обучения, который сам будет разрабатывать и запускать тесты – необходимо обладать экспертизой в обоих областях, а специалисты с такими познаниями – это редкость. Да и времени на создание такого монстра уйдёт немало, а тестировать свой продукт компании хотят здесь и сейчас.
Тестирование на проекте всегда начинается с выстраивания ручных процессов – появляется тест-план и база с первыми с тестами, которые организуют собой последующие наборы – дымовые (smoke) и регрессионные (regression), например. Чем больше ручной тестировщик уделяет внимание рутинным проверкам – тем более он подвержен профессиональному выгоранию и эффекту “замыливания глаза” – со временем он перестаёт замечать тривиальные ошибки в очевидных местах (пробегается по функционалу “на автомате”). Чтобы сократить процент рутинных задач и тестировать их эффективнее, а также снизить нагрузку на ручных тестировщиков – начинают вводиться автотесты. В этом вся и разница.
Насколько среди разработчиков востребованы фирмы или сервисы которые предоставляют услуги комплексного тестирования? Почему такие фирмы или сервисы не стали доминировать?
Сегодня данные сервисы есть, а завтра их может и не быть. Тем более, так или иначе, нужен человек, а может даже не один, который будет внедрять услуги данных фирм/сервисов на текущий проект – ведь необходимо разобраться, как их услуги работают и как их можно применить на практике конкретно у нас. Если речь о компаниях, которые занимаются ручным тестированием на заказ, то тут тоже не всё так просто – ваш продукт может быть сложным для восприятия рядовым пользователем, возможно у вас есть огромная документация по тому функционалу, который вы разработали. И для того, чтобы тестировщики извне приступили к тестированию вашего функционала, им будет необходимо прежде ознакомиться с самой системой – всё будет зависеть о её сложности. Гораздо дешевле и надёжднее получается нанять специалистов в штат, которые будут организовывать процессы тестирования с вниманием к особенностям проекта, без оплаты подписки сторонним сервисам.
Иван Меркель, руководитель отдела инженерных практик Т1 Консалтинг.
В тестировании программных продуктов в Enterprise-сегменте ИИ пока не используется, в отличие от веб-разработки, мобильной разработки или разработки баз данных, где технология уже довольно активно применяется.
Есть единичные сообщения о попытках, но пока это удел энтузиастов. Внедрение технологии тормозят высокий уровень задач и дефицит специалистов, которые могут написать алгоритм эффективного тестирования. Кроме того, Agile-подход, подразумевающий, что решение несколько раз претерпевает изменения, иногда кардинальные, не позволяет задать жесткие параметры тестирования на этапе разработки проекта.
Почему автоматизированные системы тестирования еще не вытеснили ручное тестирование?
У ответа на этот вопрос есть экономическая и технологическая составляющие. С точки зрения экономики, сегодня проще и дешевле нанять тестировщика, особенно если вести поиск специалистов в регионах.
С точки зрения технологии, человек справляется лучше, так как при автоматизированном тестировании, которое представляет собой предписанную последовательность действий для машины, оценка логики решения остается вне теста. Человек же способен увидеть нарушения логики и заметить нюансы.
Кроме того, при автоматизированном тестировании процесс фрагментирован: для каждого блока решения скрипт готовит отдельная группа разработчиков, но при сборке цельного решения что-то важное может ускользнуть, а человек-тестировщик видит полную картину.
Падает ли потребность в тестировщиках по мере развития современных инструментов разработки ПО? Что дешевле – человек-тестировщик или адекватное ПО?
Написание алгоритмов тестирования – процесс сложный и дорогой. Проблем добавляет дефицит квалифицированных программистов. Тестировщика найти проще, но надо учитывать, что длительность работы тестировщиком зачастую небольшая: грамотный специалист быстро эволюционирует, например, в бизнес-аналитика. Это обуславливает то, что спрос на тестировщиков в ближайшее время снижаться не будет, но рынок труда переместится в регионы.
Насколько среди разработчиков востребованы фирмы или сервисы, которые предоставляют услуги комплексного тестирования?
Игроки рынка, имеющие собственные подразделения разработки, закрывают этот фронт работ своими силами. Но иногда и им требуются услуги по тестированию под разные задачи. Например, в случаях, когда мобильное приложение написано несколькими подрядчиками или требуется аудит безопасности, они могут заказать комплексное тестирование. Но рынок достаточно узкий.
Илларионов Евгений, руководитель отдела тестирования Т1 Консалтинг.
В ближайшее время автоматизированное тестирование не сможет полностью вытеснить ручное по нескольким причинам. Во-первых, автотесты применяют к уже стабильному функционалу: отладка алгоритма и диагностика ошибок в новом функционале более трудоемкие, чем ручное компонентное тестирование даже в несколько итераций.
Во-вторых, некоторые тестовые сценарии сложно «поддаются» автоматизации либо в принципе не реализуемы. Это может быть связано с различными факторами, например, с отсутствием прямого доступа к определенным тестовым стендам из-за юридических нюансов.
В-третьих, в то время как автоматизация подразумевает в основном сверку ожидаемого результата и фактического, человек в силу своей природы способен замечать большее и может сформировать дополнительные замечания в работе ПО, помимо основного сценария.
Однако это не означает, что надо отказаться от автоматического тестирования. Если для небольших проектов дешевле привлечь небольшую команду тестирования на определенный срок, то для больших проектов, которые постоянно дорабатываются, себестоимость ручного тестирования в каждом релизе увеличивается и без автоматизации остановить этот процесс сложно.
Идеальный вариант, на мой взгляд, – это гибрид ручного тестирования с автоматизацией. Главное в этом случае правильно выстроить процесс взаимодействия человека с роботом.
Развитие инструментов разработки ПО уменьшает вероятность возникновения ошибок, но не избавляет от них полностью. Банальные опечатки или неправильную интерпретацию требований никто не отменял. Поэтому на вопрос «падает ли потребность в тестировщиках» могу однозначно ответить, что нет. Потребность в квалифицированных специалистах по тестированию только увеличивается с учетом темпов развития ИТ-сферы.
Мне кажется, оценка по стоимости при сопоставлении «человек-тестировщик или адекватное ПО» не совсем корректна. С одной стороны, стоимость специалиста явно ниже, чем лицензионного инструмента для разработки ПО, но с другой стороны – есть и бесплатные инструменты. Я думаю, что только гибридное тестирование на выходе позволит получить современный продукт и за меньшую стоимость.
Насколько среди разработчиков востребованы фирмы или сервисы, которые предоставляют услуги комплексного тестирования?
Такие фирмы или сервисы становятся достаточно востребованы в последнее время. Компании-разработчику бывает выгодно обратиться за услугами по тестированию на рынок, когда начинается разработка нового продукта, а внутренних специалистов с нужными компетенциями у нее нет.
Почему такие фирмы или сервисы не стали доминировать?
Как правило компании-разработчики стараются нарастить внутри себя команду с хорошей экспертизой: это выгодно с экономической точки зрения и позволяет быстро переключать ресурсы с одного проекта на другой, когда возникает необходимость узконаправленного краткосрочного тестирования, например, в случае аудита нагрузки. В компаниях, занимающихся исключительно тестированием, держать таких специалистов без проектов невыгодно.
Александр Садыков, руководитель департамента контроля качества центра программных решений ИТ-компании «Инфосистемы Джет».
В сфере ручного и автоматизированного тестирования применение искусственного интеллекта – достаточно редкое явление. В очень локальных случаях можно выделить применение машинного зрения для тестирования интерфейсной части продукта, если по каким-то причинам нельзя применять стандартные библиотеки. Но по сути сейчас разработано достаточное количество платных и бесплатных аналогов, позволяющих тестировать интерфейс любых систем. Есть обучаемые инструменты статического анализа кода, которые позволяют автоматизировано проверять нарушение алгоритмов, неинициализированные переменные, утечки памяти, безопасность и т.п. Наиболее популярные: SonarQube, PVS-Studio, Pychecker, Pylint.
С очень большой натяжкой можно назвать искусственным интеллектом различные утилиты для комбинаторики тестов по заданным параметрам, применяемым в процессе дизайна тест-кейсов.
Зато характерна обратная ситуация: все большую популярность приобретает история тестирования машинного обучения. В наших проектах, связанных с ML, неотъемлемой частью команды дата-сайнтистов является QA инженер (Quality Assurance engineer, — специалист, проверяющий качество ПО). Он помогает прорабатывать стратегию обеспечения качества прогнозной или рекомендательной модели, а также связанных условий по интеграциям, целостности данных и пользовательского интерфейса.
Почему автоматизированные системы тестирования еще не вытеснили ручное тестирование? Почему ручное и автоматизированное тестирование — это разные подходы к процессу устранению ошибок в ПО?
Автоматизированное тестирование в первую очередь нужно для сокращения времени на принятие решения. Но на его основе нельзя делать полноценные выводы о выпуске продукта в продуктивную среду. Это решение должен принимать человек. Здесь важна комплексная оценка: качество тестового покрытия требований, успешность прогона автоматических и ручных кейсов, критичность обнаруженных дефектов, сроки их исправления.
Нельзя сбрасывать со счетов и нефункциональную составляющую: удобство интерфейса продукта и скорость его отклика, возможность многопользовательской работы, уязвимость решения перед атаками хакеров. Эти вещи могут проверяться только в ручном или полуавтоматическом режиме под полным контролем человека.
Падает ли потребность в тестировщиках по мере развития современных инструментов разработки ПО? Что дешевле — человек-тестировщик или адекватное ПО?
Понятно, что прогресс не стоит на месте, появляются новые технологии разработки, больше готовых открытых библиотек, инфраструктурных инструментов. Но при этом качество итогового продукта все равно остается на совести инженера, который разработал программный код. Важно продумать стратегию тестирования приложения, основываясь на рисках качества, целях и бюджете. Создать тестовые данные, окружения, стенды, определить виды тестирования. А это может сделать только человек: найти правильный баланс между скоростью доставки изменений до конечного пользователя и их качеством.