Касательно командной разработки с интенсивным применением LLM — ну да, растёт скорость внедрения изменений. За всем уследить не получается, и мы натыкаемся на нелепые баги, которые можно было бы обнаружить за секунды, ещё до релиза деплоя. Наверное, уследили бы, если бы изменение было планомерным, предсказуемым и затрагивало только одно секундное дело. А оно затрагивает много место сразу, в которые никто не заходил и ломаться было нечему… Если бы всё всегда ломалось предсказуемо, то уж мы бы…
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!