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!

Удалил FB с телефона. Ну, такоэ, он же через браузер доступен…

В Firefox на страницах FB через адблок спрятал все кнопки типа «лайк». Вместо тыцанья лайков можно писать комментарии. Вскоре понял, что и комментарии особо не нужны, и всё стало восприниматься более отстраненно — прочитал и прочитал, нет нужды на всё реагировать.

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

Стал делать записи на FB в «заметках», местами даже ценные (техника проезда серпантинов на машине, например), просто потому, что там сохранялась хронология записей. Сегодня все те «заметки» с FB исчезли — от спасибо, мрази…

Самой жуткой особенностью FB всегда была абсолютная невозможность смотреть записи в хронологическом порядке, даже в своём аккаунте. Хайнлайн про это всё целый рассказ написал «Они» (They, 1939) — человек находится в дурке, и он уверен в том, что мир неправильный, что им управляют какие-то «кукловоды», а его уверяют в обратном. Но однажды шел сильный дождь, и человек (непонятно почему) отодвинул штору на окне, выходящем на тыльную сторону дома:

Очень сильный дождь шел на фасадной стороне, а здесь, с этого окна, погода была прекрасной, солнечной и никакого дождя…

И он пытался это всё объяснить Элис, своей жене, а она его уверяла в том, что ему просто показалось… А потом:

Существо, которое он знал под именем Элис, не меняя своего облика вошло в комнату, где все они собрались.

[…]

— …И наша программа потерпела поражение из-за того, что Вы не обеспечили тогда дождь не только с фасада, но и с тыльной стороны его дома. Впредь работайте более тщательно над выбором средств.

Порядок в рассуждениях приходит от последовательности. Если последовательность убрать, рассуждение начнёт перескакивать с десятое на триста восемьдесят седьмое (почему бы и нет?) и обратно на — на что? На десятое? Нет, ведь в этом окружении нет последовательности. Вместо «десятого» посмотри на «семь тысяч двадцать шестое». Why, кагбэ, not? Нелогично, но логично — просто неочевидно.

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

Стал ходить в спортзал смотреть многочасовые записи аварий на Youtube. Отказаться от отвлечения невозможно, но просмотр этого контента хотя бы было полезным — чем больше аварий ты «видел», тем больше шансов их распознать задолго до происшествия (большинство происходят из-за неверных предположений, потому откровенная глупость, и только после чисто технические причины).

К чему это я всё… Понятно, что невозможно просто перестать отвлекаться на что-то. Не будет FB и Youtube — будешь упорно считать муравьёв в муравейнике. Сегодня я на Facebook я вообще перестал ходить, и видео с авариями смотрю редко, но накатило неприятное ощущение о том, что я всё равно много зависаю в бездне бессмысленного в других источниках. Как-то сразу пришло и решение о том, что надо перестать реагировать, надо замедлиться:

• Нигде и никак не трогать кнопку like. Их даже прятать не пришлось, они как-то очень просто игнорируются, вероятно, помог когдатошний опыт насильного скрытия лайков в браузере. А никто и не заметит, что я ничего не лайкаю, быгыг, так что…
• Твиттер — включил режим «Защитить посты», в нём все записи видны только уже существующим читателям. Комментировать под другими записями можно, но это увидит почти никто, исчезает социальное взаимодействие.
• Threads — то же замое. Подзамочность ограничивает и мою возможность комментировать некоторые чужие постс, и это очень хорошо…
• Сигналы о получении новых сообщений — подавить повсюду. Хорошо бы и дверной звонок отключить. На днях прекратил контракт про стационарный телефон, и ничего не поменялось.
• В браузере есть расширение Enhancer for YouTube — убирает шортсы, убирает все «видео по данной теме», может убрать и комментарии. На экране осталось одно только видео, которое можно посмотреть и закрыть, ничего более. Когда в листе «Смотреть позже» собралось больше полутора тысяч видео — надо удалять, не может быть всё сразу важным и стоящим внимания. А я же ещё не разобрал каталог «Загрузки», там за много лет собралось 76 000 файлов, и не все они нужны, но какие-то важны, а какие-то просто дубли, и это всё тоже надо как-то (когда-то) рассортировать…
• При просмотре чего-то — не запоминать и не делать вид, что всё понятно, а делать записи в бумажном блокноте, с ручкой в руке. Это помогает замедлиться сосредоточиться, потому что записываешь только самое важное, и пересказываешь. И смысл этого не в том, чтобы записать услышанное, а чтобы после услышанного записать своё рассуждение, а его же надо хоть как-то обдумать. Много видео таким образом не посмотришь, и это помогает замедлиться. А ещё процесс заполнения ручки дорогими чернилами медитативен, последователен, всепоглощающ, однозначен.
• Выключать компьютеры, когда от них отходишь. Дело даже не в расходе электроэнергии, дело в принудительной смене фокуса. Надо ещё привыкнуть сразу гитары в кофры закатывать, а не перекладывать туда-сюда по комнате…
• Смотреть старые черно-белые фильмы, в которых последовательно рассказывают какую-то историю, с прологом, монологом и эпилогом.
• Ходить. Два кэмэ в одну сторону, и столько же обратно — без наушников, без аудиокниг, без цели.
• И важно to embrace the boredom. Мышление в порядок можно привести только насильно и лучше делать это принудительно, но самостоятельно.

