Driving Quality: How To Succeed In Automotive QA (eBook)
292 Seiten
Books on Demand (Verlag)
978-3-6951-0858-9 (ISBN)
Emre Bakis is a consultant, coach, and assessor specializing in Quality Assurance, Automotive SPICE®, and Functional Safety for the automotive industry. With hands-on experience supporting major OEMs and suppliers, Emre has guided project teams through complex assessments, process improvement initiatives, and safety-critical system development. He holds a Masters degree in Vehicle Engineering from HTW Berlin and brings a combination of technical depth and practical coaching to every project. Over the years, he has worked in various QA roles; from Software Quality Improvement Leader (SQIL) to Functional Safety Engineer and has support-ed both startups and global suppliers in navigating ASPICE, ISO 26262, and IATF 16949 requirements. Emre is certified as a Competent Automotive SPICE Assessor, ISO 26262 Red Belt, SAFe Agilist, and ISTQB Foundation Tester. His mission is to make quality more accessible and collaborative, turning process know-how into practical project impact. When he is not leading workshops or preparing teams for au-dits, Emre enjoys sharing his knowledge with newcomers to the field. This book reflects that passion, offering a structured, beginner-friendly introduction to what truly makes QA successful in automotive projects.
3. Quality Basics
Before diving into tools, templates, or industry frameworks, it's essential to understand the mindset and principles that define real quality work. Many QA beginners are surprised to discover that quality goes beyond testing. It involves mindset, emotional intelligence, communication, and preventing problems before they occur.
In this chapter, we’ll explore the foundations that shape everything else in your QA journey. You’ll see why “test passed” doesn’t always mean “ready to ship”, how to approach your role with the mindset of a quality advocate, and how continuous improvement (through models like the PDCA cycle) becomes part of your daily routine.
We’ll begin by clearing up one of the most common sources of confusion for newcomers: the difference between QA, QC, testing, and auditing.
3.1 QA vs QC vs Testing vs Auditing
If you're new to the world of quality in automotive, you’ve probably heard a lot of similar-sounding terms: QA, QC, testing, and auditing – see overview in Figure 6 . These terms are often used interchangeably in everyday conversation, but in a professional context, they mean different things, and understanding those differences is key to your role as a quality assurance engineer.
Figure 6: Overview QA, QC, Test and Audit
Let’s break them down one by one and see where they fit into the bigger picture.
3.1.1 Quality Assurance (QA)
Quality assurance is the discipline of shaping how work gets done so that problems are avoided before they even have a chance to occur. Rather than reacting to issues after the fact, QA focuses on building robust processes, clear expectations, and consistent documentation, that guide teams to do the right things from the beginning.
QA = Preventing Defects
In automotive projects, this means working across all stages, not just in testing, to make sure that each phase is built on solid ground. QA helps ensure that teams understand not only what they need to deliver, but how to deliver it in a way that meets quality, safety, and compliance expectations.
What QA does:
- Defines standards, templates, and quality workflows
- Ensures reviews of project deliverables (e.g. requirements, architecture, test plans) before approval
- Plans and monitors quality-related milestones and activities
- Supports conformance with e.g. ASPICE, ISO 26262, IATF 16949, and internal processes
- Drives lessons learned sessions and leads process improvement initiatives
- Acts as a neutral voice in decision-making, focused on risk and long-term impact
QA is not a separate island. It works with development and project teams, not against them. Good QA adds value by enabling smoother collaboration, reducing late-stage firefighting, and providing transparency into how quality is actually being achieved.
Example:
A QA engineer ensures that all software requirements are reviewed and approved for clarity and testability before any development begins. This small step prevents misinterpretation and makes downstream test planning significantly easier. It also supports ASPICE traceability and reduces rework during integration.
3.1.2 Quality Control (QC)
While quality assurance focuses on preventing defects through well-defined processes, quality control deals with identifying defects after a work product has been created – see Figure 7. Quality control reacts by checking whether process results meet the required specifications.
QC = Detecting Defects
QC plays a critical role in verifying the output of development, manufacturing, or testing activities. Quality control leaves the work method unchanged but assesses if the finished product, such as a software module, ECU, or sensor, is suitable for the following project step or customer use.
What QC does:
- Verifies whether products meet defined acceptance criteria
- Performs inspections, measurements, or visual checks
- Detects deviations from specifications, tolerances, or standards
- Ensures defective items are flagged and either corrected or rejected
- Often supports release decisions in production or supplier quality management
→ QC typically happens near the end of a phase, before delivery or handover, for example, after implementation but before integration or shipping.
Example:
A QC technician receives a batch of brake pressure sensors from a Tier-2 supplier. Using calibrated tools, the technician checks that each sensor meets tolerance thresholds for voltage output and mechanical pressure range. Any part that fails this inspection is rejected or flagged for rework, ensuring that only conforming parts enter the assembly line.
→ QC helps prevent defective products from reaching the customer. But if the same problem keeps appearing, it’s usually a sign that upstream QA processes need improvement.
Figure 7: QA vs. QC
Figure 7 illustrates the conceptual difference between Quality Assurance (QA) and Quality Control (QC), not just in terms of goals, but in how each role supports the overall quality strategy.
On the left side, QA focuses on how work is done. It includes defining processes, creating templates, providing checklists, and offering training to help teams do things right from the start. These are proactive activities, aiming to prevent defects before they occur.
On the right side, QC addresses the results of that work. It checks outputs through reviews, inspections, and testing. Both random samples and structured assessments help catch problems that slipped through. These activities are reactive by nature but essential to detect issues before release.
For quality professionals, this overview helps clarify where your responsibilities lie and how they relate to other quality functions. You’re not expected to do everything, but to connect the pieces and make sure that prevention and detection work hand in hand.
3.1.3 Testing
Testing is a focused activity within the quality domain that aims to prove whether the system behaves as intended. It is one of the most visible and measurable forms of quality work, and it plays a central role in verifying whether requirements have been correctly implemented.
Testing = Demonstrating That It Works
Unlike broader QC activities, testing is part of QC and specifically targets functionality. It checks whether a system or component produces the correct output under expected and unexpected conditions. Testing helps uncover design flaws, software bugs, and integration issues before the system reaches the customer.
What testing does:
- Verifies that system behavior matches defined requirements
- Verifies functionality at different levels: unit, integration, and system
- Uses structured test cases, expected results, and traceability to requirements
- Often includes automated scripts for regression and performance tests
- Produces documented evidence: logs, reports, and defect records
Testing goes beyond pass or fail. It provides objective, reproducible evidence that the software and/or system meets expectations or does not. It's also a key element in ASPICE and ISO 26262 projects, where traceability from requirement to test result is mandatory.
Example:
A software tester executes a series of automated and manual test cases on the braking control module. One test confirms that when the brake pedal is pressed, the signal is received, processed, and leads to brake engagement within the specified time window. Any deviation is logged, analyzed, and, if needed, fixed and retested.
→ Good testing doesn’t just confirm that the system works, it also challenges the system to fail gracefully, recover safely, and meet performance expectations under edge cases.
3.1.4 Auditing
Auditing is a formal activity that focuses not on the product itself, but on how the product was developed. The goal of an audit is to assess whether a team or organization is following it’s defined processes, methods, and standards and whether those processes are effective.
Auditing = Evaluating the Process
It looks at the evidence of process execution: Are teams documenting decisions? Are required reviews happening? Is traceability maintained? In the automotive world, this is essential for demonstrating coverage with frameworks like ASPICE, ISO 26262, or IATF 16949.
Audits can be performed by internal quality teams, customers (e.g., OEMs), or external assessors as part of a certification or supplier evaluation.
What auditing does:
- Evaluates whether the defined process is actually being followed
- Compares...
| Erscheint lt. Verlag | 9.10.2025 |
|---|---|
| Sprache | englisch |
| Themenwelt | Technik |
| ISBN-10 | 3-6951-0858-4 / 3695108584 |
| ISBN-13 | 978-3-6951-0858-9 / 9783695108589 |
| Informationen gemäß Produktsicherheitsverordnung (GPSR) | |
| Haben Sie eine Frage zum Produkt? |
Größe: 2,8 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich