Комментарии 93
Я работаю AQA в крупной аутсорс компании и могу сказать, что ИИ очень сильно галлюцинирует и делает всё, чтобы тест выдавал passed, даже если для этого придётся изменить сам тест и сделать его некорректным в контексте. Для некоторых задач он помогает, но всё равно нужно внимательно следить за тем, что он делает, и разбирать его действия. Поэтому, на мой взгляд, лучше сразу написать всё как надо, чем потом вносить правки в 100+ тестов.
Вы же и ответили на свой вопрос - тестировщики не используют агентов.
Образовался дисбаланс - одна часть системы стала работать быстрее (разработка), другая нет (тестирование). Это вызывает раздражение менеджмента. Тестирование должно быть автоматизировано. Если люди этому сопротивляются или не догоняют, их будут убирать.
Но за 20 баксов в месяц много не накодишь. Это означает эпизодическое использование агентов, не фуллтайм. Если перейти на полную скорость, то обычные тестеры вообще в пролете.
Накодить много можно, если использовать Luna 6 Max, а не Astra. У меня лимиты на Luna 6 не кончаются на 20 баксовом тарифе.
🤦♂️
Три машинистки беседуют. Одна говорит: Я могу печатать со скоростью 200 знаков в минуту. Другая: А я 250! Третья: А я 1000! ??? …тихонько так добавляет: только такая фигня получается…
Девушка пришла устраиваться стенографисткой. Ее спрашивают:
- А сколько знаков в минуту вы набираете?
- Две тысячи...
- Ооооо!!!
- ... но такая херня получается!
Думаю роли аналитика и тестировщика будут совмещаться. Тестировщик должен понимать что должно работать с точки зрения бизнеса, а что не является допустимым
Программист с ИИ пишет код за день вместо недели.
Очередной кликбейт от ИИ-автора. Что за абстрактный программист, за день реализующий и отдающий на тестирование недельную задачу? Приведите примеры пожалуйста.
А что именно вас смущает? Не любую, конечно, задачу, но связанную с простой переделкой большого (заранее неизвестного) количества кода - легко.
Насущный пример - обновили версию PHP, теперь нужно весь код сайта проверить на возможные ошибки и поправить их. Большинство ошибок там простейшие, исправляются добавлением одной проверки или переделкой синтаксиса, но их много (заранее неизвестно сколько) и их нужно искать и на это уходит значительная часть времени.
С ИИ-шкой вся рутина с поиском и правками ускоряется на порядки, остаётся только читать и верифицировать. И список урлов для проверки и сценариев тестирования составляется одним промптом.
Нет, конечно, если программист привык работать "по-энтерпрайзному", 90% времени проводя за ожиданием доступов/допусков, созвонами-переписками, написанием красивых отчётов со скриншотами и пр., то тут да, как не ускоряй оставшиеся 10%, заметного прироста эффективности не получится. Но по счастью (или нет) так сейчас не везде устроено.
Большого это всякие библиотеки он сам начнёт целые библиотеки переписывать с 7-й на 8-ю версию? Чето страхово стало.
П.С. хотя как раз для таких задач, где логику трогать не надо а лишь под новую версию обновить, как будто ИИ подходит лучше всего, но большие объемы пугают, чего он там на делает. Но в принципе если пустить только на код непосредственно самого сайта. Без библиотек, фремворках, то в принципе может и можно.
Не.
Я тут пытался переписать критичную систему VB Net => C# и внести доработки.
Там такое количество приколов, что полностью снять риски простым тестированием невозможно.
Так вы же сами в своём примере прекрасно подтвердили то, о чём я написал в статье. :) Раньше программист неделю искал и исправлял ошибки после обновления PHP, а теперь с помощью ИИ сделал это за день. Отлично! Но дальше вы сами пишете: остается только читать и верифицировать. А кто будет проверять, что после сотни автоматически внесённых исправлений ничего не сломалось? Что сайт работает не только на главной странице, но и во всех пользовательских сценариях? Что исправление одной ошибки не породило три новых? Составить список URL и сценариев тестирования одним промптом, не то же самое, что выполнить эти сценарии и убедиться в полноте проверки. Именно об этом моя статья. Мы научились значительно ускорять производство кода, но проверка его корректности от этого автоматически не ускорилась в той же пропорции. Получается, программист выдаёт всё больше изменений, а тестировщикам приходится проверять всё больший объём работы. А насчёт энтерпрайза, созвоны, доступы и отчёты действительно могут тормозить разработку. Но отсутствие бюрократии ещё не гарантирует отсутствие багов. :)
Раньше программист неделю искал и исправлял ошибки после обновления PHP,
...и при этом забуривался в каждый уголок кода, и как итог прекрасно знал, что где лежит, и куда нужно, если что, стукнуть молоточком,
а теперь с помощью ИИ сделал это за день
...и как раньше не знал, что сломалось и как это чинить, так и сейчас не знает.
Отлично!
Быстро, дёшево.... ну, вы понели.
...и при этом забуривался в каждый уголок кода, и как итог прекрасно знал, что где лежит, и куда нужно, если что, стукнуть молоточком,
Ну, на протяжении пары дней может и знал бы идеально, как студент перед зачётом. Через год спросишь - либо не вспомнит, либо, что хуже - вспомнит неверно.
Но ведь ничто не мешает программисту и сейчас, в сэкономленное ИИшкой время этим заниматься.
Более того, он может вот так просто прийти и сказать начальству "вот, я задачу выполнил, можно я оставшуюся часть недели буду просто сидеть и читать код?". Ответ на этот вопрос довольно наглядно покажет, насколько бизнес готов вот за это платить зарплату.
Ну, на протяжении пары дней может и знал бы идеально, как студент перед зачётом. Через год спросишь - либо не вспомнит, либо, что хуже - вспомнит неверно.
Я уже десятый год вспоминаю — чтой-то не зажужжал.
в сэкономленное ИИшкой время
Это Вы сейчас про то, которое я занимаюсь выяснением, где ещё оно накосячило?
Справедливое замечание. Конечно, речь не о том, что абсолютно любой программист любую недельную задачу теперь выполняет за день. Примеры задач, где кодинг-агенты могут дать такое ускорение: Добавление нового REST API в существующий проект: обработчики, валидация, работа с БД, миграции, тесты. Интеграция с внешним API по готовой документации. Рефакторинг существующего модуля с сохранением поведения и написанием тестов. Реализация новой функциональности по аналогии с уже существующей в проекте. Раньше программист значительную часть времени тратил на самостоятельное написание и отладку кода. Теперь существенную часть этой работы может выполнять агент под контролем разработчика. Разумеется, задачи, требующие проектирования сложной архитектуры, исследований или выяснения требований, за день волшебным образом не решаются. И главное: я ведь не утверждаю, что весь цикл разработки сократился с недели до дня. Именно об этом статья! Программист может передать функциональность на тестирование значительно быстрее, но это совершенно не означает, что она быстрее попадёт в продакшен. Собственно, поэтому я и считаю, что тестирование становится узким местом.
надо различать тех кто пишет тесты и тех кто их исполняет (гоняет).
Разработка тестов может быть гораздо сложнее чем собственно разработка! Проверить чужую работу может только специалист более высокого уровня. Не зря все измерительное-испытательное-тестовое оборудование стоит на порядок дороже чем обычные продуктовые поделки, оно должно быть на порядок точнее, надежнее, итд итп.
Я тоже за то чтобы ценить труд тестеров, даже (а может особенно) тех кто эти тесты просто выполняет. А некоторые тестеры еще и бодаются со всякими аналитиками по поводу того какие требования имеют тестируемость, а какие нет - это вообще сказочные персонажи, но мне с такими приходилось работать! Очень скучаю!
Я могу на своем примере. Я не программист, но делал стартап с программистами, два года примерно. Так вот сейчас я лично сам, делаю себе за 3-4 часа плагин под проектирование, который с прогером мы бы делали минимум две недели, учитывая согласы и переделки. Свой узкоспециализированный софт - тут ии идеально помогает. Но, так как я сам знаю, что должно быть и как - я сразу сам его и тестирую жестко, по сути работая на плагине на живом проекте. Какой-то vst аудио плагин я сделать не смогу, т.к. понятия не имею всех тонкостей.
Вы не одиноки. Мне много друзей предпринимателей пишут что раньше столько бабок на этих дорогих и криворуких программистов тратили и времени и нервов. А щас они сами за 100 баксов в месяц воротят, то что им делали по пол года. Но статья не про это. А про нормальные компании где выстроены процессы. Где есть пул программистов и пул тестировщиков. И процессы надо менять. Тестировщиков надо больше чем программистов. Иначе качество падает.
и все молчат про то, что QA хорошо бы понимать суть проекта и shift left и вот это все. Иначе QA снова становится последней инстанцией и козлами отпущения. Компании сами себе по ногам стреляют с таким подходом, когда не понимают, для чего нанимают людей.
Проблема не найти QA. Проблема найти толкового QA, который, по сути, будет обладать пониманием проекта на уровне разработчика, просто делегировано на него будет именно тестирование. Это всегда было проблемой и ИИ этот перевес просто усиливает.
Вот он - дешевый и пряморукий тестировщик, которого никто почему-то (внезапно!) не хочет брать на работу 🤣
Иди в программисты, если там всё так легко и ты такой весь пряморукий, чё ж ты? 😁
За день сгенерить можно и двухнедельную работу "по старому", причём вообще элементарно, достаточно 3-4 терминала. Но вот 20$ - это утопия, сразу видно автор этого не делал. 200$ надо.
Значит криво делали. Я пол года уже не вылажу из concurrent 3-10 терминалов. Работы переделал больше, чем за предыдущие 10 лет. Практически закрыл уже весь старый тех долг, накопленный в компании за 20 лет. И высаживаю 200$ подписку за 3-4 дня. Поэтому приходится 2 держать. А локальные модели мусор полный, пробовал. С топами даже сравнивать нельзя.
Не совсем понимаю сложность с 10-ю терминалами. Я использую один так как задач не много, но я бы легко и 10 и 20 потянул были бы задачи, это же просто вопрос времени привыкнуть и любой вайбкодер даже так сможет лишь бы были задачи.
Я и не написал, что сложно. Я написал, что много. А минусующие товарищи, не верящие, что агентами можно кодить, походу и за 3 года не переведутся.
не верящие, что агентами можно кодить,
Ну да, а на «Фармане» можно летать. Но есть нюанс.
Опять вайбкодеры сказки пишут. Во-первых если их код не тестировать, то вообще полная шляпа будет. Во-вторых зачастую заказчик не выплёвывает по 100500 фич в день, такое просто не нужно зачастую.
Думаю будет востребованным исследовательское тестирование, когда человек пробует разные неочевидные способы использования и поиска проблем в моменте, поскольку с тестированием по спецификации справляются и нейронки
А ещё можно за день при помощи агентов выдавать столько кода, сколько выдает за год компания с тысячами сотрудников, только какой в этом смысл, если задача не решается, а агенты пишут бред вместо решения задач?
Я уже увидел, как в некоторых компаниях разработчики настолько воодушевились, что запускают агентов в таск менеджер, после чего агенты что-то делают - и эта таска отдается в тестирование агентом. Нужно ли говорить о том, что это просто игра в рулетку и кол-во возвратов тикетов возросло?
Всё бы было хорошо, но за агентам нужно постоянно следить, нужно постоянно их направлять. Можно запустить 3-5 задачи параллельно и следить за их выполнением, доделывать/фиксить... Но полностью запускать в конвейерном режиме агентов можно только для узких задач которые были оттестированы и меняются только переменные, а не тип задач.
Я уже увидел, как в некоторых компаниях разработчики настолько воодушевились, что запускают агентов в таск менеджер, после чего агенты что-то делают - и эта таска отдается в тестирование агентом. Нужно ли говорить о том, что это просто игра в рулетку и кол-во возвратов тикетов возросло?
Это называется вайб-девелопмент /sarcasm
Есть еще вайб-предпринимательство - это когда и общением с контрагентами занимается нейроагент. Ну и там либо прокатит, либо нет...
Так я об этом и пишу. :) Кодинг-агенты значительно ускоряют написание кода, но совершенно не гарантируют, что этот код решает поставленную задачу. Именно поэтому я и считаю, что сейчас роль тестировщиков становится ещё важнее. Раньше программист мог неделю писать функционал, который тестировщик проверял день. Теперь программист с агентом может за день выдать недельный объём работы, а тестировщику всё равно нужно проверять результат. Причём потенциально ошибочного кода теперь гораздо больше. И я нигде не предлагаю запускать агентов без присмотра. Наоборот, программист должен управлять агентами, проверять их решения и нести ответственность за результат. А вот когда компании начинают измерять эффективность количеством закрытых агентами тикетов, а не количеством реально решённых задач, получается замечательный конвейер по производству нейрослопа. :) Мой тезис простой: ускорение разработки без соответствующего усиления контроля качества, это не повышение производительности, а ускорение производства ошибок.
странно получается: есть агент, который пишет код, есть тесты, которые пишет (во многом) человек и которые должны "верифицировать", что написал агент. вы всё хотите поручить братьям нашим старшим, надеясь на их "опыт", что все тесты они пишут "как надо" и пр. мб стоит натравить на тесты еще одного агента, который будет верифицировать тесты, на этого - еще одного и тд) test-dd становится test-like dd.
Попросите себе ещё одну подписку. И +10%-20% к зп. И тестируйте сами. У Вас ведь теперь появилось время разобраться в том что делает qa.
Не знаю, у меня ультра за 2 недели дохнет которая за 200 баксов. Там по 5 - 6 агентов пилят фронт, бек, субд, тесты, cicd. Сами открывают браузер и тыкают там мышой чего получается и всё это как одна задача - сделать фичу Х под ключь. А не просто что ну она сделана и её кому то надо проверить. Ну а глобально я один делаю продукт, который не навайюкодить за неделю. Управляемый, горизонтально масштабируемый RAG завод на EDD архитектуре, который может пережевать для ИИ что угодно в закрытом контуре. Ну как делаю, сделал уже за 3 месяца по 400 баксов в месяц. Раньше бы на это ушло наверное года 3. Уж больно заковырканный мир документации и её форматов. Да и вообще до фенькиной горы форматов файлов всяких. А 1С индексировать - целое искусство.
По итогу - сверху сам наблюдаешь за всем, чего получается. Что по нагрузке, как масштабируется. Чего по сайзингу. Какие пользовательские сценарии как реализованы. Как всё работает. Где что и какими тестами покрыто.
Ну и сам руками тыкаешь в то что получилось. И даже пользуешься потом сам тем чего сотворил. И сам к себе в агента приходишь с новыми хотелками.
Мир поменялся вобщем. Токены - забористая дурь. Поджирают иной раз семейный бюджет. И дают чистый кайф от творчества.
Не актуально оно сейчас рассуждать что где то кто то Вас блокирует в чем то) Ну возьмите себе его работу и автоматизируйте через ИИ 95%. Остальные 5 - хьюман ин зе луп) Верификация
И, кстати, я не особо понимаю, почему тестировщики не используют кодинг‑агентов?
Используют, но с переменным успехом. Встречался с результатами работы. Если дать ИИ задачу "потестируй и найди ошибки", без лишних подробностей, то ИИ на каждую реальную ошибку выдаст 2-3 сгаллюцинированных. Особенно, если будет смотреть в код, где всегда полно лишнего (либо уже не используемого, либо ещё).
Плюс, для тестирования требуется много контекста - задача у тестировщика написана как "протестировать фичу Х", а на деле это не получится просто скопипастить ИИ-шке: нужно уточнять, под каким пользователем, с какими настройками и пр. И при возникновении ошибки снять скриншот (какой области), добавить на него стрелки (какие и как), написать шаги воспроизведения и ожидаемый результат. Прописывать это всё каждый раз может оказаться дольше, чем вручную открыть и протестировать.
Так не надо что бы ИИ делала работу тестировщика. Надо самому тестировать. ИИ только может ускорить тестировщика при оформлении тикетов или при написание автотестов пользовательского интерфейса. Тестировщики сейчас стали на столько важны именно потому что они своими руками проверяют нейрослоп от программистов. Это последний рубеж который некоторые компании придумали вообще убрать.
>"потестируй и найди ошибки", без лишних подробностей, то ИИ на каждую реальную ошибку выдаст
Странно да? Garbage in, garbage out. Доказывает лишь то, что не надо кормить агентов мусором.
Чтобы был контекст, надо его дать, конечно не кинуть в чат а организовать места хранения контекста и дать агенту доступ к нему. При работе с агентами тоже нужен инженерный подход. У меня вся документация и функциональные требования хранятся в локальной RAG базе (которую агент и написал), каждый день по расписанию подгружаются обновления, у агента есть доступ по mcp до rag базы, jira, confluence, figma и остальным ресурсам на проекте. Есть скиллы по тест дизайну, баг репорту, написанию тест кейсов и т.д. Хуки запрещают лишние действия. И когда агент получает задачу, весь контекст у него есть, он знает где ему посмотреть требования, где узнать как работает система, посмотрит связанные задачи. Знает как правильно написать кейсы, как проверить и завести баг репорт. А в код ему смотреть незачем, цель тестирования проверить пользовательские сценарии, а как это в коде реализовали по барабану. Код пусть unit тесты проверяют
Я без RAG обошелся, у меня 35 приложений к agents.md по 10к. Разбито помодульно, по функциональности. Агент сам разбил. Задолбало контекстное окно пухнуть. Интересно RAG лучше в этом смысле, меньше токенов нужно?
Кстати гугл далеко неоднозначен к RAG и множественным agents-*.md https://share.google/aimode/hSSrRYb0YIizXuTqM
В теории агент читает и знает, а на практике “извините, я только первые 20 строк прочитал”.
Потому что при нормально выстроенном процессе разработке не важно с агентами или без, тестирование - это часть процесса разработки. Поэтому высказывание "программист что-то наговнякал, а мне проверять" оно не корректно само по себе.
Сам процесс:
1. Задача в трекере. Прежде чем задача назначается кому-то происходит валидация требований. Задача обычно небольшая.
2. Написание спецификации/контракта с агентом.
3. Валидация спецификации/контракта другим агентом или агентом в другой сессии. Тут нет контекста предыдущего агента, поэтому он не будет пытаться подогнать ответ под решение. Может быть несколько итераций.
4. Реализация по согласованному контракту.
5. Проверка реализации. Также в несколько итераций в чистом контексте.
Собственно говоря, потом вы можете взять спецификацию, взять залитую на тест реализацию и попросить агента протестировать.
А что дальше? А дальше у логи приложения идут в какую-нить Grafana вместе с метриками и у агента есть доступ по MCP к этой информации. Он может мониторить не вызвал ли релиз какую-нибудь ошибку.
Короче, автоматизировать тестирование - это довольно простая задача.
ох… ситуация - страшная, на мой взгляд.
выдача объема кода - не показатель. например, 20% кода могут определять ключевые моменты архитектуры. а 80% - быть по сути утилитарным кодом, который можно и с агентом писать.
не во всех кейсах возможны вообще автотесты. не везде сейчас вообще LLM сможет сгенерить нужные тесты. более того - тестеры без серьезных знаний в области - просто покрывают основной, первичный слой проблем - точнее, отсекают буквально мусорный код, не более.
текущая ситуация с CVE - появилось огромнейшее количество инструментов анализа, и уязвимости находятся одна за другой. при этом - качество кода и тестирования скатывается. time-to-market - ключевая метрика последние годы, увы.
чтобы не быть голословным - вот мой личный пример, когда и ручные тестирования, и высокие квалификации - провалились на уровне либы международного уровня. как бы это нашел LLM? какая должна быть квалификация тестера? https://github.com/unicode-org/icu4x/discussions/4527
Дык а в чем проблема? Всегда есть некоторое расхождение между тем как мы думаем, что система работает и тем, как она работает в реальности. Если нет тестов, которые покрывают каждый конкретный случай (а в приведенном примере вряд ли это возможно - мы же не будем генерировать тесты на все возможные комбинации юникода), то баг сидит в системе и ждет пока на него кто-то не наткнется. Часть багов можно поймать стат-анализаторами кода, некоторые баги LLM хорошо ловят путем анализа кода и выявления потенциальных дырок в бизнес-логике и непокрытых сценариях. Остальное - дело случая.
“мы же не будем генерировать тесты на все возможные комбинации юникода”. о, именно это я и сделал в том числе :) могу поделиться по теме блоком аналитики :)
но вообще - я не отрицаю сам слой. я его просто считаю неполноценным. как и текущую ситуацию с квалификацией тестеров, признаваемой достаточной. а с LLM для отлова ещё нужно уметь работать - потому что нужно знать, что спрашивать, чтобы получить ответы. иначе - мы в целом получаем generic ПО.
С этим никто и не спорит. Поймать абсолютно все баги невозможно, даже если посадить десять тестировщиков на одного программиста. Но есть принципиальная разница между ситуацией, когда кодинг-агент написал код, сам его проверил и сообщил, что всё прекрасно, и ситуацией, когда независимый тестировщик попытался этот код сломать. LLM может найти ошибки в коде, написать тесты и проверить их прохождение. Но проблема в том, что она часто проверяет реализацию на соответствие собственному пониманию задачи. Если изначально неправильно поняла требования, то может написать неправильный код и успешно покрыть его неправильными тестами. :) Именно поэтому я и считаю, что с ростом производительности программистов роль независимого тестирования должна усиливаться, а не сокращаться. Не потому, что тестировщики найдут абсолютно все, а потому, что они способны обнаружить то, о чем разработчик вместе со своим агентом даже не подумал. Иначе мы просто увеличиваем скорость производства не только функционала, но и потенциальных ошибок.
По программистам тоже ситуация забавная: сколько ни работал в коллективах, только 20% программистов выдают 80% всего кода, а другие 80% выдают всего 20%
Очередной автор, который мерой результативности считает объём выданного кода...
Разные участки кода имеют разную степень зрелости.
Два байта изменений в ключевой код ядра часто требуют значительно больше опыта, работы и времени чем сотни килобайт кода для свеженаписанной фичи-прототипа - потому что в первом случае от них зависит вся программа а во втором случае код в 90% случаях отправляется в помойку.
Если девелоперы используют агентов, очено странно, что QA их не используют
Со стороны AQA: агенты очень помогают находить root cause сложных багов. Для каких-то flaky кейсов, на которые раньше полдня уходило, сейчас можно сделать за час.
Код автотестов тоже руками практически не пишем, первоначальное ревью тоже от агента.
Тест дезайн изначальный тоже от агента, но вот его уже приходится ревьюить сильно, тут зависит от того сколько контекста ты ему смог передать, и иногда бывает много лишних кейсов (если контекста много), или плохое качество, если контекста мало.
В целом, не могу сказать что объём работы который может сделать AQA увеличился в разы, скорее процентов на 20-30, но сильно изменилось качество, если раньше часто забивали автоматизацию сложных в воспроизведении негативных сценариев, то теперь добавлять их проще. Вместо 5-7 автотестов на юзерстори, добавляется 10-15.
Нельзя на разработчика повесить 10-икс больше работы без потери качества. У человека ограничены когнитивные возможности, а каждая задача, каждый прилет ревью их тратит. Если экономить на ревью и планировании будет копиться техдолг, ллм будет копировать свои плохие паттерны т.к. код для нее ориентир, чинить одно ломать другое итд В итоге проблемы поддержки скажутся на бизнесе.
Да-да, в стародавние времена лозунг был: "Даешь план по валу!". ИИ ускорил кодирование – вот тут бы и переключиться на создание более качественного продукта, не меняя скорости разработки. Как бы не так! Мы лучше завалим киберпространство тоннами глючного нейрослопа, но подход менять не будем. Передовики производства, стахановцы, туды их в качель...
Программист с ИИ пишет код за день вместо недели. Почему компании сокращают тестировщиков?
Потому что есть скилы test-suite-architect, test-driven-dev, http-load-profiler и прочие, а добавление VL модели при правильной настройке еще и unit/e2e тесты напишет и запустит их.
В обоих случаях (человек vs LLM) тесты зеленые и ничего толком не гарантируют.
Тестировщик негодуэ 🤣
Программист вполне справляется с работой тестировщика, а вот наоборот - нет и подавно. Так что я бы предложил просто накинуть лаве программистам, чем брать на работу таких токсичных тестировщиков))
У нас кстати как раз нет тестировщиков, зато есть ИИ и системные аналитики и весь процесс тестирования распределяется между нами и ничего - в багах не тонем.
Вопрос ведь не в том, способен ли программист выполнять работу тестировщика. Конечно, способен. Вопрос в разделении ответственности и профессиональной специализации. Программист сосредоточен на том, чтобы реализовать функциональность, а тестировщик на том, чтобы найти в ней проблемы. Это два разных подхода к одной задаче. Более того, разработчик зачастую склонен проверять, что его код работает так, как он задумал. А тестировщик проверяет, что произойдет, если все пойдет не так, как задумывалось. :) Если у вас процесс работает без отдельных тестировщиков ну прекрасно. Но это не означает, что такая организация будет эффективно масштабироваться на любые команды и проекты. И уж тем более не отменяет проблему: когда ИИ ускоряет написание кода в несколько раз, нагрузка на проверку этого кода тоже возрастает.
Программист сосредоточен на том, чтобы реализовать функциональность, а тестировщик на том, чтобы найти в ней проблемы.
У Вас опять в слове «овнокодер» полно опечаток.
Это они «реализуют функциональность», шаг влево, шаг вправо — попытка к побегу. А программист именно что начинает продумывать все возможные варианты разивития событий — особенно те, когда что-то пойдёт не так — ещё до того, как напишет первую строчку кода.
Это я Вам как именно что программист говорю.
Тестировщики это круто. Сам большую часть работал без них (обычные сайты там на разработке экономят, какое ещё тестировщикам платить), а в одном месте были. С ними по качеству существенно лучше выходило. Чем если сам разраб+сеошник+менеджер+заказчик глянет. Другое дело что не всегда баги это прям проблема проблем, "ну подумаешь в редком кейсе не сработало, ещё раз пользователь попробует и сработает." особенно если деньги от этого пропасть не могут.
У вас 2.5 года опыта работы с ваших же слов, откуда вы вообще можете делать такие утверждения?
У вас 2.5 года опыта работы с ваших же слов, откуда вы вообще можете делать такие утверждения?
С Пика Даннинга, конечно же!
Программист вполне справляется с работой тестировщика
Только не своего кода
Очень часто стали встречаться низко IQ'шные, кто ниасилил разработку и понятия не имеет не только о том, что она из себя представляет.
Вот это низкое IQ прослеживается не только в качестве мышления и способности строить причинно-следственные связи, но и в спорах, аргументах.
Уровень такого человека как разработчика - работник или бывший руководитель веб студии «Сыр», которая раз в квартал сделает лендинг кофейни и массажиста с глючной прокруткой и невидимыми кнопками в мобильной версии. Работник не знает что такое git, ci, кэш, нагрузка и пр.
Такой человек в роли разработчика никогда не делал что-то серьезнее, чем CRUD, т.к. его ремесло - слепая копипаста из stackoverflow, но никак не программирование.
Глядя на настоящего разработчика у такого человека всегда возникала зависть к его умственным способностям, творчеству и реализации, не говоря уже о финансовых показателях.
И тут появляется генераторы текста, агенты.
Из-за низкого порога вхождения он решается "для прикола" оплатить подписку и создать лендинг: и, LLM выдаёт весьма неплохой результат по меркам студии «Сыр»! Дизайн не хуже того, что делал Петя, сотрудник студии. О, да!
Наш низкоуровневый (с нюансом) разработчик - теперь вайбкодер, а программисты вокруг - резко стали ненужны.
Так, из отважных единиц очков IQ рождается "эксперт", который ничего не понимает, зато делает вид, что всё знает. И то, что раньше он сделать не мог ввиду своей отсталости, теперь делает LLM, пусть это и бесполезное. И что, что нейрослоп? Ведь это пока работает!
"Эксперт", будет пытаться до конца компенсировать отсутствие своего IQ нейрослопом и спорами там, где у него 0 компетенции, ведь как работает LLM на самом деле его не особо то волнует, ведь оно работает! И что, что генеративный и не умеет ничего нового придумывать и мыслит лишь тем, чем его обучили?
Такой "эксперт" никогда не нащупает край возможности генеративного LLM, поскольку сам он никогда не пройдет тест на логику. Но ему этого и не надо.
Зато теперь уровень самооценки низкоуровнего "эксперта" держится не только на его иллюзии причастности к разработке, но и иллюзии ненужности тех, чей IQ кратно выше его.
Самооценка подобная этой будет расти с лимитами генератора текстов.
А для пущей уверенности "эксперт" вместо аргументов будет козырять прогревами заявлений дергающегося кучерявого фрика в очках, заднеприводного воришки из OpenAI, а также тех, кто научился проходить собесы в Телеграмм и предлагает уволить всех, кто умеет писать код руками. Тут ещё в помощь его аргументации приходит экономический кризис, который некоторые зарубежные компании списывают на ИИ.
Есть такое. Но, с другой стороны, слабые программисты были вытеснены с рынка, так как теперь любой предприниматель может попросить ИИ написать ему простую автоматизацию, а не ждать несколько недель, пока живой программист ее сделает, и не оплачивать его работу по завышенным ценам, будто он мегагуру.
Это тоже весьма спорный вопрос. Кому больше угрожает ИИ? Такой предприниматель обычно не хочет заниматься сайтом не с ИИ не без ИИ у него других дел хватает чтоб еще сидеть с сайтом заморачиваться. (особенно если там хотя бы многостраничный каталог а не просто лендинг) проще одного двух спецов держать с неогромной з.п. может даже на частичке. И если их убрать вообще ни кого не останется. Или команды где десяток сильных спецов с большой з.п. сложным ПО занимаются, ну подумаешь 1-го, 2-х уберём, 8-9 с ИИ все равно много останется.
Ну мои знакомые предприниматели пока что иного мнения )))))))))))))))))
У них как у предпринимателей - хочешь сделать хорошо - сделай сам - раньше сами не могли мозгов не хватало и навыков - а щас могут тут ИИ подсунули им и они вообще выдохнули
У предпринимателей задачи очень простые где не нужен мега гуру программист )))))
Может совсем какие то мелкие ИПшники, которые все в одну каску тянут. У меня так другие предприниматели. У которых какой-никакой персонал есть и объемы. И даже если у них остаётся свободное время от бизнес вопросов предпочтут отдохнуть или ещё как потратить. А не пыхтеть самому лишь бы сэкномить на разрабе.
П.С. Я тоже про обычную рутину на средних сайтах. А не что там очень сложное.
Вы описываете средний бизнес. Его в штучном варианте в несколько раз меньше мелкого бизнеса. Мелкий бизнес это владелец детейлинг центра, шоу рума и тд. Не сетевой бизнес как Вы описываете.
ИИшка говорит. Малый бизнес это 16 – 100 человек, средний 101 – 250 человек(с некоторыми исключениями). Я прям точно не знаю сколько человек у тех кто моими услугами пользуется в компании работает, но по ощущениям😆 меньше сотни. И там сами директора сайтами там не занимаются, не охота, они даже со мной не всегда общаются, не редко менеджер какой то от них задачи ставит, который тоже не то чтобы хочет дополнительных обязанностей и чего то самому вайбкодить. Поэтому рабочие места сайтоделов обыкновенных больше защищены чем сеньоров в крупном ИТ.
раньше сами не могли мозгов не хватало и навыков - а щас могут тут ИИ подсунули им и они вообще выдохнули
...и мозгов у них по-прежнему не хватает понять, какое овно получилось.
@Hemml: Да, всё, в чем ты не разбираешься, нейронка делает хорошо. Но вот то, в чем ты что-нибудь понимаешь, она всегда делает плохо
Я столкнулся с непониманием того, что тестировщики стали узким горлышком в процессе разработки ПО.
Мы столкнулись с тем, что вы не понимаете, что такое код и ПО, и как они должны производиться.
Современные программисты, используя кодинг‑агентов по подписке за 20$ в месяц, могут за день своей работы выдать объем кода и функционала, который ранее они делали неделю или даже месяц.
Не могут. Просто потому, что обозначенная неделя - это не кодинг
Это согласование макетов и контрактов, получение доступов, уточнение 1001 нюансов логики и прочее и прочее. В целом статья явно носит манипулятивнынй характер с некорректным главным посылом. Простите а Вы точно разрабатывали по по сложности чуть больше небольшого проекта ?
Посмотрите мой профиль. Там найдется мой опыт работы и тд…
Посмотрите мой профиль. Там найдется мой опыт работы и тд…
Коллеги, я сходил к нему в гитхаб, чтобы вам не пришлось.
Опыт работы так и брызжет через край:
pinduoduo-mcp: 19 commits, docs: add Pinduoduo MCP implementation plan, 2026-11-01
ai-cam: 35 commits, docs: план AI Cam — чат с ИИ, который видит веб-камеру, 2026-10-30
subtask4llm: 25 commits, Initial commit 2026-10-26
blueprint4llm: 104 commits, Initial commit 2026-10-20
ai-life-experement: 22 commits, Initial commit 2026-09-15
ai-coding-manifesto: 4 commits, Initial commit 2026-07-14
ai-asset-screener: 12 commits, Initial commit 2025-08-22
fastpy-rs: 77 commits, Initial commit 2025-07-22
url-text-fetcher: 2 commits, Initial commit 2025-08-23
ai-tarot: 13 commits, Initial commit 2025-05-27
cblt: 215 commits, Initial commit 2024-11-06
ai-agent-telegram-bot: 24 commits, Initial commit 2025-03-30
rust-recipes-for-beginners: 27 commits, Initial commit 2024-11-05
rustsn: 111 commits, Initial commit 2024-11-20
candle-simplified-example: 6 commits, Initial commit 2023-09-03
Найди все возможные ошибки. напиши для этого тесты. Чем больше красных тестов тем лучше.
Проверь и исправь найденные ошибки. После исправления проверь существующими тестами. Тесты из красных должны стать зелеными.
Верниcь к п.1
скорее нужны какие-то бизнес-аналитики, которые будут понимать что вообще хотели получить от ПО и работает ли по бизнесу. а тестировщики как они сейчас - которые техническую часть делают, так будут те же агенты, программисты же и будут делать соседней момделью и своим харнесом дополнительным (доплачивать, конечно же, программисту за то что он запускает агента-тестера - никто не будет)
Занятно, только сегодня Дипсику поставил задачу, максимально покрой тестами проект, и потом напиши что, в принципе, ИИ-агент не может покрыть тестами и нужен человек.
Потом и другую модель пущу следом с такой же задачей, узнать что Дипсик пропустил или налажал.
20/80 - это правило Парето. В ИТ это значит, что настоящий программист (из 20) может всё сделать в одиночку - от первичной встречи с заказчиком до сдачи проекта и получения денег, выполняя различные роли, как архитектор, аналитик, тим-лид, тестировщик, кодер и т.д. И от использования ИИ-агентов и вайб-кодинга максимально выигрывают они.
Нужно исходить из того, что главный тестировщик, в конечном итоге - заказчик, который зачастую сам до конца не представляет что он хочет, а тестировщики не клиента могут проверить только основные, явно прописанные сценарии, которые далеко не всё покрывают, в принципе. Поэтому "под ключ" можно сделать только, если стоят задачи, типа - "Сделайте мне точно такой-же сайт, только с моими данными" или сделайте что-то типа сайта-визитки, лишь бы было. Короче, клиента (или его работников, непосредственно взаимодействующих с разрабатываемым ПО) можно и нужно использовать как тестировщиков, оговаривая это в договоре, экономя на внутренних тестировщиках, от увеличения количества которых мало пользы.
ИИ-после покрытия всеми тестами моего проекта написал, про потребность в живом тестировщике и остальных
Коротко: ИИ-агент хорошо закрывает всё, где есть формальный оракул — «ответ 200», «в JSON есть поле», «после клика открылся экран», «покрытие не упало». Человек нужен там, где оракул — вкус, закон, деньги, реальное устройство или ответственность.
Что ИИ-агент не может закрыть в принципе
Отдельно: ИИ не несёт ответственности. Он может написать «всё зелёное», но подписать релиз деньгами, персональными данными и репутацией должен человек.
Что должен тестировать живой тестировщик в первую очередь
Для astro3d.ru я бы расставил так:
Деньги end-to-end — маленький реальный платёж, доступ, чек, возврат, повторный вход, партнёрское начисление. Раз в релиз и раз в месяц.
Вход и восстановление — VK, Telegram, код из письма, истёкший токен, выход на всех устройствах, заблокированный аккаунт.
Карты на реальных устройствах —
radix2D,radix3D,synastry2D,transit2D,calendar2D: мобильные жесты, поворот, тёмная тема, печать, PDF, глифы, большие дома/аспекты.ИИ-чат — 15–20 сценариев: астрология, бытовой вопрос, медицинский вопрос, попытка prompt injection, длинный диалог, обрыв стрима, лимиты, публикация и PDF.
Почта — Gmail, Яндекс, Mail.ru: папка «Спам», ссылки, отписка, повторная отправка.
Доступность — только клавиатура, один экранный диктор, zoom 200%, контраст.
Поддержка — виджет на телефоне, реальный диалог, вложение, гость/вошедший, оператор ответил/не ответил.
Регресс по релизу — 10–15 главных пользовательских путей на iPhone Safari + Android Chrome + desktop Chrome/Firefox.
Раз в месяц — отдельно: pen-test, нагрузочный прогон, восстановление из бэкапа, матрица браузеров, вычитка статей и астрологических трактовок экспертом.
Что можно автоматизировать, но человек всё равно подписывает
axe/Lighthouse — ловят 30–40% проблем доступности, остальное руками.Visual diff — подсвечивает изменения, но «нормально/ненормально» решает человек.
k6 — даёт цифры, а решение «выдержит ли прод» — за SRE.
ZAP/сканеры — находят известные классы, но не логические дыры.
LLM-as-judge — помогает с оценкой ответов, но сам предвзят; нужен человек.
Практическое правило: ИИ готовит прогон и триаж, человек делает приёмку по рискам. Зелёный CI — это «нет известных поломок», а не «продукт готов к релизу».
Скоро весь софт будет разрабатываться по принципу голландского штурвала - компьютер пишет, компьютер тестит и релизит, но страдает - человек и юзер...
Проблема эффективной разработки нынче решается увольнением, тех кто не дает тащить в прод непроверенное в адском темпе. Таких называют не эффективными и просят на выход, остаются только эффективные, которые могут зажмуриться и сделать вид, что качество не хуже, ну или что фичаделивери лучше качества. И не важно, программисты, тестеры, менеджеры, если не поддерживаешь обкурившихся ИИ топов, ты не эффективен, пожалуйте на выход пожалуйтса.
Главное, что большая часть компаний и продуктов может так жить, да у них след из сгоревших сотрудников, потеряных клиентов (из тех что попали на некачество), но в целом полет нормальный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программист с ИИ пишет код за день вместо недели. Теперь нужно больше тестировщиков?