«И я бы сказал, что куда бы вы ни пошли, вам стоит знать Postman…» © оригинал

Нет.

Не стоит «обязательно знать Postman» и вообще не надо к нему привязываться. Postman — всего лишь одна из лопат, которой надо копать.

Обязательно надо понять, что такое API само по себе, как/почему оно работает. А каким именно инструментом его можно удобнее и проще использовать — это уже второй этаж.

У нас в конторе на днях произошёл резкий и однозначный переход на Bruno, потому что подписка на корпоративное окружение в Postman уже начало стоить каких-то заметных денег. Если бы мы все были жёстко присевшими на Postman, держали бы там разветвлённую сеть из запросов и покрыли бы их всех тестами на внутреннем фреймворке Postman, и массово запускали бы всё это при каждом релизе, то отказ от Postman был бы «ОЙ БЛЭТ!». А так — ну, не стало Postman, а файлы с коллекцией запросов остались, и дальше делаем то же самое, просто уже в Bruno.

Через какое-то время рынок снова поменяется, и у тех, кто только начинает, начнутся страдания о том, что же учить — или Postman, или Bruno, tertium non datur. И только на пенсии им станет очевидно, что учить надо вообще третье — принципы технологий обмена данными.

Относительно этого отдельно взятого видео (с отдельно взятым мнением его автора о том, что для джунов глобально важно, а что нет) — оно уже есть, обсуждать его незачем. Ну, видео и видео, сделал и молодец.

Вопрос к тем, кто тоже хочет делать подобные видео — может быть, не надо являть себя народу в режиме «я знаю, как надо правильно»?

Может быть, не надо потакать аудитории?

Может быть, надо спрашивать и предлагать порассуждать?

Postman или что угодно другое — это инструмент, который надо или не надо использовать исходя из контекста. Мы же хз, куда попадают айтишники — некоторые сразу в рай, некоторые — на проекты, где этот ваш API вообще никому никуда не сдался, где надо всего лишь целыми днями пихать в консоль sql-запросы и думать о том, куда же тут, бляха, развиваться?! А потом случится то, что и этот ваш Postman, и этот ваш Bruno станут никому не нужным археологическим шлаком, и…

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

Придумал простой способ добавить себе напоминалки о чём-то, что нужно сделать, глядя в консоль — прямо в консоль.

Он, как корова, может

• сожрать все ваши pdf, ppt и всякие видео с ютуба,
• пережевать их и переварить,
• выдать обратно сжатый набор информации о том, что внутри.

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

Вкратце такие дела

При закидывании материалов в эту инфо-мясорубку можно получить

1. или study note
2. или summary (revision) note

Итоговые тексты будут слегка отличаться.

Это Study Notes

Это Revision Notes

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

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

Зато быстро.

Очень быстро.

Настолько быстро, что если бы стародавние времена уже был такой сервис, то сей докладчик мог бы сэкономить всем нам время своей говорильней — мог бы просто распечатать Study Notes, прочитать их вслух за семь минут, и доклад окончен!

Вероятно, все конференции будущего будут проходить в таком ускоренном режиме.

Могут спросить, а зачем понадобился отдельный сервис для всего такого, если у нас есть доступ в исходный chat.openai.com, где есть все те же функциональные возможности… Я бы не стал про это спрашивать. Я предложил распарсить это же видео из 2017-го, и в чате включился саммари-галлюциноген:

The video you’re referring to offers an analysis of the current military situation in Ukraine, focusing on the developments in early September 2024. It details the collapse of the Vuhledar direction and the fall of Novohrodivka…

