1 Min. Lesezeit
Agile Compliance in der Life-Sciences-QA: Widerspruch oder Wettbewerbsvorteil?
Wie verändert die Integration von Compliance in agile Workflows die regulierte Softwareentwicklung?Das Wichtigste auf einen Blick: Agile und...

Praxisnah. Erfolgsbewährt. Maßgeschneidert. Erfahren Sie mehr über unsere Case Studies.
5 Min. Lesezeit
Andrea Cotet : Freitag, 22.5.2026
Was passiert, wenn ein Navigationssystem glaubt, man fahre auf einer Straße, die es gar nicht gibt? Oder wenn die Estimated Time of Arrival, kurz ETA, um 25 Minuten danebenliegt – mitten in einer europäischen Großstadt zur bekannten Rushhour?
Solche Fragen lassen sich auf einer Test Bench im Labor nur begrenzt beantworten. Dafür braucht es reale Straßenbedingungen.
Bei TestSolutions testen wir Software. Meistens im Büro, auf Testsystemen, mit Tickets in Jira und Testfällen in Excel. Aber in Automotive-Projekten testen wir auch dort, wo Navigations- und Infotainmentsysteme später tatsächlich genutzt werden: im Fahrzeug, im Verkehr, auf Stadtautobahnen, in europäischen Metropolregionen, in umsatzstarken Absatzregionen, auf Nebenstraßen, an Kreisverkehren und vor Ladesäulen.
Dieser Artikel erklärt, warum Field Acceptance Testing für OEMs und Tier-1-Zulieferer keine Kür ist – sondern ein zentraler Bestandteil systematischer Qualitätssicherung.
Wer ans Navi denkt, denkt meist an eine Karte und eine Stimme, die sagt, wo man abbiegen soll. Das ist der sichtbare Teil. Darunter liegen mehrere Schichten, die zuverlässig zusammenspielen müssen:
Jede dieser Schichten kann Fehler enthalten. Und viele davon zeigen sich erst dann, wenn das System tatsächlich im Fahrzeug genutzt wird.
Für die Qualitätssicherung bedeutet das: Es reicht nicht, nur einzelne Funktionen isoliert zu testen. Entscheidend ist, wie das Gesamtsystem unter realen Bedingungen reagiert – also dann, wenn Kartendaten, Live-Daten, Fahrzeughardware, Benutzerinteraktion und Verkehrssituation gleichzeitig zusammenspielen.
Test Benches sind in der Automotive-QA unverzichtbar. Sie ermöglichen reproduzierbare Tests, frühe Fehlererkennung und strukturierte Prüfungen, bevor ein System im Fahrzeug validiert wird. Auf Prüf- und Testumgebungen lassen sich echte und simulierte Steuergeräte, sogenannte ECUs, kombinieren, um eingebettete Infotainmentsysteme realitätsnah zu testen.
Das ist wertvoll, keine Frage.
Aber eine Test Bench simuliert. Er kann nicht vollständig nachbilden, was auf einer echten Straße passiert: eine unerwartete Baustelle, die das Navi ignoriert. Einen Kreisverkehr, den die Datenbank falsch klassifiziert. Eine Ladesäule, die laut App verfügbar ist – vor Ort aber gesperrt oder außer Betrieb. Eine Route, die technisch korrekt berechnet wurde, für den Fahrer aber kaum nachvollziehbar ist.
Die physische Realität ist der härteste Testfall.
Der Mehrwert liegt deshalb nicht im Entweder-oder. Gute Automotive-QA verbindet beides: strukturierte Tests auf der Test Bench und Field Acceptance Testing im realen Fahrbetrieb.
Wenn wir live testen, arbeiten wir als Acceptance-Test-Team. Wir betrachten das System aus Sicht des Endnutzers – nicht nur aus der Perspektive der Entwicklung. Genau dieser Blick ist wichtig, weil viele Fehler nicht an einer einzelnen Funktion hängen, sondern am Nutzungskontext.
Konkret sieht das so aus:
Zwei Fahrzeuge, zwei Systeme.
Ein Fahrzeug nutzt das Navigationssystem des OEM, das andere eine etablierte Referenzlösung. Beide Fahrzeuge sind mit GPS-Trackern ausgestattet, die kontinuierlich Positionsdaten aufzeichnen. So lassen sich Abweichungen zwischen berechnetem und tatsächlichem Weg lückenlos belegen.
Strukturierte Testfälle, flexibel angepasst.
Der Testmanager bereitet Routen vor – von A nach B, mit definierten Parametern. Gleichzeitig muss das Team auf Verkehr, Wetter, Straßensperrungen oder andere reale Bedingungen reagieren können. Denn genau das tut auch der echte Fahrer. Testabdeckung geht vor starrer Prozesstreue.
Dokumentation während der Fahrt.
Der Co-Driver beziehungsweise Testbegleiter dokumentiert die Ergebnisse direkt während der Fahrt: Zeitpunkt der Routenberechnung, Abfahrtszeit, berechnete und tatsächliche ETA, Beobachtungen, Abweichungen, GPS-Koordinaten, Screenshots und Fotos der Situation vor Ort. Nichts wird im Nachhinein aus dem Gedächtnis rekonstruiert.
Benchmarking.
Wie gut schlägt sich das OEM-System im Vergleich zu einer Referenzlösung? Wo weicht es ab – und handelt es sich dabei um einen Fehler, eine Datenabweichung oder eine bewusste Design-Entscheidung.
Gerade dieser letzte Punkt ist wichtig: Nicht jede Abweichung ist automatisch ein Bug. Manchmal priorisieren Systeme unterschiedliche Kriterien – zum Beispiel kürzeste Strecke, schnellste Route, Energieverbrauch, Ladeoptionen oder Verkehrsdichte. Field Acceptance Testing hilft dabei, solche Unterschiede sichtbar, bewertbar und entscheidbar zu machen.

