Use case · Test planning

Test plan from the OEM spec sheet

Instead of collecting requirements from the spec by hand and checking them against standards: Cevelar extracts the obligations, maps them to UN 38.3, IEC 62619, and the EU Battery Regulation, and derives a defensible test plan. Fewer senior-days, less audit rework, less Polarion maintenance.

Book a briefing Try the demo
  • Spec → test plan
  • Gaps visible early
  • Export to Polarion/Jira
Spec 2847-B · mapping3 of 4 mapped
  1. §4.3.2Vibration 3-axisTC-014Vibration packOK
  2. §4.5.1Thermal shockTC-021Thermal shockOK
  3. §6.1Salt spray 96 h——Gap
  4. §7.2ReportingR-3Test reportOK
Excerpt · demo data

Context

From spec sheet to test plan

An OEM spec mixes prose, tables, translations and standard references. Validation teams read it line by line into Excel. The expensive failure is not a lab fail. It is a sentence that never became a requirement with an ID.

Cevelar reads PDF, DOCX or XLSX, splits sentences into obligations, attaches clauses (UN 38.3, IEC 62619, OEM) and flags what has no test case. The plan is the input for lab booking and for Arc.

What gets lost when it stays manual

  • One sentence, two languages, two obligations. The second sits after the semicolon.
  • A standard without a section. “Per UN 38.3” is not traceability.
  • OEM hardness only in email. The rig never sees it.

More on the flow: validation planning in three steps.

Impact

The plan is born where the spec lives.

Spec → test plan Traceability, not keyword search
Gaps early Visible before the lab, not in the audit
  1. Extract requirements Pull obligations from prose, tables, and multilingual specs — including what sits after the semicolon.
  2. Decompose & sharpen One sentence, two obligations: separate ambiguous requirements into individually testable statements.
  3. Map standards Bind each obligation to its clause (UN 38.3, IEC 62619, EU Battery Regulation, ASPICE).
  4. Derive the test plan Test cases, acceptance criteria, and coverage — open gaps stay clearly flagged.

Distinction

Excel/ALM vs. Cevelar

Excel & ALM (Polarion/Jira/DOORS)

  • StrengthStore & manage tests
  • GapDo not extract and map specs
  • RiskTraceability breaks on change

Cevelar

  • StrengthSpec → test plan with standards mapping
  • GapMakes missing test cases visible
  • ExportInto existing ALM tools

For heads of validation

Fewer senior-days per test plan.

The test plan is already in the quote, traceability is ready before the ASPICE assessment, and audit rework drops because gaps show up early. Cevelar delivers this from the spec, EU-hosted — as a complement to your ALM, not a replacement.

FAQ

Spec-to-plan questions

What the plan has to do with the spec sheet.

Why not just Excel?

Excel does not hold bidirectional traceability. IDs, clauses and spec pages vanish at the next OEM revision. The auditor starts at the evidence and has to walk back to the page in the spec.

Which files can Cevelar read?

Typically PDF, DOCX and XLSX. Mixed languages in the same sentence are the normal case, not the exception.

What is the output?

Structured requirements, mapped test cases, flagged gaps, a sequence and an export that ALM tools and the lab understand.

Does the spec stay with the customer?

Yes. Processing is EU-hosted in Frankfurt. Cevelar does not train public models on your spec sheets.

Read on

Applications & standards

All use cases

Contact

Derive a test plan from a real spec.

Book a briefing or start the demo. We reply personally.

Book a briefing Try the demo