…и я решил, что я буду изучать Playwright. Почему я буду изучать именно Playwright, а не автоматизацию тестирования ПО вообще — ну так в вакансиях пишут, что надо уметь в этот ваш Плайвригхт.

Так-то я хз, как оно правильно читается, ха-ха-ха, но инглиш иззэ кэпитэл оф грэт бритэн, это я досконально знаю ещё со школы. Советское образование всегда было лучшим в мире!

А что приличному человеку нужно для успешной учебы?! Ментор нужен, конечно же. Пусть все, как дураки, бегают на общие курсы, а я возьму себе индивидуального ментора, он мне обстоятельно всё объяснит, и это будет моим конкурентным преимуществом. Мы будем с ним раз в неделю созваниваться (два раза, ладно) и он будет советовать мне, что учить, а что нет смысла учить, какие именно страницы в каких именно книгах читать, и будет спрашивать, как у меня идут дела, и я как разовьюсь! Ого! Да-да-да!

Ну и вот я вам пишу, драгэ романтикэ товарэшул молдовенескул тестировщик, а давайте вы будете мне ментором по Playwright. И по API. И по REST, чтобы три раза не вставать. Давайте раз (два раза?!) в неделю созваниваться, вы будете мне обстоятельно всё объяснять… это в ваших же интересах! Доведите меня до трудоустройства, и я сразу же вам заплачу за обучение с первой же зарплаты. Я знаю, что у начинающего зарплата будет небольшой, 1500 или 1700… ладно, 1200 долларов, я не жадный (для начала). И я сразу вам заплачу 200 евро, не обижу. Вам там, в Молдавии, много не надо, я смотрел видео либерально-уважаемой Натановны Эйдельман и знаю всё про вас и вашу страну.

Он, конечно, попытался накрутить себе цену и сбить меня с пути истинного. Начал спрашивать, а зачем вам вообще эта автоматизация, может быть, вы сперва научитесь (хотя бы!) тестировать. Или программировать, хотя бы, на том же JS. На что только не пойдут эти молдаване ради лишних 200 долларов…

Но позвольте милостивый государь, говорю я ему, я же знаю, что тестировать — слишком легко, а программировать — слишком нелегко. А я нашел хитрый способ пройти невредимым посередине — неведомая автоматизация манит меня и ждёт, когда я её открою для себя… Давайте же, ну!

А он говорит — то, чего вы хотите, звучит логично, но на деле нелогично. Вы только умеете переустанавливать винду при любой проблеме и мечтаете купить мак, якобы там ничего переустанавливать не надо… Но вы даже в настройки системы никогда не заходили! Как вы будете скрипты в Playwright писать, если вы локатор в html не найдете, даже если вам на него укажут пальцем указательным?! Почему бы вам не изучить html для начала? И на Linux посмотрите, там тоже основы несложные…

Каюсь, зря я ему про всё это рассказал, что умею только переустанавливать винду и мечтаю купить в Шымкенте дорогой мак занедорого, и что ничего не знаю про html. Слишком я откровенный, что поделать, страдаю человеколюбием. Мы, хабаровские, всегда от этого страдаем.

Вообще я слегка уставший, но изо всех сил стараюсь оставаться вежливым, ведь с молдаванами надо разговаривать как с животными — ласково, без резких движений, а то испугается и шмыгнёт в кусты… Ну я ему и говорю, мол, а зачем мне эти твои глупые html и мануальное тестирование?! Ты такой странный, такие дурацкие предложения предлагаешь… Да ты меня НЕ СЛЫШИШЬ! У мануального тестирования нет будущего, у программирования нет будущего, в будущем будут одни только клауды, я знаю… Мне нужно научиться плайрайт, или как его там! Ментор мне нужен, мееееентоооор!

