На самом деле никто и ничто не избежит забвения. Что ни говори, а история человечества – это история автоматизации и последующей эволюции работников. Так произошло и в первую промышленную революцию, и во вторую. Цифровая революция тоже не нарушила этот закон. Сейчас же повсюду внедряется машинное обучение и искусственный интеллект. Что ожидает сферу тестирования ПО в новом мире?
Автоматизация всемогущая
Люди всё меньше и меньше работают руками и всё больше обслуживают системы, которые делают всё за нас. Это потрясающе, не так ли? Человек вообще плохо подходит для работы, ведь мы не были спроектированы для этого. Чего, кстати, не скажешь о машинах.
И мы действительно были невероятно хороши всё это время. Хоть люди до сих пор местами работают руками, но это больше не является абсолютной необходимостью. Все однотипные задания были успешно заменены на машины, а люди стали операторами этих производственных агрегатов, что в сочетании с конвейером создало небывалые производственные мощности.
И мы продолжаем этот процесс в сумасшедшей скоростью, усложняя задачи! Google ассистент уже может забронировать для вас столик ресторане, а беспилотные роверы от Yandex способны доставить вам домой еду!
Го автоматизировать - я создал
Разумеется, сфера тестирования ПО не обошла стороной этот естественный процесс. Вообще какие-то её подвиды уже прекрасно автоматизированы. Например, то же тестирование компонентов, благодаря механизму unit-тестов, существует вполне себе автономно и сообщает о проблемах без участия человека. Конечно, тут есть проблема в том, что нужно сначала эти самые тесты написать, да причём ещё так, чтобы они действительно хорошо покрывали реализованный функционал…
Однако далеко не всё так гладко, как хотелось бы. Трудно себе представить подобную автоматизацию того же тестирования локализации. Хотя… Немного погуглив на тему “localization testing automation” я ничего не смог найти, но добавив ко всему этому “machine learning” сразу нашлось что-то интересное.
Один магистр инженерии (да, я понятия не имею как его именовать, поэтому взял из статьи :( ) провёл небольшое исследование на тему того, можно ли при помощи AI автоматизировать тестирование локализации. Был создан прототип NEAR (Navigate, Extract, Analyze and Report), который судя по результатам вполне себе успешно справился с поставленной задачей. Кстати, он успел изучить 3 приложения на предмет косяков локализации за 5 с небольшим минут. Да… Пойду что ли кофе попью…
Причём NEAR является преимущественно компиляцией из уже готовых решений – облачных AI, таких как Google Cloud Vision, Google Natural Language Processing и IBM Watson Natural Language Processing. Так что у нас уже есть нормальный такой базис, чтобы неплохо всё это автоматизировать.
Само собой, не всё так однозначно. Как можно себе представить автоматизацию юзабилити-тестирования? Да, тут тоже есть ложка машинного обучения. Я не буду оригинальным и вновь отправлюсь по пути наименьшего сопротивления – “usability testing automation machine learning”. И вот опять что-то нашлось. Нет, на этот раз никто не предлагает заменить людей на AI. Здесь уже речь идёт о том, что при помощи машинного обучения мы можем многократно улучшить анализ собранных данных. Вау! Никогда бы не подумал…
Ты должен был бороться со злом!
Да… Звучит как-то удручающе. Впрочем, не стоит унывать сразу – на этом всё не заканчивается. Или же не одной автоматизацией едины. Помимо того, существуют и различные инструменты, которые помогают уменьшить количество ошибок ещё на этапе разработки.
Например, статические анализаторы, которые анализируют исходный код и ругаются на различного рода ошибки. Тут достаточно большой спектр различных проблем в коде и потенциальных уязвимостей. Если хотите побольше узнать, что можно с их помощью найти, то почитайте эту статью.
Так что нельзя говорить, что развитие инструментов одного только тестирования меняет правила игры. Развитие культуры и инструментария разработки вносит не меньший вклад в этот процесс. А инструментов становится действительно всё больше и больше.
Если вы думаете, что всё это ограничивается статическим и динамическим анализом, то вы сильно отстали от жизни. Например, в Visual Studio 2022 появился autocomplete, который может дописывать за вами целые строки кода! И это только начало...
Сокращаем штат?
Пока вы заводите тракторы, я объясню, что всё совсем не так худо, как могло показаться на первый взгляд. Да, благодаря анализаторам кода и другим полезным инструментам до тестирования доходит всё меньше и меньше ошибок. Но есть тут одно такое небольшое «НО» - не бывает кода без багов.
Вы можете посадить тысячи тестировщиков и всё равно исправляя одну проблему будете получать новые и новые. И этот цикл поиска и исправления будет скорее всего бесконечным. Вы всегда будете находить всё больше и больше проблем. Как же это так?
Дело в том, что код – это крайне сложная структура из миллионов инструкций. Если ваш проект существует хотя бы пару-тройку лет, то скорее всего в коде никто уже до конца не разбирается. Да, что-то где-то работает, тут костыльная фабрика, а вон там потрясающие архитектурные решения… И во всём этом хаосе надо ещё находить причины бредового поведения!
Теперь давайте по одному добавлять полезные инструменты. Начнём с добавления статического анализа. Теперь он находит разные опечатки, ошибки, неправильное использование методов и т.д. Отлично! Значит теперь мы снизили нагрузку с тестировщиков? Не-а…
У вас всё ещё вагон и маленькая тележка проблем разного рода. Статический анализ покрыл только определённые типы проблем. Хорошо, давайте добавим динамический анализ! Поздравляю – утечек памяти стало меньше.
Но на этом же всё не закончится? Да, так и есть - даже если добавить всё о чём я говорил, то работа никуда не денется. Просто теперь вы в автоматическом режиме находите достаточно большое количество различных проблем. Это вовсе не означает, что теперь вам не нужны тестировщики. Это означает, что теперь вы будете находить больше проблем, благодаря поиску в широком спектре различных типовых проблем.
Эволюция профессии
Итак, а что же делать, чтобы оставаться полезным, а главное в тренде? Эволюционируйте! Не пытайтесь бороться с автоматизацией, а поймите почему и как именно она существует. Ведь, как я сказал в самом начале статьи, от неё никуда и никому не деться.
Вы будете намного ценнее, как специалист, который понимает внутреннее устройство этих систем. Что, кстати, было справедливо всегда и везде. Так что желаю вам запастись терпением и базовой теорией машинного обучения :)
Интересное
На правах рекламы
Кстати, мы занимаемся разработкой статического анализатора. Если кратко, то это штука, которая проверяет за вами код на ошибки. Если не верите, что она способна найти что-то за вами, то ловите ссылку на бесплатный триал и посмотрите сами :)
Комментарии (26)
titbit
29.09.2021 13:12+4Никуда тестировщики не денутся, не беспокойтесь.
Конечно, по мере того, как всякая автоматизация наступает на пятки, «роботы» будут уметь находить все больше и больше типов ошибок, а еще больше типов ошибок будут просто не позволять совершить. Но! Эволюция, на то и эволюция, что баги тоже будут эволюционировать и скрываться все хитрее и хитрее. Ну и наконец все баги в принципе нельзя исправить. Потому что помимо софта есть железо, в котором тоже полно багов, есть сторонний софт с которым надо взаимодействовать — он тоже не безгрешен, есть ограничения протоколов, архитектур и т.д. которые провоцируют некоторые виды проблем.
Вообще, пока все IT движется по пути практически экспоненциального усложнения, за баги я бы не переживал, я думаю они тоже экспоненциально растут в своей сложности. Если это не так, буду рад почитать или услышать исследования на эту тему.
Zalechi
29.09.2021 13:38Вопрос не в том, что баги исчезнут, а как их будут выявлять автоматически.
titbit
29.09.2021 14:01А как вы будете выявлять автоматически постоянно усложняющиеся баги? Ведь чтобы написать «правило» для автоматического выявления такого бага, его должен будет сначала досконально исследовать человек. Я уж молчу про то, что для надежной автоматической диагностики багов ваша модель описания поведения сложной системы должна быть сама по себе безошибочной, что порождает проблемы «второго порядка» — как искать баги в тестах на баги по мере усложнения самих тестов?
Zalechi
29.09.2021 14:21Хм, тогда возникает другой вопрос. Какие тесты мы можем считать автоматическими, если для его создания жизненно необходима рука человека(условно говоря)?
MrDvorak Автор
29.09.2021 14:47+3Да, я тоже думаю, что баги до конца никуда не исчезнут. Но со временем всё больше и больше проблем в коде будет находиться разного рода инструментами, так что в сфере тестирования ПО будет появляться всё больше и больше требований к глубокому понимаю языков программирования и различных технологий. Но это, конечно, моё ИМХО
ole325
29.09.2021 19:25Задачи предвидеть ошибки и тестировать еще до кода не менее актуальны, и там знание языков ничем не поможет. При одинаковой зарплате разраба и автоматизатора, уже теряется смысл выращивать автоматизатора из тестировщика. Не каждый тестировщик может дорости до SDET, а вот разработчику достаточно лишь заинтересоваться этим направлением.
titbit
30.09.2021 14:06Да, было бы интересно почитать про тенденции в мире поиска и исправления разных багов. Вот например, как искать гонки между потоками автоматически? А между ядрами процессоров? Есть ли где-нибудь утилиты, контролирующие расстановку барьеров в коде?
MrDvorak Автор
30.09.2021 15:09По большей части с этой задачей хорошо справляются динамические анализаторы, так как они анализируют инструкции во время непостредственного выполнения приложения. Разумеется для этого необходимо покрыть этот код тестами.
Статические анализаторы в свою очередь не зависят от покрытия кода, так как изучают напрямую исходный код приложения. Однако это совсем не их профиль - поиск многопоточных ошибок. Но они могут находить какие-то базовые вещи, например double-checked locking (v1036) или неправильное использование std::unique_lock (v1025).
titbit
30.09.2021 20:04+1Гонки — это же хитрые баги, воспроизводимость которых может запросто зависеть от сдвижек кода во времени, где-то что-то случилось быстрее или позже, и вот уже баг. Для их поиска недостаточно просто запустить код и посмотреть на него анализатором.
К тому же гонки — это не всегда не про блокировки вообще. Есть же lockfree алгоритмы, например. А есть еще барьеры по памяти, атомарный доступ и всякие там CASы. А мешает этому и провоцирует баги всякий out-of-order execution и store ordering на современных процессорах, а это вообще от компилятора может не зависеть. Наверное, здесь анализатор может что-то подсказать, но пока очень немного.
nixtonixto
30.09.2021 06:25+1Эволюция, на то и эволюция, что баги тоже будут эволюционировать и скрываться все хитрее и хитрее.
Но при этом человек умнее не становится — точнее, баги становятся хитрее быстрей, чем умнеет человечество. Поэтому в ближайшем будущем они станут настолько хитрыми, что поймать их смогут только машины, которые на порядки умнее людей. А люди превратятся в обслуживающий персонал для этих машин, и бороться с машинами будет так же чревато, как сейчас — бороться с камерами скорости.
moonbow
30.09.2021 11:31Никуда тестировщики не денутся, не беспокойтесь.
Ога) кто же будет тестировать программы, которые будут тестировать программы?
ole325
29.09.2021 14:50Скорее, есть перспективы исчезновения текущего автоматизированного тестирования, а вот ручное будет всегда.
Так же есть направления где можно работать вообще без классического тестирования, для условного фейсбука можно выдавать с привязкой к гео или вобще пользователям релиз для одних, бету для стран третьего мира, альфу для лояльных пользователей. А вот десктоп и с ПО в железках так не выйдет - покупатель стиралки очень расстроится, что из коробки нужно обновление поставить, т.к. с текущей прощивкой вообще нечего стирать нельзя.
А отвечая на вопрос куда пропадают тестировщики, через 3-6 лет большинство уходит дальше, т.к. далеко не всем интересно этим заниматься продолжительное время.
Formeman
29.09.2021 15:22Если под исчезновением автоматизаторов подразумеваете, что AI их вытеснит, то нет. Скорее он станет ещё одним инструментом, которым нужно уметь владеть. Да и то крайне сомнительного качества. Потому что вам могут создать хоть 100 тестов, но их поддержкой вряд-ли сможет заняться кто-то кроме человека.
ole325
29.09.2021 19:21развиваются как инструменты со стороны разработчика, так и инструменты для ручного тестировщика, и необходимость держать отдельного специалиста для трансляции тест-кейсов в скрипы и их поддержку скоро отпадет.
amedvedjev
30.09.2021 09:20лет через 50... судя по нынешним тенденциям...
ЗЫ это я вам как автоматизатор говорю. в большинстве фирм автомазации нет. даже если есть люди кто ей там занимается.
ole325
30.09.2021 18:06ну я про штаты лет через 15, а так то с вами согласен, у нас пока ручных тестировщиков по одному на 8-9 разрабов в среднем, вот на Украине лучше 1 к 3, но Украина так скорее из за найма с Европы/штатов.
moonbow
30.09.2021 09:20Интересно, для penetration test есть какая-нибудь годная автоматизация?
(Я имею в виду полный цикл, а не отдельные инструменты)
pauelbel
30.09.2021 09:20+1Можно аналогию с гриппом провести. Вакцины и лекарства каждый год новые, крутые, дорогие, но мы гриппом болеть не перестали и старый добрый чай с лимоном сопровождает нас до конца болезни ))
vlad_egrv
30.09.2021 10:34+2Что ни говори, а история человечества – это история автоматизации и последующей эволюции работников. Так произошло и в первую промышленную революцию, и во вторую.
Ну если в историю посмотреть, то окажется, что внезапно тестировщики еще задолго до программистов появились, просто назывались по другому (испытатели, отдел технического контроля и т.д.), и на протяжении всех революций это было неизменным. Поработав как в ОТК на производстве, так и тестировщиком ПО, могу сказать, что это намного более схожие вещи, чем принято думать.
Опять же, в статье рассмотрены в основном инструменты QA для разработчика (стат анализ, юнит тесты), тестировщик вообще не занимается этим, предполагаю что автор к тестированию отношения не имеет, из всех сфер тестирования упомянута локализация и метафизическое юзабилити.
Ок, представим что мы покрываем машинным обучением какую то часть функционала, но настраивать нейросетку под конкретную софтину, думать как и когда запускать её, кормить ее входными данными и анализировать выходные (даже если они будут содержать только "все ок" и "не ок") будет тоже тестировщик
alcochtivo
Для меня это выглядит так. Чтобы тестировщики стали не нужны совсем требуется: код без ошибок и с железной логикой; для этого нужны - спека\тз без ошибок и с железной логикой. И всё равно это всё разобьётся об юзер экспириенс)) Но это только моё мнение.