Мне тоже не понравилось постоянно поддерживать в коде каждый новых чих в Gherkin Особенно когда количество разных тестов (а не один тест с разными входными параметрами) уходит за несколько тысяч.
На мой взгляд Gherkin более менее удобен только для описания высокоуровневых потребностей (Продукт, Компонент, Фича, Сторя) - там действительно можно загнать PO чтобы он очень быстро написал в 50 строк для чего продукт используется. Все остальное (тесты, шаги и проч.) должно быть в коде (или TMS) без разницы в каком там формате вы подаете входные данные (xml, json, что угодно).
А в конце строится Аллюр 3.0 для любых заинтересованных, в котором можно красиво увидеть тесты с красивыми шагами и непокрытые тестами стори.
К сожалению, не убедили. В 2025 большинство топит за playwright, и да, он действительно хорош, перейдите, не пожалеете. Можете даже прокси классы прокинуть, попробовать, чтобы Selenium Api сохранить
На графике красной линией обозначен Bug, и теперь наша изначальная гипотеза о том, что техдолг может напрямую влиять на рост дефектов, полностью подтверждается. Мы видим, как сильно рос техдолг разработки и вместе с тем уровень дефектов тоже
Не согласен с этим утверждением. 1. С 01 октября 2024 по 01 января 2025 цифры не бьются - тех долг по Dev растет, а багов меньше. Это может произойти, если продукт просто прошел пик активной разработки, и дальше пошли уже мелкие фичи без особого изменения архитектуры. 2. По хорошему у багов надо бы на вес дефекта смотреть, минорные и тривиальные обычно мало интересуют бизнес. 3. Выпущенные бизнес-задачи меряете в штуках, они имеют одинаковый размер в трудозатратах (сторипоинтах и проч.) ?
4. Непонятно как за пару слайдов убедить бизнес отдать 20% мощностей под тех. долг, распишите про это подробнее, на каком мероприятии и как это происходит, это интересный кейз
Когда будете распространять среди коллег внутри компании / команды, рекомендую сразу поднимать в сети сервис и обращаться через MCP SSE. Будет примерно так
У нас тоже не взлетело на деревьях и таблицах. Возможно решением этой проблемы как раз является связка MCP разных сервисов
1. MCP сервис справки - чтобы LLM могла почитать что за продукт, для чего он нужен, какие у него есть кнопочки 2. MCP Playwright - чтобы LLM могла в нем этот продукт потыкать
Привет, расскажите пожалуйста что такое "кластере качества" ? как он устроен, кто в нем главный ? какие у него цели ? где про его устройство прочитать ?
Расскажите пожалуйста, какие должности у вас являются стейкхолдерами и как они оценивают качество продукта по количеству ошибок, найденных тестером. Ну и в добавок : на каком мероприятии они делают оценку, оценивает каждый SH или все вместе делают отчёт, кто еще присутствует на этом мероприятии ?
Было бы круто расписать по подробнее про ДСов и почему у них нет ресурсов и какие компетенции там нужны, чем это отличается от обычного тестирования. Ну и в догонку как вы планируете спринт и квартал, какие цели ставит бизнес и т.д.
Привет, для чего вводить отдельную команду по тестированию моделей? почему это не может сделать команда, которая эту модель вам отдает. Мы же все играем в SCRUM: команда владеет результатами своей работы, а именно ценным и готовым к выпуску Инкрементом продукта.
Привет, у нас такая штука не взлетела и ушла в спам.
Почему: среди дня у тестера может быть несколько запусков тестов, маленьких и больших, а еще куча разных репозиториев, в них могут быть отдельные пайпы, эти данные в почте дико раздражают. А еще есть ручные тесты, там вообще непонятно когда отправлять письмо.
Мы что сделали: 1. Инфу со всех запусков автотестов, инфу по ручным тестам и инфу по тестовому покрытию собрали в один Allure отчет, который в пайпе пересобирается и доступен у команде по статичной ссылке типа team/branch/ 2. На дейли (афтепати) тестер показывает актуальный отчет. На ретро смотрят покрытие
Маловато новизны. Про всё это написано и переписано десятки раз
Мне тоже не понравилось постоянно поддерживать в коде каждый новых чих в Gherkin
Особенно когда количество разных тестов (а не один тест с разными входными параметрами) уходит за несколько тысяч.
На мой взгляд Gherkin более менее удобен только для описания высокоуровневых потребностей (Продукт, Компонент, Фича, Сторя) - там действительно можно загнать PO чтобы он очень быстро написал в 50 строк для чего продукт используется.
Все остальное (тесты, шаги и проч.) должно быть в коде (или TMS) без разницы в каком там формате вы подаете входные данные (xml, json, что угодно).
А в конце строится Аллюр 3.0 для любых заинтересованных, в котором можно красиво увидеть тесты с красивыми шагами и непокрытые тестами стори.
А в целом рад, что у автора получилось
А возможно дать доступ не только разработчикам к коду ?
К сожалению, не убедили. В 2025 большинство топит за playwright, и да, он действительно хорош, перейдите, не пожалеете. Можете даже прокси классы прокинуть, попробовать, чтобы Selenium Api сохранить
Я отказался от fluent потому что отладка с нем это целая история.
// Act - выполнение действий _mainWindowController .SetUserData(userData) .ClickRegistrationButton();Поставьте точку останова на методе ClickRegistrationButton и попробуйте отладить тест, затем SetUserData и сделайте тоже самое. Удобно ?
TestY пробовали? Выглядит интересно, стоит ноль рублей
Не согласен с этим утверждением.
1. С 01 октября 2024 по 01 января 2025 цифры не бьются - тех долг по Dev растет, а багов меньше. Это может произойти, если продукт просто прошел пик активной разработки, и дальше пошли уже мелкие фичи без особого изменения архитектуры.
2. По хорошему у багов надо бы на вес дефекта смотреть, минорные и тривиальные обычно мало интересуют бизнес.
3. Выпущенные бизнес-задачи меряете в штуках, они имеют одинаковый размер в трудозатратах (сторипоинтах и проч.) ?
4. Непонятно как за пару слайдов убедить бизнес отдать 20% мощностей под тех. долг, распишите про это подробнее, на каком мероприятии и как это происходит, это интересный кейз
Согласен полностью, успешный успех теперь и в хабре
С теорией понятно, а что с инструментами? Где удобнее рисовать? Может где-то можно yaml в схему перегонять? Что из этого OpenSource?
Не ограничивайтесь тестированием, идите дальше, достройте ваш Скрам: на бизнес-требованиях добавьте значок всей команды.
Когда будете распространять среди коллег внутри компании / команды, рекомендую сразу поднимать в сети сервис и обращаться через MCP SSE. Будет примерно так
{
"type": "streamable-http",
"url": "https://server:port/mcp"
}
У нас тоже не взлетело на деревьях и таблицах.
Возможно решением этой проблемы как раз является связка MCP разных сервисов
1. MCP сервис справки - чтобы LLM могла почитать что за продукт, для чего он нужен, какие у него есть кнопочки
2. MCP Playwright - чтобы LLM могла в нем этот продукт потыкать
Тогда есть шанс
одно и тоже
Особой разницы с Roo Code не заметил, ну разве что денег надо заплатить.
Привет, расскажите пожалуйста что такое "кластере качества" ? как он устроен, кто в нем главный ? какие у него цели ? где про его устройство прочитать ?
Привет, на FlaUI.WebDriver пробовали переход? Там подобие XPath прикрутили
Расскажите пожалуйста, какие должности у вас являются стейкхолдерами и как они оценивают качество продукта по количеству ошибок, найденных тестером. Ну и в добавок : на каком мероприятии они делают оценку, оценивает каждый SH или все вместе делают отчёт, кто еще присутствует на этом мероприятии ?
Было бы круто расписать по подробнее про ДСов и почему у них нет ресурсов и какие компетенции там нужны, чем это отличается от обычного тестирования. Ну и в догонку как вы планируете спринт и квартал, какие цели ставит бизнес и т.д.
Привет, для чего вводить отдельную команду по тестированию моделей? почему это не может сделать команда, которая эту модель вам отдает. Мы же все играем в SCRUM: команда владеет результатами своей работы, а именно ценным и готовым к выпуску Инкрементом продукта.
Привет, у нас такая штука не взлетела и ушла в спам.
Почему: среди дня у тестера может быть несколько запусков тестов, маленьких и больших, а еще куча разных репозиториев, в них могут быть отдельные пайпы, эти данные в почте дико раздражают. А еще есть ручные тесты, там вообще непонятно когда отправлять письмо.
Мы что сделали:
1. Инфу со всех запусков автотестов, инфу по ручным тестам и инфу по тестовому покрытию собрали в один Allure отчет, который в пайпе пересобирается и доступен у команде по статичной ссылке типа team/branch/
2. На дейли (афтепати) тестер показывает актуальный отчет. На ретро смотрят покрытие