<!--
SURESOFT verification suite overview (landing page) web page copy (overview_contents.md) [EN]
- Publication-ready copy, tables, and figures written in web page section order
- [Section n | Component] comments: screen composition notes for that block (design reference only, not published)
- Editorial principle: the landing page covers "what value each product delivers + a feature summary" only;
  detailed explanations are linked out to each product page (Learn more)
- Source of facts: the docs/static, docs/ct, and docs/cover product copy (inheriting their underlying sources)
- Images: overview/images (to be newly produced; see the image production notes in each section)
-->

<!-- [Section 1 | Hero: H1 + definition + metric strip + key diagram + CTA] -->

# SURESOFT Verification Suite | Code Verification for Mission-Critical Software

The Suresofttech (SURESOFTTECH) verification suite supports code verification for mission-critical software in three stages: before the code runs (STATIC), while tests are designed and executed (CT), and by confirming how much of the code those tests actually executed (COVER).

<!-- Use the definition above verbatim as the meta description -->

<!-- Metric strip: 4-column cards. Set the value of each item large and the label small -->

- **Verification products** — STATIC · CT · COVER
- **Static analysis inspection patterns¹** — 1,200+
- **Measurable code coverage types²** — up to 10
- **Application domains** — automotive · aerospace · defense · railway · nuclear · medical

¹ Based on STATIC Enterprise.
² Based on COVER Enterprise; Standalone supports up to 7. The supported scope varies by edition, language, and product version, so the detailed applicable scope must be confirmed against your own environment.

*Before the code runs, while the tests run, and from the results — each product verifies a different point in the development flow*

