In an Allure 2 report, what does the severity view show for a test whose result carries no `severity` label, and for one whose severity value is misspelled?

middleshould knowfreq 48%

answer

an ordinary label, not a typed field
five levels, lowercase on the wire
no match means the default wins
absent and normal look identical

basics

~20 s

Both land on normal. Allure 2 reads the severity label, matches it against blocker, critical, normal, minor and trivial, and falls back to normal when the label is absent or the value matches none of them. Nothing warns you.

solid answer

~40 s

severity is an ordinary label -- a name and a value -- and the report resolves that value against the five levels SeverityLevel declares: BLOCKER, CRITICAL, NORMAL, MINOR, TRIVIAL, written lowercase on the wire. Allure 2 looks for one severity label, tries to match its value, and where either step comes up empty it substitutes normal. So an unlabelled test and a deliberately normal one are indistinguishable in the report, and critcal becomes normal in silence. Matching ignores case, so Critical is fine; only a value outside the five falls through. This is the opposite of how the tree labels behave: a missing suite removes a level from the tree, whereas a missing severity is filled in with a default.

`severity` is an ordinary label -- a name and a value -- and the report resolves that value against the five levels `SeverityLevel` declares: `BLOCKER`, `CRITICAL`, `NORMAL`, `MINOR`, `TRIVIAL`, written lowercase on the wire. Allure 2 looks for one `severity` label, tries to match its value, and where either step comes up empty it substitutes `normal`. So an unlabelled test and a deliberately normal one are indistinguishable in the report, and `critcal` becomes `normal` in silence. Matching ignores case, so `Critical` is fine; only a value outside the five falls through. This is the opposite of how the tree labels behave: a missing `suite` removes a level from the tree, whereas a missing `severity` is filled in with a default.

code

json · 7 lines

json

{
  "name": "checkout rejects an expired card",
  "status": "failed",
  "labels": [
    { "name": "severity", "value": "critcal" }
  ]
}

go deeper

for a junior

Recall that severity is a label whose value is one of five levels -- blocker, critical, normal, minor, trivial -- written in lowercase on the result file.

for a middle

Explain the two routes to normal: no severity label at all, and a value matching none of the five. Say that the comparison ignores case, so capitalisation is not the trap.

for a senior

Point out what the default costs a reader of a consolidated report: you cannot tell an untriaged suite from one that deliberately chose normal, and no view in the report will tell you which you are looking at.

for a principal

Decide whether an absent severity should read as normal or as a gap in the suite, and be able to say what you would add upstream to make that distinction visible at all.

Severity is a label, not a field

Nothing on an Allure test result is called "severity". What exists is an ordinary entry in the labels array whose name happens to be severity and whose value is a string. The five levels live in SeverityLevel -- BLOCKER, CRITICAL, NORMAL, MINOR, TRIVIAL -- and each is written to the file in lowercase: blocker, critical, normal, minor, trivial.

That framing explains everything that follows. A field could be typed and validated at the point of writing. A label value is just a string in a list, so validation can only happen later, in whatever reads it -- and the reader has to decide what to do with a string it does not recognise.

The two roads to `normal`

When Allure 2 prepares a result for its severity view it does two things in sequence:

Look for one severity label. If the result carries none, there is nothing to resolve.
Match the value against the five levels. The comparison ignores case, so Critical, CRITICAL and critical all resolve to the same level. A value that matches none of the five resolves to nothing.

If either step comes up empty, the result is treated as NORMAL. That single fallback is doing a lot of quiet work:

what the result actually carries	what the report shows
no `severity` label at all	normal
`severity` = `normal`	normal
`severity` = `Critical`	critical -- case is not the problem
`severity` = `critcal` (typo)	normal
`severity` = `high` (wrong vocabulary)	normal

Rows one, two, four and five are indistinguishable in the report. A suite that never set severity, a suite that set it deliberately, a suite with a typo and a suite using a different vocabulary all read the same.

Why the silence is the interesting part

There is no warning, no rejection and no separate bucket for unusable values, and there is a good reason for that: the label is a free string by design, so an unrecognised value is not an error condition. The report cannot tell a typo from a deliberate label the report simply does not group on.

The consequence is that the severity view is not evidence about the suite. It tells you how the report chose to display each result; it does not tell you how many results actually declared a severity. If someone asks "how much of our regression pack is marked blocker?", the severity view can answer that. If they ask "how much of it has never been triaged for severity at all?", the view cannot answer it, because the untriaged tests are sitting inside the normal bar.

To answer the second question you have to go back to the result files and count how many carry a severity label at all -- or arrange for the thing writing the results to stamp a value that means "nobody said", so that absence has its own name.

The contrast with the tree labels

This is worth holding next to the other well-known label group, because the two behave in opposite directions and knowing that is what separates a memorised answer from an understood one:

parentSuite / suite / subSuite, and epic / feature / story. A missing value drops a level from the tree. Absence removes structure.
severity. A missing value is replaced by a default. Absence invents a value.

Both are silent, and both are the report making a decision on your behalf. Neither is wrong -- a tree level named "unknown" would be noise, and a severity view with a sixth "no idea" bar would be too -- but they fail in ways that look nothing alike, so the diagnosis differs.

Duplicates

labels is a list, so a result can carry two severity labels. The report asks for a single one and takes whichever it finds; which one that is, is not defined by anything you can rely on. A result carrying both critical and minor will render under one of them, consistently enough to be confusing and arbitrarily enough to be wrong.