Über mehrere Jahre und in unterschiedlichen europäischen Metropolregionen hinweg – darunter zentrale urbane Märkte, stark frequentierte Pendlerregionen und umsatzstarke Absatzgebiete – hat sich gezeigt: Die Bandbreite möglicher Findings ist groß.
Typische Beispiele aus solchen Testreihen sind:
Jeder dieser Befunde hat Konsequenzen: für das Nutzererlebnis, für die Kundenzufriedenheit und für die Marke.
Für den Fahrer ist es am Ende nicht entscheidend, ob der Fehler in der Kartendatenbank, im Backend, in der Routenlogik oder in der Integration liegt. Entscheidend ist, ob das System zuverlässig wirkt. Genau deshalb müssen solche Fehler im Zusammenspiel getestet werden.
Field Acceptance Testing ist besonders dann wertvoll, wenn mehrere Datenquellen, Systemkomponenten und Lieferanten beteiligt sind. Je mehr Schnittstellen ein System hat, desto größer wird die Wahrscheinlichkeit, dass Fehler nicht in einer einzelnen Komponente entstehen, sondern im Zusammenspiel.
Aus QA-Sicht sind dabei vor allem fünf Fragen entscheidend:
1. Testen wir nur Funktionen – oder auch Nutzungssituationen?
Ein Navigationssystem kann im Labor formal korrekt funktionieren und im Alltag trotzdem schlechte Ergebnisse liefern. Reale Nutzungssituationen zeigen, ob das System für den Fahrer nachvollziehbar und verlässlich ist.
2. Sind unsere Testregionen repräsentativ?
Nicht jede Region stellt dieselben Anforderungen. Dichte Innenstädte, Pendlerkorridore, Grenzregionen, Ladeinfrastruktur und umsatzstarke Märkte sollten gezielt berücksichtigt werden.
3. Können wir Abweichungen sauber belegen?
GPS-Tracks, Zeitstempel, Screenshots und Fotos machen Findings nachvollziehbar. Ohne belastbare Dokumentation wird aus einem echten Fehler schnell eine subjektive Beobachtung.
4. Vergleichen wir gegen eine sinnvolle Referenz?
Benchmarking gegen etablierte Referenzsysteme hilft, Abweichungen einzuordnen. Dabei geht es nicht darum, jedes Verhalten zu kopieren, sondern Unterschiede zu verstehen und bewerten zu können.
5. Fließen die Ergebnisse zurück in Entwicklung und Datenqualität?
Field Testing ist nur dann wirksam, wenn Findings nicht isoliert bleiben. Sie müssen in Kartenupdates, Backend-Verbesserungen, Routenlogik, UI-Anpassungen oder Lieferantenfeedback übersetzt werden.
Fahrzeuge sind heute fahrende Softwareplattformen. Navigations- und Infotainmentsysteme werden nicht mehr ausschließlich von OEMs selbst entwickelt. Tier-1-Zulieferer und spezialisierte Technologiepartner liefern ganze Systemkomponenten. Dadurch entstehen mehr Schnittstellen, mehr potenzielle Fehlerquellen und mehr Integrationskomplexität.
Für Zulieferer ist das eine klare Anforderung: Wer ein System an einen OEM liefert, muss nachweisen können, dass es im realen Fahrbetrieb funktioniert – nicht nur auf dem Papier, im Labor oder auf der Test Bench. Testfahrten mit strukturiertem Abnahmecharakter sind dafür ein zentrales Instrument.
Für OEMs gilt dasselbe: Bevor ein neues Fahrzeug auf den Markt kommt, muss sichergestellt sein, dass das Navigationssystem – inklusive aller Datenbank- und Live-Daten-Komponenten – den Erwartungen der Kunden entspricht. Das ist keine Frage des Vertrauens in den Lieferanten. Das ist systematische Qualitätssicherung.
Unsere Stärke liegt in der Verbindung aus strukturierter Software-QA und praktischer Automotive-Erfahrung. Wir testen nicht nur gegen Spezifikationen, sondern prüfen, wie Systeme unter realen Bedingungen funktionieren: im Fahrzeug, im Verkehr, bei wechselnden Datenlagen und mit Blick auf das tatsächliche Nutzererlebnis.
Dazu gehören unter anderem Tests von Navigationsdatenbanken, Live-Daten, eMobility-Diensten, Infotainment-Komponenten und Ladeinfrastruktur. Entscheidend ist dabei nicht nur, ob ein System technisch funktioniert, sondern ob es im realen Nutzungskontext verlässliche Ergebnisse liefert.
Wir kennen die Komplexität eingebetteter Systeme, die Anforderungen des OEM-Umfelds und die Realität des Fahrens.
Testfahrten sind kein Ausflug. Sie sind ein methodisch fundierter Teil des Field Acceptance Testings – mit klaren Test Cases, nachvollziehbarer Dokumentation und messbaren Ergebnissen.
Wer Navigationssoftware oder andere fahrzeugseitige Systeme abnehmen will, kommt an echten Straßenbedingungen nicht vorbei. Für OEMs und Tier-1-Zulieferer, die Navigationssysteme realitätsnah absichern wollen, ist Field Acceptance Testing kein Zusatzaufwand, sondern ein entscheidender Qualitätsnachweis.
Sie planen Abnahmetests eines Navigations- oder Infotainmentsystems im Feld? Dann sprechen wir gerne mit Ihnen darüber, welche Testszenarien sinnvoll sind und wo reale Straßenbedingungen den Unterschied machen.
1 Min. Lesezeit
Wie verändert die Integration von Compliance in agile Workflows die regulierte Softwareentwicklung?Das Wichtigste auf einen Blick: Agile und...
Die Luftfahrtbranche befindet sich in einer der tiefgreifendsten Transformationen ihrer Geschichte. Konzepte wie NDC und ONE Order versprechen eine...
Es gibt eine weit verbreitete Annahme, die sich in Software-Entwicklungsteams heimlich verbreitet: Die KI-Tools sind inzwischen so gut, dass das...