Я вам вчера посоветовал всё закинуть в LLM, чтобы она вам пояснила. Вы это сделали? Там еще был совет почитать книгу, но ее надо все же сначала а купить, а LLM доступны сразу.
Вы снова наступаете на одни и те же грабли. Вот часть ваших заблуждений только из этого сообщения (которые и объясняют провал внедрения):
Комплексная документация является потерянным артефактом в разрезе Agile, так как она не представляет высокой ценности для заказчика.
Agile не про то, что надо писать хорошо - он про то, что надо делать так, как нужно заказчику
По Agile, документация менее важна, чем работающая фича.
Вчера уже сколько раз я делал акцент, что речь про исчерпывающую документацию, но вы этого в упор не замечаете и не понимаете, о чем речь, хотя разжёвано по несколько раз. Последняя попытка, может на английском понятнее: Working software over comprehensive documentation.
Далее цитаты:
Плюс - Agile не предполагает документирование решения до его разработки
Цель Agile - не получение качественного с инженерной точки зрения продукта
перед тем как задача будет выполнять проводится глубокий анализ и проектирование, которые обязательно проходят ревью (чего не требует Agile, кстати).
Сам по себе DF противоречит местами манифесту, причем достаточно существенно
Вы просто не понимаете, что такое Agile. И, что более показательно, не хотите его понять, при том, что вам разные люди в комментариях пишут одинаковые вещи.
Вы просто каждом новым комментариям оказываете медвежью услугу Тензору. После такой "презентации" внедрения процессов желающих идти к вам станет меньше. Никто не хочет работать в карго-культе, особенно, когда ответственные или приближенные к ним люди не слышат ничего, кроме своего личного мнения.
Автор статьи исходит из ложной предпосылки, что в Agile документацией можно пренебречь. Равно как и то, что Agile дает скорость — это классические заблуждения. Из-за чего ожидаемо вытекает немало проблем. Он приходит к выводу, что
Документация — это потерянный артефакт в мире гибких методологий...
и "находит" решение
Documentation First призван устранить недостатки гибких методологий\фреймворков, снизить риски за счет бюрократизации в нужных местах.
И тут две фундаментальные ошибки — сначала с потерянным артефактом, затем с призванием DF.
Сам подход с документацией не нов, раньше он назывался RDD (Readme Driven Development) и другими именами. Но его появление в команде, работающей якобы по Agile, это не что-то новое, а сигнал, что Agile был внедрен как карго-культ, без понимания сути.
Зрелая команда с развитой инженерной культурой не нуждается в том, что ей "внедряли" DF. Для нее предварительный анализ, проектирование и написание необходимой документации — это не отдельный подход, а здравый смысл, часть процесса разработки ПО, без которого не написать качественный код. А весь Agile именно про то, что нужно писать хорошо, нужно писать тесты, нужно заниматься парным программированием. Всё это создает циклы ревью и улучшений итогового продукта.
Поэтому, отвечая на вопрос — противоречия между Agile и DF/RDD нет.
Это не взаимоисключающие вещи. Agile это фреймворк, DF это инженерная практика, которая естественным образом уже есть внутри этого фреймворка (опять же, в зрелых командах, которые понимают, что они делают).
Проблема, которая возникла в статье, возникла не потому, что Agile и DF/RDD не совместимы, а потому, что команда автора изначально выкинули из своего процесса базовую инженерную практику, а потом героически ее вернула под новым названием, свалив при этом вину на Agile.
Отвечу на оба комментария здесь. Ваша позиция предельно ясна, но она основывается на ряде фундаментальных заблуждений, которые вы последовательно повторяете.
Коммуникацию должен обеспечить какой-то инструмент. Мы работаем не в идеальном мире с идеальными людьми...
Инструменты коммуникации в Agile — дейли, демо, груминг, ретро и прочие ритуалы, если команда считает их необходимыми. Также он призывает к постоянному взаимодействию с заказчиками. Если в рамках этих инструментов команда не может прийти к общему пониманию и зафиксировать результат, то это не проблема инструмента, а неумение им пользоваться.
Ссылаться снова на "неидеальный мир" выглядит как попытка снять с себя ответственность за выстраивание процесса.
Если любой инструмент не имеет конкретно обозначенного результата, с измеримыми критериями - его не будет.
Это фундаментальное непонимание инструментов, процессов, результатов и что из них когда работает.
Потому, что наша задача "обсудить и когда-нибудь придти к решению".
Нет, это ваша задача. И это ваша же проблема, что у вас такой подход. Вы не владеете инструментами коммуникации и не понимаете, какие артефакты должны быть на выходе. В чем, собственно, и признаетесь, хотя не понимаете этого.
Обозначенные подходы решают проблемы коммуникации, но не решают проблему полноты информации. И не решат. Хотя бы потому, что носитель знаний в условно завтра уже может не работать...
Вы снова описываете проблему, который зрелый Agile решает по определению.
Это проблема не коммуникации как таковой, а видения и восприятия.
...
Общение, без фиксации его результат приведет только к тому, что кто-то будет понимать то о чем договорились по-своему, а не так как требуется в итоге. И это нормально, так как у людей как минимум разный контекст.
И снова вы не понимаете, как пользоваться коммуникацией. Для вас это, видимо, общение без фиксации. А в Agile это работает совсем не так. В реальном мире, кстати, тоже. Для совсем ленивых уже нейронки составляют саммари беседы. Если вы не можете ограничить скоуп проблем на митингах и зафиксировать договоренности и результаты, то при чем тут Agile? Я сейчас описываю какие-то банальные и очевидные вещи, которые делались еще лет 10 назад минимум и каждый участник процесса понимал важность этого. При этом это было вне зависимости от методологии, потому что это здравый смысл, но у вас в сообщении он вырезан.
Нет противоречит. Но, как сказано в манифесте от 2001 года работающий функционал лучше полной\хорошей технической документации.
В манифесте написано: Работающий продукт важнее исчерпывающей документации. Не "полной", не "хорошей", а "исчерпывающей" — это против бюрократии и документа ради документа, а не против необходимой документации. И не "лучше", а "важнее" — это о приоритетах, а не о замене. И эта ценность не является разрешение на создание технического долга и отказа от необходимости документировать.
Также в Agile нет ничего про скорость. Ни в ценностях, ни в принципах. Agile не говорит, что ПО будет разрабатываться быстрее, он не дает таких гарантий и обязательств. Более того, по гибким методологиям релиз полного продукта скорее всего будет позже, чем по каскадной модели. Но за счет ранних поставок и гибкости выпущенная часть функционала может помочь бизнесу закрывать свои цели, а не ждать полного релиза.
Бизнес готов жертвовать здесь и сейчас качеством документации ради скорости релиза фичи.
А это просто непонимание, что делать хорошо сразу будет намного дешевле, чем переделывать потом.
Замечу, вы сейчас подгоняете уже Agile под практику DF, так как сложно отрицать очевидный плюс от осознанного проектирования с фиксацией результат в виде документации.
Правда, это противоречит одному из принципов Agile - работающий код важнее полной\хорошей документации.
Это прекрасно. Вы, видимо, серьезно считаете, что DF настолько уникален, что никто не додумался сначала проработать документацию, а потом писать код? Я расстрою, но в реальном мире в зрелых командах, работающих по Agile (и не только), так делают с самого начала и никто не говорит про DF. Это просто здравый смысл, чтобы самим потом было легче работать — не заказчику с кодом работать, не ему его тестировать.
В моем сообщении нет "подгонки", есть лишь правильное прочтение манифеста. Вы читаете его как разрешение на отказ от документации. А моя трактовка выше. Но, что показательно, вы упорно раз за разом неверно понимаете эту ценность.
И пропишу явно уже сотый раз — написание документации не противоречит Agile.
Мне нравятся ценности Agile
Ага, особенно про документацию. Видите ли, все ценности и принципы работают вместе. Если вы от них отходите, что гибкие методологии позволяют, это уже будет какая-то отдельная интерпретация.
Извините, но Вы пытаетесь все свести к одной единственной проблеме и инструменты. Так не работает.
В данном случае из всего написанного вами четко прослеживается проблема коммуникаций. Про это написал не только я. Может пора уже задуматься?
Вот Вы сами же и привели пример, почему DF обеспечивает коммуникацию. Бизнес и разработка должны работать вместе, а у работы должен быть проверяемый результат. Но принимать участие в процессе разработки 8 часов, закрыв на свои задачи глаза - не может большая часть заказчиков.
Я вам пишу про одно, а вы интерпретируете как вам удобно. О чем это снова говорит? О проблемах с коммуникацией. И как иллюстрация непонимания — вы пишите про какие-то 8 часов, считая, видимо, что всё это время должно быть общение с заказчиком. И снова вопрос возникает — как с такими знаниями можно было пытаться что-то внедрить? Вы же ни одной ценности и принципа нормально донести не сможете. Сейчас вот вы нашли DF. Через год что-то еще. Но первопричины так и остались.
Коммуникация без формализации в виде какого-то результата (документа) приведет к слишком большим затратам заказчика. Ведь нет некоего источника знаний о том, что надо сделать.
И вот пример чудовищного непонимания.
Так получилось, что человек, который реализовал скрипты сборки SPA попал на очень длительный срок в больницу... Проблема решилась бы, будь документация...
И вот тоже упорное непонимания важности документации. Из раза в раз вы считаете, что можно без нее, как и в описанной истории. Но нет, нельзя без нее. И команда, которая попала в ту ситуацию, если бы работала по Agile с полным его пониманием, в ней бы не оказалась, а так виновата только команда, а не методология.
Про "демо", простите - опять же, вы немного лукавите. Забываю о неудобной в данном случае ценности, что любая итерация должна быть полезна для бизнеса.
Вы просто не понимаете, что такое "бизнес-ценность". И снова у вас демо это как повод отчитаться перед заказчиком. Демо это не "любая" итерация. Это один из ритуалов для обратной связи и синхронизации. На демо, еще раз повторюсь, должен показываться готовый к релизу функционал, а не "мы сделали зеленую кнопку, не увольняйте".
А то, что вы пишите — неумение декомпозировать, чтобы на выходе получить небольшой, но функциональный для бизнеса продукт или его часть. В зрелых командах есть специалисты, которым это под силу такое разбиение. И снова забываете, что Agile — про гибкость, но устраиваете какую-то обязаловку по результатам, напрочь упуская все преимущества этой методологии.
Собственно, у нас разница в восприятии Agile - для вас гибкая разработка есть совместное "творчество", для меня это процесс производства с повышенными гарантиями нужного результата. На мой взгляд первое возможно, но до тех пор пока продукт не стал большим и ошибки в его логике не приводят к издержкам клиентов. И DF как раз позволяет повысить полезность коммуникации.
Ваш взгляд — разработка это конвейер. Agile-взгляд — разработка это непредсказуемый процесс R&D.
А то, что вы пишите, не имеет отношения к Agile. У нас нет разницы в восприятии — у вас просто нет знаний в этой области, хотя вы упорно пытаетесь доказать обратное, демонстрируя каждый раз еще большие пробелы и методологическую пропасть.
Вместо часовых споров о решении - формализация функции полезности архитектором доработки, описание решение и ревью с предметными обсуждениями. Вместо постоянного вовлечения заказчика по одним и тем же вопросам - материализация ответов в виде документа.
Еще раз, я не отрицаю важности коммуникации (этот тезис нравится Вам), я говорю то, что результатом любой коммуникации должен стать некий проверяемый результат. И этот результат - техническая документация.
И снова все мимо Agile. Если вы спорите без результата, то вы неправильно наладили процесс коммуникации, т.к. в команде нет понимания, что она должна сделать. Если вы постоянно вовлекаете заказчика, значит вы снова не смогли наладить процесс коммуникации между ним и командой. Если у вас нет результата коммуникации, то вы снова не поняли, как пользоваться этим инструментом.
Абсолютно каждое предложение является примером непонимания гибких методологий и уже в который раз подсвечивается одна и та же проблема.
В статье этого и нет. Есть описание проблем, которые никак не решаются в гибких методологиях (это отдается на откуп команде)...
недостаток Agile как раз в том, что он хорошо решает только часть проблем, а часть - оставляет "на усмотрение команды".
То, что вы считаете недостатком, является преимуществом и сутью Agile — доверием к профессионализму и самоорганизации команды. Фреймворк дает свободу. Если команда не знает, что с ней делать и "ищет маму", которая даст четкие регламенты, то это не проблема фреймворка. Это проблема зрелости и компетенции команды. Напомню принцип: Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
По Agile большей ценностью является не разбор техдолга, а релиз функционала. Коммуникация в том то и дело, что налажена - но она не решает проблемы техдолга, не решает проблем отсутствия полного набора нужной информации. И не может - хотя бы потому, что все привлеченные могут и не знать о чем-то (как пример с SPA интернет-магазина), нет конкретных инструментов.
Это опасное и неверное утверждение. В Agile есть все инструменты — ретро, беклог, практики из экстремального программирования, беклог продукта, DoD. Зрелая команда и владелец продукта понимают, что игнорирование техдолга сегодня приведет к прекращению поставки ценности завтра. И они выделяют на это время в спринтах.
DF позволяет закрыть эти проблемы, которые гибкие методологии оставляют как раз на усмотрение команды.
И снова мимо. Более того, этап технического проектирования можно спокойно записать в DoD. А то, как вы описываете DF — закрывает ваши пробелы инженерной дисциплины и самоорганизации. И да, ваша попытка внедрить DF выглядит именно как первый попавшийся велосипед, как вам справедливо написали.
DF - это в большей степени есть форма выражения результат, проверяемого. DoR ему не противоречит, как и Agile. Тогда чем Вам не нравится DF?
Мне не "не нравится DF". Мне не нравится, что вы его позиционируете как внешнее средство для проблем Agile. При этом вы не понимаете, что эти проблемы сами же и создали. Практика нормального подхода к документации есть изначально в Agile при работе зрелой команды. А у вас же провалено внедрение Agile, потому что вы не поняли, как его применять и зачем, но увидели одну точечную проблему и нашли для нее точечный инструмент. Перефразирую — для меня очевидно, что документация является частью процесса разработки в Agile. Для вас это наоборот.
Тут нет проблемы коммуникации - это адекватная разница целей.
Цель любого заказчика извлечение выгоды... Цель любого разработчика - реализовать продукт...
У вас одна роль хочет быстро, а другая хочет качественно, а третья домой пораньше пойти. Что это? Это именно проблема коммуникации, потому что у каждого своя цель, а не одна общая. Вы еще спорите зачем-то. Чтобы вы понимали, как выглядят ваши слова — "у нас нет проблем в общении, просто мы не общаемся".
Так одна из проблем в материале и обозначена, что многие в гибкий методологиях команда определяет самостоятельно
Это преимущество гибких методологий, которое описано в принципах. С другой стороны получается, что вы, зная такую особенность, и что она вам не подходит, все равно внедряли. Очень умно! Чем больше пишите, тем хуже выставляете себя и компанию.
Вы подменяете в удобном свете для себя цитаты :-). Они про разное, если вчитаетесь. Первая - о том, что большая часть заказчиков закроет глаза на проблемы, которых можно было бы избежать при наличии нормальной проработке, для них будет важнее срок.
Я не работаю у вас и могу называть вещи своими именами, а не выставлять в удобном свете провал внедрения методологии, а потом упорно всем пытаться показать в комментариях, что Agile не торт.
Суть в том, что те цитаты являют собой замкнутый круг причины и следствия. И то, что вы отделяете одно от другого, очень грустно. Зрелая команда может сказать "нет" плохим решениям. А вы пытаетесь показать, что это неизбежно.
Кстати, интересный (неудобный) пример проблем гибких методологий - в какой-то момент, одна знакомая компания закрыла большой продукт. У заказчика поменялось видение того, как должна решаться проблема. Было потрачено полтора года работы команды из 5 человек на подсистему советов в интернет-магазинах на основе ИИ. Поменялось видение - поменялось решение. Коммуникация была на хорошем уровне, ничто не предвещало. Просто заказчик в какой-то момент осознал, что его проблема решается проще. Замечу - все ценности и артефакты соблюдались, проблема выявилась на последних этапах внедрения. Когда стало ясно, что видение было ошибочным - споткнулись на банальностях, которые можно было выявить до этих затрат. Просто формализовав результат и все критерии качества.
Это не "неудобный" для Agile пример. Это идеальный пример того, как не надо делать Agile. Если команда за полтора года, а это примерно 36 двухнедельных спринтов, работала над продуктом и только на последних этапах получила обратную связь от заказчика, что видение было ошибочным, значит в процессе не было ни одной реальной итерации с поставкой ценности и получением обратной связи. Просто что-то делали по водопаду с двухнедельными отрезками. Отличный пример карго-культа.
Смотрите, Вы начинаете судить в удобных фактов для Вашей гипотезы, игнорирую большую часть того, что было сказано.
А давайте посмотрим на факты, которые вы сами изложили?
Первое - где Вы нашли, что документация игнорировалась?
Вы не писали прямо "мы забили на документацию", хотя во всех ответах ниже про ценности вы именно на это очень жирно намекаете.
Но вот цитаты, которые показывают ваше отношение к документации:
Проблема: Разработчики понимали свою конкретную задачу, но общего контекста не осознавали.
Причина: То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
Признание: в начале проекта мы жалели времени на детальное продумывание задачи
Осознание: нам не избежать разработки документации
Личный опыт: прошел все пять стадий принятия того, что свои задачи я должен также документировать, пусть и в виде промежуточных документов.
Последствия игнорирования: Первый результат: пока не понимаем необходимый объем документации, который нужно делать при таком подходе.
Вывод: Документация — это потерянный артефакт в мире гибких методологий.
Где Вы нашли нарушение дисциплины, проблемы коммуникации?
Проблемы коммуникации:
Разработчики понимали свою конкретную задачу, но общего контекста не осознавали
То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
и потом получали "волейбол": разработчики отдавали задачи тестировщикам, те возвращали им обратно… и так снова и снова, долго и мучительно
Они исходят не от заказчика, который о них может не помнить или банально не знать, а от реализации
Проблемы дисциплины:
в начале проекта мы жалели времени на детальное продумывание задачи
мы постоянно всё переделывали
Фича создаст поток ошибок и правок, которые надо "дожать" в короткие сроки
чем более "гибким" становился подход, тем сильнее проявлялись узкие места.
мы постоянно всё переделывали
Начинаются доброски "в последний вагон" перед релизом
Мы планируем итерацию, а не пытаемся решить всю задачу, следовательно, пренебрегаем анализом дополнительных требований к ней
Но эти примеры — ерунда по сравнению с тем, что вы сами писали в комментариях.
Нет инструментов. Есть только идея, что если люди будут соблюдать ценности и активно взаимодействовать, то получится эффективно.
И еще раз — инструментов достаточно. Просто для этого надо понимать, что такое Agile, чего в данном конкретном случае не было вообще.
С точки зрения получения нужного для заказчика результатов - у гибких методологий нет равных, так как они дают промежуточные точки контроля (а это они, каким бы красивым эпитетом они не назывались бы). И их цель не минимизация рисков (считайте, издержек - они принимаются как данность), а получение максимальной ценности за вложенную стоимость.
И опять вы упорно не хотите понять, что демо — это не для контроля. Как и упорно игнорируете факт, что с заказчиком должно быть общение. Чисто логически — при регулярном общении с заказчиков нет смысла в контроле в виде демо, потому что он и так в курсе в любой день. Более того, заказчику могут дать доступ к тестовому стенду, где он может сам смотреть, как меняется продукт буквально в любой момент времени и тут же давать обратную связь — это отлично работает в рамках Agile в реальном мире. Но так как вы не знаете, что такое Agile, то для вас это элементы контроля. С таким подходом, где команда может организоваться и работать сама, ваше понимание расходится полностью.
Материал же о том, как уменьшить риски, достаточно дешевым способом.
Нет, материал о том, как команда, провалив внедрение Agile из-за непонимания его ценностей и отсутствия инженерной дисциплины, вернулась к привычной директивной модели, выставив гибкую методологию крайней.
И сейчас, вместо того, чтобы писать ответ, лучше ознакомьтесь с книгой Боба Мартина. Она читается за вечер. Объективно — ничего нового вы уже не напишете, лучше своими комментариями не сделаете. Так посвятите время самообразованию и вдумчиво ознакомьтесь с книгой "Чистый Agile".
В крайнем случае закиньте статью и все переписки в LLM, она вам пояснит.
Если бы написали про попытку внедрения Agile, про то, как сами ее провалили и почему, и как в итоге пришли к выводу, что вам больше подходит DF, хотя это не методология и вообще непонятно, что у вас в итоге сейчас, то такая статья была бы намного лучше, честнее, интереснее, но увы, имеем что имеем.
Вы не упростили. Вы не поняли ни тогда, ни сейчас. И подменили понятие "исчерпывающий" на "хороший". И вместо того, чтобы это признать, вы пытаетесь зачем-то оправдаться, делая только хуже.
Agile не призывает делать хорошо (него нет для этого измеримых показателей), он призывает делать как нужно сейчас заказчику.
Эти слова тоже не имеют отношения к Agile. Потому что именно Agile призывает непрерывно работать вместе с заказчиком и делать именно хорошо, потому что переделывать будет намного дороже. И еще раз процитирую принцип: Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Еще скажите, что здесь явно не указано "делать хорошо", значит так делать не надо.
Уже в который раз написанное вами противоречит Agile. Это невероятно показательно.
Не могу сказать, что прям хорошо владею темой — все же здесь обсуждались самые поверхностные вещи. Для лучшего понимания в своё время прочитал "Чистый Agile" от Боба Мартина, "Пользовательские Истории" от Майка Кона, "Agile-тестирование" от Лайзы Криспин и Джанет Грегори. Также знакомился с какой-то версией PMBOK, и, насколько знаю, последние редакции смещались в сторону гибких методологий. Еще было много статей, что-то у Кента Бека читал, статьи Мартина Фаулера, но точно уже не вспомню. В целом можно просто открыть список авторов Agile и искать их статьи/книги.
Много опыта дала работа по Agile, где он хорошо внедрен и там, где внедрен очень плохо — на контрасте сразу видно, что не так и как должно было бы быть.
Вижу, что сообщение вы отредактировали. Хотя ничего нового я не увидел.
А как вы определяете необходимую глубину анализа? Часто - проблемы того или иного решения в сложной системе оценить получается при достаточно подробном анализе и формировании документации по решению. Собственно вот мы и пришли к DF.
DoR, груминг. Это гибче, чем DF. И ваш DF это по сути DoR, который вы зачем-то противопоставили Agile.
Для заказчика разработка технической документации чаще всего будет ниже работающей фичи.
И снова проблема в коммуникации. Я надеюсь, вы понимаете, что она слишком часто повторяется что в статье, что в ответе, что в дополненном ответе? Что это не случайность, а систематическая проблема.
В том, что вы привели есть две основные проблемы
Эм. Там ноль проблем, если понять, что вы используете гибкую методологию, а не набор жестких регламентов. Вы сами определяете, какая глубина анализа нужна под конкретно ваш продукт. И это очевидно из всей философии Agile.
тезис "работать вместе" не фиксирует результат и требования к нему.
Так если вам и этот принцип не подходит, зачем тогда тащили себе Agile? Вам нужны директивы, но Agile не про это. Но вот конкретно в этом предложении вы не понимаете, что "работа вместе" это процесс, в ходе которого создаются артефакты: пользовательские истории, критерии приемки, документация, схемы и т.д. Agile не говорит "ни в коем случае ничего не фиксируйте!". Он говорит о фиксации результатов совместной работы, хотя и в явном виде это не указано. Ваше непонимание этого базового различие между процессом и результатом показательно.
Собственно, DF и дает вполне применимые инструменты, чтобы заполнить "белое пятно". Мы заполнили это так - в чем тут проблема?
Проблема не в том, что вы сделали, а как. Белое пятно не в Agile, а в вашей его реализации. Agile это фреймворк, он дает свободу действий и инструменты для корректирования и выстраивания процессов. Но и отвечаете за эти вещи вы сами. С DF вы просто начали делать ту часть работы, которую Agile изначально перекладывал на вас. То, что вам для этого потребовались явные указания, а не здравая логика и корректная интерпретация манифеста — не вина Agile, а проблемы ваших процессов.
Рынок динамичен, конкуренты не будут сидеть сложа руки - это аргументация бизнеса, вполне обоснованная...А проблемы - можно поправить.
//и из начала самой статьи:
Наша основная боль была в том, что мы постоянно всё переделывали... на самом деле под капотом надо было сделать еще 100500 правок, чтобы не задеть рядом стоящий функционал или полностью замкнуть кейс.
Думаю, тут комментарии излишни.
Признание проблем методологии - позволила начать внедрение DF и я в этом не вижу проблемы. Собственно, статья и говорит о том, как обойти проблемы и закрыть белые пятна.
В методологии нет проблем. Она как была в вашей конкретной реализации, так и осталась. Все ответы кричат о тотальном непонимании принципов, ценностей, ритуалов — это видно и по вашим остальным комментариям здесь. Agile требует зрелости, дисциплины, коммуникаций. Если этого нет, и никто в этом не заинтересован, то внедрить гибкую методологию не получится. Что у вас и произошло. Вы буквально повторили все классические ошибки, начиная с отказа от документации и заканчивая слепым следованием ритуалов без понимания их смысла. И на фоне этого возвращение к директивной модели с DF для вас выглядело как решением.
Для Agile работающий проект важнее хорошей документации.
Вы намеренно игнорируете цитаты из манифеста, которые я вам указал?
Работающий продукт важнее исчерпывающей документации
А у вас почему-то документация стала хорошей. Вы просто не поняли, что написано и сделали свою интерпретацию, которая расходится с Agile. И если что, Agile не говорит "делайте плохо". Он наоборот призывает делать хорошо, потому что переделывать потом будет дороже.
Весь ваш комментарий подчеркивает, что вы снова ставите во главу угла не коммуникации между людьми, а какой-то подход. Точно такая же ситуация была в самой статье. Вы последовательно подменяете принципы живой коммуникации формальными процессами. И возникает риторический вопрос — не постигнет ли DF такая же участь?
Но проект может касаться очень большой системы, которая имеет "под капотом" большое количество не явных факторов.
Вы не первая и не последняя компания, работающая с легаси. В мире накоплен огромный инженерный опыт решения именно таких проблем с помощью гибких подходов (LeSS, Lean, etc.). Фразы про "большую систему" или про "реальный" мир в 2025 выглядят не как реальные трудности, а как менеджерский провал, который разгребает команда.
Контекст для менеджера/заказчика и контекст для разработчика - могут быть разными. В идеальном мире, задача уже содержит решение.
И снова вы пишете, что у вас проблемы с коммуникацией, которые вы не решаете. Даже не так — вы считаете, что решили их через внедрение DF. Но под коммуникацией (я рассмотрю Agile) подразумевается общение между заказчиком, аналитиком, дизайнером, разработчиком, тестировщиком, менеджером. Если все эти люди вовлечены в процесс обсуждения полученной документации, то снимаю шляпу. Но что-то мне подсказывает, что это даже близко не так.
DF решает эту проблему тем, что дает точку, в которой разработчик должен обсудить все требования и критерии качества.
Переложили ответственность на разработчиков. И, кстати, здесь тоже вы пишите про проблемы с коммуникацией. Пока нет документации, нет понимания у каждого участника процесса, должно быть написано 0 строчек кода. И это не только не противоречит Agile, но и прекрасно ложится на описанные принципы.
DF - это и есть один из способов общения, который обеспечивает коммуникацию и заставляет участников не просто обсудить задачу, а зафиксировать требования, решения и ограничения. Т.е. по-факту смотреть не только на вершину айсберга и сделать такой анализ проверяемым результатом.
А это еще раз говорит и о проблемах с коммуникацией (и непониманием, что это концептуально такое) и непониманием Agile, хотя я специально привел принципы, в которых нет ничего сложного или противоречивого. Кратко: DF это не один из способ общения, не натягивайте сову на глобус.
Я раскрою страшную тайну. DF это просто нормальный процесс проектирования с артефактами в виде документации. И в целом сам подход можно описать как "семь раз отмерь, один отрежь". Ну или "сначала думаем, потом делаем". Это было задолго до прошлого века. Как и подходы, сформулированные в Agile манифесте, использовались задолго до его создания. Более того, любая небольшая команда (а не набор разношерстных специалистов, запертых в одном помещении) придет примерно к тем же выводам, которые есть в Agile, будучи с ним незнакомыми.
Не соглашусь - для заказчика "демо" и есть точка контроля, гарантия того, что он получает нужный ему результат. Можно играть словами и называть корректировки "обратная связь", но сути это не меняет. И да, DF позволяет синхронизироваться намного раньше момента, когда команда уже "пошла не туда".
Не соглашаться вы можете с чем угодно. Это ваше личное мнение и право. Однако, есть пропасть между обоснованным личным мнением и тотальным непониманием какой-то концепции. Вот здесь мы имеем второй случай, и, что примечательно, при всех цитатах вы продолжаете доказывать свою точку зрения, хотя могли бы разобраться в предмете дискуссии. Конкретно по этому абзацу — для вас демо это формальный акт приемки заказчиком. Для Agile это то, что я описал — момент синхронизации для всех участников процесса, на котором показываемый функционал не должен быть сюрпризом для заказчика, потому что коммуникация должна быть постоянной. Вы же этого так и не поняли. Демо это не пилить что-то срочно две недели, чтобы потом показать, это готовый результат (инкремент) итеративного процесса разработки с полным вовлечением заказчика. Игра слов это вот выше про "DF как один из способов общения", а процесс с демо является следствием из принципов Agile. Там прям написано: разработчики и представители бизнеса должны ежедневно работать вместе. Не можете этому следовать? Agile не для вас, не надо его насильно впихивать. "И да, DF позволяет синхронизироваться" — кхм, весь Agile про общение, но чтобы понять важность коммуникации, понадобился DF? И снова — тут тоже про проблему коммуникации.
Красивая идея - чаще всего в жизни не работает. Как раз Брукс в "Мифический человекомесяц" это очень хорошо показал.
Удобная позиция, но не сработает. Проблема в том, что для внедрения чего-либо, нужно сначала очень хорошо провести анализ. Но с Agile почему-то другая ситуация, его бегут внедрять, потому что другие же тоже бегут. Хотя с учетом постоянного упоминания Брукса складывается ощущение, что новые подходы внедряются по мере прочитанных книг. И прежде чем ссылаться в 10 раз на одного и того же автора, стоило бы ознакомиться с книгой "Чистый Agile" от Боба Мартина, чтобы закрыть свои пробелы и понять, что же на самом деле у вас пошло не так и почему виноват не Agile. Небольшой спойлер — там прям написано, что Agile для малых и средних команд.
Для ясности — я не топлю за какую-то конкретную методологию. Но я категорически против бездумного внедрения чего-либо, что здесь и было описано, а затем обвинения инструмента в своей некомпетентности.
Будем называть вещи своими именами. DF это не откровение, а базовый этап проектирования (все мы помним "семь раз отмерь, один отрежь"), который существовал задолго до всех нас. Вы пришли к нему, потому что провалили внедрение Agile.
У вас на старте большой проект с плохой документацией. Вместо того, чтобы начать с разбора техдолга и налаживания человеческих коммуникаций, вы попытались внедрить "новомодную" методологию, вырвав из нее ритуалы, но проигнорировав ценности. Когда это предсказуемо провалилось, вы обвинили методологию. И своим ответом вы лишь подтвердили это.
Вы написали отличную статью о том, как вы и ваша команда провалили внедрение Agile. И немудрено — сложно внедрить то, что не понимаешь. Рассмотрим примеры этого непонимания в цитатах.
Разработчики понимали свою конкретную задачу, но общего контекста не осознавали.
Это говорит об отсутствии инженерной культуры. В принципах Agile есть такой пункт: Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Нет контекста — нет условий и поддержки. И даже если это было до внедрения, это говорит о провале в управлении командой, который методология не исправит.
Наша основная боль была в том, что мы постоянно всё переделывали. Разработчики понимали свою конкретную задачу, но общего контекста не осознавали. То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
Из принципов: Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Agile очень сильно нацелен на коммуникацию, а у вас же это одна из проблем. При этом есть еще один принцип: Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Так происходит потому, что все agile-методологии придерживаясь одних и тех же ценностей приводят к увеличению точек контроля (т.е. частой демонстрации промежуточного результата)
Ценностей придерживается команда. И если вы поняли ценности как "показывать демо", то вы не поняли Agile. В самом манифесте, кстати, ничего нет про частую демонстрацию. Из принципов: Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев и Работающий продукт — основной показатель прогресса. Демо является не "точкой контроля", как у вас написано, а инструментом для получения обратной связи. На демо можно понять, то ли вообще делали, какие дальше шаги и т.д. Это больше синхронизация команды и заказчика, а не лишь бы показать что-то ради галочки. Если что — никто не гонит сделать за две недели что-то рабочее. В гибких методологиях слово "гибкость" является ключевым, но вместо этого описаны какие-то рамки. из-за которых страдает процесс разработки.
Ожидаемый эффект выглядит привлекательно:
повышаем осознанность доработок,
----------------
Иными словами, нам не избежать разработки документации, если мы хотим решить проблему, описанную выше.
Agile не против документации. Как и не против нормального планирования. Мотивированные профессионалы должны прекрасно понимать важность документации, проектирования, планирования. Из принципов: Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Мы планируем итерацию, а не пытаемся решить всю задачу, следовательно, пренебрегаем анализом дополнительных требований к ней. Они исходят не от заказчика, который о них может не помнить или банально не знать, а от реализации. Именно глубиной анализа итерации мы жертвуем, применяя гибкие методы управления проектами.
В Agile ничего не сказано про пренебрежение и жертвование глубиной анализа. Это ваш неправильный вывод, которому вы следовали. Из принципов: На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Более того, вы же прекрасно понимали, что жертвуете анализом, так что мешало применить принцип о способах улучшения стиля работы? По тому, что написано складывается ощущение, что вы сами придумали два стула: "либо Agile", "либо анализ"
Фича создаст поток ошибок и правок, которые надо "дожать" в короткие сроки. И это не противоречит ценностям Agile. В рамках методологий такой подход является нормой: показываем итерацию, получаем правки, исправляем, а потом снова показываем "полуфабрикат", который продолжает быть проблемой в живом продукте…
Забавно то, что это не имеет отношения к Agile. Это провал управления командой и планированием. Из принципов: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Не надо показывать итерацию. На демо должен показываться готовый к выпуску продукт (или его часть, которая должна пройти DoD), а не задеплоенное наспех и без тестирования на демо-стенд нечто. И технически это не противоречит ценностям, да. Как не противоречит им и непонимание методологии. Просто таких вещей там быть не должно. Как должно быть — читаем для начала манифест, там очень простые вещи, которые написали инженеры. И в качестве единственной проблемой в живом продукте выступает только тот, кто пытается внедрять методологию без ее понимания, а этим пронизана вся статья.
Сегодня такой подход называется Documentation First.
Вы изобрели этап нормального планирования. Конечно, лучше поздно, чем никогда, но всё это должно быть следствием принципа из Agile: На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Выяснили детали — создали документацию, верифицировали через бизнес. Иначе как можно приступать к работе, если сами не понимаете, как должно работать в итоге.
Документация — это потерянный артефакт в мире гибких методологий.
Что, простите? Да, есть ценность Работающий продукт важнее исчерпывающей документации, но если вы ее истолковали как документация не нужна, то это снова не проблема Agile. Вот специально же написано в манифесте, чтобы не было кривых интерпретаций: То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. Вот прям еще раз: не отрицая важности того, что справа, то есть "исчерпывающей документации". Но у вас это превращается в потерянный артефакт. На сайте манифеста это шесть строк, которые не противоречат друг другу, но каким-то немыслимым образом это читают как "мы документация не пишем, у нас Agile", загоняют проекты в яму, а затем винят методологию в собственной некомпетентности.
Получается интересная картина. Чтобы работать по Agile, нужно его хоть немного понимать или быть к нему открытым. Но в большинство статей о неудачах с гибкими методологиями говорится не "мы облажались при попытке внедрить", а "Agile не работает". И вот это "облажались" есть в этой статье, но оно подается как "Agile плохой".
Вообще ни разу. Ассеты можно заменить в любой (почти) момент. А вот идею — нет. А то с логикой про "чужое" можно зайти в дебри, что должен быть свой движок, а затем и свой формат текстур, а еще надо запускать на своей ОС со своими контроллерами.
Видимо, теперь соискателей из Совкомбанка надо будет на собесах гонять по теории тестирования и проверять умение писать тесткейсы.
А так в статье есть какие-то абстрактные цифры, что стало лучше, но кто теперь делает ревью тесткейсов? Кто занимается оптимизацией тестовой модели? Кто проверяет тесткейсы на дубли? Кто ставить приоритеты, теги, раскидывает по разделам? Кто отлавливает галлюцинации ллм?
Как будто генерацией сделали красиво для отчётов. Без технических данных и конкретных примеров на данном ресурсе это минус.
Статья называется "Оптимизация процессов тестирования", но при этом начинается с инструментов для автоматизации.
Именно о процессах здесь ничего нет.
Вся "оптимизация" не заключается в узкой возможности сменить одну библиотеку на другую. Но вместо рассмотрения более простых вариантов, например банального файла properties, предлагаются другие библиотеки.
Кстати, в этой библиотеке предусмотрены методы, которые сразу возвращает Int или List — не нужно возиться с преобразованиями
Вот как это читается: вместо пары методов на 2-3 строки, возвращающих Int и List мы предлагаем затащить в проект новую библиотеку со своими зависимостями, гипотетическими конфликтами, необходимостью обновления.
Про оптимизацию ли это? Не уверен.
Но настраивая процессы автоматизированного тестирования, стоит отрываться от кода и внимательнее смотреть на процессы — именно тут кроется плодородная почва для оптимизации.
Так тестирования или автоматизированного тестирования? Автоматизация это лишь часть общего процесса. А библиотеки на фоне настройки QG просто не имеют значения.
Ну, хотя бы потому что такого раньше просто не было. Серьёзно. Это первая
Без маркетингового булшита не обошлось, зато его градус куда ниже в этой статье, что приятно. Но круто, что наконец-то полезный инструмент, заимствующий старые идеи аллюра и сайпреса. Полагаю, дальше брать нормальные нейминги тестов, делать на них ссылки, интегрировать напрямую в систему отчетов и добавить конфиг на скрытие графиков. И тогда все звезды гитхаба ваши.
Вы потратили столько времени на комментарий, что видно — тема действительно вас зацепила. И это хорошо: значит, я попал в настоящую боль индустрии.
Благодарю за внимание к теме. Видимо, моя критика задела за живое, раз за 19 минут вы успели ознакомиться и с моим комментарием, и со статьей по ссылке, может даже ролик посмотрели, там всего лишь час, да еще и ответ написали! Впечатляет.
Новый сам подход, делать это не через костыли и плагины в браузере.
Подкладывание файлов, какая-то установка, менять код зачем-то — не костыли. Ноль двойных стандартов. При этом в вашем же примере есть импорт аллюра, который генерирует более чем достаточную информацию для подобной визуализации.
Потому что старая статья есть, но никто этим не пользуется.
Хорошо, что есть человек, способный говорить за всех, который, правда, не удосужился понять, почему идея не внедрились, но куда там, 19 минут, некогда думать. То решение было показано всего лишь на какой-то никому не известной конференции, рекламы которой нет ни в баннерах, ни в рассылках. Нонеймы, что с них взять, jugru какой-то, а кто их знает — всего лишь десяток лет что-то делают.
Хорошая попытка заменить старую статью якобы новым подходом, но нет. У вас странная позиция во всем ответе, что если что-то старое, то оно плохое. Это даже не столько глупо, сколько непрофессионально.
Если бы всё было так идеально, как вы описываете с TMS и ручным линкованием тестов
Если ваши тесткейсы не покрывают нужные сценарии, то циферки в айфрейме уж тем более не смогут показать ничего внятного. Вот вам такой вот факт, как раз это ваш инструмент. Идеальность здесь не при чем, это базовый элемент работы.
TMS — это документация.
TMS это Test Management System или же Система Управления Тестированием. Если вы путаете TMS с документацией, то пора бы освежить знания в области тестирования. То, что вы пишете, показывает очень плохой уровень понимания процессов.
Мой инструмент — это факт.Документация не показывает реальное поведение тестов на фронте. Никогда.
Вот этот уровень, например. Если у вас тесткейсы в TMS не содержат ожидаемого поведения, то вы на одном берегу, а тестирование на другом. И между вами океан под названием "Никогда". Документация не должна показывать реальное поведение. Она должна просто иметь описание ожидаемого и шаги.
TMS показывает, что ЗАДУМАНО тестировать.
Вы используете странные слова. Вот реально, подучите теорию тестирования что ли. В этом предложении неправильно просто всё. Я помогу — Тесткейс это набор последовательных действий с ожидаемым результатом. Тут нет ничего про "задумано", но есть алгоритм, который должен быть основан на документации по продукту. И да, если вы не можете организовать рабочий процесс, чтобы было покрытие по сторям/фичам/эпикам, то это повод задуматься о своей компетенции.
Мой инструмент показывает, что ФАКТИЧЕСКИ тестируется.
Это вы будете с такими фразами его продавать. Потому что ваш инструмент показывает только взаимодействия. Вот я открыл ваш пример, инпут Email. Как у вас по отчету понять, что проверяется введенная информация? А никак. У вас просто отчет "Fill: 8", "Value: 8". 8 раз заполнили и 8 раз что-то там с value сделали — но менеджер спросит, "какие кейсы покрывают поле email?" — что ответите? А ничего. Зато график красивый.
И в итоге вопрос «А что реально покрыто?» просто за бортом. Тонет в "Никогда" рядом с «Где дырки в UI?» и «Почему баги всплывают на очевидных сценариях?». Подсказка — проверки это assert. У вас их нет. У вас (чуть другой пример, но тоже для email) — Fill: 5, Value: 7, Visible: 2. Мы проверили видимость обязательного поля два раза? Заполнили 5 раз, но взяли значение 7 раз? По такому результату может быть что угодно и оно никак не соотносится с покрытием. У вас есть проверка заполнения поля? Тоже нет. Есть какое-то "Value: 8". Пустое? Заполненное? Какие цифры/буквы, сколько их? Самый простой джуновский вопрос на тестирование формы накинет кучу адекватных сценариев, но все они будут у вас в отчете как "Value: 8", которое просто значит, что тут что-то вводили 8 раз (вернее, что метод сработал столько раз). При этом это могло быть как в 1 тесте, так и в 8 — информации об этом тоже нет. И вы еще что-то писали про экстрасенсов. А метрики кликов и прочего можно подключать через яндекс. Да любой, кто видел вебвизор, думал о внедрении подобного в автотесты.
Хотя странно: если у вас всё настолько идеально через TMS, ручные тест-кейсы и процессы — зачем вы вообще читаете статьи про современные методы контроля покрытия?
Ваша статья не имеет никакого отношения ни к современному, ни к методу контроля, ни к покрытию. Не говоря уже о том, что у вас код на старых технологиях. Сейчас GO в моде. С другой стороны вот вы сделали инструмент, который должен был показывать покрытие, но он этого не делает. Получается, что мы оба не получили то, что хотели. Иронично, не правда ли.
Если по-честному — ваш подход морально устарел лет на пять.
Мои подход не старый — документация и процессы это признак зрелости команды. Зато вы поиграли в песочнице гитхаба. Каждому своё уровень занятий.
Сегодня в реальных проектах автотесты пишутся сразу, без бумажной прослойки в TMS.
И пишутся прослойкой между монитором и стулом.
Еще скажите, что без документации реальные проекты делаются. И потом сделайте круглые глаза, когда спросят «Почему баги всплывают на очевидных сценариях?». И внезапно после такого люди начинают бегать с горящей пятой точкой, искать доки по чатам и создавать нормальную вики, затем тесткейсы, затем автотесты или cases-as-code.
Контроль покрытия — это не вера в чекбоксы в тест-менеджменте, а проверка реального поведения UI.
Сами придумали аргумент про веру и сами его героически опровергли. Сильный подход.
Контроль покрытия здесь вообще не в кассу. Видимо, у вас нет базы по тестированию, чтобы адекватно формулировать мысли в данной области. Но галочки в TMS точно таким же образом бесполезны, что и ваши отметки с кликами. Только вот в TMS можно увидеть покрытие по сценариям, а у вас в отчете нет.
Я понимаю, что хочется защищать старые процессы — в них вложено много сил. Но мир меняется.
Моя любимая ложная дихотомия "старое плохое, новое хорошее".
Вы так пишете, как будто ваша "разработка" это что-то морально новое. Вообще нет. Не очень понял, при чем тут возраст процессов. Процессы либо есть, либо их нет. Возраст не влияет на их качество, а вот люди, которые их используют — да. Кардинально нового за последние 20 лет ничего не придумали. Хотите нового — попробуйте поесть ногами вместо рук, это будет свежо. Инноваций в статье нет. Я понимаю, что хочется защищать свою разработку — в нее вложено много сил. Но мир меняется. И если вам кажется, что вы что-то придумали — это не значит, что до вас это не было сделано (более качественно к тому же).
И если вам кажется, что инновации не нужны — это не значит, что они не работают.
Опять сами героически опровергли выдуманный собой же аргумент. Герой! Но принцесса в другом замке. При этом необходимость инноваций не гарантирует, что они будут работать. Вы бы хоть думали перед ответами, а то я за вас пояснения вношу.
Вы продолжаете говорить про процессы, как будто они волшебным образом решают всё. На практике процессы часто расходятся с реальностью,
Значит вы просто не видели нормальных. Очень жаль. И если вам кажется, что процессы не нужны — это не значит, что они не работают. Тут бы мне еще придумать аргумент про инновации, решающие что-то волшебным образом, а затем опровергнуть, но, пожалуй, откажусь.
и я предлагаю инструмент, который это видно делает. Мой инструмент показывает то, чего не видно в TMS
Не, это мы проходили — не делает вообще ничего реально полезного. Только лишний код, лишние файлы, лишние зависимости.
Напомню пример ваш же выше — поле email "Fill: 8", "Value: 8". Что тут покрыли? Сколько сценариев? Какие позитивные, а какие негативные? Без привязки к кейсам (которая реализована в статье и вроде как в сайпресе) вы собрали статистику, которая не дает объективной картины. Как статистика поля email покрывает кейс с выделением его красным при клике по кнопке входа, если там сложный реакт-компонент с десятком врапперов внутри, часть их которых в shadowroot? Подсказка — никак. И таких реальных кейсов из реального мира (это из того, про который вы говорите, ну тот, который меняется и всё такое). Ваше "покрытие" это фикция, не более. Оно не имеет отношения к покрытию реальному, потому что нет метрик по сценариям
Если вы не видите в этом ценности — отлично. Это просто значит
что в данном случае ее реально нет. Было бы неплохо сначала провести полноценный анализ, погуглить coverage по инструментам, тогда вы бы сделали иначе. Но анализ это часть процессов, тех самых, которые старые, и которые я защищаю по вашей версии.
Но это не значит, что проблемы не существует.
А если человек придумал проблему и ее решил, означает ли это, что проблема существует и для других людей? Кажется, что нет. Но мы смело может забиться встретиться в этой статье через 5 лет и посмотреть, что стало с вашим инструментом. При условии, что вы ничего не будете менять. То есть не добавлять информацию про кейсы, не делать для других языков, не избавляться от лишних файлов и отвратительного подхода с библиотекой, когда приходится писать дополнительную обертку для методов. Также чтобы ни в коем случае не парсили отчет аллюра, который содержит всё нужное в себе. И уж тем более не смотреть в сторону плагина для него. Ведь иначе вы будете использовать старые идеи, которые не инноваторские, а вообще чужие.
И уж точно это не делает ваш комментарий чем-то большим, чем очередной спич в стиле "раньше было лучше". Мир меняется. Инструменты тоже.
Прям в сердечко кольнули! Мой так называемый вами "спич" не был о том, что раньше было лучше. Если бы вы потратили на чтение больше времени, то заметили бы, что упоминание прошлого касалось ваших громких слов про инноваторство и прочего маркетингового bullshit'а.
Не менее смешно про какие-то новые инструменты. Проверим? Плейрайту пять лет, хотя и он не сам по себе появился. Сайпресу больше 7. Селениуму вообще страшно уже сколько. Айфрейму, который вы используете, больше 25 лет. Питону3 больше 15 лет. И самой идее с такими отчетами тоже больше 5 лет — и это только с момента публичной версии. Ну как там с новыми инструментами? Что-то не очень, не правда ли?
P.S. Критиковать легче, чем создавать.
Вам это не помешало проигнорировать вопросы и замечания по существу и заниматься эйджизмом технологий и процессов.
Спасибо, что своим комментарием подчеркнули, что в отрасли по-прежнему нужен новый взгляд на проблему.
Я подчеркивал, что ваша текущая реализация бесполезна для практического применения. И давал конкретные советы по тому, как ее улучшить. Для этого все инструменты есть. А отрасли нужны хорошие специалисты, а не любители смотреть на проблемы и решать выдуманные вещи. P.S.: Только не придумывайте скриншот-тестирование.
Слова громкие, но этой идее уже лет пять: https://habr.com/ru/companies/jugru/articles/491844/. Хотя если так подумать, то любой ваш инструмент будет для вас инновационным, даже если его уже сделали другие люди 20 лет назад.
Сейчас нет ни одного нормального способа понять, что реально покрыто UI-тестами. Но... Теперь есть.
Да всегда это было — TMS. В реальном проекте локаторы с графиками интересны тем, кто их до этого не видел. Через день это станет белым шумом. Ваш "инструмент" добавляет только дополнительный код в проект (как минимум это добавляет накладные расходы и непонятные перспективы). Старая концепция работы через отчет намного лучше и продуманнее, чем ваша идея. Да даже вы сами ссылаетесь на Cypress UI Coverage — там есть связь с тестами.
Ну давайте честно, как сейчас обычно проверяют покрытие UI-тестов?
Никак
Ну это вранье (= Так себе начинать с этого статью на техническом ресурсе.
Можно строить матрицы покрытий, таблицы, рисовать дашборды в TMS. Выглядит красиво. Но по факту — всё устаревает быстрее, чем успевает появиться. И если вы когда-то вручную пытались оценить покрытие UI — вы знаете, как быстро это становится бессмысленным.
Странный аргумент. Но, что самое смешное, он более чем применим к тому, что вы "придумали". Видимо, вы не в курсе, раз пишите такое, но нормальный процесс автоматизации тесткейсов строится так:
Берется ручной тесткейс (который адаптирован для автоматизации, проверен и т.д.)
Автоматизируется (ему проставляется id из TMS для линковки и не только)
Отмечается как автоматизированный в TMS
И на дашборде теперь видно, сколько автоматизировано, а сколько нет. Устареть эта информация может только если вообще перестать вести TMS. Но это вопросы к процессам и там уже совсем другие проблемы в таком случае вырисовываются. Каждый запуск автотестов будет помечать данный тесткейс результатом из прогона. В некоторых TMS даже в режиме реального времени. Просто ноль устаревания, зато максимум смысла.
А вот "Выглядит красиво" — а это скорее про ваши столбики в "Total number of elements" и подобном, пользы от которых как от числа строк кода — вроде бы цифра есть, но применить ее некуда.
Пишем мы, значит, UI-тесты. Запускаем. Они что-то проверяют, что-то кликают, иногда даже баги находят. Но вот вопрос — что именно они проверяют? И насколько качественно?
Открывается отчет, в котором всё должно быть. Если этого нет, то надо налаживать процессы. Уж извините, но это шизофренией отдает, когда вы не доверяете написанным тестам и вместо этого лезете в какой-то отчет, в котором вообще нет ничего про тесткейсы.
А кнопку в настройках юзера, которая в модалке? А то, что при незаполненной форме кнопка неактивна? А если текст обрезался в navbar-ре — кто это заметит?
И, как ни странно, снова информация в TMS, где будет линковка между тесткейсом и автотестом. Если у вас не так, то соболезную, но своим инструментом вы эту проблему не решаете от слова "никак". Более того, если у вас 20 взаимодействий с активной кнопкой при заполненном поле, и 2 при незаполненном, то как вы поймете, что проверка на неактивность при незаполненности должно быть 3? Ну вот просто три кейса должно быть автоматизировано на неактивность. У вас инструмент показывает, что 2. Но вы же не смотрите в TMS, а значит инструмент просто бесполезен для вашего же примера.
Написал тесты. Посмотрел в терминал. Всё зелёное. Ну вроде молодец? А потом открываешь отчёт — и видишь, что по факту проверяется три кнопки и один h1.
Если эти три кнопки и один h1 покрывают бизнес-логику, то молодец. У вас странные примеры. Можно придумать аналогичный, но в обратную сторону — "Покрыты 50 кнопок и все поля ввода! Ну, вроде молодец! А потом открываешь тесткейсы, а там надо было проверять бизнес-логику".
Ревью автотестов без экстрасенсорики
При этом для понимания по вашему отчету, зачем нужен был клик, нужна экстрасенсорика более сильных магов с ТНТ, ведь в отчете кода не будет.
“А какие части UI у нас вообще не покрыты тестами?” — классика. С этим инструментом можно буквально ткнуть в отчёт и сказать:
Не надо говорить, надо смотреть в TMS, где должны быть отмечены уже автоматизированные тесткейсы.
В реальном мире если у вас 20 тестов, которые начинаются с клика одной кнопки, вы получите просто 20 отметок о клике, которые не скажут, что покрыто, а что нет. Видимо, надо уточнить, что покрытие это не увидеть, что по кнопке был сделан клик и проверено состояние. Без контекста в этом нет смысла. Вы почему-то приводите ровно то, что выгодно вам. Совершенно не учитывая, что не всё надо покрывать, что такое покрытие вообще ничего не даст. Что надо отталкиваться не от него, а от тесткейсов и смотреть в них в первую очередь. И что отчет без них не имеет смысла, т.к. визуально трассировка шагов у вас не прослеживается. Также не учитывается, что есть подготовка тестовых данных (или изменение их во время теста) через api, что не будет отображено на UI, то есть элемент может быть вообще не отмечен. Также если у вас есть какая-то отметка, что проверена видимость кнопки, то это не говорит о том, что пропущен кейс на задизейбленность и т.д. То есть без тесткейсов это бесполезно. Но если есть тесткейсы и там есть все эти шаги и проверки, то зачем смотреть визуально? Вы предлагаете от отсутствия проверки на элементе подниматься наверх и смотреть на связанные тесткейсы. Когда должно быть наоборот — из тесткейсов строится покрытие. И если оно было плохое там, то это не сторонний инструмент должен показывать, а ревью тесткейсов (для этого есть разбивка по user story). Но, допустим, что какую-то кнопку не надо вообще покрывать. Проджект так сказал (функционал меняется, или не приоритет). Но вы каждый раз в отчете видите, что она не покрыта и перестаёте понимать свои же придуманные coverage-критерии.
Ты просто открываешь отчёт, показываешь страницу — и видно: есть ли этот селектор; тестировался ли он;
И продакт спрашивает — "а вот эта user story покрыта?", и ты такой "Ну, эээ... вроде да, по моему отчету этого нет, только селектор". И вот ключевая проблема (помимо того, что не будут смотреть отчет, это на уровне скриншотов и видео всех запусков) — отметки о кликах и проверках бесполезны без привязки к тестам. И в статье, на которую я ссылаюсь в самом начале, все это было сделано. Да, пять лет назад. Так что увы, сегодня без инноваций.
Вот этим статья больше похожа на маркетинговый bullshit:
Инновационный инструмент для визуализации UI-покрытия, который на момент написания этой статьи ... Это реально киллер-фича ... Вот он — контроль эволюции качества ... Это такой уровень прозрачности, которого раньше не было ни в одном UI-репорте ... это настоящий прорыв в области UI-автоматизации ... меняет подход к тестированию.
и прочие восторженные фразы для продажи, но не для реального дела.
В целом почти все аргументы статьи строятся на том, что процессы автоматизации, да и тестирования, отсутствуют напрочь, но их каким-то чудом должен закрыть отчет. Хотя по приведенным примерам решаются искусственно выдуманные проблемы.
С другой стороны если вы изучите старое решение, посмотрите, как оно реализовано, добавите в своё (уберете из своего отчеты, они вообще не нужны), то в этом уже появится некоторый смысл.
1 строчка сценария без десяти строк логики. Остальное собирает структура проекта.
Ну как без десяти строк? Они у вас просто внутри. Аналогично с моим примером — этот код завернуть в какой-то шаблонный элемент и будет один и тот же код вызываться из разных мест: UsersTable.assertEmail(”jane”, “doe@jane.doe.com”), CustomersTable.assertEmail(”jane2”, “doe2@jane.doe.com”). Можно тоже сказать, что это одна строчка, а остальное собирает структура проекта.
А в отчёте увидим примерно следующее:
Проверяем, что значение [email] пользователя [jane.doe] соответствует "jane.doe@example.com"
На мой взгляд, это очень даже не плохое описание, особенно если учесть, что я вообще ничего для этого не написал.
Только вот люди так тесткейсы не пишут. На строчку тесткейса “Залогиниться под покупателем” у вас будет 10 строк такого роботизированного описания, которое мануальщику читать больно, и в результате вместо общей работы над качеством продукта получаем, что каждый работает для себя. И вот чтобы стало удобно, вам придется все эти формализованные шаги обернуть в step(”Залогиниться под покупателем”, ()→{…}), чтобы на верхнем уровне было описание действия, а на нижнем служебная информация.
Плюс я могу изменить параметр в конфигурации и сразу получить этоже на английском.
А зачем? Ну то есть какой смысл в смене языка? Тесткейсы пишутся на одном языке, так зачем в коде возможность его переключения? Для логов английский, его переключать не надо, для тесткейсов тот, на котором они написаны. Но даже если и надо, то не составит труда в код выше добавить switch/if на все варианты с Language, который будет реагировать на конфиг.
ListWC действительно отчасти является wrapper. Его главная цель привнести строгую типизацию…Типизация заставляет создавать чёткую структуру, взамен даёт кучу контроля которая в итоге и даёт 1 строчку кода вместо 10ти.
Это на самом деле странный и противоречивый аргумент. Типизация это хорошо. Но она не дает контроль, который приведет к сокращению строк. Ваша 1 строчка добавляет кучу аннотаций, АОП, какие-то дополнительные телодвижение, подменяет реализацию Selenide (а скришот делается там, где вы ассерты заменили? а умные ожидания ваши тоже задаются точечно?). Не очень понимаю, в чем проблема с фильтрами в коллекциях. Не помню, чтобы stream api стал нерукопожатным. Инкапсуляция же решает все проблемы. И не понимаю, чем ListWC объективно лучше любого другого класса, который будет принимать внутрь себя ElementsCollection и таким образом тоже приносить строгую типизацию.
В общем, проще написать кодом
class Table {
private final String tableName;
private final SelenideElement tableLocator;
public Table(String tableName, SelenideElement tableLocator) {
this.tableName = tableName;
this.tableLocator = tableLocator;
}
public TableRow getRowByName(String rowName) {
SelenideElement rowElement = tableLocator.$$(".elements-list")
.filter(Condition.text(rowName)).first();
return new TableRow(tableName, rowName, rowElement);
}
}
class TableRow {
private final String tableName;
private final String rowName;
private final SelenideElement rowElement;
public TableRow(String tableName, String rowName, SelenideElement rowElement) {
this.tableName = tableName;
this.rowName = rowName;
this.rowElement = rowElement;
}
@Step
public TableRow assertFieldValue(String fieldName, String expectedValue) {
Allure.getLifecycle().updateStep(stepResult ->
stepResult.setName("Таблица (%s), строка (%s), поле (%s), ожидаем (%s)"
.formatted(tableName, rowName, fieldName, expectedValue)));
rowElement
.$(".%s".formatted(fieldName))
.shouldHave(Condition.text(expectedValue));
return this;
}
}
Два класса, в которых поправить локаторы и они будут универсальны для любых таблиц. При этом здесь всё на виду — понятно, как расширять и как пользоваться.
И тест будет примерно как у вас, разве что промежуточных методов меньше, но это +пара классов такой же (никакой) сложности:
new Table("Список покупателей", Selenide.$(".table"))
.getRowByName("Dmitriy")
.assertFieldValue("Email", "dima9000@dima.com")
.assertFieldValue("Name", "Dima");
//B отчете будет:
//Таблица (Список покупателей), строка (Dmitriy), поле (Email), ожидаем ([dima9000@dima.com](<mailto:dima9000@dima.com>))
//Таблица (Список покупателей), строка (Dmitriy), поле (Name), ожидаем (Dima)
Выглядит так себе на самом деле, особенно, когда проверок больше. Но вот вариант с софт ассертом из junit5 (хотя это плохо и в целом проблема тесткейса, который надо переписать):
step("Проверить данные покупателя: Email, Name, Age", () -> {
TableRow rowByName = new Table("Список покупателей", Selenide.$(".table"))
.getRowByName("Dmitriy");
assertAll(
() -> rowByName.assertFieldValue("Email", "dima9000@dima.com"),
() -> rowByName.assertFieldValue("Name", "Dima"));
});
//B отчете будет
//Проверить данные покупателя: Email, Name
// Таблица (Список покупателей), строка (Dmitriy), поле (Email), ожидаем (dima9000@dima.com)
// Таблица (Список покупателей), строка (Dmitriy), поле (Name), ожидаем (Dima)
Все решилось стандартными средствами.
Не вижу способа как это избавит от написания логики типа "assertEmail(String userId, String expectedEmail)" и даст мультиязычность.
Код выше отвечает на это. Ну и кодом .email().assertText() вы не избавились от логики типа assertEmail(String userId, String expectedEmail), вы просто завернули это в другой класс или метод. Код класса TableRow можно аналогично завернуть в метод email()/name()/age()/address(), чтобы не писать каждый раз в assertFieldValue в явном виде "Email". Просто будет кучка методов, делающих return new TableRow(tableName, Имя/Фамилия/Адрес/Возраст, rowElement). Это ровным счетом ничего не меняет. Про мультиязычность аргумент не могу принять, я ни разу не видел, чтобы она хоть где-то встречалась, то есть чтобы внутреннее описание нужно было на двух языках. А шаги из тесткейсов у вас в любом случае должны быть на том же языке.
К тому-же цель была доработать selenide, а не отказаться от него
Так делайте PR. Просто ваш код не дорабатывает Selenide, а местами даже от него отказывается без реального профита. Те же ассерты левые зачем-то. И ловите зачем-то StaleElementReferenceException, перезагружаете коллекции, хотя все это давно решено.
Когда работаешь с кучей таблиц soft assert(ами) в части случаев пользоваться придётся.
Тут два момента. Первый — в селениде можно делать кастомные проверки, которые вполне справятся с этой задачей. Второй — как только начинают говорить про софт-ассерты из-за каких-то проверок, то это индикатор плохого тест-дизайна. Это как делать велосипед с квадратными колесами, а потом говорить, что садиться больно.
И ни разу я не видел такого чёткого процесса. Тот кто платит зарплату - тот заказывает и музыку.
Так вы QA или кто? Тот, кто платит зарплату, не знает ни про тестирование, ни про разработку. Он нанимает специалиста. И QA, как специалист, просто обязан улучшать процессы, до которых может дотянуться. Если ваше видение с компанией в этом плане расходится, то зачем работать через силу? Более того, когда компания захочет переходить с вашего подхода на 1 в 1 соответствие тесткейсам, ей потребуется человек, который сможет понять, что вы написали, что уже непросто из-за АОП (которое там не нужно), который будет это править, переписывать абсолютно все ваши автотесты, потому что их и руками пройти сложно. Такой подход делает максимально дорого по всем параметрам. И сравните с моим кодом — он занял минут 10, но легко расширяем, легок в использовании, не требует дополнительных знаний вообще. При этом он дает ту же самую типизацию.
В прошлый раз еще за это глаз зацепился. Такое в коде тестов — плохо. Вы же тащите наружу в тест методы, которые должны быть спрятаны. Что еще раз говорит о том, что ваши описания шагов — низкоуровневые и должны быть обернуты описаниями из тесткейсов. “The basic rule of thumb for a page object is that it should allow a software client to do anything and see anything that a human can.” — Мартин Фаулер про Page Object.
И давайте в финале сравним ваш код и мой вариант, как это у вас в документации с Selenide. Так будет честнее. А то везде сравнение абстракций разного уровня, что неспортивно.
Ваш вариант с убранными методами, которых у меня нет:
@PageObject
@Getter
@Accessors(fluent = true)
public class DynamicEmployeesListPage extends Page {
@Name("Employees")
@ListLocator(css = "#employeeTableBody tr")
protected ListWC<EmployeeRecord> employees = new ListWC<>();
@Widget
@Getter
@Accessors(fluent = true)
public static class EmployeeRecord extends AbstractWidget {
@Name("First name")
@LocatorChain(xpath = "td[1]")
protected Value firstName;
@Name("Age")
@LocatorChain(xpath = "td[3]")
protected Value age;
@Name("Email")
@LocatorChain(xpath = "td[4]")
protected Value email;
public EmployeeRecord(SelenideElement rootElement) {
super(rootElement);
}
@Override
public String getId() {
return email.text();
}
}
}
А вот мой:
class TablePage {
public Table employeeTable() {
return new Table("Список покупателей", Selenide.$(".table"));
}
}
class TableTest {
@Test
void test() {
new TablePage().employeeTable()
.getRowByName("Dmitriy")
.assertEmail("dima9000@dima.com")
.assertFirstName("Dima")
.assertAge("50");
}
}
//в класс TableRow было добавлено три метода
public TableRow assertAge(String expectedAge) {
return assertFieldValue("Age", expectedAge);
}
public TableRow assertEmail(String expectedEmail) {
return assertFieldValue("Email", expectedEmail);
}
public TableRow assertFirstName(String expectedFirstName) {
return assertFieldValue("First name", expectedFirstName);
}
Только вот вы сравниваете и не показываете внутреннюю реализацию, а у меня даже с ней код короче и понятнее даже с учетом того, что это низкоуровневые шаги, а не действия пользователя. И можно сделать абстрактным класс Table и закидывать уже в его наследников любое количество и комбинации TableRow (который тоже можно сделать абстрактным и тоже что угодно творить внутри, например, кнопки добавить).
Конечно, можно сказать, что любой сценарий состоит из последовательности простых действий. Может, в идеальном мире, так и было бы, но если попробовать написать тест для CRM, содержащей десятки таблиц, множество виджетов в каждой записи, сложные фильтрации, поисковые запросы, загрузки, импорты данных, динамические события и прочее – итоговый тест может состоять из 50–60 строк, где каждая строка является достаточно сложным шагом. После этого, взглянув на автогенерированный отчёт, спорить о его "легкочитаемости" будет крайне сложно.
Для начала стоит вспомнить, что перед тем, как что-то автоматизировать, нужно взять тесткейс. И если в нем будет 50-60 строк, то и в автотесте должно быть столько же — сценарий для автотеста не должен кардинально отличаться от мануального. И если в ручном “каждая строка является достаточно сложным шагом”, то надо начать с пересмотра ручных тесткейсов. Что-то мне подсказывает, что даже если в ручном будут все эти 60 шагов, то они с большой долей вероятности должны быть с вложенными. Например
Заполнить таблицу
Заполнить имя
Заполнить фамилию
И в автотесте тоже должна будет отразиться такая же вложенность. И тогда всё свернется раз в 10. И в эти вложенные шаги никто не будет заглядывать до тех пор, пока там не будет падения.
то придётся писать обёртку:
Всё, что у вас представлено — обертки над селенидом и аллюром. Вы переизобрели Page Objects с типизацией, которым более десяти лет назад уже реализовали, привет Html elements, Atlas, JDI.
Все действия в отчёте будут выглядеть одинаково.
Хм. Ну если писать как вы предлагаете, то да. Но в джаве мы умеет пробрасывать параметры. И через жизненный цикл аллюра можно делать параметризацию для названия шага (а не только дергать startStep и stopStep). И тогда получится ровно, что у вас на скринах, только минимальными усилиями.
Что если нам нужно сделать проверку каждого в отдельности из 30 параметров и для каждого создать отдельный метод с описанием? То есть:
Людям дали Selenide, но они упорно тащили ассерты в стиле селениума. element.text() и затем Assertions.assertThat показывает, что вы или не умеете пользоваться Selenide, или не хотите.
И делать так для остальных 29 параметров? Конечно, нет.
Или вы запутались в своих аргументах, или что-то еще случилось. Вы же передаете имя пользователя, по которому делается фильтр. Написанный метод уже является достаточно универсальный. Нужно красивое описание в отчете? Пишите тогда так:
А если надо еще и название таблицы в строку шага, так прокидывайте ее через конструктор. И такой вариант более гибкий, чем указывать все в Step над методом.
Ну а если вам не нравятся дополнительные логгируемые шаги Selenide, то для этого есть настройка: new AllureSelenide().includeSelenideSteps(false);
Или же если вам не нужны параметры в шагах, то и их тоже можно удалять. Allure дает широкие возможности для кастомизации.
… сравнивая все параметры посредством Soft Assert. Да, это здоровое решение, но всё равно придётся писать логику, а о красивом автологируемом отчёте можно забыть.
Не, с софт-ассертом очень больное решение. А автологируемый отчет берите выше. И для его реализации не нужно ничего городить дополнительно (кроме оберток поверх инпутов/кнопок/прочего специфичного для каждого UI-проекта).
Если в Selenide для работы со списками используется класс ElementsCollection, то в Allurium для этой цели применяется класс ListWC
При этом класс ListWC использует внутри ElementsCollection, вы просто сделали обертку со своими методами и своей логикой, которая ничего нового не принесла.
Глянул еще внутрь ListWC. Кажется, вы просто принципиально отказываетесь от Selenide, но городите свои костыли, чтобы что? Как я понял, чтобы только вам было понятно и удобно. Но вот только чтобы писать в вашем стиле, нужно потратить немало времени. То есть для перехода от Selenium к Selenide нужно меньше времени, чем для перехода от Selenide к Alluruim. При этом примеры отчетов, которые я вижу, вообще не похожи на реальные кейсы.
Не будет в тесткейсе мануальщик писать "Ввести [Сова] в инпут текстового поля списка полей ввода". Или "Проверить, что значение инпута текстового поля [Login] равно [john]". И руками этот кейс потом тоже проходить больно с таким описанием.
А так последний скрин прекрасно создается кодом, который я показал выше. Без АОП, без дополнительных фреймворков, без ломбока, без Name, без Locator (кстати, не заметил примеров работы с динамическими локаторами) — только на Allure+Selenide.
Так что в качестве личного петпроекта только для одного изолированного автоматизатора, чьи отчеты смотрит только он сам, это прикольно, но для работы в qa-отделе тут пилить и пилить (и получить обратно Selenide с Allure).
Я вам вчера посоветовал всё закинуть в LLM, чтобы она вам пояснила. Вы это сделали? Там еще был совет почитать книгу, но ее надо все же сначала а купить, а LLM доступны сразу.
Вы снова наступаете на одни и те же грабли. Вот часть ваших заблуждений только из этого сообщения (которые и объясняют провал внедрения):
Вчера уже сколько раз я делал акцент, что речь про исчерпывающую документацию, но вы этого в упор не замечаете и не понимаете, о чем речь, хотя разжёвано по несколько раз. Последняя попытка, может на английском понятнее:
Working software over comprehensive documentation.Далее цитаты:
Вы просто не понимаете, что такое Agile. И, что более показательно, не хотите его понять, при том, что вам разные люди в комментариях пишут одинаковые вещи.
Вы просто каждом новым комментариям оказываете медвежью услугу Тензору. После такой "презентации" внедрения процессов желающих идти к вам станет меньше. Никто не хочет работать в карго-культе, особенно, когда ответственные или приближенные к ним люди не слышат ничего, кроме своего личного мнения.
Автор статьи исходит из ложной предпосылки, что в Agile документацией можно пренебречь. Равно как и то, что Agile дает скорость — это классические заблуждения. Из-за чего ожидаемо вытекает немало проблем. Он приходит к выводу, что
и "находит" решение
И тут две фундаментальные ошибки — сначала с потерянным артефактом, затем с призванием DF.
Сам подход с документацией не нов, раньше он назывался RDD (Readme Driven Development) и другими именами. Но его появление в команде, работающей якобы по Agile, это не что-то новое, а сигнал, что Agile был внедрен как карго-культ, без понимания сути.
Зрелая команда с развитой инженерной культурой не нуждается в том, что ей "внедряли" DF. Для нее предварительный анализ, проектирование и написание необходимой документации — это не отдельный подход, а здравый смысл, часть процесса разработки ПО, без которого не написать качественный код. А весь Agile именно про то, что нужно писать хорошо, нужно писать тесты, нужно заниматься парным программированием. Всё это создает циклы ревью и улучшений итогового продукта.
Поэтому, отвечая на вопрос — противоречия между Agile и DF/RDD нет.
Это не взаимоисключающие вещи. Agile это фреймворк, DF это инженерная практика, которая естественным образом уже есть внутри этого фреймворка (опять же, в зрелых командах, которые понимают, что они делают).
Проблема, которая возникла в статье, возникла не потому, что Agile и DF/RDD не совместимы, а потому, что команда автора изначально выкинули из своего процесса базовую инженерную практику, а потом героически ее вернула под новым названием, свалив при этом вину на Agile.
Отвечу на оба комментария здесь. Ваша позиция предельно ясна, но она основывается на ряде фундаментальных заблуждений, которые вы последовательно повторяете.
Инструменты коммуникации в Agile — дейли, демо, груминг, ретро и прочие ритуалы, если команда считает их необходимыми. Также он призывает к постоянному взаимодействию с заказчиками. Если в рамках этих инструментов команда не может прийти к общему пониманию и зафиксировать результат, то это не проблема инструмента, а неумение им пользоваться.
Ссылаться снова на "неидеальный мир" выглядит как попытка снять с себя ответственность за выстраивание процесса.
Это фундаментальное непонимание инструментов, процессов, результатов и что из них когда работает.
Нет, это ваша задача. И это ваша же проблема, что у вас такой подход. Вы не владеете инструментами коммуникации и не понимаете, какие артефакты должны быть на выходе. В чем, собственно, и признаетесь, хотя не понимаете этого.
Вы снова описываете проблему, который зрелый Agile решает по определению.
И снова вы не понимаете, как пользоваться коммуникацией. Для вас это, видимо, общение без фиксации. А в Agile это работает совсем не так. В реальном мире, кстати, тоже. Для совсем ленивых уже нейронки составляют саммари беседы. Если вы не можете ограничить скоуп проблем на митингах и зафиксировать договоренности и результаты, то при чем тут Agile? Я сейчас описываю какие-то банальные и очевидные вещи, которые делались еще лет 10 назад минимум и каждый участник процесса понимал важность этого. При этом это было вне зависимости от методологии, потому что это здравый смысл, но у вас в сообщении он вырезан.
В манифесте написано:
Работающий продукт важнееисчерпывающейдокументации. Не "полной", не "хорошей", а "исчерпывающей" — это против бюрократии и документа ради документа, а не против необходимой документации. И не "лучше", а "важнее" — это о приоритетах, а не о замене. И эта ценность не является разрешение на создание технического долга и отказа от необходимости документировать.Также в Agile нет ничего про скорость. Ни в ценностях, ни в принципах. Agile не говорит, что ПО будет разрабатываться быстрее, он не дает таких гарантий и обязательств. Более того, по гибким методологиям релиз полного продукта скорее всего будет позже, чем по каскадной модели. Но за счет ранних поставок и гибкости выпущенная часть функционала может помочь бизнесу закрывать свои цели, а не ждать полного релиза.
А это просто непонимание, что делать хорошо сразу будет намного дешевле, чем переделывать потом.
Это прекрасно. Вы, видимо, серьезно считаете, что DF настолько уникален, что никто не додумался сначала проработать документацию, а потом писать код? Я расстрою, но в реальном мире в зрелых командах, работающих по Agile (и не только), так делают с самого начала и никто не говорит про DF. Это просто здравый смысл, чтобы самим потом было легче работать — не заказчику с кодом работать, не ему его тестировать.
В моем сообщении нет "подгонки", есть лишь правильное прочтение манифеста. Вы читаете его как разрешение на отказ от документации. А моя трактовка выше. Но, что показательно, вы упорно раз за разом неверно понимаете эту ценность.
И пропишу явно уже сотый раз — написание документации не противоречит Agile.
Ага, особенно про документацию. Видите ли, все ценности и принципы работают вместе. Если вы от них отходите, что гибкие методологии позволяют, это уже будет какая-то отдельная интерпретация.
В данном случае из всего написанного вами четко прослеживается проблема коммуникаций. Про это написал не только я. Может пора уже задуматься?
Я вам пишу про одно, а вы интерпретируете как вам удобно. О чем это снова говорит? О проблемах с коммуникацией. И как иллюстрация непонимания — вы пишите про какие-то 8 часов, считая, видимо, что всё это время должно быть общение с заказчиком. И снова вопрос возникает — как с такими знаниями можно было пытаться что-то внедрить? Вы же ни одной ценности и принципа нормально донести не сможете. Сейчас вот вы нашли DF. Через год что-то еще. Но первопричины так и остались.
И вот пример чудовищного непонимания.
И вот тоже упорное непонимания важности документации. Из раза в раз вы считаете, что можно без нее, как и в описанной истории. Но нет, нельзя без нее. И команда, которая попала в ту ситуацию, если бы работала по Agile с полным его пониманием, в ней бы не оказалась, а так виновата только команда, а не методология.
Вы просто не понимаете, что такое "бизнес-ценность". И снова у вас демо это как повод отчитаться перед заказчиком. Демо это не "любая" итерация. Это один из ритуалов для обратной связи и синхронизации. На демо, еще раз повторюсь, должен показываться готовый к релизу функционал, а не "мы сделали зеленую кнопку, не увольняйте".
А то, что вы пишите — неумение декомпозировать, чтобы на выходе получить небольшой, но функциональный для бизнеса продукт или его часть. В зрелых командах есть специалисты, которым это под силу такое разбиение. И снова забываете, что Agile — про гибкость, но устраиваете какую-то обязаловку по результатам, напрочь упуская все преимущества этой методологии.
Ваш взгляд — разработка это конвейер. Agile-взгляд — разработка это непредсказуемый процесс R&D.
А то, что вы пишите, не имеет отношения к Agile. У нас нет разницы в восприятии — у вас просто нет знаний в этой области, хотя вы упорно пытаетесь доказать обратное, демонстрируя каждый раз еще большие пробелы и методологическую пропасть.
И снова все мимо Agile. Если вы спорите без результата, то вы неправильно наладили процесс коммуникации, т.к. в команде нет понимания, что она должна сделать. Если вы постоянно вовлекаете заказчика, значит вы снова не смогли наладить процесс коммуникации между ним и командой. Если у вас нет результата коммуникации, то вы снова не поняли, как пользоваться этим инструментом.
Абсолютно каждое предложение является примером непонимания гибких методологий и уже в который раз подсвечивается одна и та же проблема.
То, что вы считаете недостатком, является преимуществом и сутью Agile — доверием к профессионализму и самоорганизации команды. Фреймворк дает свободу. Если команда не знает, что с ней делать и "ищет маму", которая даст четкие регламенты, то это не проблема фреймворка. Это проблема зрелости и компетенции команды. Напомню принцип:
Над проектомдолжны работать мотивированные профессионалы. Чтобы работа была сделана,создайте условия, обеспечьте поддержку и полностью доверьтесь им.Это опасное и неверное утверждение. В Agile есть все инструменты — ретро, беклог, практики из экстремального программирования, беклог продукта, DoD. Зрелая команда и владелец продукта понимают, что игнорирование техдолга сегодня приведет к прекращению поставки ценности завтра. И они выделяют на это время в спринтах.
И снова мимо. Более того, этап технического проектирования можно спокойно записать в DoD. А то, как вы описываете DF — закрывает ваши пробелы инженерной дисциплины и самоорганизации. И да, ваша попытка внедрить DF выглядит именно как первый попавшийся велосипед, как вам справедливо написали.
Мне не "не нравится DF". Мне не нравится, что вы его позиционируете как внешнее средство для проблем Agile. При этом вы не понимаете, что эти проблемы сами же и создали. Практика нормального подхода к документации есть изначально в Agile при работе зрелой команды. А у вас же провалено внедрение Agile, потому что вы не поняли, как его применять и зачем, но увидели одну точечную проблему и нашли для нее точечный инструмент. Перефразирую — для меня очевидно, что документация является частью процесса разработки в Agile. Для вас это наоборот.
У вас одна роль хочет быстро, а другая хочет качественно, а третья домой пораньше пойти. Что это? Это именно проблема коммуникации, потому что у каждого своя цель, а не одна общая. Вы еще спорите зачем-то. Чтобы вы понимали, как выглядят ваши слова — "у нас нет проблем в общении, просто мы не общаемся".
Это преимущество гибких методологий, которое описано в принципах. С другой стороны получается, что вы, зная такую особенность, и что она вам не подходит, все равно внедряли. Очень умно! Чем больше пишите, тем хуже выставляете себя и компанию.
Я не работаю у вас и могу называть вещи своими именами, а не выставлять в удобном свете провал внедрения методологии, а потом упорно всем пытаться показать в комментариях, что Agile не торт.
Суть в том, что те цитаты являют собой замкнутый круг причины и следствия. И то, что вы отделяете одно от другого, очень грустно. Зрелая команда может сказать "нет" плохим решениям. А вы пытаетесь показать, что это неизбежно.
Это не "неудобный" для Agile пример. Это идеальный пример того, как не надо делать Agile. Если команда за полтора года, а это примерно 36 двухнедельных спринтов, работала над продуктом и только на последних этапах получила обратную связь от заказчика, что видение было ошибочным, значит в процессе не было ни одной реальной итерации с поставкой ценности и получением обратной связи. Просто что-то делали по водопаду с двухнедельными отрезками. Отличный пример карго-культа.
А давайте посмотрим на факты, которые вы сами изложили?
Вы не писали прямо "мы забили на документацию", хотя во всех ответах ниже про ценности вы именно на это очень жирно намекаете.
Но вот цитаты, которые показывают ваше отношение к документации:
Проблема: Разработчики понимали свою конкретную задачу, но общего контекста не осознавали.
Причина: То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
Признание: в начале проекта мы жалели времени на детальное продумывание задачи
Осознание: нам не избежать разработки документации
Личный опыт: прошел все пять стадий принятия того, что свои задачи я должен также документировать, пусть и в виде промежуточных документов.
Последствия игнорирования: Первый результат: пока не понимаем необходимый объем документации, который нужно делать при таком подходе.
Вывод: Документация — это потерянный артефакт в мире гибких методологий.
Проблемы коммуникации:
Разработчики понимали свою конкретную задачу, но общего контекста не осознавали
То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
и потом получали "волейбол": разработчики отдавали задачи тестировщикам, те возвращали им обратно… и так снова и снова, долго и мучительно
Они исходят не от заказчика, который о них может не помнить или банально не знать, а от реализации
Проблемы дисциплины:
в начале проекта мы жалели времени на детальное продумывание задачи
мы постоянно всё переделывали
Фича создаст поток ошибок и правок, которые надо "дожать" в короткие сроки
чем более "гибким" становился подход, тем сильнее проявлялись узкие места.
мы постоянно всё переделывали
Начинаются доброски "в последний вагон" перед релизом
Мы планируем итерацию, а не пытаемся решить всю задачу, следовательно, пренебрегаем анализом дополнительных требований к ней
Но эти примеры — ерунда по сравнению с тем, что вы сами писали в комментариях.
И еще раз — инструментов достаточно. Просто для этого надо понимать, что такое Agile, чего в данном конкретном случае не было вообще.
И опять вы упорно не хотите понять, что демо — это не для контроля. Как и упорно игнорируете факт, что с заказчиком должно быть общение. Чисто логически — при регулярном общении с заказчиков нет смысла в контроле в виде демо, потому что он и так в курсе в любой день. Более того, заказчику могут дать доступ к тестовому стенду, где он может сам смотреть, как меняется продукт буквально в любой момент времени и тут же давать обратную связь — это отлично работает в рамках Agile в реальном мире. Но так как вы не знаете, что такое Agile, то для вас это элементы контроля. С таким подходом, где команда может организоваться и работать сама, ваше понимание расходится полностью.
Нет, материал о том, как команда, провалив внедрение Agile из-за непонимания его ценностей и отсутствия инженерной дисциплины, вернулась к привычной директивной модели, выставив гибкую методологию крайней.
И сейчас, вместо того, чтобы писать ответ, лучше ознакомьтесь с книгой Боба Мартина. Она читается за вечер. Объективно — ничего нового вы уже не напишете, лучше своими комментариями не сделаете. Так посвятите время самообразованию и вдумчиво ознакомьтесь с книгой "Чистый Agile".
В крайнем случае закиньте статью и все переписки в LLM, она вам пояснит.
Если бы написали про попытку внедрения Agile, про то, как сами ее провалили и почему, и как в итоге пришли к выводу, что вам больше подходит DF, хотя это не методология и вообще непонятно, что у вас в итоге сейчас, то такая статья была бы намного лучше, честнее, интереснее, но увы, имеем что имеем.
Вы не упростили. Вы не поняли ни тогда, ни сейчас. И подменили понятие "исчерпывающий" на "хороший". И вместо того, чтобы это признать, вы пытаетесь зачем-то оправдаться, делая только хуже.
Эти слова тоже не имеют отношения к Agile. Потому что именно Agile призывает непрерывно работать вместе с заказчиком и делать именно хорошо, потому что переделывать будет намного дороже. И еще раз процитирую принцип:
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Еще скажите, что здесь явно не указано "делать хорошо", значит так делать не надо.Уже в который раз написанное вами противоречит Agile. Это невероятно показательно.
Предположу, что этот вопрос мне.
Не могу сказать, что прям хорошо владею темой — все же здесь обсуждались самые поверхностные вещи. Для лучшего понимания в своё время прочитал "Чистый Agile" от Боба Мартина, "Пользовательские Истории" от Майка Кона, "Agile-тестирование" от Лайзы Криспин и Джанет Грегори. Также знакомился с какой-то версией PMBOK, и, насколько знаю, последние редакции смещались в сторону гибких методологий. Еще было много статей, что-то у Кента Бека читал, статьи Мартина Фаулера, но точно уже не вспомню. В целом можно просто открыть список авторов Agile и искать их статьи/книги.
Много опыта дала работа по Agile, где он хорошо внедрен и там, где внедрен очень плохо — на контрасте сразу видно, что не так и как должно было бы быть.
Вижу, что сообщение вы отредактировали. Хотя ничего нового я не увидел.
DoR, груминг. Это гибче, чем DF. И ваш DF это по сути DoR, который вы зачем-то противопоставили Agile.
И снова проблема в коммуникации. Я надеюсь, вы понимаете, что она слишком часто повторяется что в статье, что в ответе, что в дополненном ответе? Что это не случайность, а систематическая проблема.
Эм. Там ноль проблем, если понять, что вы используете гибкую методологию, а не набор жестких регламентов. Вы сами определяете, какая глубина анализа нужна под конкретно ваш продукт. И это очевидно из всей философии Agile.
Так если вам и этот принцип не подходит, зачем тогда тащили себе Agile? Вам нужны директивы, но Agile не про это. Но вот конкретно в этом предложении вы не понимаете, что "работа вместе" это процесс, в ходе которого создаются артефакты: пользовательские истории, критерии приемки, документация, схемы и т.д. Agile не говорит "ни в коем случае ничего не фиксируйте!". Он говорит о фиксации результатов совместной работы, хотя и в явном виде это не указано. Ваше непонимание этого базового различие между процессом и результатом показательно.
Проблема не в том, что вы сделали, а как. Белое пятно не в Agile, а в вашей его реализации. Agile это фреймворк, он дает свободу действий и инструменты для корректирования и выстраивания процессов. Но и отвечаете за эти вещи вы сами. С DF вы просто начали делать ту часть работы, которую Agile изначально перекладывал на вас. То, что вам для этого потребовались явные указания, а не здравая логика и корректная интерпретация манифеста — не вина Agile, а проблемы ваших процессов.
Думаю, тут комментарии излишни.
В методологии нет проблем. Она как была в вашей конкретной реализации, так и осталась. Все ответы кричат о тотальном непонимании принципов, ценностей, ритуалов — это видно и по вашим остальным комментариям здесь. Agile требует зрелости, дисциплины, коммуникаций. Если этого нет, и никто в этом не заинтересован, то внедрить гибкую методологию не получится. Что у вас и произошло. Вы буквально повторили все классические ошибки, начиная с отказа от документации и заканчивая слепым следованием ритуалов без понимания их смысла. И на фоне этого возвращение к директивной модели с DF для вас выглядело как решением.
Вы намеренно игнорируете цитаты из манифеста, которые я вам указал?
Работающий продукт важнее
исчерпывающейдокументацииА у вас почему-то документация стала хорошей. Вы просто не поняли, что написано и сделали свою интерпретацию, которая расходится с Agile. И если что, Agile не говорит "делайте плохо". Он наоборот призывает делать хорошо, потому что переделывать потом будет дороже.
Весь ваш комментарий подчеркивает, что вы снова ставите во главу угла не коммуникации между людьми, а какой-то подход. Точно такая же ситуация была в самой статье. Вы последовательно подменяете принципы живой коммуникации формальными процессами. И возникает риторический вопрос — не постигнет ли DF такая же участь?
Вы не первая и не последняя компания, работающая с легаси. В мире накоплен огромный инженерный опыт решения именно таких проблем с помощью гибких подходов (LeSS, Lean, etc.). Фразы про "большую систему" или про "реальный" мир в 2025 выглядят не как реальные трудности, а как менеджерский провал, который разгребает команда.
И снова вы пишете, что у вас проблемы с коммуникацией, которые вы не решаете. Даже не так — вы считаете, что решили их через внедрение DF. Но под коммуникацией (я рассмотрю Agile) подразумевается общение между заказчиком, аналитиком, дизайнером, разработчиком, тестировщиком, менеджером. Если все эти люди вовлечены в процесс обсуждения полученной документации, то снимаю шляпу. Но что-то мне подсказывает, что это даже близко не так.
Переложили ответственность на разработчиков. И, кстати, здесь тоже вы пишите про проблемы с коммуникацией. Пока нет документации, нет понимания у каждого участника процесса, должно быть написано 0 строчек кода. И это не только не противоречит Agile, но и прекрасно ложится на описанные принципы.
А это еще раз говорит и о проблемах с коммуникацией (и непониманием, что это концептуально такое) и непониманием Agile, хотя я специально привел принципы, в которых нет ничего сложного или противоречивого. Кратко: DF это не один из способ общения, не натягивайте сову на глобус.
Я раскрою страшную тайну. DF это просто нормальный процесс проектирования с артефактами в виде документации. И в целом сам подход можно описать как "семь раз отмерь, один отрежь". Ну или "сначала думаем, потом делаем". Это было задолго до прошлого века. Как и подходы, сформулированные в Agile манифесте, использовались задолго до его создания. Более того, любая небольшая команда (а не набор разношерстных специалистов, запертых в одном помещении) придет примерно к тем же выводам, которые есть в Agile, будучи с ним незнакомыми.
Не соглашаться вы можете с чем угодно. Это ваше личное мнение и право. Однако, есть пропасть между обоснованным личным мнением и тотальным непониманием какой-то концепции. Вот здесь мы имеем второй случай, и, что примечательно, при всех цитатах вы продолжаете доказывать свою точку зрения, хотя могли бы разобраться в предмете дискуссии. Конкретно по этому абзацу — для вас демо это формальный акт приемки заказчиком. Для Agile это то, что я описал — момент синхронизации для всех участников процесса, на котором показываемый функционал не должен быть сюрпризом для заказчика, потому что коммуникация должна быть постоянной. Вы же этого так и не поняли. Демо это не пилить что-то срочно две недели, чтобы потом показать, это готовый результат (инкремент) итеративного процесса разработки с полным вовлечением заказчика. Игра слов это вот выше про "DF как один из способов общения", а процесс с демо является следствием из принципов Agile. Там прям написано: разработчики и представители бизнеса должны ежедневно работать вместе. Не можете этому следовать? Agile не для вас, не надо его насильно впихивать. "И да, DF позволяет синхронизироваться" — кхм, весь Agile про общение, но чтобы понять важность коммуникации, понадобился DF? И снова — тут тоже про проблему коммуникации.
Удобная позиция, но не сработает. Проблема в том, что для внедрения чего-либо, нужно сначала очень хорошо провести анализ. Но с Agile почему-то другая ситуация, его бегут внедрять, потому что другие же тоже бегут. Хотя с учетом постоянного упоминания Брукса складывается ощущение, что новые подходы внедряются по мере прочитанных книг. И прежде чем ссылаться в 10 раз на одного и того же автора, стоило бы ознакомиться с книгой "Чистый Agile" от Боба Мартина, чтобы закрыть свои пробелы и понять, что же на самом деле у вас пошло не так и почему виноват не Agile. Небольшой спойлер — там прям написано, что Agile для малых и средних команд.
Для ясности — я не топлю за какую-то конкретную методологию. Но я категорически против бездумного внедрения чего-либо, что здесь и было описано, а затем обвинения инструмента в своей некомпетентности.
Будем называть вещи своими именами. DF это не откровение, а базовый этап проектирования (все мы помним "семь раз отмерь, один отрежь"), который существовал задолго до всех нас. Вы пришли к нему, потому что провалили внедрение Agile.
У вас на старте большой проект с плохой документацией. Вместо того, чтобы начать с разбора техдолга и налаживания человеческих коммуникаций, вы попытались внедрить "новомодную" методологию, вырвав из нее ритуалы, но проигнорировав ценности. Когда это предсказуемо провалилось, вы обвинили методологию. И своим ответом вы лишь подтвердили это.
Вы написали отличную статью о том, как вы и ваша команда провалили внедрение Agile. И немудрено — сложно внедрить то, что не понимаешь. Рассмотрим примеры этого непонимания в цитатах.
Это говорит об отсутствии инженерной культуры. В принципах Agile есть такой пункт:
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Нет контекста — нет условий и поддержки. И даже если это было до внедрения, это говорит о провале в управлении командой, который методология не исправит.Из принципов:
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.Agile очень сильно нацелен на коммуникацию, а у вас же это одна из проблем. При этом есть еще один принцип:
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.Ценностей придерживается команда. И если вы поняли ценности как "показывать демо", то вы не поняли Agile. В самом манифесте, кстати, ничего нет про частую демонстрацию. Из принципов:
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцевиРаботающий продукт — основной показатель прогресса. Демо является не "точкой контроля", как у вас написано, а инструментом для получения обратной связи. На демо можно понять, то ли вообще делали, какие дальше шаги и т.д. Это больше синхронизация команды и заказчика, а не лишь бы показать что-то ради галочки. Если что — никто не гонит сделать за две недели что-то рабочее. В гибких методологиях слово "гибкость" является ключевым, но вместо этого описаны какие-то рамки. из-за которых страдает процесс разработки.Agile не против документации. Как и не против нормального планирования. Мотивированные профессионалы должны прекрасно понимать важность документации, проектирования, планирования. Из принципов:
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.В Agile ничего не сказано про пренебрежение и жертвование глубиной анализа. Это ваш неправильный вывод, которому вы следовали. Из принципов:
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Более того, вы же прекрасно понимали, что жертвуете анализом, так что мешало применить принцип о способах улучшения стиля работы? По тому, что написано складывается ощущение, что вы сами придумали два стула: "либо Agile", "либо анализ"Забавно то, что это не имеет отношения к Agile. Это провал управления командой и планированием. Из принципов:
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Не надо показывать итерацию. На демо должен показываться готовый к выпуску продукт (или его часть, которая должна пройти DoD), а не задеплоенное наспех и без тестирования на демо-стенд нечто. И технически это не противоречит ценностям, да. Как не противоречит им и непонимание методологии. Просто таких вещей там быть не должно. Как должно быть — читаем для начала манифест, там очень простые вещи, которые написали инженеры. И в качестве единственной проблемой в живом продукте выступает только тот, кто пытается внедрять методологию без ее понимания, а этим пронизана вся статья.Вы изобрели этап нормального планирования. Конечно, лучше поздно, чем никогда, но всё это должно быть следствием принципа из Agile:
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Выяснили детали — создали документацию, верифицировали через бизнес. Иначе как можно приступать к работе, если сами не понимаете, как должно работать в итоге.Что, простите? Да, есть ценность
Работающий продукт важнее исчерпывающей документации, но если вы ее истолковали как документация не нужна, то это снова не проблема Agile. Вот специально же написано в манифесте, чтобы не было кривых интерпретаций:То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. Вот прям еще раз:не отрицая важности того, что справа, то есть "исчерпывающей документации". Но у вас это превращается впотерянный артефакт. На сайте манифеста это шесть строк, которые не противоречат друг другу, но каким-то немыслимым образом это читают как "мы документация не пишем, у нас Agile", загоняют проекты в яму, а затем винят методологию в собственной некомпетентности.Получается интересная картина. Чтобы работать по Agile, нужно его хоть немного понимать или быть к нему открытым. Но в большинство статей о неудачах с гибкими методологиями говорится не "мы облажались при попытке внедрить", а "Agile не работает". И вот это "облажались" есть в этой статье, но оно подается как "Agile плохой".
Вообще ни разу. Ассеты можно заменить в любой (почти) момент. А вот идею — нет. А то с логикой про "чужое" можно зайти в дебри, что должен быть свой движок, а затем и свой формат текстур, а еще надо запускать на своей ОС со своими контроллерами.
Видимо, теперь соискателей из Совкомбанка надо будет на собесах гонять по теории тестирования и проверять умение писать тесткейсы.
А так в статье есть какие-то абстрактные цифры, что стало лучше, но кто теперь делает ревью тесткейсов? Кто занимается оптимизацией тестовой модели? Кто проверяет тесткейсы на дубли? Кто ставить приоритеты, теги, раскидывает по разделам? Кто отлавливает галлюцинации ллм?
Как будто генерацией сделали красиво для отчётов. Без технических данных и конкретных примеров на данном ресурсе это минус.
Статья называется "Оптимизация процессов тестирования", но при этом начинается с инструментов для автоматизации.
Именно о процессах здесь ничего нет.
Вся "оптимизация" не заключается в узкой возможности сменить одну библиотеку на другую. Но вместо рассмотрения более простых вариантов, например банального файла properties, предлагаются другие библиотеки.
Вот как это читается: вместо пары методов на 2-3 строки, возвращающих Int и List мы предлагаем затащить в проект новую библиотеку со своими зависимостями, гипотетическими конфликтами, необходимостью обновления.
Про оптимизацию ли это? Не уверен.
Так тестирования или автоматизированного тестирования? Автоматизация это лишь часть общего процесса. А библиотеки на фоне настройки QG просто не имеют значения.
Надо было читать статью с конца, сэкономил бы время. Хотя примеры сравнения по строкам весьма потешные.
Как же надоели эти LLMные статьи. @Aleron75, вам самим такое нормально выкладывать? Нигде не ёкает?
Без маркетингового булшита не обошлось, зато его градус куда ниже в этой статье, что приятно. Но круто, что наконец-то полезный инструмент, заимствующий старые идеи аллюра и сайпреса. Полагаю, дальше брать нормальные нейминги тестов, делать на них ссылки, интегрировать напрямую в систему отчетов и добавить конфиг на скрытие графиков. И тогда все звезды гитхаба ваши.
И снова на все мои вопросы о практическом применении ни одного ответа. Это лучшая иллюстрация "пользы" вашего инструмента.
Благодарю за внимание к теме. Видимо, моя критика задела за живое, раз за 19 минут вы успели ознакомиться и с моим комментарием, и со статьей по ссылке, может даже ролик посмотрели, там всего лишь час, да еще и ответ написали! Впечатляет.
Подкладывание файлов, какая-то установка, менять код зачем-то — не костыли. Ноль двойных стандартов. При этом в вашем же примере есть импорт аллюра, который генерирует более чем достаточную информацию для подобной визуализации.
Хорошо, что есть человек, способный говорить за всех, который, правда, не удосужился понять, почему идея не внедрились, но куда там, 19 минут, некогда думать. То решение было показано всего лишь на какой-то никому не известной конференции, рекламы которой нет ни в баннерах, ни в рассылках. Нонеймы, что с них взять, jugru какой-то, а кто их знает — всего лишь десяток лет что-то делают.
Хорошая попытка заменить старую статью якобы новым подходом, но нет. У вас странная позиция во всем ответе, что если что-то старое, то оно плохое. Это даже не столько глупо, сколько непрофессионально.
Если ваши тесткейсы не покрывают нужные сценарии, то циферки в айфрейме уж тем более не смогут показать ничего внятного. Вот вам такой вот факт, как раз это ваш инструмент. Идеальность здесь не при чем, это базовый элемент работы.
TMS это Test Management System или же Система Управления Тестированием. Если вы путаете TMS с документацией, то пора бы освежить знания в области тестирования. То, что вы пишете, показывает очень плохой уровень понимания процессов.
Вот этот уровень, например. Если у вас тесткейсы в TMS не содержат ожидаемого поведения, то вы на одном берегу, а тестирование на другом. И между вами океан под названием "Никогда". Документация не должна показывать реальное поведение. Она должна просто иметь описание ожидаемого и шаги.
Вы используете странные слова. Вот реально, подучите теорию тестирования что ли. В этом предложении неправильно просто всё. Я помогу — Тесткейс это набор последовательных действий с ожидаемым результатом. Тут нет ничего про "задумано", но есть алгоритм, который должен быть основан на документации по продукту. И да, если вы не можете организовать рабочий процесс, чтобы было покрытие по сторям/фичам/эпикам, то это повод задуматься о своей компетенции.
Это вы будете с такими фразами его продавать. Потому что ваш инструмент показывает только взаимодействия. Вот я открыл ваш пример, инпут Email. Как у вас по отчету понять, что проверяется введенная информация? А никак. У вас просто отчет "Fill: 8", "Value: 8". 8 раз заполнили и 8 раз что-то там с value сделали — но менеджер спросит, "какие кейсы покрывают поле email?" — что ответите? А ничего. Зато график красивый.
И в итоге вопрос «А что реально покрыто?» просто за бортом. Тонет в "Никогда" рядом с «Где дырки в UI?» и «Почему баги всплывают на очевидных сценариях?». Подсказка — проверки это assert. У вас их нет. У вас (чуть другой пример, но тоже для email) — Fill: 5, Value: 7, Visible: 2. Мы проверили видимость обязательного поля два раза? Заполнили 5 раз, но взяли значение 7 раз? По такому результату может быть что угодно и оно никак не соотносится с покрытием. У вас есть проверка заполнения поля? Тоже нет. Есть какое-то "Value: 8". Пустое? Заполненное? Какие цифры/буквы, сколько их? Самый простой джуновский вопрос на тестирование формы накинет кучу адекватных сценариев, но все они будут у вас в отчете как "Value: 8", которое просто значит, что тут что-то вводили 8 раз (вернее, что метод сработал столько раз). При этом это могло быть как в 1 тесте, так и в 8 — информации об этом тоже нет. И вы еще что-то писали про экстрасенсов. А метрики кликов и прочего можно подключать через яндекс. Да любой, кто видел вебвизор, думал о внедрении подобного в автотесты.
Ваша статья не имеет никакого отношения ни к современному, ни к методу контроля, ни к покрытию. Не говоря уже о том, что у вас код на старых технологиях. Сейчас GO в моде. С другой стороны вот вы сделали инструмент, который должен был показывать покрытие, но он этого не делает. Получается, что мы оба не получили то, что хотели. Иронично, не правда ли.
Мои подход не старый — документация и процессы это признак зрелости команды. Зато вы поиграли в песочнице гитхаба. Каждому своё уровень занятий.
И пишутся прослойкой между монитором и стулом.
Еще скажите, что без документации реальные проекты делаются. И потом сделайте круглые глаза, когда спросят «Почему баги всплывают на очевидных сценариях?». И внезапно после такого люди начинают бегать с горящей пятой точкой, искать доки по чатам и создавать нормальную вики, затем тесткейсы, затем автотесты или cases-as-code.
Сами придумали аргумент про веру и сами его героически опровергли. Сильный подход.
Контроль покрытия здесь вообще не в кассу. Видимо, у вас нет базы по тестированию, чтобы адекватно формулировать мысли в данной области. Но галочки в TMS точно таким же образом бесполезны, что и ваши отметки с кликами. Только вот в TMS можно увидеть покрытие по сценариям, а у вас в отчете нет.
Моя любимая ложная дихотомия "старое плохое, новое хорошее".
Вы так пишете, как будто ваша "разработка" это что-то морально новое. Вообще нет. Не очень понял, при чем тут возраст процессов. Процессы либо есть, либо их нет. Возраст не влияет на их качество, а вот люди, которые их используют — да. Кардинально нового за последние 20 лет ничего не придумали. Хотите нового — попробуйте поесть ногами вместо рук, это будет свежо. Инноваций в статье нет. Я понимаю, что хочется защищать свою разработку — в нее вложено много сил. Но мир меняется. И если вам кажется, что вы что-то придумали — это не значит, что до вас это не было сделано (более качественно к тому же).
Опять сами героически опровергли выдуманный собой же аргумент. Герой! Но принцесса в другом замке. При этом необходимость инноваций не гарантирует, что они будут работать. Вы бы хоть думали перед ответами, а то я за вас пояснения вношу.
Значит вы просто не видели нормальных. Очень жаль. И если вам кажется, что процессы не нужны — это не значит, что они не работают. Тут бы мне еще придумать аргумент про инновации, решающие что-то волшебным образом, а затем опровергнуть, но, пожалуй, откажусь.
Не, это мы проходили — не делает вообще ничего реально полезного. Только лишний код, лишние файлы, лишние зависимости.
Напомню пример ваш же выше — поле email "Fill: 8", "Value: 8". Что тут покрыли? Сколько сценариев? Какие позитивные, а какие негативные? Без привязки к кейсам (которая реализована в статье и вроде как в сайпресе) вы собрали статистику, которая не дает объективной картины. Как статистика поля email покрывает кейс с выделением его красным при клике по кнопке входа, если там сложный реакт-компонент с десятком врапперов внутри, часть их которых в shadowroot? Подсказка — никак. И таких реальных кейсов из реального мира (это из того, про который вы говорите, ну тот, который меняется и всё такое). Ваше "покрытие" это фикция, не более. Оно не имеет отношения к покрытию реальному, потому что нет метрик по сценариям
что в данном случае ее реально нет. Было бы неплохо сначала провести полноценный анализ, погуглить coverage по инструментам, тогда вы бы сделали иначе. Но анализ это часть процессов, тех самых, которые старые, и которые я защищаю по вашей версии.
А если человек придумал проблему и ее решил, означает ли это, что проблема существует и для других людей? Кажется, что нет. Но мы смело может забиться встретиться в этой статье через 5 лет и посмотреть, что стало с вашим инструментом. При условии, что вы ничего не будете менять. То есть не добавлять информацию про кейсы, не делать для других языков, не избавляться от лишних файлов и отвратительного подхода с библиотекой, когда приходится писать дополнительную обертку для методов. Также чтобы ни в коем случае не парсили отчет аллюра, который содержит всё нужное в себе. И уж тем более не смотреть в сторону плагина для него. Ведь иначе вы будете использовать старые идеи, которые не инноваторские, а вообще чужие.
Прям в сердечко кольнули! Мой так называемый вами "спич" не был о том, что раньше было лучше. Если бы вы потратили на чтение больше времени, то заметили бы, что упоминание прошлого касалось ваших громких слов про инноваторство и прочего маркетингового bullshit'а.
Не менее смешно про какие-то новые инструменты. Проверим? Плейрайту пять лет, хотя и он не сам по себе появился. Сайпресу больше 7. Селениуму вообще страшно уже сколько. Айфрейму, который вы используете, больше 25 лет. Питону3 больше 15 лет. И самой идее с такими отчетами тоже больше 5 лет — и это только с момента публичной версии. Ну как там с новыми инструментами? Что-то не очень, не правда ли?
Вам это не помешало проигнорировать вопросы и замечания по существу и заниматься эйджизмом технологий и процессов.
Я подчеркивал, что ваша текущая реализация бесполезна для практического применения. И давал конкретные советы по тому, как ее улучшить. Для этого все инструменты есть. А отрасли нужны хорошие специалисты, а не любители смотреть на проблемы и решать выдуманные вещи.
P.S.: Только не придумывайте скриншот-тестирование.
Слова громкие, но этой идее уже лет пять: https://habr.com/ru/companies/jugru/articles/491844/. Хотя если так подумать, то любой ваш инструмент будет для вас инновационным, даже если его уже сделали другие люди 20 лет назад.
Да всегда это было — TMS. В реальном проекте локаторы с графиками интересны тем, кто их до этого не видел. Через день это станет белым шумом. Ваш "инструмент" добавляет только дополнительный код в проект (как минимум это добавляет накладные расходы и непонятные перспективы). Старая концепция работы через отчет намного лучше и продуманнее, чем ваша идея. Да даже вы сами ссылаетесь на Cypress UI Coverage — там есть связь с тестами.
Ну это вранье (= Так себе начинать с этого статью на техническом ресурсе.
Странный аргумент. Но, что самое смешное, он более чем применим к тому, что вы "придумали". Видимо, вы не в курсе, раз пишите такое, но нормальный процесс автоматизации тесткейсов строится так:
Берется ручной тесткейс (который адаптирован для автоматизации, проверен и т.д.)
Автоматизируется (ему проставляется id из TMS для линковки и не только)
Отмечается как автоматизированный в TMS
И на дашборде теперь видно, сколько автоматизировано, а сколько нет. Устареть эта информация может только если вообще перестать вести TMS. Но это вопросы к процессам и там уже совсем другие проблемы в таком случае вырисовываются. Каждый запуск автотестов будет помечать данный тесткейс результатом из прогона. В некоторых TMS даже в режиме реального времени. Просто ноль устаревания, зато максимум смысла.
А вот "Выглядит красиво" — а это скорее про ваши столбики в "Total number of elements" и подобном, пользы от которых как от числа строк кода — вроде бы цифра есть, но применить ее некуда.
Открывается отчет, в котором всё должно быть. Если этого нет, то надо налаживать процессы. Уж извините, но это шизофренией отдает, когда вы не доверяете написанным тестам и вместо этого лезете в какой-то отчет, в котором вообще нет ничего про тесткейсы.
И, как ни странно, снова информация в TMS, где будет линковка между тесткейсом и автотестом. Если у вас не так, то соболезную, но своим инструментом вы эту проблему не решаете от слова "никак". Более того, если у вас 20 взаимодействий с активной кнопкой при заполненном поле, и 2 при незаполненном, то как вы поймете, что проверка на неактивность при незаполненности должно быть 3? Ну вот просто три кейса должно быть автоматизировано на неактивность. У вас инструмент показывает, что 2. Но вы же не смотрите в TMS, а значит инструмент просто бесполезен для вашего же примера.
Если эти три кнопки и один h1 покрывают бизнес-логику, то молодец. У вас странные примеры. Можно придумать аналогичный, но в обратную сторону — "Покрыты 50 кнопок и все поля ввода! Ну, вроде молодец! А потом открываешь тесткейсы, а там надо было проверять бизнес-логику".
При этом для понимания по вашему отчету, зачем нужен был клик, нужна экстрасенсорика более сильных магов с ТНТ, ведь в отчете кода не будет.
Не надо говорить, надо смотреть в TMS, где должны быть отмечены уже автоматизированные тесткейсы.
В реальном мире если у вас 20 тестов, которые начинаются с клика одной кнопки, вы получите просто 20 отметок о клике, которые не скажут, что покрыто, а что нет. Видимо, надо уточнить, что покрытие это не увидеть, что по кнопке был сделан клик и проверено состояние. Без контекста в этом нет смысла. Вы почему-то приводите ровно то, что выгодно вам. Совершенно не учитывая, что не всё надо покрывать, что такое покрытие вообще ничего не даст. Что надо отталкиваться не от него, а от тесткейсов и смотреть в них в первую очередь. И что отчет без них не имеет смысла, т.к. визуально трассировка шагов у вас не прослеживается. Также не учитывается, что есть подготовка тестовых данных (или изменение их во время теста) через api, что не будет отображено на UI, то есть элемент может быть вообще не отмечен. Также если у вас есть какая-то отметка, что проверена видимость кнопки, то это не говорит о том, что пропущен кейс на задизейбленность и т.д. То есть без тесткейсов это бесполезно. Но если есть тесткейсы и там есть все эти шаги и проверки, то зачем смотреть визуально? Вы предлагаете от отсутствия проверки на элементе подниматься наверх и смотреть на связанные тесткейсы. Когда должно быть наоборот — из тесткейсов строится покрытие. И если оно было плохое там, то это не сторонний инструмент должен показывать, а ревью тесткейсов (для этого есть разбивка по user story). Но, допустим, что какую-то кнопку не надо вообще покрывать. Проджект так сказал (функционал меняется, или не приоритет). Но вы каждый раз в отчете видите, что она не покрыта и перестаёте понимать свои же придуманные coverage-критерии.
И продакт спрашивает — "а вот эта user story покрыта?", и ты такой "Ну, эээ... вроде да, по моему отчету этого нет, только селектор". И вот ключевая проблема (помимо того, что не будут смотреть отчет, это на уровне скриншотов и видео всех запусков) — отметки о кликах и проверках бесполезны без привязки к тестам. И в статье, на которую я ссылаюсь в самом начале, все это было сделано. Да, пять лет назад. Так что увы, сегодня без инноваций.
Вот этим статья больше похожа на маркетинговый bullshit:
и прочие восторженные фразы для продажи, но не для реального дела.
В целом почти все аргументы статьи строятся на том, что процессы автоматизации, да и тестирования, отсутствуют напрочь, но их каким-то чудом должен закрыть отчет. Хотя по приведенным примерам решаются искусственно выдуманные проблемы.
С другой стороны если вы изучите старое решение, посмотрите, как оно реализовано, добавите в своё (уберете из своего отчеты, они вообще не нужны), то в этом уже появится некоторый смысл.
Ну как без десяти строк? Они у вас просто внутри. Аналогично с моим примером — этот код завернуть в какой-то шаблонный элемент и будет один и тот же код вызываться из разных мест: UsersTable.assertEmail(”jane”, “doe@jane.doe.com”), CustomersTable.assertEmail(”jane2”, “doe2@jane.doe.com”). Можно тоже сказать, что это одна строчка, а остальное собирает структура проекта.
Только вот люди так тесткейсы не пишут. На строчку тесткейса “Залогиниться под покупателем” у вас будет 10 строк такого роботизированного описания, которое мануальщику читать больно, и в результате вместо общей работы над качеством продукта получаем, что каждый работает для себя. И вот чтобы стало удобно, вам придется все эти формализованные шаги обернуть в step(”Залогиниться под покупателем”, ()→{…}), чтобы на верхнем уровне было описание действия, а на нижнем служебная информация.
А зачем? Ну то есть какой смысл в смене языка? Тесткейсы пишутся на одном языке, так зачем в коде возможность его переключения? Для логов английский, его переключать не надо, для тесткейсов тот, на котором они написаны. Но даже если и надо, то не составит труда в код выше добавить switch/if на все варианты с Language, который будет реагировать на конфиг.
Это на самом деле странный и противоречивый аргумент. Типизация это хорошо. Но она не дает контроль, который приведет к сокращению строк. Ваша 1 строчка добавляет кучу аннотаций, АОП, какие-то дополнительные телодвижение, подменяет реализацию Selenide (а скришот делается там, где вы ассерты заменили? а умные ожидания ваши тоже задаются точечно?). Не очень понимаю, в чем проблема с фильтрами в коллекциях. Не помню, чтобы stream api стал нерукопожатным. Инкапсуляция же решает все проблемы. И не понимаю, чем ListWC объективно лучше любого другого класса, который будет принимать внутрь себя ElementsCollection и таким образом тоже приносить строгую типизацию.
В общем, проще написать кодом
Два класса, в которых поправить локаторы и они будут универсальны для любых таблиц. При этом здесь всё на виду — понятно, как расширять и как пользоваться.
И тест будет примерно как у вас, разве что промежуточных методов меньше, но это +пара классов такой же (никакой) сложности:
Выглядит так себе на самом деле, особенно, когда проверок больше. Но вот вариант с софт ассертом из junit5 (хотя это плохо и в целом проблема тесткейса, который надо переписать):
Все решилось стандартными средствами.
Код выше отвечает на это. Ну и кодом
.email().assertText()вы не избавились от логики типаassertEmail(String userId, String expectedEmail), вы просто завернули это в другой класс или метод. Код классаTableRowможно аналогично завернуть в методemail()/name()/age()/address(), чтобы не писать каждый раз вassertFieldValueв явном виде "Email". Просто будет кучка методов, делающихreturn new TableRow(tableName, Имя/Фамилия/Адрес/Возраст, rowElement). Это ровным счетом ничего не меняет. Про мультиязычность аргумент не могу принять, я ни разу не видел, чтобы она хоть где-то встречалась, то есть чтобы внутреннее описание нужно было на двух языках. А шаги из тесткейсов у вас в любом случае должны быть на том же языке.Так делайте PR. Просто ваш код не дорабатывает Selenide, а местами даже от него отказывается без реального профита. Те же ассерты левые зачем-то. И ловите зачем-то StaleElementReferenceException, перезагружаете коллекции, хотя все это давно решено.
Тут два момента. Первый — в селениде можно делать кастомные проверки, которые вполне справятся с этой задачей. Второй — как только начинают говорить про софт-ассерты из-за каких-то проверок, то это индикатор плохого тест-дизайна. Это как делать велосипед с квадратными колесами, а потом говорить, что садиться больно.
Так вы QA или кто? Тот, кто платит зарплату, не знает ни про тестирование, ни про разработку. Он нанимает специалиста. И QA, как специалист, просто обязан улучшать процессы, до которых может дотянуться. Если ваше видение с компанией в этом плане расходится, то зачем работать через силу? Более того, когда компания захочет переходить с вашего подхода на 1 в 1 соответствие тесткейсам, ей потребуется человек, который сможет понять, что вы написали, что уже непросто из-за АОП (которое там не нужно), который будет это править, переписывать абсолютно все ваши автотесты, потому что их и руками пройти сложно. Такой подход делает максимально дорого по всем параметрам. И сравните с моим кодом — он занял минут 10, но легко расширяем, легок в использовании, не требует дополнительных знаний вообще. При этом он дает ту же самую типизацию.
В прошлый раз еще за это глаз зацепился. Такое в коде тестов — плохо. Вы же тащите наружу в тест методы, которые должны быть спрятаны. Что еще раз говорит о том, что ваши описания шагов — низкоуровневые и должны быть обернуты описаниями из тесткейсов. “The basic rule of thumb for a page object is that it should allow a software client to do anything and see anything that a human can.” — Мартин Фаулер про Page Object.
И давайте в финале сравним ваш код и мой вариант, как это у вас в документации с Selenide. Так будет честнее. А то везде сравнение абстракций разного уровня, что неспортивно.
Ваш вариант с убранными методами, которых у меня нет:
А вот мой:
Только вот вы сравниваете и не показываете внутреннюю реализацию, а у меня даже с ней код короче и понятнее даже с учетом того, что это низкоуровневые шаги, а не действия пользователя. И можно сделать абстрактным класс Table и закидывать уже в его наследников любое количество и комбинации TableRow (который тоже можно сделать абстрактным и тоже что угодно творить внутри, например, кнопки добавить).
Для начала стоит вспомнить, что перед тем, как что-то автоматизировать, нужно взять тесткейс. И если в нем будет 50-60 строк, то и в автотесте должно быть столько же — сценарий для автотеста не должен кардинально отличаться от мануального. И если в ручном “каждая строка является достаточно сложным шагом”, то надо начать с пересмотра ручных тесткейсов. Что-то мне подсказывает, что даже если в ручном будут все эти 60 шагов, то они с большой долей вероятности должны быть с вложенными. Например
Заполнить таблицу
Заполнить имя
Заполнить фамилию
И в автотесте тоже должна будет отразиться такая же вложенность. И тогда всё свернется раз в 10. И в эти вложенные шаги никто не будет заглядывать до тех пор, пока там не будет падения.
Всё, что у вас представлено — обертки над селенидом и аллюром. Вы переизобрели Page Objects с типизацией, которым более десяти лет назад уже реализовали, привет Html elements, Atlas, JDI.
Хм. Ну если писать как вы предлагаете, то да. Но в джаве мы умеет пробрасывать параметры. И через жизненный цикл аллюра можно делать параметризацию для названия шага (а не только дергать startStep и stopStep). И тогда получится ровно, что у вас на скринах, только минимальными усилиями.
Людям дали Selenide, но они упорно тащили ассерты в стиле селениума. element.text() и затем Assertions.assertThat показывает, что вы или не умеете пользоваться Selenide, или не хотите.
Или вы запутались в своих аргументах, или что-то еще случилось. Вы же передаете имя пользователя, по которому делается фильтр. Написанный метод уже является достаточно универсальный. Нужно красивое описание в отчете? Пишите тогда так:
Это, очевидно, даст в отчете:
Проверяем пользователя Вася, ожидаем email vasya@vasya.com
Проверяем пользователя Маша, ожидаем email masha@masha.com
А если надо еще и название таблицы в строку шага, так прокидывайте ее через конструктор. И такой вариант более гибкий, чем указывать все в Step над методом.
Ну а если вам не нравятся дополнительные логгируемые шаги Selenide, то для этого есть настройка: new AllureSelenide().includeSelenideSteps(false);
Или же если вам не нужны параметры в шагах, то и их тоже можно удалять. Allure дает широкие возможности для кастомизации.
Не, с софт-ассертом очень больное решение. А автологируемый отчет берите выше. И для его реализации не нужно ничего городить дополнительно (кроме оберток поверх инпутов/кнопок/прочего специфичного для каждого UI-проекта).
При этом класс ListWC использует внутри ElementsCollection, вы просто сделали обертку со своими методами и своей логикой, которая ничего нового не принесла.
Глянул еще внутрь ListWC. Кажется, вы просто принципиально отказываетесь от Selenide, но городите свои костыли, чтобы что? Как я понял, чтобы только вам было понятно и удобно. Но вот только чтобы писать в вашем стиле, нужно потратить немало времени. То есть для перехода от Selenium к Selenide нужно меньше времени, чем для перехода от Selenide к Alluruim. При этом примеры отчетов, которые я вижу, вообще не похожи на реальные кейсы.
Не будет в тесткейсе мануальщик писать "Ввести [Сова] в инпут текстового поля списка полей ввода". Или "Проверить, что значение инпута текстового поля [Login] равно [john]". И руками этот кейс потом тоже проходить больно с таким описанием.
А так последний скрин прекрасно создается кодом, который я показал выше. Без АОП, без дополнительных фреймворков, без ломбока, без Name, без Locator (кстати, не заметил примеров работы с динамическими локаторами) — только на Allure+Selenide.
Так что в качестве личного петпроекта только для одного изолированного автоматизатора, чьи отчеты смотрит только он сам, это прикольно, но для работы в qa-отделе тут пилить и пилить (и получить обратно Selenide с Allure).