Treat duplicate severity labels as a defect in whatever wrote the results -- typically an annotation on a class and another on the method, or an adaptor adding one on top of an explicit one -- rather than as a precedence rule to learn.

What to take away

severity is a label whose value is one of five lowercase strings; matching is case-insensitive.
Absence and non-matching values both resolve to normal, silently.
The severity view therefore cannot distinguish "marked normal" from "never marked".
If that distinction matters to you, it has to be created upstream, where the results are written.

## Severity is a label, not a field Nothing on an Allure test result is called "severity". What exists is an ordinary entry in the `labels` array whose `name` happens to be `severity` and whose `value` is a string. The five levels live in `SeverityLevel` -- `BLOCKER`, `CRITICAL`, `NORMAL`, `MINOR`, `TRIVIAL` -- and each is written to the file in **lowercase**: `blocker`, `critical`, `normal`, `minor`, `trivial`. That framing explains everything that follows. A field could be typed and validated at the point of writing. A label value is just a string in a list, so validation can only happen later, in whatever reads it -- and the reader has to decide what to do with a string it does not recognise. ## The two roads to `normal` When Allure 2 prepares a result for its severity view it does two things in sequence: 1. **Look for one `severity` label.** If the result carries none, there is nothing to resolve. 2. **Match the value against the five levels.** The comparison ignores case, so `Critical`, `CRITICAL` and `critical` all resolve to the same level. A value that matches none of the five resolves to nothing. If **either** step comes up empty, the result is treated as `NORMAL`. That single fallback is doing a lot of quiet work: | what the result actually carries | what the report shows | |---|---| | no `severity` label at all | normal | | `severity` = `normal` | normal | | `severity` = `Critical` | critical -- case is not the problem | | `severity` = `critcal` (typo) | normal | | `severity` = `high` (wrong vocabulary) | normal | Rows one, two, four and five are indistinguishable in the report. A suite that never set severity, a suite that set it deliberately, a suite with a typo and a suite using a different vocabulary all read the same. ## Why the silence is the interesting part There is no warning, no rejection and no separate bucket for unusable values, and there is a good reason for that: the label is a free string by design, so an unrecognised value is not an error condition. The report cannot tell a typo from a deliberate label the report simply does not group on. The consequence is that **the severity view is not evidence about the suite**. It tells you how the report chose to display each result; it does not tell you how many results actually declared a severity. If someone asks "how much of our regression pack is marked blocker?", the severity view can answer that. If they ask "how much of it has never been triaged for severity at all?", the view cannot answer it, because the untriaged tests are sitting inside the normal bar. To answer the second question you have to go back to the result files and count how many carry a `severity` label at all -- or arrange for the thing writing the results to stamp a value that means "nobody said", so that absence has its own name. ## The contrast with the tree labels This is worth holding next to the other well-known label group, because the two behave in opposite directions and knowing that is what separates a memorised answer from an understood one: - **`parentSuite` / `suite` / `subSuite`, and `epic` / `feature` / `story`.** A missing value **drops a level** from the tree. Absence *removes* structure. - **`severity`.** A missing value is **replaced by a default**. Absence *invents* a value. Both are silent, and both are the report making a decision on your behalf. Neither is wrong -- a tree level named "unknown" would be noise, and a severity view with a sixth "no idea" bar would be too -- but they fail in ways that look nothing alike, so the diagnosis differs. ## Duplicates `labels` is a list, so a result can carry two `severity` labels. The report asks for a single one and takes whichever it finds; which one that is, is not defined by anything you can rely on. A result carrying both `critical` and `minor` will render under one of them, consistently enough to be confusing and arbitrarily enough to be wrong. Treat duplicate severity labels as a defect in whatever wrote the results -- typically an annotation on a class and another on the method, or an adaptor adding one on top of an explicit one -- rather than as a precedence rule to learn. ## What to take away - `severity` is a label whose value is one of five lowercase strings; matching is case-insensitive. - Absence and non-matching values both resolve to `normal`, silently. - The severity view therefore cannot distinguish "marked normal" from "never marked". - If that distinction matters to you, it has to be created upstream, where the results are written.

Two `severity` labels end up on one result. Which one does the report use?
Only one, and which one is not something to rely on. The report asks for a single `severity` label and takes whichever it finds, so a result carrying both `critical` and `minor` renders under one of them arbitrarily. Treat duplicates as a defect in whatever wrote the result rather than as a precedence rule.
How would you find out which suites never set severity at all?
Not from the severity view -- everything unlabelled already reads as normal there. You have to go back to the result files and count how many carry a `severity` label at all, or arrange for the writer to stamp a distinct value when nobody supplied one, so that absence has a name of its own.

saying these in an interview costs you the question

Thinks severity is a typed field on the result
Expects a misspelled value to raise an error
Assumes an unset severity is left blank
Believes severity changes whether the test passes

In an Allure 2 report, what does the severity view show for a test whose result carries no `severity` label, and for one whose severity value is misspelled?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Severity is a label, not a field

The two roads to normal

Why the silence is the interesting part

The contrast with the tree labels

Duplicates

What to take away

▾common follow-ups2 questions

▾red flags4 flags

Severity is a label, not a field

The two roads to normal

Why the silence is the interesting part

The contrast with the tree labels

Duplicates

What to take away

answer

go deeper

The two roads to `normal`

The two roads to `normal`