Он уже занервничал, начал говорить про отвлеченное, мол, а вот вы про клауды говорите — какие именно? Вы про Cloud computing или про семейство ой-ай моделей Claude? А я ж не знаю, о чем он лопочет… Всякие будут, веско говорю. Оно сегодня так развивается, что ай-ой, завтра вообще будет ой-вэй. И пока все вы будете ой-ой, я буду спокойно автоматизировать. Месяц-другой. А потом переключусь на что-то поинтереснее…

А он всё не угомонится, он меня уже с фланга обходит — а хотите, мы просто поговорим о том, как IT устроено? У меня день свободен, я машине под лобовое стекло полиуретановый герметик загнал, спешить некуда. Могу вам рассказать, с чего всё начинается и где там нужен Плэйрайт, а дальше вы сами решите, с чего вам начать…

Мммм, нет, я уже всё понял, не хочет этот полиуретан поработать индивидуальным ментором. Не хотят люди деньги зарабатывать, не хотят… Ну и не надо. Я совсем уже почти договорился с одним бывшим программистом из дома напротив, так он мне устроит краткосрочные курсы по Playwright. Десят тыщ тенге за одно занятие, ну и что? Это недорого. Занятия утром и вечером, а в обед я буду заниматься дома бесплатно, я всегда имею возможность заниматься дома бесплатно и доставать свежие версии Playwright и другие полезные скрипты. В конце концов, если мне покажется недостаточно, так я всегда смогу прикупать нужное в даркнете. Пусть всякие дураки берут учебные курсы задорого. Вот я вижу, вы всегда берете учебные курсы задорого. А я могу брать их же с рутрекера, слитые, бесплатные, у меня там есть аккаунт, и они даже слитые будут лучше, чем ваши онлайн и задорого. Ваши курсы битые, а у меня будут целые, хорошие, проверенные временем курсы! Вы человек ещё молодой, вы ещё не понимаете, что главное в жизни — это устроиться с хорошими образовательными курсами… Ведь мир заполонили дурные, своекорыстные люди! Да господи же боже ж мой, ну нигде же нет от них спасения! Куда ни сунься — везде ведь они! Везде блат, по знакомству можно достать всё, а без знакомства человек ничто — особенно, если он не сумел как следует устроиться по образовательному аспекту…

На том и разошлись.

Весь последний абзац — мой вольный парафраз из Стругацких, «Рукопись ОЗ», раздел 23-25, спич Матвея Матвеевича утром на кухне. Соррянчики, не удержался, очень уж было похоже.

А кто виноват?

Я, конечно же.

Человек проделал сложную работу и, как говорит тащ. военврач Курпатов, «оказался в конструкции» в которой он нашел изящное решение своей проблемы. Ему не нужно ни тестировать, ни программировать, он уже решил, что ему просто нужно освоить Playwright. Он всё продумал, он ВСЕХ перехитрил, он сумел выехать, он молодец, осталось только найти кого-то, кто ему покажет, что где нажимать и чтобы светлое будущее наконец-то настало.

А тут я со своим ненужным мнением, пытаюсь ему объяснить что-то, что превышает его уровень понимания темы (винду переустановить…) на невозможном для него уровне объяснения. Мог бы я поменьше рассказывать про абстрактно-игристое?! Вы же не поэт, к чему вам смотреть, как ветер колотит воду по чреву пепельно-сизых финских волн!?

Но я исхожу из того, что нельзя отказывать голодному в еде, а интересующемуся в объяснении. И если я могу что-то объяснить, то давай объясню, тебе потом проще будет понимать, как всё устроено и принимать взвешенные решения.

Я, конечно же, сказал, что если вы вообще ничего не знаете о том, как делают ПО, Playwright сам по себе не имеет смысла, что там надо будет смотреть в код html и писать команды, мол, значение этого элемента сохранить в переменную и сравнить с ожидаемым результатом. Например:

let totalPrice = document.querySelector('#totalPrice').textContent;
let expectedResult = 100;

if (Number(totalPrice) === expectedResult) {
console.log("Total price: PASS");
}

