Comments 26
Для меня это выглядит так. Чтобы тестировщики стали не нужны совсем требуется: код без ошибок и с железной логикой; для этого нужны - спека\тз без ошибок и с железной логикой. И всё равно это всё разобьётся об юзер экспириенс)) Но это только моё мнение.
Конечно, по мере того, как всякая автоматизация наступает на пятки, «роботы» будут уметь находить все больше и больше типов ошибок, а еще больше типов ошибок будут просто не позволять совершить. Но! Эволюция, на то и эволюция, что баги тоже будут эволюционировать и скрываться все хитрее и хитрее. Ну и наконец все баги в принципе нельзя исправить. Потому что помимо софта есть железо, в котором тоже полно багов, есть сторонний софт с которым надо взаимодействовать — он тоже не безгрешен, есть ограничения протоколов, архитектур и т.д. которые провоцируют некоторые виды проблем.
Вообще, пока все IT движется по пути практически экспоненциального усложнения, за баги я бы не переживал, я думаю они тоже экспоненциально растут в своей сложности. Если это не так, буду рад почитать или услышать исследования на эту тему.
Вопрос не в том, что баги исчезнут, а как их будут выявлять автоматически.
Да, я тоже думаю, что баги до конца никуда не исчезнут. Но со временем всё больше и больше проблем в коде будет находиться разного рода инструментами, так что в сфере тестирования ПО будет появляться всё больше и больше требований к глубокому понимаю языков программирования и различных технологий. Но это, конечно, моё ИМХО
Задачи предвидеть ошибки и тестировать еще до кода не менее актуальны, и там знание языков ничем не поможет. При одинаковой зарплате разраба и автоматизатора, уже теряется смысл выращивать автоматизатора из тестировщика. Не каждый тестировщик может дорости до SDET, а вот разработчику достаточно лишь заинтересоваться этим направлением.
По большей части с этой задачей хорошо справляются динамические анализаторы, так как они анализируют инструкции во время непостредственного выполнения приложения. Разумеется для этого необходимо покрыть этот код тестами.
Статические анализаторы в свою очередь не зависят от покрытия кода, так как изучают напрямую исходный код приложения. Однако это совсем не их профиль - поиск многопоточных ошибок. Но они могут находить какие-то базовые вещи, например double-checked locking (v1036) или неправильное использование std::unique_lock (v1025).
К тому же гонки — это не всегда не про блокировки вообще. Есть же lockfree алгоритмы, например. А есть еще барьеры по памяти, атомарный доступ и всякие там CASы. А мешает этому и провоцирует баги всякий out-of-order execution и store ordering на современных процессорах, а это вообще от компилятора может не зависеть. Наверное, здесь анализатор может что-то подсказать, но пока очень немного.
Эволюция, на то и эволюция, что баги тоже будут эволюционировать и скрываться все хитрее и хитрее.
Но при этом человек умнее не становится — точнее, баги становятся хитрее быстрей, чем умнеет человечество. Поэтому в ближайшем будущем они станут настолько хитрыми, что поймать их смогут только машины, которые на порядки умнее людей. А люди превратятся в обслуживающий персонал для этих машин, и бороться с машинами будет так же чревато, как сейчас — бороться с камерами скорости.
Никуда тестировщики не денутся, не беспокойтесь.
Ога) кто же будет тестировать программы, которые будут тестировать программы?
Скорее, есть перспективы исчезновения текущего автоматизированного тестирования, а вот ручное будет всегда.
Так же есть направления где можно работать вообще без классического тестирования, для условного фейсбука можно выдавать с привязкой к гео или вобще пользователям релиз для одних, бету для стран третьего мира, альфу для лояльных пользователей. А вот десктоп и с ПО в железках так не выйдет - покупатель стиралки очень расстроится, что из коробки нужно обновление поставить, т.к. с текущей прощивкой вообще нечего стирать нельзя.
А отвечая на вопрос куда пропадают тестировщики, через 3-6 лет большинство уходит дальше, т.к. далеко не всем интересно этим заниматься продолжительное время.
Если под исчезновением автоматизаторов подразумеваете, что AI их вытеснит, то нет. Скорее он станет ещё одним инструментом, которым нужно уметь владеть. Да и то крайне сомнительного качества. Потому что вам могут создать хоть 100 тестов, но их поддержкой вряд-ли сможет заняться кто-то кроме человека.
развиваются как инструменты со стороны разработчика, так и инструменты для ручного тестировщика, и необходимость держать отдельного специалиста для трансляции тест-кейсов в скрипы и их поддержку скоро отпадет.
Интересно, для penetration test есть какая-нибудь годная автоматизация?
(Я имею в виду полный цикл, а не отдельные инструменты)
Можно аналогию с гриппом провести. Вакцины и лекарства каждый год новые, крутые, дорогие, но мы гриппом болеть не перестали и старый добрый чай с лимоном сопровождает нас до конца болезни ))
Что ни говори, а история человечества – это история автоматизации и последующей эволюции работников. Так произошло и в первую промышленную революцию, и во вторую.
Ну если в историю посмотреть, то окажется, что внезапно тестировщики еще задолго до программистов появились, просто назывались по другому (испытатели, отдел технического контроля и т.д.), и на протяжении всех революций это было неизменным. Поработав как в ОТК на производстве, так и тестировщиком ПО, могу сказать, что это намного более схожие вещи, чем принято думать.
Опять же, в статье рассмотрены в основном инструменты QA для разработчика (стат анализ, юнит тесты), тестировщик вообще не занимается этим, предполагаю что автор к тестированию отношения не имеет, из всех сфер тестирования упомянута локализация и метафизическое юзабилити.
Ок, представим что мы покрываем машинным обучением какую то часть функционала, но настраивать нейросетку под конкретную софтину, думать как и когда запускать её, кормить ее входными данными и анализировать выходные (даже если они будут содержать только "все ок" и "не ок") будет тоже тестировщик
Сижу в геймдеве и ржу про "автоматизацию", нуну)
Куда исчезнут тестировщики?