I’m a QA engineer

QualityMax keeps QA work connected from a test case to the executable automation and the evidence from its runs. Use this path to decide how to organize existing test assets before you generate or migrate anything.

Start with test cases and coverage

The core concepts define the hierarchy: projects contain test cases, and a test case can have one or more automation scripts. This separation keeps a scenario readable even when its browser or API implementation changes.

Coverage is evidence, not just a count. For each important behavior, keep the test case’s intent, the script that exercises it, and the execution result aligned. The web app quickstart shows how generated test cases move into a runnable workflow.

Use QTML for portable test intent

QTML (Quality Testing Meta Language) is a declarative, natural-language-oriented format for describing tests. QualityMax can parse and validate QTML, import QTML documents into projects as test cases, and export projects and test cases back to QTML. That makes it useful when a team wants a reviewable test definition in addition to the generated implementation.

Before relying on a QTML import, validate a small representative set and compare the resulting test cases with the intended behavior. Keep the source document and the execution evidence together so changes remain auditable.

Bring in TestRail work deliberately

QualityMax supports importing test cases from TestRail suites and mapping TestRail statuses to QualityMax statuses. Use a limited project or suite first: verify the case names, status mapping, and ownership conventions before expanding the integration.

Suggested first session

1. Model one product area with clear test cases.
2. Import or write a small QTML sample and review the resulting cases.
3. Pilot one TestRail suite, then use run evidence to assess real coverage.