Вам тут всё понятно? В переменную totalPrice cохранить значение из элемента #totalPrice в виде plain text. Перевести этот plain text в число. Сравнить число из переменной totalPrice со значением из переменной expectedResult. Всё понятно человеку, который не имеет понятия, что такое html, переменные и прочие абстрактные абстракции? Оказалось, что нет. И что это всё, очевидно, лишнее. Зачем это всё?

Почему же я просто не сказал ему «Нет»? Человек понял только то, что его пытаются разубедить, ему показалось, что над ним издеваются. Человек хочет просто научиться Playwright. Он же не спрашивал, как оно всё устроено. Может быть, надо было просто показать ему Playwright?

Это проще показать или объяснить?

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

Впервые я увидел это году в 2017-ом, наверное. Коллега установил какой-то софт для записи экрана, и тот софт нарисовал ему на экране квадрат — область, содержимое которой попадет в видеозапись. А коллега хотел записать сразу весь экран, а не квадрат. Он это ПО сразу удалил и пошёл искать аналоги.

Я это ПО у себя установил, увидел упомянутый квадрат, ухватил его за край курсором мыши и понял, что область видеозаписи можно спокойно растянуть, передвинуть, и вообще можно нажатием одной клавиши переключиться в режим записи всего экрана — я просто посмотрел в настройки софта… И написал коллеге, мол, it works, this gizmo is adjustable! Переключись в другой режим, нажми такую-то клавишу.

Коллега ответил, что нененене, этот софт неадекватный, он скоро найдёт другой.

Ну ок.

Сам по себе Playwright — это фреймворк для написания кода, через который можно будет вызывать из небытия браузер и в этом браузере эмулировать действия пользователя, тыкать кнопки, пролистывать страницы, кликать по ссылкам и проверять наличие каких-то элементов или содержимое этих элементов. И тут надо бы объяснить, что такое фреймворк…

А чтобы взаимодействовать с элементами в коде html надо хотя бы немного разобраться с этим самым html. Начнём с того, что это не язык программирования, это язык логической разметки текста (Hypertext Markup Language). Там дальше есть неэпически запутанные моменты и нюансы, но в основе — нет ничего сложного, смотрите….

Чтобы разобраться с html, надо написать свой код, своими руками, полностью в отдельном файле, и открыть это всё в браузере и посмотреть, что получилось. Сделал три страницы, вывел текст, вывел изображения, соединил эти три страницы через линки — увидел и понял, как оно работает.

Заодно посмотришь, по нраву ли тебе айтишная работа — колотить код и смотреть, как он вроде бы складывается в нужное, а вот тут не получается, а вроде бы всё правильно написал, а что-то не так, а что именно не так, а почему оно, бляха, не работает… ааааа, вот почему оно, бляха, не работает, а я сделаю вот так, и оно, бляха, заработало, но не совсем так, как мне хотелось… И вот так целый день.

C’mon, do-something…

А потом приходят какие-то дементоры и говорят, что это мы отменяем, требования поменялись, тут будет фича вообще без требований, а тут мы еще не знаем, а вот это надо срочно переделать, а вот это не трогать. И теперь оно всё никак не заработает, потому что тут убрали, там добавили, и в целом вроде всё просто, но…

И вот так целый день.

А когда понял, как устроены элементы в html — можно смотреть и понимать, как их делают программисты. Что есть параметры. Что есть классы. Что оформление элемента вынесено в общие файлы, потому что так устроен CSS (Cascading Style Sheets), а идею, силу и особенности CSS надо объяснять отдельно. Потом надо объяснить, что ты можешь открывать исходный код любого сайта и смотреть, как он устроен, и понимать, как с этим всем можно работать.

Пришло время идентифицировать элементы в коде, и это можно делать разными способами… которые во фреймворке Playwright реализованы так и эдак, и к ним можно обращаться или так, или эдак…

Одновременно с изучением html есть возможность хотя бы поверхностно потрогать траву ладонями основные принципы тестирования ПО. Playwright нам нужен не сам по себе, а для выполнения тестирования ПО в браузере руками робота, условно говоря. А чтобы тестировать, надо не тыркать элементы в html по-отдельности, а надо продумывать (распознавать логикой) сценарии, по которым будущие пользователи будут пользоваться нашим приложением.