Ок, пусть для учёбы будет отдельный сервис. Походу, там под капотом много всякого сделано.

Также проверил сборку summary из видео, которое используется для настройки аудиооборудования. Там в начале произносят „Warning, this video contains flashes and moving images”, а потом выводят звук то в левом канале, то в правом.

Робот, конечно, постарался извлечь из этого хоть что-то…

Summary / Highlights

• Video Warning: The video contains flashes of moving images.
• Subscription Reminder: Viewers are encouraged to subscribe to the Master Study channel. (это название канала, на котором видео)

Key Points

• Content Warning: Important for viewers sensitive to flashing images.
• Engagement: Encourages audience interaction through subscriptions, enhancing community building.

Additional Notes

• The video may include educational content related to study techniques or productivity tips, but specific details are not provided in the excerpts.

Revision Questions

• What precautions should viewers take when watching videos with flashing images?
• Why is subscribing to educational channels beneficial for students?

Ну да, ну да — без контекста это всё не имеет никакого смысла.

А вот по-настоящему сложные тексты эту машинерию доста файно подламывают, быгыг…

Не сведет с ума ИИ закарпатский лэнгуаге

Полноценный японский «танка» на UML

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

Рисовать их можно и на обоях, и в не очень удобном LibreOffice Draw, в MS Visio (не щупал уже сто лет), и в опенсорсном Modelio, и в браузерном draw.io. Там надо тыкать курсором по иконкам и стрелочкам, перетаскивать их по экрану и соединять в логичном порядке, после чего сохранить в виде картинки, которую надо вставить в свою документацию. И хорошо, если это надо сделать только один раз и картинка маленькая. Как правило, что-то надо поменять, или полотно диаграммы становится очень большим, на несколько экранов во все стороны — и там всегда надо что-то менять. Снова надо сгенерировать картинку, снова надо её прикрепить к странице и вставить в нужное место.

Есть другое решение — диаграммы можно не рисовать, а прямо в режиме редактирования документа в Notion (или в Confluence, или в IDE умного разработчика) в plain text с разметкой Markdown расписывать узлы диаграммы и связи между ними, а обновленная диаграмма автоматически перерисовывается. LaTeX way!

Проект называется Mermaid (русалка), работает на JavaScript, подключается как плагин в Confluence или Notion, в средах разработки, и даже в Jupyter notebook. Потыкать в свободном режиме — https://mermaid.live

Диаграмм в Mermaid множество: Class Diagram, Entity Relationship Diagram, User Journey, Gantt, Pie Chart, Quadrant Chart, Requirement Diagram, Gitgraph (Git) Diagram, C4 Diagram, Mindmaps, Timeline, Zenuml, Sankey, XYChart, Block Diagram. Cамые ходовые три:

1. Блок-схема (Flowcharts)
2. Диаграмма состояний (State diagram)
3. Диаграмма последовательности (Sequence diagram)

Mermaid в Notion

В Notion (не наш выбор, но и там есть жизнь) блок с мермайдом вызывается командой, которую можно даже не дописывать:

Получаем поле с представлением «Split» — сверху код, а внизу результат его правильной работы:

Когда дело сделано, разумно переключить отображение содержимого блока на «Preview», чтобы не пугать прожект-манагера непонятными буковками.

Блок-схема

Она же Flowchart. Документация по ней подробна и адекватна.

Блок-схема состоит из узлов (геометрических фигур) и ребер (стрелок/линий), и объявляется непременно с направлением развёртывания — сверху вниз (TD) или слева направо (LR):

Пример:

flowchart TD
S(Простая последовательность шагов)
--> id1(Самурай всё понимает)
--> E(Разговор исчерпан)

S — Start.

E — End.

Между ними можно расположить сколько угодно узлов. Называть их можно буквами любого алфавита, который есть в кодировке UTF-8, от «id1, id2, id3» до «самурайУмничает».

Сплошные управляющие стрелки (рёбра) указываются так:

-->

Стрелка с прерывистой линией:

-.->

Стрелку можно ставить перед узлом, а можно после. Мне удобнее воспринимать их в начале строки.

Стрелками можно связывать не только на каждый следующий узел, но и непоследовательно прыгать к любым другим узлам. Например, можно связать id3 с id1:

flowchart TD 
  S(Простая последовательность шагов) 
  --> id1(Самурай всё понимает) 
  --> id2(Невод закинут в море) 
  -.-> id3(Дед, ну ты дурак? ©) 
  --> id1 
  --> E(Разговор исчерпан)

