Qase brings a test repository, planned scope, run results, and defects together. This helps when manual testing and automation need consistent terminology and reporting for a specific delivery. Distinguish a test's instructions from observations during execution: editing a case does not mean the product was retested, and yesterday's green run does not validate today's build.
Repository, plan, run, and result
A project defines the work area, suites organize cases, and a test case describes a scenario to check. A Qase test plan is a reusable case selection, rather than a complete test strategy document. A test run is an execution event with participants and context; a result is the outcome of one case within that run. A defect links an observation to corrective work. Plans can be reused, while results belong to particular runs and dates.
Building a useful repository
Organize the product into stable areas and choose names that express a condition and expected effect. “A blocked user cannot create an order” is more precise than “User check.” Describe preparation, test data, and how to observe the result. Automation attributes, priority, and links support selection but cannot replace meaningful scenarios. Draft ideas can be captured quickly; before entering release scope, they must become executable checks.
Selecting by risk and configuration
Choose minimal critical journeys for smoke testing and checks of changed areas and likely side effects for regression. Agree how to represent browser, device, and role: configurations, separate runs, or case parameters. Avoid dozens of copies when only input values differ. Parameterization must still preserve distinct expectations. An incorrect password and a disabled account may require separate scenarios despite sharing a login form.
Practice: importing contacts
A team is changing CSV import. Requirements promise correct UTF-8 handling, rejection of rows without email, and no duplicate contacts on repeat upload. Three safe files are prepared: two valid contacts with Cyrillic text, a row without email, and a repeat of the first file. Addresses use a test domain and real email delivery is disabled. Verify final data and the import report, beyond successful upload completion.
- 1.Create encoding, validation, and repeat-import cases in an import suite. State the initial contact count and expected change in each.
- 2.Build an import test plan, then a run for the required build and configuration. Its contents should be clear, with no accidentally included unfinished drafts.
- 3.Upload the valid file. Verify two created contacts, preserved Cyrillic text, and agreement between the final report and actual data.
- 4.Upload the file without email. Expect the agreed row error and no invalid contact; retain a sanitized file and the actual message.
- 5.Upload the first file again. The approved duplicate policy determines whether to reject or update, but contacts must not multiply unexpectedly.
- 6.Record each case result and link failures to defects. After fixes, repeat affected checks on a new build while preserving previous observations.
Statuses and accurate execution reporting
Distinguish passed, failed, blocked, skipped, and invalid according to team rules and project settings. An unavailable import service is different from a UTF-8 handling defect: execution may never have reached that step. An inapplicable case should not silently improve the pass rate. Result comments should explain the observation, blocker, and next step without requiring readers to reconstruct a messaging conversation.
What happens when a case changes
According to Qase's current documentation, source-case changes can synchronize into an active run while that check has no result. Once a result is recorded, the executed version is retained. Starting a run therefore does not unconditionally freeze every instruction. Coordinate substantial edits with active testers; otherwise, different people may follow different instructions within a run sharing one name and start date.
Connecting automated results
Use a stable Qase ID to link automated tests to cases, and agree on run creation and configuration reporting. For parallel execution, decide how jobs add results to a shared run and who completes it after the final shard. One early-finishing job must not close the whole run. Test a small set with an intentional failure, skip, and attachment, then reconcile launched tests, received results, and missing records.
A Qase plan does not always filter automated tests
Linking a reporter to a test plan and restricting actual execution are separate operations. Selective execution depends on the language, framework, and reporter. Current documentation distinguishes implementations that filter the test collection from those that only send results to a linked run. Check the actual executed list in a pilot. Installing a reporter alone does not guarantee execution of only the selected plan's cases.
Reporting and repository maintenance
For release decisions, state the build, environment, executed scope, untested scenarios, and open defects. Compare pass rates only for comparable sets; excluding difficult cases can artificially improve the chart. Remove duplicates thoughtfully, review outdated preconditions, and assign owners to important scenarios. Sanitize attachments of personal data and secrets, especially before creating external report links. Check report accessibility and the acceptability of its contents separately.
Common mistakes and practical lessons
Problems arise when a plan is treated as a strategy, runs are named only by date, drafts enter mandatory regression, or missing results count as success. Uploading thousands of automated tests without stable mapping and run-completion rules is another mistake. Effective Qase use provides current cases, clear selections, and verifiable result history. The tool then helps QA explain release status and choose the next useful check.