О, самое время рассказать о том, как наши html-страницы становятся частью приложения, которое работает на сервере… И в чем разница между сайтом и сервером.

Наверное, в том же 2017-м один из наших джунов, который уже год тестировал проект, спросил, а где именно находится наше приложение? Одни говорят, что оно на сайте, другие — что оно на сервере.

Ну, ок. Объяснил.

Playwright умеет автоматически запускать и контролировать сервер, на котором находится тестируемое приложение. И оно может быть на удаленном сервере, а может работать на локалхосте. Пришло время объяснить понятие localhost…

Если понял за 127.0.0.1 и 192.168…, то вернемся к Playwright. Это фреймворк, который позволяет через код программно управлять браузером. Его придумали программисты, и это не единственный фреймворк подобного рода. И чтобы им управлять, вместе с изучением html и тестирования надо посмотреть в основы JavaScript (стал основным языком работы с элементами в браузере) или Python (многие считают его норм для начинающих и таки почему бы и нет). Кажется, что для этого надо сперва научиться программировать, но это только кажется. Чтобы программировать, надо не код писать, а думать как программист. Можно научиться писать код и не научиться программированию.

Кажется нелогичным, но это логично.

Я знаю английский язык, но от этого я не стал англичанином.

Можно научиться играть на пианино и не быть музыкантом, для этого нужен природно-обострённый слух и надо освоить математическую грамоту музыкального мышления.

Вместе с основами html спокойно учим основы программирования на примере JS или Python. Само по себе это знание не сделает нас программистами. Да и вряд ли мы продвинемся дальше основ. Кто-то да, кто-то нет, заранее неизвестно, что и у кого будет получаться. Расчехляем простую рабоче-крестьянскую логику, смотрим на чужой код и разбираемся, как там все устроено. Сперва на простых примерах, затем на всё более сложных.

Вгрызаемся дальше. В командной работе надо будет пользоваться тем языком, которым уже пользуются другие однокомандники. Да, в одиночку можно писать скрипты для Playwright на JavaScript или на TypeSсript или на Python или на ассемблере. Но если в рабочей группе все пишут на Go — ты тоже должен писать скрипты на Go, это не обсуждается. Надо понимать основные принципы языков программирования, а не привязываться к синтаксису.

Далее оказывается, что для работы с общей кодовой базой надо разобраться в том, где она лежит, как её взять и как в неё добавлять свою работу — разбираемся с git (заодно глянем и на svn, не помешает понимать эту тему в принципе, а не в частностях). А для этого надо разобраться с тем, что такое файлы, где они лежат, как с ними работает твоя операционная система, а это вряд ли будет Windows. Давай объясню, как работает Linux…

А как работает обмен данными между серверами? Рассказать про API? Показать, что это само по себе, откуда взялось и как его трогать? Нет, я не буду ограничиваться только «я покажу тебе Postman» — надо понимать, что такое API вообще, а не отдельный софт, через который можно взаимодействовать с API.

И чего мы привязались к API? А реляционные базы данных кого уже давно ждут? Объяснить, почему они называются реляционными?

C’mon, just do something…

Я понимаю, что эта штука делает в принципе.

Я понимаю, как это устроено в принципе.

Я понимаю, как найти локатор на странице в принципе.

Я понимаю, как обезопаситься от того, что этот локатор в будущем может поменять свое местоположение или переименоваться или стать видимым только после выполнения какого-то действия на странице — в принципе.

И вот теперь мы берём Playwright и спокойно его используем, и всё будет работать. C’mon, это уже не так уж и сложно! Заморочено, конечно, и много всякого, но в основе своей не сложно. Просто это «длинное» знание, которое приходит медленно, после изучения, привыкания и понимания простых принципов. Это не то, что можно показать на экране и сказать «Вот эту кнопку нажимай, а эту не надо трогать».

