CtrlK
BlogDocsLog inGet started
Tessl Logo

blazemeter-functional-testing

Comprehensive guide for BlazeMeter Functional Testing, including GUI Functional Tests, API Tests (deprecated), Action Library, and debugging. Use when working with Functional Testing for (1) Creating GUI Functional Tests (YAML, Java IDE, Python IDE), (2) Managing Functional Tests (duplicate, delete, move, rename), (3) Using test data in Functional Tests, (4) Working with Action Library, (5) Debugging Functional Tests, (6) Understanding browser support, or any other Functional Testing tasks. Note - API Functional Tests are deprecated in favor of API Monitoring.

66

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./resources/skills/blazemeter-functional-testing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured index-style SKILL.md with excellent progressive disclosure: every reference file is real, one level deep, annotated with its contents, and mapped to usage conditions, and the MCP tooling section provides concrete invocations. The main weakness is redundancy — Quick Start, Reference Files, and When to Use Each Reference repeat the same navigation information — plus the absence of any inline quick-start example for the core test-creation tasks and no error-recovery guidance in the workflow.

Suggestions

Merge 'When to Use Each Reference' into the 'Reference Files' list (e.g., a one-line 'Use when...' under each link) and delete the duplicate section to cut the body's token cost by roughly a third.

Replace the 'Quick Start' topic list, which duplicates the reference mapping, with one concrete quick-start snippet (e.g., a minimal Taurus YAML for a GUI Functional Test) so the most common task has executable inline guidance.

Drop or tighten the generic 'When to Use MCP Tools' bullets ('Automation: Integrate functional testing into automation workflows') and add one error-recovery line to the Example Workflow (e.g., what to check when `blazemeter_execution` reports a failed run).

DimensionReasoningScore

Conciseness

Mostly efficient prose, but three sections restate the same mapping: 'Quick Start' ('GUI Tests: Create tests using scriptless UI, YAML files, or IDEs...'), the 'Reference Files' annotations, and 'When to Use Each Reference' ('GUI Tests: When creating, managing, or reporting on GUI Functional Tests') all say nearly the same thing, and the 'When to Use MCP Tools' bullets ('Automation: Integrate functional testing into automation workflows') are generic filler. It is above a 2 because nothing explains concepts Claude already knows; it is below a 4 because the duplicated navigation sections are unnecessary tokens that could be merged.

3 / 5

Actionability

The MCP section gives executable, concrete invocations with required args and return values ('`blazemeter_tests` with action `list`... Required args: `test_id` (integer) or `project_id` (integer)') plus a four-step example workflow. It is not a 5 because the core skill tasks (actually authoring a GUI test, YAML shape, debugging steps) have no inline quick-start snippet — they are only pointed at via reference links — leaving minor gaps in executable coverage of the common cases.

4 / 5

Workflow Clarity

The 'Example Workflow' is a clear, unambiguous sequence ('1. Use `blazemeter_tests` with action `list`... 2. ... `read`... 3. `blazemeter_execution` with action `read`... 4. Review execution results'). These are read-only operations, so destructive/batch validation caps do not apply; it is below 5 only because there are no checkpoints or error-recovery guidance (e.g., what to do when an execution fails), and the primary task workflows (test creation) are deferred to references without any sequencing in the body.

4 / 5

Progressive Disclosure

The body is a pure overview/index: all five bundle files in references/ (gui-tests.md, api-tests.md, action-library.md, debugging.md, browsers.md) are linked one level deep with a content summary each ('Overview, Create YAML File, Create from Java IDE...'), and navigation is further aided by per-reference 'when to use' guidance. The bundle links stay within this skill's references (cross-links go to other skills, not nested deeper here), matching the anchor for a clear overview with well-signaled one-level-deep references.

5 / 5

Total

16

/

20

Passed

Description

88%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description in the enumerated-trigger style of the rubric's good examples: it states the domain, inventories concrete capabilities, and gives an explicit 'Use when...' clause covering six numbered task categories plus a deprecation boundary note. The only gaps are a few missing natural synonyms (Selenium, Taurus, scriptless) and minor overlap risk with adjacent BlazeMeter skills.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete capabilities: 'Creating GUI Functional Tests (YAML, Java IDE, Python IDE)', 'Managing Functional Tests (duplicate, delete, move, rename)', 'Using test data', 'Working with Action Library', 'Debugging', and 'browser support' — comprehensive concrete coverage of the domain, matching the anchor for multiple specific concrete actions. It is not a 4 because coverage spans all major task areas of the skill with no noticeable gap.

5 / 5

Completeness

It explicitly answers both questions: 'what' via the leading capability inventory ('Comprehensive guide for BlazeMeter Functional Testing, including GUI Functional Tests, API Tests (deprecated), Action Library, and debugging') and 'when' via the explicit trigger clause 'Use when working with Functional Testing for (1)... (6), or any other Functional Testing tasks'. This mirrors the rubric's top anchor with concrete trigger phrases, so neither 4 nor below fits.

5 / 5

Trigger Term Quality

Good natural-term coverage: 'GUI Functional Tests', 'YAML', 'Java IDE', 'Python IDE', 'test data', 'Action Library', 'debugging', 'browser support', 'duplicate, delete, move, rename'. It is not a 5 because common user variations such as 'Selenium', 'Taurus', 'scriptless tests', or 'cross-browser testing' are absent; it is above a 3 because the phrases present are ones a BlazeMeter user would naturally say.

4 / 5

Distinctiveness Conflict Risk

The niche is clear ('BlazeMeter Functional Testing' with scoped triggers), and the deprecation note ('API Functional Tests are deprecated in favor of API Monitoring') actively disambiguates from the adjacent API Monitoring skill. It falls short of 5 because generic phrases like 'Debugging Functional Tests' and the trailing 'any other Functional Testing tasks' leave minor overlap risk with sibling BlazeMeter skills (performance testing, test data, recorders).

4 / 5

Total

18

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 5 missing, 5 deeper-than-1-level

Warning

Total

15

/

16

Passed

Repository
Blazemeter/bzm-mcp
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.