Ещё есть комментарии — через «два символа процента»:

%%{init: {"flowchart": {"htmlLabels": true}} }%%

Форматирование узлов на блок-схеме

Их форма задаётся скобками.

flowchart TD 

S[\Простая последовательность шагов/]
 --> id1{Самурай всё понимает}
 --> id2[Невод закинут в море]
 -.-> id3(Дед, ну ты дурак? ©) 
-.-> id2 
--> E[/Разговор исчерпан\]

Комментарии на стрелках

flowchart TD 

S[\Простая последовательность шагов/] 
--> id1(Самурай всё понимает)
-.-> |размахнувшись| id2(Невод закинут в море)
--> E[/Разговор исчерпан\]

Пометить узлы разными цветами

Для этого надо объявить классы сущностей через ’classDef’, а там чистый CSS, поэтому названия или коды цветов надо взять из htmlcolorcodes.com

flowchart TD

classDef decisionPoint color:black,stroke:DarkOrange,fill:Snow,stroke-width:1px,text-align:left;
classDef startPoint color:black,stroke:White,fill:#93e4e6,stroke-width:1px,text-align:left;
classDef endPoint color:gold,stroke:White,fill:black,stroke-width:1px,text-align:left;

S[\Простая последовательность шагов/]:::startPoint
--> id1(Самурай всё понимает)
--> id2[Невод закинут в море]:::decisionPoint
-.-> id3(Дед, ну ты дурак? ©)
--> id2
--> E[/Разговор исчерпан\]:::endPoint

Затем применить классы к узлам через три двоеточия.

Не надо излишне увлекаться раскрасками. Стартовый и эндовый узлы лучше пометить не цветом, а формой узла через наклоны обрамляющих слэшей:

[\ старт /] и [/ финиш \]

Цвета, если действительно надо применять, следует подобрать неяркие. Учесть, что кто-то будет смотреть это всё в darkMode.

Поменять размер шрифта одного из узлов

Через управляющие команды CSS:

classDef decisionPoint font-size:0.9em,color:black,stroke:DarkOrange,fill:Snow,stroke-width:1px,text-align:left;

Вписать в один узел несколько строк

Просто переносим буквы/слова внутри узла на новую строку. В моем примере каждая новая (перенесенная) строка начинается с булита — это необязательно, просто выглядит как список на слайде. Кавычки вроде нужны, а на деле не обязательны.

flowchart TD 

classDef leftAlign font-size:0.9em,color:black,stroke:DarkOrange,fill:Snow,stroke-width:1px,text-align:left; 