А если я скажу вам сразу «Нет»? Ну, вам же легче будет?

Привет каждому, кто приходил ко мне с запросом «Научите меня тестировать…», а я в ответ говорил «Ок. Сделайте сайт, три страницы, давайте посмотрим, как получится и зайдёт ли оно вам…» — может быть, вы уже самостоятельно попытались и поняли, что само по себе тестирование не очень сложное занятие, но сперва надо освоить некоторые очень неочевидные основы. Надо будет лезть в настройки системы и отдельных программ, смело что-то перещелкивать и понимать, что после этого поменяется, и отвечать за результат. И в какой-то момент обязательно надо будет понять разницу между сайтом и сервером.

Тестирование само по себе — абстрактная тема, которую рукам не пощупать. Всё IT работает на абстракциях. Учиться IT — изучить абстрактные темы, для которых в быту нет и не может быть объяснений или примеров, их надо придумывать. Но можно научиться взаимодействовать с абстракциями, можно наполнять их смыслом, придавать им смыслы, перехватывать изменение смыслов… Можно понимать, что перед тобой условные переменные, и что данные в этих переменных бывают разных типов. Нужно тестировщику это знание или нет? Или оно подразумевается, потому что это база нашей профессии?!

Так что да, иногда надо сразу говорить «Нет», а не пытаться объяснить, что три тысячи лет назад один древнегрек возвращался домой с рынка (по-ихнему агора) и посмотрел на звёзды…

Our whole universe was in a hot dense state,
Then nearly fourteen billion years ago expansion started. Wait…

QA процессы — можно внедрить, конечно, но

• в разработке ПО гарантирование качества не гарантирует ни качества, ни отсутствия багов. Долго объяснять, но это так, ПО не делается, как клоны на фабрике, это каждый раз уникальный артефакт со множеством особенностей, из которых некоторые наследуемые, а некоторые неожиданно новые.
• тестирование стоит на фундаменте из требований, которые надо сперва наладить и запрягать перед каретой, а не после. Если мы деплоим 256 изменений за один раз по вторникам, то как именно трэкать эти самые требования? Где? Кем? Скорее всего, это ПО развивается не по требованиям, а по невнятным ожиданиям бизнеса. Нет требований — нет и гарантий соответствия им, потому что нечему соответствовать, тестирование живёт в режиме «сравнить наблюдаемое с ожидаемым». Нет ожиданий — не с чем сравнивать, остаётся только исследование в режиме «я не уверен, как оно должно работать…» А исследование ПО в QA этого ПО не конвертируется.

Любопытно, что всё то, что мы сегодня переживаем, уже было — в начале девяностых, когда понадобилось ускорить поставку ПО, потому что бизнес же тестирует гипотезы и идёт вслепую, а не по продуманному и однозначному пути. И пришёл agile, и все ускорились, и в двухтысячных годах XX века я не видел в разработке живых тест-аналитиков и тест-дизайнеров, к тому времени их уже всех свезли на остров Литтл-Сент-Джеймс (в составе Американских Виргинских островов), где американский финансист Джеффри Эпштейн & Co регулярно путали их с девицами красными.

И это случилось так быстро, что в двухтысячных уже всем казалось нормальным, что тестировщик сам придумывает тест-кейсы, сам их дизайнит и сам их выполняет. Ну, как дизайнит… он знает о том, что существует тест-дизайн, где надо какие-то таблицы придумывать, но на это всегда нет времени. Проще читать требования напрямую, на ходу придумывать проверки и сразу их выполнять. Придумывать тест-кейсы — где вы на это время найдёте?

А сегодня нам уже и требования негде взять, потому что ПО генерируется быстрее, чем кто-то соображает, зачем его нужно генерировать и что именно оно должно делать. И как именно… И какой бизнес будет стоять за нагенерированным ПО. Те же сайты не нужны сами по себе, они нужны бизнесу как витрина, как сборщик заказов…

