Карти на стіл.

100% покриття. Третина тестів жодного разу не запускалась.

У більшості систем управління тестуванням вимога вважається покритою, щойно до неї прив'язали тест. Але прив'язка нічого не каже про те, чи тест запускався минулої ночі, чи його пропустили, чи він падає вже тиждень. Покриття стає заявою — і реліз підписують на підставі заяв.

Доказ, заява чи ще нічого — і завжди видно, що саме.

Червоне — вирішальне, зелене — заслужене. Одне падіння робить вимогу червоною. Зеленою вона стає, лише коли кожен кейс запущено і він пройшов. Відомий дефект — усе одно падіння: він приходить червоним зі значком known, а не тихо зеленим.

Ваша QA-команда не бачить більшості ваших тестів.

Юніт-, інтеграційні, а часто й API-тести живуть у репозиторіях і пайплайнах розробників. QA їх не бачить — тож або повторно перевіряє на e2e те, що вже покрито нижче, або пропускає те, що не покрив ніхто. На питання «а це десь тестується?» відповідають з пам'яті.

Уся тестова піраміда — в одному місці.

Кожен рівень — юніт, інтеграційні, API, e2e, ручні — з усіх репозиторіїв, CI-пайплайнів і тестових прогонів, зібраний в одну піраміду для кожного сьюту. На кожному рівні видно вердикти й прогалини. Розробники відкривають карти QA, QA — тим, хто підписує реліз. А сьют, перекошений догори, одразу видно таким, яким він є, — ріжком морозива.

Від специфікації до вердикту, якому можна вірити

1. Специфікація. Прив'яжіть документи, з яких виріс сьют; OpenCards перевіряє, що посилання живі.
2. Вимоги. Правила, інваріанти й ризики з пріоритетом P0–P2.
3. Кейси. Кожен — на найнижчому рівні, що його перевіряє, у піраміді, з трасуванням до вимог.
4. Тести. У ваших репозиторіях — написані людьми або вашим агентом.
5. Прогони. CI надсилає JUnit-звіт; люди фіксують ручні вердикти. Один формат результату для обох.
6. Вердикти. Результати лягають на кейси, згортаються до вимог і сьютів, і кожна прогалина видна.

Що на столі

Те, що світиться, — вже працює. Пунктир — у планах: ми малюємо власний продукт так само, як він малює ваш.

Вже працює

• Каталог від вимог. Сьюти в дереві папок; у кожного — реєстр вимог і каталог кейсів із трасуванням в обидва боки.
• Піраміда для кожного сьюту. Рівні у фіксованому порядку — форму тестування видно з першого погляду.
• Прогони й вердикти. Ручні прогони замість таблиці: pass, fail, flaky, blocked — з тим, хто і коли, прив'язані до релізу.
• Звіти з CI. JUnit із Playwright і vitest — з GitHub Actions, GitLab CI, Bitbucket Pipelines або будь-якого CI через curl. Те, що не вдалося зіставити з кейсом, показується, а не губиться.
• Insights. Інбокс для тріажу: нові падіння, на які ще ніхто не дивився, відомі дефекти з test.fail() і test.fixme(), вимоги без жодного тесту.
• Ваш агент — у вашому воркспейсі. 50 MCP-інструментів для Claude Code і Claude Desktop — у межах ролей вашого воркспейсу.
• З документації — в каталог. Агент читає документацію фічі й імпортує її вимоги та кейси — спершу пробний прогін, нічого не видаляється.
• Специфікації й пошук. Посилання на документи за сьютом із перевіркою, що вони живі; пошук будь-якого кейсу, вимоги чи сьюту за ID.
• Воркспейси й ролі. Вхід через Google; власний you.opencards.dev; Owner, Editor, Viewer; токени для CI та агентів.

У планах

• У планахВимоги звідти, де вони живуть. Збір із Jira, Confluence, файлів або вільного тексту.
• У планахАгенти, що пишуть тести. Обрали кейси, натиснули Implement — переглядаєте pull request.
• У планахПідписання релізу. Обсяг змін із Jira, чекліст для рев'ю, закріплені докази, одне рішення.
• У планахUAT з аудитом. Один агент проходить сценарії приймання, інший оцінює докази. Агент, що виконав роботу, не ставить собі оцінку.

Приводьте свого агента.

OpenCards говорить MCP. Підключіть Claude Code — і агент читатиме каталог, імпортуватиме документацію фічі, підбиратиме потрібний скіл для тесту, прив'язуватиме написані тести й розбиратиме падіння — рівно з тими правами, що має ваша роль.

claude mcp add --transport http opencards https://you.opencards.dev/api/mcp

Замініть you на свій воркспейс.

Один крок у CI. Нічого не губиться мовчки.

Додайте один крок після тестів. Він виконується і тоді, коли тести впали, і не може зламати пайплайн. Кожен результат прив'язується до кейсу за явним ID або за шляхом і назвою; результат, який не вдалося зіставити, показується як неприв'язаний, а не викидається. Інжест, що мовчки відкидає незіставлене, — бреше.

      # …after the step that runs your tests
      - name: Report to OpenCards
        if: ${{ !cancelled() }}   # also when the tests failed
        env:
          OPENCARDS_URL: https://you.opencards.dev
          OPENCARDS_PRODUCT: web
          OPENCARDS_TOKEN: ${{ secrets.OPENCARDS_TOKEN }}
        run: |
          curl -fsSL "$OPENCARDS_URL/api/ci/reporter.mjs" -o opencards-report.mjs || exit 0
          node opencards-report.mjs reports/junit.xml unit

Кожен відкриває свої карти

• QA-інженерБачите, що вже протестували розробники, перш ніж писати ще один e2e. Таблиця прогонів більше не потрібна з першого дня.
• QA-лідПрогалини за вимогами й рівнями, щоденний інбокс для тріажу і «покрито», яке означає «запущено».
• Власник релізуЩо входить у реліз і чи справді його тести пройшли — з доказами, а не з відсотком.
• РозробникОдин крок у CI — і ваші юніт- та інтеграційні тести враховуються. Агент працює з каталогом замість вас.