**[Request a Demo](https://www.suresofttech.com/customer/inquiry.php)** · **[Talk to Us About Your Environment](https://www.suresofttech.com/customer/inquiry.php)**

---

<!-- [Section 2 | 3 problem cards + summary statement] -->

## Why code verification is needed

**"The build passed and testing is done" is not a verification result.**

- **A successful compile does not mean there will be no defects at runtime** — memory leaks, NULL dereferences, and array-bound overruns pass compilation and survive into execution.
- **A "testing complete" report without numbers behind it** — if you do not know which code actually ran, defects in the branches and conditions your tests never reached simply remain.
- **Standards ask for records, not just activities** — safety and regulated projects must leave behind, in reviewable form, what was verified and against which criteria.

These three problems are addressed by different verification activities. Defects found without running the code, behavior confirmed by designing and executing tests, and the indicator showing how much of the code those tests executed each belong to a different tool.

---

<!-- [Section 3 | Key diagram + 3-column summary table. The central block of the landing page] -->

## The three products across the development flow

**STATIC works before execution, CT designs and executes the tests, and COVER verifies from the test results.**

| Aspect | STATIC | CT | COVER |
|---|---|---|---|
| Verification method | Static analysis (no code execution) | Dynamic testing (test design and execution) | Dynamic analysis (measurement of execution results) |
| Question it answers | Does this code contain rule violations and latent defects? | Does this code behave as intended? | How far into the code did the tests reach? |
| Primary stage | Coding, commit, build | Unit and integration testing | From unit testing through system and target testing |
| Representative output | Defect list, rule compliance rate, quality metrics | Test results, requirements traceability, coverage | Coverage indicators, unexecuted code, measurement reports |

> **How does coverage in CT differ from COVER?** CT provides coverage for the unit and integration tests it designs and executes, while COVER measures coverage from the execution results of testing you already perform (manual testing, system testing, real-target testing, and so on). Used together, they let you manage coverage obtained from requirements-based testing separately from the structure-based testing that fills the remaining gaps.

---

<!-- [Section 4 | 3 product cards (same format: definition → 3 value points → feature summary → Learn more)
     ★ Place one representative screen image per card.
     ★ Detailed specifications (rule lists, coverage type definitions, integration matrices) stay off the landing page and belong to the product pages. -->

## The products at a glance

### STATIC — Source Code Static Analysis

A static analysis tool that detects coding rule violations, runtime errors, and potential security vulnerabilities without executing the source code.

**What it delivers**

- **Runtime error detection without execution** — more than 1,200 inspection patterns and more than 30 kinds of semantic analysis find memory, arithmetic, and array-bound errors before the code is ever run.
- **Automatic checking against domain rule sets** — automatically checks coding rules such as MISRA, AUTOSAR C++14, and CERT, CWE-based security weaknesses, and items from DAPA, HKMC, and Ministry of the Interior and Safety guidelines.
- **Management that does not stop at detection** — tracks defect status and assignees, and manages quality trends with the rule compliance rate (RCR) and defect density.

**Feature summary** — coding rule inspection · runtime error detection · software quality metrics · defect management and objective tracking · AI-assisted remediation (Smart Suggestion, Agent Chat) · CI and configuration management integration

**Editions** — Enterprise (web server-based central management; C/C++, C#, Java, Kotlin, Python) / Standalone (VS Code-based IDE; C/C++)

<!-- Representative image: reuse the asset from the STATIC product copy (no new capture needed) -->
![Example of the STATIC Enterprise project list screen. For each project the language, manager, remaining/suppressed/new/closed defect counts, and latest analysis time are displayed, so the code quality status of multiple projects can be compared at a glance.](../static/images/projects-list.png)
*Project static analysis status — compare the analysis status and defect indicators of multiple projects on one screen*

[Learn more about STATIC →](../static/static_contents.md)

### CT — Dynamic Code Verification

A test automation solution for unit, integration, and code-based testing of mission-critical C/C++ software. It connects test environment setup, test design and generation, execution, code coverage analysis, reporting, and traceability management into a single flow.

**What it delivers**

- **Unit and integration verification in one flow** — manages test conditions and data, designs and executes tests at the function, module, and interface level, and confirms them with statement, branch, and MC/DC coverage.
- **Less repetitive work in test design** — ALIRA AI inside the product and DVERA, the integration solution for AI coding agents, assist with test design, generation, and error analysis. Generated tests are verified against actual execution results and code coverage.
- **Verification that leaves evidence behind** — links requirements, tests, execution results, and coverage for use as review reports and traceability records.

**Feature summary** — unit and integration test design and execution · reuse of existing Google Test assets · statement/branch/MC/DC coverage with control flow views · ALIRA AI · DVERA · CI-based repeated verification · team testing · ALM (Polarion, codebeamer) and V-SPICE integration

**Tool certification** — CT holds TÜV SÜD tool certification for ISO 26262, IEC 62279/EN 50716, IEC 60880, IEC 62304, and IEC 61508. The certification applies to a specific CT version and the functional scope defined in the Certification Report.

<!-- Representative image: reuse the asset from the CT product copy (no new production needed) -->
![Example of CT code coverage results — C/C++ code, statement, branch, and MC/DC coverage per function, and a control flow graph on one screen. The figures shown are examples.](../ct/images/ct-code-coverage-ui-en.png)
*Code coverage and control flow — review under-covered code together with its execution paths*

[Learn more about CT →](../ct/ct-product-page.md)

### COVER — Test Coverage Measurement

A dynamic analysis tool that analyzes test execution results as code coverage to confirm the sufficiency of software testing.

**What it delivers**

- **Multiple coverage types from a single test run** — Enterprise measures up to 10 coverage indicators and Standalone up to 7 from the results of a single test execution.
- **Measurement without changing your test procedure** — after the initial integration setup, you continue to use your existing compilers, IDEs, and test methods, and application source code is not modified manually.
- **Measurement all the way to embedded targets** — a proprietary probe insertion method ([Korean Patent No. 10-1667262](https://patents.google.com/patent/KR101667262B1/en)) keeps the probe code small, so measurement is possible even on targets with little memory headroom. Execution overhead is around 10%.³

**Feature summary** — function, statement, line, branch, and MC/DC coverage measurement · per-line execution display and MC/DC truth tables · changed-function and changed-line coverage (EE) · organization-level aggregation and reporting (EE) · embedded target measurement (SE) · built-in measurement criteria per standard and guideline · Open API and CI integration

**Editions** — Enterprise (agent + server + web; C/C++, C#, Java) / Standalone (local PC installation; C/C++, C#)

³ Actual overhead varies with the language, target performance, the coverage types measured, and the instrumentation scope.

<!-- Representative image: reuse the asset from the COVER product copy (no new capture needed) -->
![Example of the COVER Enterprise module detail screen. A per-file coverage tree, a statement coverage summary, a bar chart of the 10 coverage types, and a test priority list are shown together. The figures on screen are example data.](../cover/images/module-overview.png)
*Module coverage status — coverage summary, coverage types, and test priorities on one screen*

[Learn more about COVER →](../cover/cover_contents.md)

---

<!-- [Section 5 | Selection guide: situation → product table. Give the decision criteria only and link details to product pages] -->

## Which product do you need?

| What you need right now | Where to start |
|---|---|
| Check and evidence compliance with coding rules (MISRA, CERT, and others) | STATIC |
| Filter out memory, arithmetic, and boundary errors that are hard to reproduce in testing | STATIC |
| Manage code quality trends and defect handling across the organization | STATIC (Enterprise) |
| Design and execute unit and integration tests and produce test records | CT |
| Maintain traceability linking requirements to tests and execution results | CT |
| Generate and run tests inside an AI coding agent workflow | CT (DVERA) |
| Measure how much code your existing tests actually execute | COVER |
| Measure coverage on a real target board | COVER (Standalone) |
| Consolidate coverage scattered across teams and servers into one report | COVER (Enterprise) |
| Build verification evidence for the highest grades such as ASIL D or Software Level A | STATIC + CT + COVER |

---

<!-- [Section 6 | Integrated scenario: the story only the landing page can tell] -->

## Using all three together

**Clear the rule violations first, confirm behavior through testing, then confirm sufficiency with coverage — one connected body of verification evidence.**

1. **Coding stage** — STATIC detects coding rule violations and runtime errors at commit and build time, assigns defects to owners, and tracks their handling status.
2. **Unit and integration testing stage** — CT designs and executes requirements-based and structure-based tests, leaving statement, branch, and MC/DC coverage together with requirements traceability.
3. **Sufficiency confirmation stage** — COVER measures coverage from test execution results including system testing and real-target testing, and uses unexecuted code as the basis for deciding what testing to add.
4. **Repeated verification** — all three products can run automatically in a CI environment, so every code change is verified against the same criteria and the results accumulate.

> An applied example: in a defense embedded project, coverage from requirements-based testing was measured with COVER, gaps were filled with structure-based testing in CT, and the combined results were used to produce a software reliability test report.

*The integrated verification flow — clearing defects, running tests, confirming sufficiency, and accumulating evidence, repeated in CI*

---

<!-- [Section 7 | Industry and standards table
     ★ Always distinguish "supports standard compliance activities" from "tool certification".
     ★ Grade-level mappings (ASIL, SIL, Software Level) stay off the landing page and are linked to the COVER page. -->

## Industries and standards

**Each product supports the verification activities required in safety and regulated projects in its own way.**

| Domain | Representative standard | STATIC | CT | COVER |
|---|---|---|---|---|
| Automotive | ISO 26262 | Coding rule inspection and static analysis results used as verification evidence | Unit and integration testing, coverage, traceability (within TÜV SÜD certification scope) | Built-in measurement criteria for ASIL A–D |
| Aerospace | DO-178C / DO-330 | Static analysis results used as verification evidence | Supports the verification activities (not within the TÜV SÜD certification scope; tool qualification is judged per project) | Built-in measurement criteria for Software Level A–D and TQL-1–5 |
| Defense | DAPA weapon system software guidelines | Rule sets based on the reliability evaluation guidelines, 6 function metrics | Unit and integration testing with test result management | Built-in statement, branch, and MC/DC criteria |
| Railway | IEC 62279 / EN 50128 · EN 50716 | Static analysis results used as verification evidence | Unit and integration testing, coverage, traceability (within TÜV SÜD certification scope) | Built-in measurement criteria for SIL 0–4 |
| Nuclear | IEC 60880 | Static analysis results used as verification evidence | Unit and integration testing, result and report management (within TÜV SÜD certification scope) | Built-in statement, branch, and MC/DC criteria |
| Medical devices | IEC 62304 | Static analysis results used as verification evidence | Test execution, result and traceability records (within TÜV SÜD certification scope) | Built-in measurement criteria for Class A–C |
| Functional safety (general) | IEC 61508 | Coding rule inspection and static analysis results used as verification evidence | Unit and integration testing, coverage, verification records (within TÜV SÜD certification scope) | Built-in measurement criteria for SIL 1–4 |

**Tool certification and tool qualification are different things.** CT holds TÜV SÜD tool certification for the standards marked above, and the certification applies to a specific product version and the functional scope defined in the Certification Report. DO-178C and DO-330 are not within CT's TÜV SÜD certification scope; for aerospace projects, tool qualification is judged per project based on the intended use and how the verification evidence is used. STATIC and COVER provide tool qualification materials for use in certification reviews; the materials actually provided and the applicable product versions and standard scope must be confirmed per project.

[See COVER's grade-level coverage mapping →](../cover/cover_contents.md) · [See CT's tool certification scope →](../ct/ct-product-page.md)

---

<!-- [Section 8 | AI feature summary. Detailed behavior is linked to the product pages] -->

## AI-assisted verification

**AI is used to reduce repetitive work, and its output is verified against actual execution results and code coverage.**

- **STATIC Agent Chat** — answers questions about tool usage, defect causes, and remediation guidance based on the STATIC guide documentation.
- **STATIC Smart Suggestion** — finds and recommends past suppression history similar to the current defect, and lets you compare the original code with the recommendation in a diff view before accepting it.
- **CT ALIRA AI** — assists with the design and generation of requirements-based and structure-based tests, and with error analysis, inside CT.
- **CT DVERA** — connects AI coding agents such as Claude Code, Codex CLI, Cursor, and GitHub Copilot so they can use CT's analysis, execution, and coverage capabilities directly from their working context.

> Tests and judgments produced by AI are not verification evidence on their own. The test intent and expected results are reviewed first, and confirmation still comes from actual execution results and code coverage.

---

<!-- [Section 9 | 3 case cards (problem/application/result). Details live on the product pages] -->

## Customer cases

### Automotive — Custom coding rules to prevent recurring errors

- **Problem** — an engine design project (C) needed custom rules to prevent errors that had actually occurred from recurring
- **Application** — custom coding rules were developed and applied with STATIC, and a rule verification step was added to the development process
- **Result** — used in the verification activities for ISO 26262 compliance

### Defense embedded — Meeting reliability test criteria

- **Problem** — 100% statement coverage and a software reliability test had to be achieved
- **Application** — coverage of requirements-based testing was measured with COVER, gaps were filled with structure-based testing in CT, and each set of results was uploaded to VPES
- **Result** — a procedure was established to combine requirements-based, structure-based, and target test results into a reliability test report

### Financial IT — Coverage as the gate for production release

- **Problem** — changed code reached production without any confirmation of test sufficiency, creating incident risk
- **Application** — COVER real-time monitoring was connected to the release approval check, and requests below 80% function coverage were rejected
- **Result** — a quality gate that requires additional testing before production release

---

<!-- [Section 10 | FAQ: only landing-page-level adoption questions. Product-specific FAQs live on each product page] -->

## Frequently asked questions

### Do we have to adopt all three products together?

No. Each product can be used independently. Because their verification purposes differ, however, projects that require coding rule compliance (STATIC), unit and integration testing (CT), and test sufficiency confirmation (COVER) get a single connected body of evidence when the products are used together.

### Which product should we adopt first?

The first product to adopt depends on which verification evidence your project lacks most. Start with STATIC if there is no code quality baseline, with CT if unit test records are required, and with COVER if you must confirm the sufficiency of testing you already perform. See [Which Product Do You Need?](#which-product-do-you-need) for the detailed criteria.

### Which languages are supported?

STATIC Enterprise supports C/C++, C#, Java, Kotlin, and Python, and STATIC Standalone supports C/C++. CT targets C/C++. COVER Enterprise supports C/C++, C#, and Java, and COVER Standalone supports C/C++ and C#. Language versions and development environments are listed in the [supported languages document](../languages/languages_contents.md).

### Can they be integrated into a CI/CD pipeline?

All three products can run automatically in a CI environment. STATIC performs static analysis automatically during the build, CT repeats regression tests and coverage analysis through the CLI, a Jenkins plugin, or Docker, and COVER aggregates results through its Open API and CI integration. See each product page for the integration details.

### Can they be used in an air-gapped (network-separated) environment?

Yes. For STATIC and COVER, the Enterprise editions run on servers and analysis or measurement agents inside your internal network, and the Standalone editions are installed on a local PC. Conditions such as AI feature availability and licensing method should be confirmed during the consultation.

### Can they be applied to embedded target environments?

Yes. STATIC supports embedded toolchains such as IAR, Keil, TASKING, Renesas, TI, and Microchip; CT executes tests on real targets over Ethernet, Serial, or JTAG; and COVER Standalone measures coverage even on resource-constrained targets.

### Do you provide materials for certification?

CT holds TÜV SÜD tool certification for ISO 26262, IEC 62279/EN 50716, IEC 60880, IEC 62304, and IEC 61508, and STATIC and COVER provide tool qualification materials. The scope actually provided and the applicable product versions must be confirmed per project.

---

<!-- [Section 11 | CTA: three product links + contact] -->

## Next steps

**Find the verification scope and product configuration that fit your project environment.**

- **[Request a Demo](https://www.suresofttech.com/customer/inquiry.php)**
- **[Talk to Us About Your Environment](https://www.suresofttech.com/customer/inquiry.php)**

| Product | One-line definition | Link |
|---|---|---|
| STATIC | A static analysis tool that detects coding rule violations and runtime errors without execution | [Learn more →](../static/static_contents.md) |
| CT | A unit, integration, and code-based test automation solution for mission-critical C/C++ | [Learn more →](../ct/ct-product-page.md) |
| COVER | A dynamic analysis tool that analyzes test execution results as code coverage | [Learn more →](../cover/cover_contents.md) |
