Skip to content
Back to skills

Automated Testing

ASecurity

Define how to automate tests (unit, integration, system/HIL where feasible) in CI/CD pipelines for medical devices with gating and evidence capture.

  • 8 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added June 6, 2026
testingrusttestingci/cd

Security analysis

A100/100

Scanned June 6, 2026

npx -y skills add lilinji/GeneTind-Life-Skills --skill automated-testing --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Automated Testing?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Automated Testing
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/lilinji-automated-testing/badge)](https://www.skillsdirectory.com/skills/lilinji-automated-testing)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
skill_id: CICD-AUTO-TEST
version: 1.0.0
last_updated: 2026-01-04
applies_to: [Class A, Class B, Class C]
jurisdiction: [Global]
prerequisites: [TEST-UNIT, TEST-INTEGRATION]
---

# Automated Testing in CI/CD

## Purpose
Define how to automate tests (unit, integration, system/HIL where feasible) in CI/CD pipelines for medical devices with gating and evidence capture.

## When to Apply
- Setting up or updating test stages in CI/CD.

## Requirements (testable)
1. Scope: Include unit, integration, and where possible system/HIL or simulators; prioritize safety-related modules. Rationale: coverage of risk areas.
2. Gating: Fail pipeline on test failures; no ignored failures for safety code. Rationale: prevent regressions.
3. Artifacts: Store test results (JUnit/XML), logs, coverage, and evidence; retain per release. Rationale: auditability.
4. Flake Management: Detect and address flaky tests; quarantine with issue filed and timeline; do not ignore. Rationale: trustworthiness.
5. Hardware Tests: If hardware required, provide conditional stages and fallbacks (sim); schedule regular hardware runs (nightly). Rationale: practicality with coverage.

## Recommended Practices
- Tag tests by type/priority; run critical ones on every commit.
- Use retries sparingly and only for known flaky, with tracking.
- Parallelize to keep feedback fast.
- Use containerized or pinned environments.

## Patterns
CI job snippet:
```yaml
test:
  script: [ "ctest --output-on-failure" ]
  artifacts:
    when: always
    paths: [ "build/test-results.xml", "coverage/" ]
```

Flake tracking entry:
```yaml
test_id: TEST-INT-210
status: flaky
issue: QA-1234
expires: 2026-02-01
```

## Anti-Patterns (risks)
- Allowing tests to fail without blocking or tracking -> risk: regressions.
- No artifacts/logs retained -> risk: unverifiable results.
- Silent retries masking real failures -> risk: shipping defects.

## Verification Checklist
- [ ] Unit/integration (and sim/HIL if available) tests run in CI.
- [ ] Failures gate merges; no ignored failures for safety code.
- [ ] Results/logs/coverage stored as artifacts per run/release.
- [ ] Flaky tests tracked with issues and timelines.
- [ ] Hardware-dependent tests scheduled; sim fallback provided.

## Traceability
- Link CI test runs to test IDs (`TEST-###`) and requirements; store artifacts with release metadata.

## References
- IEC 62304 verification expectations.
- FDA/MDR submission evidence needs.

## Changelog
- 1.0.0 (2026-01-04): Initial automated testing skill with gating and artifact capture.

## Audit History
- **2026-01-04**: Audit performed. Verified:
  - IEC 62304 verification expectations correctly referenced
  - CI/CD patterns follow industry best practices for regulated environments

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…