Test Management & Reporting
Where cases, runs and defects live once a suite outgrows a spreadsheet: planning a cycle and linking results back to requirements. Interviewers ask how you prove what was tested.
on this pageshowhide
explore
- Case Inventories90 questions
- Suite and Folder Shape19 questions
- Cycles and Executions17 questions
- Requirement and Defect Links17 questions
- Versions and Baselines18 questions
- Feeds, Tokens and Exports19 questions
- Result Consolidation95 questions
- Interchange Schemas20 questions
- Steps and Attachments19 questions
- History and Trends17 questions
- Grouping and Labelling21 questions
- Delivery and Verdicts18 questions
questions
185 · 2 sectionsIn a TestRail-class test management product, what does assigning a test cycle item to a named tester change, and what does that tester's queue show?
basics
~20 sAssignment records an owner on one cycle item, so it leaves the shared pile and appears in that tester's filtered queue. It changes nobody's result: an assigned item stays untested until an outcome is recorded.
In a TestRail-class case repository, a requirement-coverage panel reports a single percentage — what sits in the numerator and what forms the denominator?
basics
~20 sThe denominator is the set of requirements the panel's saved filter selects; the numerator is how many of those satisfy the panel's configured covered condition. The unit counted is the requirement, not the test case.
In a TestRail- or Xray-class test case repository, what does attaching a variant table to one stored case do, and how does a placeholder in a step get its value?
basics
~20 sA variant table holds one row of values per run of the same stored case. Placeholders in the step text name a column, and the repository substitutes that row's value, producing one execution per row.
Before a TestRail-class case repository can create a defect in a separate issue tracker, what must the two systems agree on about the destination?
basics
~20 sTwo things, as a pair: which tracker project receives the item, and which item type it is created as. Trackers attach mandatory fields, closed value lists and workflow to that pair, so the mapping is defined against it.
In a TestRail-class case repository, what does filing a defect straight from a failed execution pre-fill into the new tracker item?
basics
~20 sFiling from a failed execution pre-fills the draft ticket with the run's context: which case failed, which cycle it ran in, the environment or build under test, who recorded the result, and the comment and evidence captured at failure time.
In an Allure results directory, what does a `-container.json` file hold, and how does it relate to the `-result.json` files beside it?
basics
~10 sA -container.json file holds Allure's TestResultContainer: setup in befores, teardown in afters, and a children list naming by uuid the results it wraps. The test bodies themselves live in separate -result.json files.
In an Allure results directory, where do the bytes of an attached screenshot or log actually live, and what does the matching `Attachment` entry inside a `-result.json` file hold?
basics
~20 sThe bytes live in a file of their own in the results directory, named with a random UUID, the suffix -attachment, and the file's extension. The JSON entry beside the test holds only a pointer: name, source and type.
On a test result in an Allure 2 report, what do the `retriesCount` and `retriesStatusChange` fields say, and what does `retriesCount` deliberately not include?
basics
~20 sretriesCount is how many earlier attempts were folded into this result, so it excludes the attempt on screen; a test executed twice reads one. retriesStatusChange is true when any earlier attempt ended in a different status.
An Allure 2 report is regenerated on every CI build, yet its trend chart always shows a single point and each test case page shows only the current run. What is missing, and where does Allure 2 get trend data from?
basics
~20 sThe previous report's history directory is missing. Allure 2 keeps no database: it builds trends only from a history folder already present in the results directory it reads, so you copy that folder in from the last report before generating.
In ReportPortal, a launch's generated error clusters are returned as `ClusterInfoResource` objects. What do the `index`, `message`, `matchedTests` and `launchId` fields on one of them tell you?
basics
~20 smessage is the shared failure text the group formed around, matchedTests counts the test items in it, index is the identifier the analyzer gave the group, and launchId scopes the cluster to a single launch.