А ещё в древности ПО поставляли на дисках, и обновлять его было крайне сложно, поэтому наши предки старались его как-то привести в готовое состояние ДО релиза. Но мы уже не они, мы перепрыгнули в парадигму «ПО работает на сервере, к которому мы постоянно имеем доступ, и если мы найдём ошибку — просто быстро её исправим», и это полностью true в отношении мелких ошибок. А если ошибка будет NOT мелкая, ну, откатим софт… наверное. Стоимость исправления ошибки упала, зачем вы требуете время на то, чтобы тестировать тщательно до релиза? Тестируйте после релиза, что вам мешает? Давайте сперва выпустим софт, чтобы продажи были, а потом вы будете его тестировать. Вот вам требования, не нойте.

А сегодня и требований «уже не стало, а скоро совсем не будет» © нашсеньор Паниковский. Мне уже предлагают воспринимать под видом требований абстрактные тексты, которые были сгенерированы по сгенерированному коду. Текст получается осмысленным на расстоянии одного предложения, а вместе эти предложения не склеиваются.

Всё, как мы любим — без воды, без резолюции, без нервотрёпки, без коагуляции десереализационного инкремента, без хтонических завихрений, без un pahar de tocănică gustoasă la a voastră masa măiastră.

Хочешь ещё?

Я понимаю коллегу, который тоже задолбан и был вынужден предложить хоть что-то под видом требований, он поднатужился и выдал — дякую, аж пiдскакую. А дальше со всей этой слезинкой ребёнка что делать?

В норме я могу, читая требования

• распознавать ситуации, которые наше ПО должно обработать,
• распознавать ситуации, которые наше ПО не должно обрабатывать,
• распознавать ситуации, которые наше ПО не должно обработать, но которые могут произойти
• распознавать ситуации, про которые наши разработчики требований и ПО по какой-то причине не подумали
• распознавать ожидания, которые подразумеваются, но не были явно объявлены — не все связи и требования очевидны, не обо всех детальках можно додуматься заранее

То есть, мой процесс состоит из нескольких фаз: осознание, обдумывание, согласование, выполнение. Всё это требует какого-то времени. Что можно машинизировать и ускорить?

Осознание

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

Можно их сгенерировать — вот вам и, кагбэ, ускорение. Но придётся разбираться в нагенерированном. То есть, произойдёт мощный спид ап на первой фазе, а затем…

Обдумывание

… всё равно мучительно медленный разбор — нужны часы.

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

А ещё тест-кейсы пишут или по требованиям, или по уже работающему приложению. Второй подход ублюдочен, но с него начинают все. Первый подход сложен, но он более разумен и эффективен. Anyway, и на то и на это нужны часы пропорционально количеству функциональностей ПО — чем их больше, тем больше времени нужно.

Согласование

Очень важный этап, который мы все дружно скипнем. Сколько раз уже скипали, неужели на этот раз что-то бомбанёт? Вроде не должно…

Выполнение

Вручную тестирование делается медленно — нужны часы.

Можно какие-то проверки делать через тот же Playwright, но не все же, и их так или иначе надо будет записать в виде кода. LLM тут может нас спидануть, но придётся или слепо доверять тому, что нагенерированно по объявлению, или настырно разбираться в каждом отдельно взятом кейсе. Нужны часы на подготовку тестов для автоматизации и, к сожалению, в будущем понадобится МНОГО часов на их постоянное переписывание, потому что автоматы будут устаревать и спотыкаться на ровном месте — просто потому, что так они устроены.

И надо, чтобы этим занимались отдельные пацаны, и для успеха им нужны уже кем-то продуманные тест-кейсы, чтобы не переключаться между разными уровнями абстракции. Впрочем…

А если после всего этого ВНЕЗАПНО выясняется, что требования уже где-то как-то непредсказуемо поменялись, то надо всю эту аналитическую работу выполнять заново. Это реалистично? В погоне «успеть вовремя» её будут выполнять частично, а значит, никаких гарантий не будет, ПО поедет в релиз от станции Тревожность до станции Бадабумц, потому что тестировщики опять пропустили какую-то досадную (местами лютую) мелочь.

