The same question before every release. Which requirement was tested, and with what result?
Test cases sit in one tool, work items in a second, requirements in a third, and the report comes out of a spreadsheet. What connects them is a column of numbers somebody maintains by hand.
- 01
The defect loses its link to the requirement along the way.
- 02
Coverage lives in a spreadsheet that is already out of date by release day.
- 03
A test run cannot be repeated without assembling it again.
The link is made while working. Not at reporting time, and not in a second spreadsheet.
01
Test cases on the requirement
A test case hangs off the story or requirement it came from. The link is a relation in the system, not a number in a column.
02
Test runs with environment and assignment
A run records who tested, on which environment and with what result. Repeating means starting, not assembling again.
03
Defect as a work item, straight from the step
A failed step becomes a work item in the same cycle, carrying the step, the environment and the run.
04
Coverage from real data
Which requirement was tested how often and with what outcome is read from the runs. The hand-kept matrix goes away.
05
QualityTree as the frame
The framework is part of the platform. Maturity levels and practices hang off the same test cases and runs your team works with, instead of living beside them in a deck.
Everything for the evidence, in one space.
Requirement with test case
Testing, issue, document and repetition
One data set for quality assurance
Test run with a result per case
Defect becomes a task in the same project
Quality gate
Coverage from the runs
Quality snapshot
Pass rates across releases
Test plan next to the requirement
Environment and assignment
Regression testing before a release. From the test plan to the published report.
The apps behind it. All in the same space, no second tool.
Test Management carries the testing, Projects the work items beside it, Docs the requirements and Automation the repetition.
Test Management
Quality assurance in the same space, with test cases and runs attached to the task.
Projects
Agile project management for product and engineering teams, with cycles and releases.
Docs
The wiki for your team's knowledge, with version history and export to PDF, DOCX and Markdown.
Automation
Workflows without code, triggered by events from any app.
Connected to the workbench. Six connections from everyday testing.
Builds from version control, error data from production, work items from an existing tool, results into the channel.
One product, one vendor. Test Management is not a separate product.
Test management belongs to the same product as work items and documentation. There is no second tool for the test cases and no add-on to keep running alongside.
One contract, one contact, one roadmap.
No marketplace and no third-party add-ons to run.
Operated in a Swiss data centre or on your own hardware.
Evidence for the compliance review
Information security is certified to ISO 27001 and processing meets the nFADP and the GDPR. The documents are ready before you ask for them.
Questions from test management. Five that come up in almost every first conversation.
Can we feed in automated test results?
Results can be reported to a test run today through the HTTP integration.
How is a requirement linked to a test case?
As a relation between two objects in the same space, visible in both directions: the requirement shows its test cases, the test case shows its requirement.
Are there coverage metrics?
Yes, read from the runs: tested, open and failed, per requirement and per release.
Can we manage environments and test data?
Environments hang off the test run and can be reported on. Test data goes into a Registry directory with the fields you need.
Is QualityTree part of the product?
Yes, the framework belongs to the product like every other module. What Collabase costs in your case is set in the quote, once scope and operating model are clear.
Other disciplines in the same system.
Test it against your own content. A proof of concept is ready within days.
We set up an instance with your content and you test it against real workflows. In a first conversation we clarify scope, operating model and timing.