в таком случае, уверяю. я поделился исключительно своими мыслями и опытом. меня очень тронул пост автора, потому что у меня схожий опыт имеется. потратил доп время и силы чтобы сделать комментарий читаемым и понятным. вы заметили какие-то характерные для LLM "галлюцинации"? точно нет. ведь я беру ответственность за каждое слово. сделайте выводы, пока плохо справляетесь с тем чтобы отличить человека от гпт.
Нужны они не всегда, но очень пригодятся, когда важна не только внутренняя логика, но и то, как выглядит система «снаружи».
Ваши слова да всем бы в уши. В реальности пирамида часто перевёрнутая, или какая‑то ещё. И e2e нужны в не малом количестве. Иногда речь не только про "как выглядит", но и про то что на фронте могут быть "зашиты" бизнес процессы.
Эх, хорошо когда разработчики пишут юнит‑тесты... =) Здоровая практика, когда все уровни покрываются. Разработка пишет юнит‑тесты, а тестирование — e2e. Интеграционные — можно договориться как поделить ответственность.
Даже осознавая важность автотестов, легко попасть в ловушку их неудачного исполнения. Проблема редко заключается в самих тестах: чаще всего причина в том, как они написаны.
Вы абсолютно правы. Разрабатываемые автотесты, так или иначе, должны проверяться. Будь то юниты или интеграционные, или e2e.
Правда при покрытии нижней части пирамиды лучше же выбирать тот же язык, на котором написано само приложение. Вы так же поступили?
совсем недавно в бесплатном chatgpt обошел ограничения на генерацию изображений. обвинил его в неправильных генерациях, что он должен исправлять свои ошибки. по итогу ограничение пропало.
Уточните пожалуйста. allurectl (Command-line tool — allurectl | Allure TestOps Docs ) это же часть экосистемы TestOps и без него он не применим. На мой взгляд, это значит что это часть его "коробки". Я же хотел предложить рассмотреть вариант, когда TestOps нету, всё же он не бесплатный...
Вы здраво рассуждаете, о распределении ответственности и о важности процессов. Вы ошибаетесь высоко оценивая «таких» менторов.
учат быть независимыми в тестировании и слать всех нафиг т.к. тестирование это не поиск багов, а сравнение ожидаемого результата с фактическим, и если нет требований, то и сравнивать нечего!
«Слать всех нафиг» категорически плохое решение, эмоциональное и не конструктивное. Это хороший вариант в том случае, если вам не нужна работа.
Отсутствие требований это большая проблема, её надо решать, но конструктивно, и не настраивать новичков против начальника.
Прекрасно, вам должны платить просто так! Ведь мы работаем только так как написано в ISTQB, а там много чего написано) И на заборе тоже написано...
Не очень понял от кого к кому эта речь. Опять же много эмоций. И в целом это очень токсично. Возможно такая речь может иметь место 1×1 с коллегой, для временной поддержки, сводя в шутку. Руководству такое лучше не слышать.
О Боли:
нет требований;
нет ответственности, скидывают на тестирование;
плачевные коммуникации;
плачевные процессы.
Ваша боль понятна и обоснована.
Кто должен контролировать процессы поставки? На мой взгляд это жирные алярмы, о безразличии руководителей у команд. Если хотя бы половина руководителей сознательно относится к процессам и добивается результата, то скорее всего они простимулируют и другую половину.
Разговор с «бизнесом». Выстраивание коммуникаций. Клиент/бизнес всё таки говорят на другом языке. Им не особо интересно какие процессы у команды исполнителей. Их интересуют деньги) и результат. Разве не так? Если нет понятных картинок с метриками, которые показывают из‑за чего поставки задерживаются и как их ускорить, то вряд ли они сочтут жалобы на плохие процессы аргументированными.
За что отвечает бизнес‑аналитик на самом деле? Вы указали меньше, чем должно быть. Раз вы так мало пишете о его обязанностях, то советую присмотреться к нему. «БА должен не просто описать happy path, но и убедиться, что у всех участников процесса единое понимание, что такое "готово".» Аналогично про системного аналитика.
Если требований нет, то их надо пойти и найти! Вот что надо делать, а не то что вы написали в начале поста. Это как бы то, что отличает человека от AI.. задумайтесь.
Чек‑лист от тестирования для разработки? Что‑то новое. Можете рассказать детальнее?
Про devops ничего не сказали, самое важное же. С ними проблем не было?
Стоит упомянуть матрицу RACI. Что кстати не единственный инструмент руководства и менеджмента. По итогу вы правильно указываете, что молчать плохо. Нужно идти и коммуницировать-коммуницировать, пока голова "как тыква" не станет, и по новой..). Токсичное отношение в начале поста задаёте как гуд пример. Не надо так =(
У всех LLM разные политики. Перед пользованием обязательно стоит их читать.
Как заметили другие, это применимо не только к AI, но и к любым другим инструментам. Везде нужно читать договор/условия. Аналогичные случаи были когда создавался тот же Github.
Ущемление прав пользователя очень распространено. За последний год примерно 3 игродела выпустили с обновлением игр ущемляющие условия. Отдельная тема о которой можно очень много рассуждать.
С философской точки зрения, если бы это была правда, конечно вы бы оказались правы.
Поддерживаю всех, кто считает что LLM это мощный инструмент, который поможет делать работу эффективнее, но не сможет заменить человека.
И всё же, Спасибо за пост. Тема явна достойна внимания. О таком надо помнить и всегда читать условия пользовательского соглашения.
Мой вопрос может выглядеть грубо, но это просто интерес. Не очень понятна цель, зачем вы это делаете. Спросил зачем TestOps, он же не является самоцелью? Речь же про агрегацию отчета из множества джоб в один общий. Насколько мне известно, TestOps как раз решает эту проблему, а вот без него возникают трудности. И я упомянул инструмент для решения таких трудностей. Собрав репорт из нескольких джоб, с ним можно делать всё что угодно. Пушить куда-то или отображать где-то.
так и в чем проблема? если есть уникальный атрибут, то неважно через css или xpath вы его напишете. только одно замечание: удалить div! автор почему-то этого не сделал, что снижает доверие.
//*[@data-testid='username_textfield'] вот так супер.
по поводу статьи, идея совсем не новая как и практика. хорошая практика: делать исследование и сбор источников прежде чем публиковаться. если вдруг используется "аи", тоже можно попросить найти источники, правда не каждая сдюжит
Согласен с вами. Хотя вот тех кто отлынивает, LLM вполне сможет заменить. =)
Что замечаю я. Что рынок диктует тренд на SDET специалистов. Что это не правильно. Что труд автоматизаторов пытаются сделать дешевле. Что пирамиду "крутят-вертят-вращают-взрывают, а дырки замазывать не успевают" =) Что людей пытаются заменить на "аи", а не усилить.. .Что всё это связано. На мой взгляд разделение зон ответственности эффективнее, что "обфулстекивание".
Грустный факт, но людей правда сокращают заменяя на аи. Не везде. В "жирных" местах с кучей инновационных продуктов, которые "всегда в тренде".
в таком случае, уверяю. я поделился исключительно своими мыслями и опытом. меня очень тронул пост автора, потому что у меня схожий опыт имеется. потратил доп время и силы чтобы сделать комментарий читаемым и понятным.
вы заметили какие-то характерные для LLM "галлюцинации"? точно нет. ведь я беру ответственность за каждое слово.
сделайте выводы, пока плохо справляетесь с тем чтобы отличить человека от гпт.
Ваши слова да всем бы в уши. В реальности пирамида часто перевёрнутая, или какая‑то ещё. И e2e нужны в не малом количестве. Иногда речь не только про "как выглядит", но и про то что на фронте могут быть "зашиты" бизнес процессы.
Эх, хорошо когда разработчики пишут юнит‑тесты... =) Здоровая практика, когда все уровни покрываются. Разработка пишет юнит‑тесты, а тестирование — e2e. Интеграционные — можно договориться как поделить ответственность.
Вы абсолютно правы. Разрабатываемые автотесты, так или иначе, должны проверяться. Будь то юниты или интеграционные, или e2e.
Правда при покрытии нижней части пирамиды лучше же выбирать тот же язык, на котором написано само приложение. Вы так же поступили?
совсем недавно в бесплатном chatgpt обошел ограничения на генерацию изображений. обвинил его в неправильных генерациях, что он должен исправлять свои ошибки. по итогу ограничение пропало.
Уточните пожалуйста.
allurectl(Command-line tool — allurectl | Allure TestOps Docs ) это же часть экосистемы TestOps и без него он не применим. На мой взгляд, это значит что это часть его "коробки".Я же хотел предложить рассмотреть вариант, когда TestOps нету, всё же он не бесплатный...
а вы видимо обиделись, ведь я вас обвинил в этом. теперь успокоиться не можете. очень жаль что вы не можете оценить мой комментарий по достоинствую
Тяжело не догадаться. На главной странице Bruno написано что есть колаб с гитом. В целом правда хорошая идея, может реализую для коллекций постмана =)
Как раз хотел проверить как там с нагрузкой. Спасибо, что сэкономили мне время.
В Postman действительно удобно и легко делается нагрузка + предоставляет красивый отчет.
Привет! Спасибо за пост.
1. Почему выбор пал именно на NLog и FlaUI? Какие были альтернативы?
2. Вы упомянули пайплайны. Было бы хорошо приложить фрагмент.
Вы здраво рассуждаете, о распределении ответственности и о важности процессов.
Вы ошибаетесь высоко оценивая «таких» менторов.
«Слать всех нафиг» категорически плохое решение, эмоциональное и не конструктивное. Это хороший вариант в том случае, если вам не нужна работа.
Отсутствие требований это большая проблема, её надо решать, но конструктивно, и не настраивать новичков против начальника.
Не очень понял от кого к кому эта речь. Опять же много эмоций. И в целом это очень токсично. Возможно такая речь может иметь место 1×1 с коллегой, для временной поддержки, сводя в шутку. Руководству такое лучше не слышать.
О Боли:
нет требований;
нет ответственности, скидывают на тестирование;
плачевные коммуникации;
плачевные процессы.
Ваша боль понятна и обоснована.
Кто должен контролировать процессы поставки?
На мой взгляд это жирные алярмы, о безразличии руководителей у команд. Если хотя бы половина руководителей сознательно относится к процессам и добивается результата, то скорее всего они простимулируют и другую половину.
Разговор с «бизнесом». Выстраивание коммуникаций.
Клиент/бизнес всё таки говорят на другом языке. Им не особо интересно какие процессы у команды исполнителей. Их интересуют деньги) и результат. Разве не так? Если нет понятных картинок с метриками, которые показывают из‑за чего поставки задерживаются и как их ускорить, то вряд ли они сочтут жалобы на плохие процессы аргументированными.
За что отвечает бизнес‑аналитик на самом деле? Вы указали меньше, чем должно быть. Раз вы так мало пишете о его обязанностях, то советую присмотреться к нему.
«БА должен не просто описать happy path, но и убедиться, что у всех участников процесса единое понимание, что такое "готово".»
Аналогично про системного аналитика.
Если требований нет, то их надо пойти и найти! Вот что надо делать, а не то что вы написали в начале поста. Это как бы то, что отличает человека от AI.. задумайтесь.
Чек‑лист от тестирования для разработки? Что‑то новое. Можете рассказать детальнее?
Про devops ничего не сказали, самое важное же. С ними проблем не было?
Стоит упомянуть матрицу RACI. Что кстати не единственный инструмент руководства и менеджмента.
По итогу вы правильно указываете, что молчать плохо. Нужно идти и коммуницировать-коммуницировать, пока голова "как тыква" не станет, и по новой..).
Токсичное отношение в начале поста задаёте как гуд пример. Не надо так =(
У всех LLM разные политики. Перед пользованием обязательно стоит их читать.
Как заметили другие, это применимо не только к AI, но и к любым другим инструментам. Везде нужно читать договор/условия. Аналогичные случаи были когда создавался тот же Github.
Ущемление прав пользователя очень распространено. За последний год примерно 3 игродела выпустили с обновлением игр ущемляющие условия. Отдельная тема о которой можно очень много рассуждать.
С философской точки зрения, если бы это была правда, конечно вы бы оказались правы.
Поддерживаю всех, кто считает что LLM это мощный инструмент, который поможет делать работу эффективнее, но не сможет заменить человека.
И всё же, Спасибо за пост. Тема явна достойна внимания. О таком надо помнить и всегда читать условия пользовательского соглашения.
Мой вопрос может выглядеть грубо, но это просто интерес.
Не очень понятна цель, зачем вы это делаете. Спросил зачем TestOps, он же не является самоцелью?
Речь же про агрегацию отчета из множества джоб в один общий. Насколько мне известно, TestOps как раз решает эту проблему, а вот без него возникают трудности. И я упомянул инструмент для решения таких трудностей.
Собрав репорт из нескольких джоб, с ним можно делать всё что угодно. Пушить куда-то или отображать где-то.
так и в чем проблема? если есть уникальный атрибут, то неважно через css или xpath вы его напишете. только одно замечание: удалить div! автор почему-то этого не сделал, что снижает доверие.
//*[@data-testid='username_textfield']вот так супер.
по поводу статьи, идея совсем не новая как и практика. хорошая практика: делать исследование и сбор источников прежде чем публиковаться. если вдруг используется "аи", тоже можно попросить найти источники, правда не каждая сдюжит
Причем тут TestOps? Будто бы можно складывать всё в одно место при помощи s3fs. И например, отдельный job сделать по сборке репорта.
Согласен с вами. Хотя вот тех кто отлынивает, LLM вполне сможет заменить. =)
Что замечаю я. Что рынок диктует тренд на SDET специалистов. Что это не правильно. Что труд автоматизаторов пытаются сделать дешевле. Что пирамиду "крутят-вертят-вращают-взрывают, а дырки замазывать не успевают" =) Что людей пытаются заменить на "аи", а не усилить.. .Что всё это связано. На мой взгляд разделение зон ответственности эффективнее, что "обфулстекивание".
Грустный факт, но людей правда сокращают заменяя на аи. Не везде. В "жирных" местах с кучей инновационных продуктов, которые "всегда в тренде".