S[\Простая последовательность шагов/]
 --> id1(Самурай всё понимает)
 --> listOfEvents("•  Некуда спешить
• Не о чём думать
• Начинается дождь"):::leftAlign
 --> id2[Невод закинут в море]
E[/Разговор исчерпан\]

Тут под произвольным именем ’newLines’ было задано соединение нескольких узлов в один общий узел. А это значит, что можно заранее соединять узлы в отдельные ветки… тааакое можно наворотить!

Разместить на одной диаграмме несколько самостоятельных ветвей

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

flowchart TD

classDef leftAlign font-size:0.9em,color:black,stroke:DarkOrange,fill:Snow,stroke-width:1px,text-align:left;

biblioteka["Понял в тишине библиотеки"]
apple["Яблоки на снегу"]
gameOver["Демоны спёрли дыхание"]
bookIsClosed["Книга недолго открыта"]
listOfEvents("• Некуда спешить
• Не о чём думать
• Начинается дождь"):::leftAlign

apple 
--> biblioteka 
--> listOfEvents

S[\Происходит жизнь/]
--> id1(Самурай всё понимает)
--> id2[Невод закинут в море]
--> listOfEvents
--> E[/Разговор исчерпан\]

id1
--> gameOver
--> bookIsClosed

Вполне можно свести узел «Книга недолго открыта» к финишу, прописав последней командой „—> E”, но это необязательно, некоторые процессы вполне самостоятельно могут закончиться «ничем».

Диаграмма последовательности

Она же Sequence diagram.

Это предпочитают программисты — удобно показать, как процессы взаимодействуют друг с другом и в каком порядке.

sequenceDiagram

Jules->>+Brett: What does Marsellus Wallace look like?
Brett-->>+Jules: …What?
Jules->>+Brett: ENGLISH, MOTHERFUCKER! DO YOU SPEAK IT!?
Brett-->>+Jules: Yes!!
Jules->>+Brett: DESCRIBE WHAT MARSELLUS WALLACE “LOOKS” LIKE!
Brett-->>+Jules: Wha-what I—?
Jules->>+Brett: SAY "WHAT" AGAIN! I DOUBLE-DARE YOU, MOTHERFUCKER!! SAY "WHAT" ONE MORE GODDAMN TIME!
Brett-->>+Jules: H-H-He's black...
Jules->>+Brett: Go on!
Brett-->>+Jules: ...He's bald...!
Jules->>+Brett: Does he look like a bitch?!
Brett-->>+Jules: What? 
Note over Jules,Brett: shoots Brett in the shoulder
Jules->>+Brett: DOES! HE! LOOK! LIKE! A BITCH?!?!
Brett-->>+Jules: NO!
Jules->>+Brett: Then why'd you try to fuck him like a bitch, Brett?
Brett-->>+Jules: I didn't...!
Jules->>+Brett: Yes, you did! YES, you DID, Brett! You tried to fuck him!

Pulp Fiction in action

Акторов может быть множество, переходы между ними тоже доступны в разных сочетаниях.

Разумно рисовать от одного актора только сплошные стрелки, а от другого только прерывистые.

Неразумно рисовать в таком стиле длинные диаграммы.

Также программисты используют рисование диаграмм через LiveScript с аналогичными возможностями:

sequenceDiagram
  actor Customer
  participant Checkout
  participant DB

  Customer->>+Checkout: Request checkout page
  Checkout->>+DB: /api/settings

и так далее по той же схеме.

Диаграмма состояний

Она же State diagram — диаграмма, которая описывает поведение систем. Ты видел её в книге Коупленда про тест-дизайн.

Всё чётко, да?

Эта диаграмма — учебная, кривая, неправильная:

Note that the diagram is still incomplete. No arrows and bulls-eyes emerge from the Cancelled states. Perhaps we could reinstate a reservation from the Cancelled NonPay state. We could continue expanding the diagram to include seat selection, flight cancellation, and other significant events affecting the reservation but this is sufficient to illustrate the technique.

© Lee Copeland

А она неправильная. Просто для экономии бумаги три перехода сведены к одному и тому же (Cancelled ByCust), а в норме это надо выводить в отдельные (тупиковые) ветви. Иногда даже из тупичка может произойти обратное действие, и если через всё пространство протягивать стрелки в одно и то же место, то через какое-то время диаграмма покрывается паутиной метаний от одного узла к другому… ох.

Её надо пересоставить в более адекватном порядке, но для разгона попробуем воссоздать как есть, сведём выход из нескольких узлов в один Cancelled ByCust:

stateDiagram-v2

[*] --> Made : giveInfo/startPayTimer
Made --> Cancelled_NonPay : PayTimer_expired
Made --> CancelledByCust : cancel
Made --> Paid : payMoney 
Paid --> CancelledByCust : cancel/Refund
Ticketed --> CancelledByCust : cancel/ReturnTicket/Refund
Paid --> Ticketed : print/Ticket
Ticketed --> Used : giveTicket
Used --> [*]

Важно: названия узлов должны быть представлены одним словом. Пробел между ними принудительно создает новый узел. Решение — отдельно создать переменную узел с условным названием и содержимым в виде слов с пробелом. Например:

stateDiagram-v2

CancelledByCust: Cancelled by Customer
Cancelled_NonPay: Cancelled when payTimer expired

[*] --> Made : giveInfo/startPayTimer 
Made --> Cancelled_NonPay : PayTimer_expired 
Made --> CancelledByCust : cancel 
Made --> Paid : payMoney 
Paid --> CancelledByCust : cancel/Refund 
Ticketed --> CancelledByCust : cancel/ReturnTicket/Refund 
Paid --> Ticketed : print/Ticket 
Ticketed --> Used : giveTicket Used --> [*]

Раз уж название каждого узла — это его уникальный идентификатор, придется все эти ответвления в «CancelledByCustomer» сделать уникальными через нумерацию. Заодно пометим цветом happyPath и отхождения от него:

stateDiagram-v2

classDef happyPath font-size:1em,color:black,stroke:DarkOrange,fill:palegreen,stroke-width:1px,text-align:left;
classDef negativeScenario font-size:1em,color:black,stroke:DarkOrange,fill:IndianRed,stroke-width:1px,text-align:left;

[*] --> Made:::happyPath : giveInfo/startPayTimer
Made --> Cancelled_NonPay:::negativeScenario : PayTimer_expired
Made --> CancelledByCustomer_1:::negativeScenario : cancel
Made --> Paid:::happyPath : payMoney 
Paid --> CancelledByCustomer_2:::negativeScenario : cancel/Refund
Ticketed --> CancelledByCustomer_3:::negativeScenario : cancel/ReturnTicket/Refund
Paid --> Ticketed:::happyPath : print/Ticket
Ticketed --> Used:::happyPath : giveTicket
Used --> [*]

Можно задать направление этой диаграммы по-горизонтали, но это воспринимается неудобно:

direction LR

Намутить тест-кейсы по этим путепроводам

Дёрнем chatGPT с задачей перемножить все эти блямбы между собой.

Для stateDiagram псевдоинтеллект выдал такое:

1. TC1: Complete Payment and Print Ticket
   • Initial State: [*]
   • Action: giveInfo/startPayTimer
   • Result: Made
   • Action: payMoney
   • Result: Paid
   • Action: print/Ticket
   • Result: Ticketed
   • Action: giveTicket
   • Result: Used
   • Final State: [*]
2. TC2: Complete Payment and Use Ticket
   • Initial State: [*]
   • Action: giveInfo/startPayTimer
   • Result: Made
   • Action: payMoney
   • Result: Paid
   • Action: print/Ticket
   • Result: Ticketed
   • Action: giveTicket
   • Result: Used
   • Final State: [*]

И так далее.

Уберем детали:

Happy Path Test Cases

1. TC1: Complete Payment and Print Ticket
2. TC2: Complete Payment and Use Ticket

Negative Scenario Test Cases

1. TC3: Payment Timer Expired
2. TC4: Cancelled by Customer Before Payment
3. TC5: Cancelled by Customer After Payment
4. TC6: Cancelled by Customer After Ticket Printed

Кхм… Позитивные тесты — отдельно напечатать билет и отдельно его использовать — ну-ну. Тебе же говорили, что диаграмма неадекватная и требует пересмотра?

А отклонения от happyPath ПИ считало норм.

Хорошо бы ещё навостриться прописывать основу для диаграмм, из которой chatGPT мог бы генерировать код для самих диаграмм, и тогда можно ускориться ещё сильнее.

Туториалы по Mermaid

Их таки есть, вот два самых наглядных:

и

Файл с примерами из второго видео — mermaid.md

ZIM

Любопытно, что в вики-редакторе Zim тоже есть модуль «Вставка диаграмм» (ему нужен GraphViz), который работает по тому же принципу — пишем словами, видим диаграмму. Редактирование диаграммы включается даблкликом по ней.

Вольное последумие

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

© Джеральд Вайнберг, книга «Exploring Requirements — quality before design» (1989), подглава «1.4 Making Sure That Everyone Can Read the Map»:

Proponents of each notation claim that their maps are “intuitive” and ”easy to read”. These statements are true in the same sense that Chinese is intuitive — in Beijing. Virtually any notational system becomes intuitive after someone has spent a lot of time working with it.

Как только диаграмма объяснила одну идею, её надо немедленно оставить в покое и не усложнять — рисуй новые.

Генеративные сервисы надо держать под пристальным, недоверчивым присмотром, бо оно тебе нагенерирует, лишь бы ты был хоть немного счастлив. Если в череде шагов не будет чего-то очевидного, то GPT ничем не поможет, оно будет работать только с тем, что ему передал нерадивый тестировщик.

Но есть беда. Чтобы тесты генерировать, нужна основа — требования. Без набора требований бедняге ПИ в qase.io не от чего отталкиваться. Мдэ.

Если кто не знает, в qase.io подразумевается, что требования надо создавать и хранить в самом qase.io, там для этого есть отдельный раздел. И если им пользуются аналитики и их ручные тестировщики, то, вероятно, всё норм — требования живут вместе с тестами, видно их покрытие, видно, что откуда начинается и чем заканчивается, и сколько всего надо переписывать, если затеяли обновляться. Но если в проекте нет аналитиков? Требования же надо не просто записать, а ещё постоянно обновлять, добавлять, редактировать, комментировать. И когда весь движняк разработки полностью находится в Jira/Слак, то кто будет вообще возиться с требованиями на отдельном ресурсе? Всегда проще требования (если есть) запихнуть, кагбэ, в Jira…

Вообще, у qase.io есть интеграция в Jira, но с ней, кхм, сложно, постоянно чувствуется, что это два отдельных ресурса. Чем-то это всё напоминает древний Zephyr на дьявольском flash — есть взаимное линкование между тестами отсюда с задачами в Jira, но и только, в глаза это всё не бросается. Решение у древнего Zephyr в конце-концов нашлось естественное адекватное — древний Zephyr был взят и убит, вместо него появился плагин, встроенный в Jira, который и наследует у Jira интерфейс, и сущности типа тест-кейсы подтягивает под рабочую задачу (как и полагается), где они явно заметны… testomat.io тоже по этому пути пошел, Xray пошел… Кто вообще отныне пойдёт НЕ через встроенную интеграцию с Jira? Только смелый qase.io, что гордо реет между молний над ревущим гневно морем и кричит в рожок победы: «Генерируйте тест-кейсы, тестировщиков — поменьше, вам же лучше будет сразу!»

Вряд ли в qase.io что-то поменяется, проект живет уже давно и не с одной только Jira его надо соединять, и сделать это бесшовно сразу со всеми — нереально, и когда-то это был осознанный выбор архитектуры. Ну ок.

А вот что в глаза бросилось — предупреждение о том, что

using Qase’s AI Test Case Generator will not result in your data being used to train the language model. This Beta version uses the ChatGPT API Platform for test case generation. OpenAI explicitly states that «We do not train on your business data».

Да, да, разумеется, да! ChatGPT именно так и работает — всё читает, всё генерирует и сразу всё забывает, он же учится с вами взаимодействовать НЕ на взаимодействии с вами! Быгыгы.

С другой стороны, а какие есть варианты? В тест-кейсах всегда есть sensitive data, и если ты уже выбрал сторонний сервис для управления ими, то нехай уже это всё читает ChatGPT, крестик уже снят. Вот только ему нужны требования…

Им следовало бы сперва придумать бредогенератор требований к проекту… Господи ты боже твой, до чего же смелая и дурная мысль! 🙂

Кто-то шпарит чётко-последовательно, каждый шаг — отдельная задача, которую надо выполнить, в Expected result или однозначный результат, или цепочка результатов.

Кто-то в первом же шаге собирает свободный собирательный образ Онегина в письме Татьяны турецкому султану в режиме «Найди и открой такой продукт от определенного продавца, в котором есть только один языковой вариант, а потом выгрузи и загрузи таблицу грейдов по товарам, в которой будет находиться уже найденный продукт. И тут же проверь его наличие через галочку проверки наличия товара в таблице грейдов». Expected result — Всё работает нормально.

Кто-то упоролся по базе данных, и после каждого действия на фронте требует перепроверить результаты в БД, при этом не приводя какой-то минимальный пример sql-запроса. Он постоянно в БД, ему все очевидно.

Кто-то маниакально добавляет в тесты уточнения о том, почему тут надо сделать так, в Expected result иногда ничего не пишет (результат очевиден же!), а иногда выдаёт нумерованный список того, что изменилось после сделанного шага, и вообще старается всё выполнить минимальным количеством шагов.

Это я.

Кто-то вместо выполнения задач рассказывает, где что находится на странице в браузере, которую он видит (точнее, видел в тот момент, когда на проекте ещё крутился старый дизайн). Откроется модальное окно — закрыть его через кнопку (Х), снова открыть, закрыть его через кнопку Esc на клавиатуре, снова открыть модальное окно, повторить всё то же самое на мобиле, повторить всё то же самое на всех языковых версиях проекта, повторить всё то же самое во всех браузерах. Expected result — ОК. Переходим к тереблению следующего модального окна на пути товара в корзину…

Тест-кейсы — тот же код с метрикой «WTF хотел сказать автор? Why? Why? Ah, that’s why…»

В принципе можно «увидеть» в космосе и тот свет, который был испущен условные 13,8 миллиарда лет назад после Большого взрыва — реликт горячего периода появления сегодняшнего мира. Этот «свет от начала времён» так и называется: реликтовое излучение.

Реликт: организм, вещь или явление, сохранившиеся как пережиток от древних эпох, от лат. relictus — оставленный.

Как появились тестировщики начала девяностых? Не было самой профессии, не было курсов, зарплаты были никакие. Они что, просто… зародились? Может быть, те, кто несколько эпох назад начали заниматься тестированием, что-то такое знали и сделали ставку на правильную лошадку?

А что такого секретного знали про будущее те, кто в начале двухтысячных начали интенсивно работать с Java? Как они поняли, что на Java будет постоянный спрос, обеспеченное будущее, постоянное повышение зарплат?

Какие неизвестные предсказания о будущем были у тех, кто вгрызался в когда-то смешной и всех раздражающий JavaScript, без которого сегодня уже как-то смешно воспринимать веб?

А ничего они не знали. Технологии появляются и исчезают, ничего не предсказуемо и не определено (привет опытным разработчикам на Pascal, Delphi, Fortran). И так бывает, что какие-то маргинальные штуки из прошлого становятся сегодня ценными, и их адепты взлетают в спросе. Начинает казаться, что они что-то знали…

Всегда хочется угадать, чем надо заниматься сегодня, чтобы в будущем иметь ценность. Но в этой угадайке мы ориентируемся на то, что имеет ценность сегодня, а сегодняшняя ценность — это всего лишь реликтовое излучение из прошлого.

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

И вообще не факт, что сегодня надо упарываться по %любой_язык%. Даже если условно сегодня за ним настоящее, вообще не факт, что за ним будущее, просто потому, что в будущем может появиться другая инфраструктура, внутри которой будет эффективнее работать что-то другое. Упарываться надо по пониманию как программировать вообще, а не на определенном языке.

Надо уметь ездить на велосипеде вообще, а не только на определенной модели.

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

Смартфоны наши тому примером.

На короткой дистанции выигрывают те, кто игнорирует «как и почему» в пользу «здесь и сейчас».

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

Всегда хочется быть среди вторых, но бегать приходится среди первых, где перспектив нет, где технологиями только пользуются, не понимая, как они устроены. Привет профессиональным «Ну, мы использовали какой-то набор команд SQL и вызовов API, а другие команды я не знаю, у нас на проекте они были ненужными», среди которых то и дело обнаруживаешь себя…

Движение в будущее

Я уже много лет не испытываю сложностей с написанием тест-кейсов, мне сложно быстро понимать новый объёмный продукт. Очень мешают иллюзии вроде «а, это мне знакомо…», а потом «ну кажетаг-то, мне же казалось, что оно вот так, а оно вон оно как…»

Тест-кейсы выглядят по-разному не по чьей-то злой воле.

Когда тесты условно-краткие — их удобно быстро считывать и выполнять, но их невозможно выполнять, если не понимаешь ни контекст, ни «как это сделать».

Когда они условно-подробные — их тупо неудобно быстро выполнять, и большинство опытных тестировщиков просто перестают их читать (а там что-то может быть изменено, ойёпт), но их можно предсказуемо выполнять средне-медленно, потому что есть подробная инструкция, которую придётся переписывать во множестве мест, если что-то где-то ВНЕЗАПНО поменяется… Ой.

Логично предположить, что если мы будем придерживаться одного ХОРОШЕГО стандарта, то все сложности исчезнут. Однако логично и то, что «стандарты» всегда тяготеют к «пусть будет много нужной и полезной информации», а это всегда в итоге формат «условно-подробнейших тест-кейсов», которые постоянно хочется «переписать попроще», но времени нет.

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

Тест-кейс — инструкция по созданию тестовой ситуации.

Иногда ситуацию можно объяснить одним предложением, и результат её очевиден. Иногда надо предварительно объяснить предусловия и не факт, что всё будет понятно. Иногда достаточно просто упомянуть, что «а ещё в базе надо проверить, что наценка на товар правильно применилась и повсюду посчиталась». Иногда надо прямо указать, куда зайти и какой запрос использовать.

Не нужно искать один-единый формат тест-кейсов. На одном и том же проекте надо использовать разные форматы тестов в зависимости от условий и контекста возникающих задач.

Общий подход — пишем тесты в виде идей. Коротко.

Идею можно уточнять — добавить несколько нужных строк. Если выглядит достаточно понятным самому себе — всё норм.

Идею можно снабжать отсылкой к подробной инструкции для выполнению отдельных шагов. Инструкции можно записывать в общие места (Confluence, Notion, тыды).

Какие-то тесты навсегда останутся однострочниками. Какие-то будут монстрами. Думать надо о том, чтобы они были понятными, а не стараться заранее определять, что и как из них получится.

Знать такое заранее было бы так же смело и странно, как точно знать завтрашний курс криптовалюты в Молдове и смело призывать всех вкладывать в передовую технологию будущего из прошлого ценную международную валюту с изображением Штефана чел Маре.