Может быть, пришло время как раньше, порезать в ролях и принудить тестировщиков выполнять работу, которую раньше делали отдельные юниты? Да, тест-дизайн стал хуже, но остался же? Можно, например, заставить тестировщика самому придумывать требования — они ему нужнее всех. И да, это будут очень плохие требования, но они же будут, хоть какие-то?!

Всё, как мы любим — без воды, в пустыне, под палящим солнцем…

Ок. Мы превратим тестировщиков в бизнес-аналитиков «с сильным навыком тестирования». И пусть эти аналитики сами гоняют LLM и сами «генерируют соответствующие артефакты», которые только им самим и нужны. Пусть Джек идёт строить дом, и пусть всё заверте…

Вот LLM, которая генерирует код проекта.

Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту.

Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются юнит-тесты для проверки проекта. Лей в прод.

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

Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, чтобы не возиться с ручным тестированием. Лей в прод.

Тут пропустим ещё один большой бэмц, после которого всех сразу допрашивают (и не только через сфинктер; что вы так сосредоточились на этом сфинктере, вы больные, что ли?!), а как так получилось, что и юнит-тесты работают, и Playwright работает, а ПО — с багами. Почему вам не хватило времени мозгов проверить руками хотя бы основные happy path? Почему этих happy path так много, товарищи? Давайте заново.

Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, и тест-кейсы для ручного тестирования. Сжимай свой сосредоточенный сфинктер, раз уж ты ни на чем другом уже не можешь сосредоточиться, и лей в прод.

А что лить-то? Мы сразу втыкаемся в то, что ручное тестирование проекта требует времени два раза — и для подготовки (когда анализируют требования и придумывают тест-кейсы), и для выполнения. И это всё никак не ускоряется. Быстро льётся, если без тестирования. А вы же хотели тестирования? Хм…

И время идёт, пока мы читали эти ужоснах тест-кейсы для ручного тестировани, та клята LLM уже перегенерировала заново код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, и новые тест-кейсы для ручного тестирования… и по цепочке всё обновила. Кхм, как говорится, блеать!…

Если генерирование ПО каждый раз создаёт ПО заново, с непредсказуемыми характеристиками и возможностями, которые надо перетестировывать заново, с нуля, с тем же уровнем недоверия, то в этой схеме не может произойти общее ускорение. В этой схеме есть моменты для локального ускорения, но в целом — нет. Это как таскать воду из колодца домой, и местами на этом пути находить сантиметрики, которые можно срезать, и весь путь туда-обратно как будто-бы сокращается и оптимизируется, да, но в целом как был километр, так и остался, и нужно принципиально другое решение, в котором вода в доме будет постоянно появляться, а таскать воду из колодца уже не придётся.

Почему мы вообще занимаемся этим трудом Сизифа, к которому аргонавты каждый день прилетают и клюют печень да «трахаютЪ мозгЪ», уж простите, не знаю как это произносится по-древнегречески!?

Если делать ПО, которое будет взаимодействовать только с другими ПО, то постоянное тестирование будет ненужным, оно перейдёт в режим одноразовой задачи, вы можете видеть положительный эффект этой условности в разделе API. А если делать ПО, которым будут пользоваться люди (местами бесконечно глупые, местами дъявольски умные), то и проверять его надо людьми, причём постоянно. Как это всё ускорить?

Да как всегда — начинаем презирать правила проезда перекрестков, уголовный кодекс и всякие ограничения здравого смысла. Надо делать всё быстро, а чинить только то, на что будут жаловаться (за что будут наказывать) — вот и вся философия, Спиноза.

Может быть, стоит убрать из этой схемы вообще всех, даром, и пусть LLM сами генерируют код и тесты, и впихивают это всё в CI/CD, и выполняют на проде, и пусть другие LLM этим всем пользуются и всё это покупают. Проекты же делают для прибыли, right? Pedal to the metal.

Hop, hop, hop, hop, hop, hop, hoba!