А якщо автотести впали, то можна використовувати Testinel CLI: pypi.org/project/testinel-cli Він має сумісний з агентами інтерфейс, та надає їм потрібний контекст: логи, скріншоти впавших тестів: res.cloudinary.com/.../tcmtdvxvjvfgms51eu6n.png
Я розробляю інструмент testinel.dev який пришвидшує root-cause аналіз падінь Selenium та Playwright автотестів, також має сумісний з агентами CLI: pypi.org/project/testinel-cli Тепер можна написати агенту: «use Testinel CLI to fix test XYZ» та CLI надасть...
Дякую, цікавий кейс трансформації процесу! Побачив, що ви дивились у бік X-Ray для дашбордів — можу запропонувати ще один варіант: я зробив Testly, де тест-кейси — це прямо звичайні Jira issues без окремих типів тікетів.
Дякую за статтю, цікаво розібрано, як AI змінює підхід до естимації. До речі, я розробив Testly, тест-менеджмент-плагін для Jira, якщо раптом стане в нагоді: marketplace.atlassian.com/...-test-management-for-jira
Дякую, дуже наочно пояснили різницю LLM/Агент/MCP! Хочу порекомендувати сій плагін — якщо тест-кейси зберігати як нативні Jira issues, той самий Jira MCP одразу працює і для тестів, без окремого підключення до TMS.
Дякую за чіткий розклад LLM/агент/MCP! Саме приклад з TestRail+Jira навів на думку: якщо тест-кейси зберігати як звичайні Jira issues, а не в окремій TMS, то для агента достатньо одного Jira MCP — і задачі, і тести в одному місці.
Коментарі