AC qa-risk-intuition
Выявляйте области тестирования, которые "выглядят просто, но на самом деле очень рискованны", чтобы помочь вам расставить приоритеты при ограниченных ресурсах. Используйте этот навык, когда времени на тестирование недостаточно, вы не знаете, на каких функциях сосредоточиться, или интуитивно чувствуете, что какая-то функция может быть проблематичной, но не можете точно сказать почему. Опытные тестировщики инстинктивно настораживаются при определенных изменениях — это не мистика, а структурированная сигнальная модель: радар из пяти сигналов риска (изменения/бизнес/технологии/данные/интеграция), количественная оценка и распределение глубины тестирования и ресурсов по уровням. Каждая точка риска имеет уникальный идентификатор (RISK-{модуль}-{тип риска}-{порядковый номер}). Сценарии использования: оценка рисков, приоритезация, где высокий риск, сигналы риска, фокус тестирования, распределение ресурсов, высокоприоритетное тестирование, когда необходимо определить фокус тестирования, когда ресурсы тестирования ограничены и нужно сосредоточиться.
машинный переводПоказать оригиналСкрыть оригинал«识别那些"看起来很简单但实际风险很高"的测试区域，帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉…»
识别那些"看起来很简单但实际风险很高"的测试区域，帮你在有限的测试资源下做优先级判断。当测试时间不够、不知道应该重点测哪些功能、或者直觉告诉你某个功能可能有问题但说不上来为什么时，应当使用此技能。有经验的测试看到某些变更会本能地警觉——这不是玄学，是可以结构化的信号模型：变更/业务/技术/数据/集成五大风险信号雷达，量化打分后按等级分配测试深度与资源。每个风险点带唯一 ID（RISK-{模块}-{风险类型}-{序号}）。 触发场景：风险评估、优先级、哪里风险高、风险信号、测试重点、资源分配、高优测试、需要判断测试重点、测试资源有限需要聚焦时。 Use when the user asks about: identifying high-risk areas that look simple — frequently changed modules, third-party dependencies, money and security paths, and historical defect hotspots.
Выявляйте области тестирования, которые "выглядят просто, но на самом деле очень рискованны", чтобы помочь вам расставить приоритеты при ограниченных ресурсах.
Как процесс C 57/100 · Есть пробелы — слабые места: результат и критерий готовности, входы и предусловия, ошибки и развилки
Как улучшить
- Свои кейсы (evals/evals.json, 4–6 реальных запросов с ожидаемыми ответами): тогда полная проверка прогонит именно их, а не черновик от модели.
- spec.yaml с триггерными фразами и утверждениями — контракт поведения для CI; `skilltest init` создаст шаблон.
Находки guard · 0
✓ Критических и высоких находок нет
Просканировано файлов: 4. Улики замаскированы. Пометки в серых чипах объясняют, почему серьёзность понижена.
По спецификации Agent Skills
✓ По спецификации Agent Skills замечаний нет
Процессный рейтинг: все десять параметров 57/100
- 0Результат и критерий готовности. Не сказано, что считать результатом
- 0Входы и предусловия. Не сказано, что нужно иметь на входе
- 0Ошибки и развилки. Линейный процесс без обработки сбоев
- 0Отчётность по ходу. Скилл ничего не сообщает по ходу работы
- 30Повторный запуск. Изменяющих операций: 1, без проверки текущего состояния
- 70Когда включается. Сказано, когда применять, но не сказано, когда не стоит
- 100Инструменты и файлы. Инструменты объявлены во frontmatter
- 100Шаги. Шагов: 9
- 100Согласованность. Имя и обязательные поля на месте
- 100Стоимость исполнения. Тело инструкции 649 токенов
Всё перечисленное измерено по тексту скилла, а не оценено моделью: цифры проверяемы. Вес параметра тем больше, чем чаще из-за него процесс встаёт.
Сигналы качества
- +5В description нет примеров фраз, по которым скилл должен срабатывать
- +4Описание не говорит, когда скилл НЕ применять (ложные срабатывания)
- +3Формат ответа не описан: модель каждый раз решает сама
- +2Инструкции на одном языке
- +3Длина description 463 символов: достаточно сигнала, не съедает бюджет
- +4Структура: 8 заголовков
- +3Пошаговые инструкции: 9 пунктов
- +4Есть примеры (3 блоков кода)
- +4Справочные файлы упоминаются в инструкциях (1 из 1)
- +1Лицензия указана
База качества 70; замечания lint вычитаются, сигналы прибавляют до 100. Итог: 89.