From Manual to Automated: Why Indian Automotive Tier-1s Are Adopting TESSY for Unit Testing

From Manual to Automated: Why Indian Automotive Tier-1s Are Adopting TESSY

The transition from manual to automated unit testing in Indian automotive software teams is not a technology trend, it is an engineering necessity driven by three converging forces: the ISO 26262 certification requirements imposed by European and Japanese OEMs, the scaling demands of AUTOSAR-based multi-platform ECU development, and the realization that manual testing simply cannot keep pace with modern firmware complexity.

This article examines the drivers behind this transition and how Razorcat TESSY addresses the specific challenges Indian Tier-1 suppliers face.

The Manual Testing Baseline

Many Indian automotive Tier-1 suppliers began their embedded software journey with manual unit testing practices:

• Engineers write test harnesses by hand in C
• Test cases are documented in Excel spreadsheets
• Coverage is not measured, or is measured using a separate instrumentation tool that is not integrated with the test framework
• Tests run manually on the developer’s machine, no CI/CD pipeline
• Regression testing happens sporadically, usually before a milestone, not on every commit

This approach works for small codebases with simple logic. It breaks down when:

• The codebase grows to hundreds of modules with thousands of functions
• ISO 26262 gives MC/DC its strongest recommendation at ASIL D, and an assessor expects the coverage evidence with auditable traceability
• OEM audits demand proof of systematic test design, not just test execution
• Multiple product variants require parallel testing across different compiler configurations

Driver 1: ISO 26262 OEM Requirements

European OEMs (Volkswagen Group, Stellantis, and other major automotive manufacturers) require their Tier-1 suppliers to demonstrate ISO 26262 compliance. For Indian Tier-1s supplying AUTOSAR software, powertrain control modules, or body controller firmware, this means:

• MC/DC coverage on ASIL C and D functions, with the rationale ISO 26262 Part 6 asks for alongside it
• Systematic test design with documented rationale, using the derivation routes Part 6 lists
• Bidirectional requirements traceability from requirements to test cases and back
• Tool qualification evidence for the testing tool (Part 8)
• Regression testing integrated into the development process

Manual testing cannot satisfy these requirements at scale. The MC/DC measurement alone requires instrumentation that manual harnesses do not provide. The traceability requirement demands a tool that links test cases to requirements in a database, not in a spreadsheet. The regression testing requirement implies automation, you cannot manually re-run thousands of test cases on every code change.

Driver 2: AUTOSAR Multi-Platform Complexity

Indian Tier-1 suppliers increasingly develop AUTOSAR-compliant software that runs on multiple hardware platforms. A body controller SWC developed for one vehicle platform must be tested against multiple MCAL (Microcontroller Abstraction Layer) configurations, different AUTOSAR BSW stacks, different target MCUs, different compiler toolchains.

TESSY handles this through its variant management and compiler integration:

• Multiple compiler configurations per project, test the same SWC with Arm Compiler 6 (for Cortex-M targets) and TASKING (for AURIX targets)
• AUTOSAR RTE stub generation: TESSY automatically generates stubs for Rte_Read, Rte_Write, and Rte_Call interfaces, isolating SWC logic from BSW dependencies
• Per-variant coverage tracking: coverage is measured separately for each target configuration because the compiled code differs

For Pune-based Tier-1 suppliers developing AUTOSAR Classic software for multiple European OEM platforms, this multi-variant testing capability eliminates the need to maintain separate test projects for each target.

Driver 3: Scaling Engineering Teams

Indian automotive engineering teams are growing rapidly. A team that had 5 firmware engineers three years ago may have 20 today, developing software for multiple ECU programs simultaneously. At this scale:

• Consistency: every engineer must follow the same test design methodology. TESSY’s Classification Tree Editor enforces systematic test design across the team.
• Visibility: project managers need to see which modules are tested, which have coverage gaps, and which are falling behind schedule. TESSY’s Test Cockpit provides project-wide testing oversight.
• Automation: CI/CD pipelines ensure that tests run on every commit, not just before milestones. TESSY’s command-line interface integrates with Jenkins, GitLab CI, and Azure DevOps.
• Knowledge retention: when engineers move between projects or leave the team, the test cases and design rationale are preserved in TESSY, not in personal spreadsheets or local scripts.

The Transition Path

Indian teams do not switch from manual to automated testing overnight. The typical transition, based on what GSAS has observed across clients in Bengaluru, Pune, Hyderabad, and Chennai, follows these phases:

Phase 1: Pilot module. Start with one safety-critical module, typically the most complex function in the highest-ASIL subsystem. Use TESSY to create systematic test cases, measure MC/DC coverage, and generate the first certification-ready reports. This demonstrates the tool’s value to management and the safety team.

Phase 2: CI/CD integration. Integrate TESSY into the project’s CI pipeline so that the pilot module’s tests run on every commit. This establishes the infrastructure for regression testing.

Phase 3: Team rollout. Train the full team on TESSY and the Classification Tree Method. Extend testing to all safety-critical modules. Set MC/DC coverage targets as CI quality gates.

Phase 4: Full project coverage. All modules under the safety plan are tested in TESSY. Coverage reports feed into the safety case. Regression testing runs automatically. New modules are added to the TESSY project as they are implemented.

This phased approach minimizes disruption. Engineers learn the tool on a real module, see the value in terms of reduced manual effort and improved coverage, and then extend the practice to the full project.

The Cost of Not Transitioning

The alternative to automated unit testing is not free. Manual testing incurs:

• Engineering time: hand-writing test harnesses, maintaining spreadsheets, manually re-running tests after changes
• Audit risk: assessors rejecting manually generated evidence as insufficient, triggering re-work
• Regression risk: undetected regressions reaching integration testing or field, where they are far costlier to isolate and fix than at the unit-test stage
• Schedule risk: discovering coverage gaps late in the project, requiring emergency test creation under time pressure

For teams targeting ISO 26262 certification, the cost of inadequate unit testing is measured in months of project delay and hundreds of engineering hours of re-work.

Why Buy from GSAS

GSAS Micro Systems is the authorized Razorcat partner, providing TESSY licensing with INR invoicing, transition consulting, onboarding workshops, and CI/CD integration support. Our engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR have guided Indian automotive teams through the manual-to-automated transition, from pilot module through full project rollout. Whether your team is just beginning the ISO 26262 journey or scaling an existing verification practice to cover more modules and more platforms, GSAS provides the tools and the local expertise to make the transition efficient.

Request a TESSY evaluation →