Anfänge  der  Testautoma1on  

Die  ersten  Testwerkzeuge  im    deutschsprachigen  Raum  

1977-­‐1982  

Keynote  Address  by  Harry  Sneed  zum  25.  TAV  Geburtstag  Bremen  am  23.  Juno  2016  

Anfänge  der  Testautoma1on  (Die  ersten  Testwerkzeuge  1977-­‐1982)  

In  der  Zeit  vom  Herbst  1977  bis  Ende  1982  entwickelte  Harry  Sneed  mit  Hilfe  der  ungarischen  RecheninsTtute  Szamok  und  SzKI    sieben  Testwerkzeuge  für  die  deutsche  Industrie.  Vier  davon  werden  hier  vorgestellt.  

•  RXVP  –  Die  MuXer  aller  Testwerkzeuge  (1975)  

•  Prüfstand  –  das  erste  deutsche  Testwerkzeug  (1977)  •  QSTS  –  das  Quelle  SoZware  Testsystem  für  IBM  Assembler  

•  KSTDS  –  das  Kienzle  SoZware  Testsystem  für  den  Test  von  embedded  SoZware  in  Geräten  

•  INTTEST  –  das  allumfassende  IntegraTonstestsystem  für  die  Tornado  Lagerhaltung  

•  ACM-­‐QS-­‐Konferenz  an  der  Bundeswehrhochschule  (1982)  

SNEED-01 TAV-2016

RXVP  –Die  MuCer  aller  Testwerkzeuge  

•  RXVP  wurde  von  der  General  Research  CorporaTon  in  Santa  Barbara  CA  in  der  Zeit  von  1972-­‐1978  entwickelt  für  den  Test  des  BallisTc  Missile  Defense  Systems.    

•  Projektleiter  war  Dr.  Ed  Miller,  später  Gründer  der  Firma  SoZware  Research  Associates.  Prof.  Charles  Ramamoorthy  von  der  Uni  California  war  Projektberater  

•  Später  im  Jahre  1977  hat  Sabine  Saib  das  Projekt  übernommen  und  weiter  geführt    

•  Es  wurde  umgetauZ  in  SQLAB  und  auf  dem  CDI  Struktokongress  1979  in  Frankfurt  vorgestellt.    

TAV-2016 SNEED-02

Sta1c  Analysis  

Dynamic  Analysis  

Program  Verifica1on  

Syntax  Analysis  

Syntax Errors

Semantic Errors

Execution Errors

Deviation Errors

Graph Checking +

Call Checking +

Units Consistency +

Mode Checking +

Asserted/Actual Use

+ Set/Use Checking

Test Results +

Execution Errors

+ Coverage

Report +

Assertion Exceptions

Annotated Listing

+ VC'S

+ Symbolic

Execution of Expressions

+ Simplified

VC'S

Indented Program Listing

+ Diagnostics

Detect Detect Detect Detect Original  Program  

Tester builds in Asserts

1976

Correct    

Program  Incorrect  

Program  with  Asserts  

Test Documentation

Die RXVP Testwerkzeugkette

Folie aus dem Jahr 1976

TAV-2016 SNEED-03

Store  Measurement  

Receive Message

Assert Check

Assert Check

Report Patient ok

Assert Check

Check  Measurement  

Range  

Report  Measurement  

Error  

Assert Check

Report Patient

in danger

Assert Check

Invalid Measure Valid Measure

Sets Validation Points

Patient Monitoring

System

Safe Range Danger Range

If Measurement valid?

Tester sitzt am TI Bildschirmterminal

und steuert den Test mit einem Lichtstift

System Tester

RXVP Assertion-based Testing System

RXVP Dynamic Analyzer verfolgt Testpfade TAV-2016 SNEED-04

Der  SoOware  Prüfstand  zum  Test  von    Siemens  SPL  und  Assembler  Module  

•  Harry  Sneed  hat  die  Entwicklung  des  Prüfstandes  schon  1976  begonnen  als  er  noch  bei  Siemens  in  der  Datenbankentwicklung  täTg  war  und  erkannte  wie  aufwendig  Testen  ist.      

•  Im  Jahre  1977  ist  er  als  Testmanager  zum  I.T.S.  Projekt  rüber  gewechselt.  Seine  Aufgabe  war  dort  die  SPL  Module  zu  testen.  Da  es  keine  Tester  gab,  hat  er  allein  mit  dem  Tool  STchproben  getestet.    

•  Im  gleichen  Jahr  war  er  auf  der  NCC  Kongress  in  Dallas  Texas  wo  er  Dr.  Ed  Miller  kennenlernte.  Sie  haben  entschieden  zusammenzuarbeiten.      

•  Im  Feb.  1978  lernt  Sneed  einen  Mitarbeiter  des  Szamok  InsTtuts  aus  Budapest  auf  der  ersten  europäischen  Testkonferenz  in  London  kennen.  Dieser  bot  Testkapazität  an.    

•  Im  Mai  1978  beginnt  der  Test  der  I.T.S.  Module  mit  Prüfstand  auf  dem  Siemens  Rechner  in  Budapest  für  DM  75  pro  Tesfall  und  DM  150  pro  nachgewiesener  Fehler.    

TAV-2016 SNEED-05

Ar1kel  über  den  Test  der      Datenbank  SoOware  bei  Siemens  1977  

Systematisches Programmtesten – ein mühsames Geschäft

TAV-2016 SNEED-06

Online – Zeitschrift für Datenverarbeitung Sept. 1977

TesVall  Extrak1on    

aus  dem  Code    

TesVall  

Tabelle  TesCreiber  

Testobjekt  Compile  &  

Einbinden  

Source

Code

Pruefstand Modultestrahmen

Entwickler programmiert

Module

Tester testet

Module

Prüfstand testet Module gegen sich selbst

Siemens ITS Projekt 1978/79

Durch    die  Ablaufanalyse  werden  Tesfälle  automaTsch  abgeleitet  aus  dem  Source-­‐Code.  

TAV-2016 SNEED-07

Prüfstand verwendet die Compile-Listing um die Moduldaten zu adressieren.

Source  Code  

AsserTon  Script  

SPL  

Compiler  

AsserTon  

Compiler  

Object  Code  

Testdata  Tables  

Test  Execu1on  

Vorzustände & Nachzustände

wird instrumentiert mit Durchlaufzähler

Daten Abweichung

Bericht

Prüfstand vergleicht die Sicht des Testers mit der Sicht des Entwicklers

Bei jeder Unterbrechung werden Vorzustände

gesetzt & Nachzustände geprüft

Entwickler Tester

Parallel Entwicklung & Test

Compile  Adressen  

TAV-2016 SNEED-08

SNEED-09 TAV-2016 Prüfstand BS2000 Testumgebung

•  In  einem  Jahr  sind  281  Module  mit  134  K  Anweisungen  von    3864  TesVällen  getestet  worden.  Bei  einem  Preis  von  DM  75,-­‐  per  TesVall  kosteten  die  TesVälle  DM  289.800  

•  Der  Mindestzweigüberdeckungsgrad  betrug  85%  

•  403  Programmfehler  wurden  berichtet  und  bestä1gt.  Bei  einem  Preis  von  DM  150,-­‐  per  Fehler,  kamen  noch  DM  60.450  dazu.  

•  Später  im  Integra1onstest  durch  den  Kunden  wurden  noch  386  Fehler  gefunden.    

•  Der  intensive  Modultest  haCe  nur  51%  aller  im  Test  aufgedeckten  Fehler  gefunden,  trotz  einer  Überdeckung  von  85%.  

•  Dies  warf  einen  SchaCen    auf  die  Effek1vität  von  einem  Modultest  bei  dem  die  Module  nur  gegen  sich  selbst  getestet  werden.  Es  brauchte  ein  unabhängiges  Testorakel.  

Ergebnisse aus dem Test mit Prüfstand TAV-2016 SNEED-10

Quelle  SoOware  Test  System    für  Makro-­‐Assembler  Module  

•  Nach  Abschluss  des  I.T.S.  Projektes  wurde  Harry  Sneed  von  Siemens  an  die  Quelle  AG  in  Nürnberg  weiter  vermiXelt.  Quelle  wollte  ein  Modultestsystem  wie  der  Prüfstand  haben,  aber  es  sollte  auf  ihre  IBM-­‐Umgebung  und  ihre  Programmiersprache  QAL  zugeschniXen  sein.      

•  Sneed  hat  zusammen  mit  den  Quelle  Entwicklern  das  QSTS  konzipiert  und  mit  PseudoCode  entworfen.  Drei  ungarische  Mitarbeiterinnen  haben  das  Tool  selbst  in  QAL  Assembler  implemenTert.      

•  Im  Gegensatz  zum  Prüfstand  lief  QSTS  im  Batchmodus.  Für  jeden  Batchlauf  wurde  ein  eigenes  Testobjekt  zusammengebaut.  Die  Testdaten  und  Sollergebnisse  wurden  in  den  generierten  Treiber  und  Stubs  fest  zugewiesen.        

•  Programmunterbrechungen  und  abweichende  Ergebnisse  wurden  in  einem  Testprotokoll  berichtet.    

•  QSTS  hat  auch  die  Einhaltung  der  Quelle  Programmierregel  kontrolliert  und  Regelverletzungen  dokumenTert.  Damals  wurde  die  Nichteinhaltung  der  Regel  mit  Strafmaßnahmen  geahndet.        

TAV-2016 SNEED-11

Quelle  SoOware  Testsystem  1979  Das  Quelle  SoOware  Testsystem  (QSTS)  erfüllte  drei  HaupVunk1onen:  •  Programmanalyse  •  Testdatengenerierung  •  Testausführung  Die  Programmanalyse  untersucht:  •  Datenstruktur  •  Ablaufstruktur  •  Programmverknüpfungen  

Testdatengenera1on  •  Die  TestdatengeneraTon  ist  ein  interakTver  Prozess.  Der  Tester  kann  Testdaten  

am  Sichtgerät  über  ROSCOE  symbolisch  zuweisen.  Die  Daten  werden  automaTsch  geprüZ  gegen  die  Datentabelle.  Wenn  sie  falsch  sind  werden  sie  zurückgewiesen.  Wenn  alle  Daten  korrekt  sind  werden  sie  tesfallweise  in  PanValet  Dateien  abgelegt.  

SNEED-12 TAV-2016

Quelle  SoOware  Testsystem  1979  

Testausführung  mit  QSTS:  •  Für  die  Testausführung  erstellt  QSTS  einen  Testrahmen  um  die  

Umgebung  des  zu  testenden  Moduls  zu  simulieren.  Der  Tester  braucht  keine  zusätzliche  Testprogramme  zu  schreiben.  QSTS  simuliert  sowohl  die    –  Übergeordnete,  bzw.  aufrufende  Module  als    auch  –  Untergeordnete,  bzw.  aufgerufene  Module  und  

–  Alle  Dateien  und  Datenbanken.    •  Mit  QSTS  ist  man  in  der  Lage,  einzelne  Module  losgelöst  von  ihrer  

Umgebung  zu  testen.  Eingaben  zu  dem  Test  sind:  

•  QAL  Assembler  Code  •  Testdatenzuweisungen  und  •  Testparameter  

SNEED-13 TAV-2016

QSTS  Testdatenzuweisung    Testdatenzuweisung:  •  &TF              01    •  &DB            SH5102    200  F    //  Datenbankzuweisung  •  &P1    =  X‘01‘                                        //  Parameterwertzuweisung  •  &P2    =  ‘C‘  •  &P3  =  99  •  R7        =    (FELD1)                            //  Registerbelegung  •  FELD1  =  ‘KUSE‘                            //  FeldinTalisierung  •  &SD        SB24502                            //  Satzbeschreibung  •  FELD2  (1)    =  30                              //  Eingabewertzuweisung  •  FELD3  =  ‘KIEL‘  •  &TD    SH5102  SH5102A    //  Testdatensatz  •  AFELD  =  ‘WUERSIG‘            //    Sollergebnisvorgabe    

SNEED-14 TAV-2016

DV51001  ($ANAL)  

DV51002  (DATPAR)  

DV51003  (EXPAR)  

DV51004  (ASSZEI,OPNPAR  

DV51005  (DATPAR)  

DV51006  (EXPAR)  

DV51007  (ABLFPA)  

DVDBTIO  (IOPARM)  

DV54009 (CONVEIN)

DV51008 (GETELEM)

KERN SORT

DV51010 (CONVAUS)

DVPRINT (LISTE)

Datenbank Tabelle

Ablauf Struktur

Diagramm

Externe Referenzen-

Liste Daten

Verzeichnis

Quelle Software Testsystem Statischer Analysator

Linkage Chart

DATPAR EXPAR OPNPAR DATPAR EXPAR ABLPAR IOPARM

CONVPAR ONPAR DBTAB CONVPAR ZEILE

QSTS  Sta1scher  Analysator     SNEED-15 TAV-2016

DV53001  (TESTDAT)  

DVDBTIO  (IOPARAM)  

DVDTIO1  (IOPARAM)  

DV53002  (PRÜFDAT)  

DVPRINT (LISTE)

Fehler Protokoll Testdaten

Tabelle Datenbank

Tabelle

DV53004 (GETELEM)

ZEILE GNEPAR

RETCODE IOPARAM IOPARAM

PanValet Member

Quelle Software Testsystem Testdatenverfasser

Linkage Chart

QSTS  Testdatenerfassung     SNEED-16 TAV-2016

Test Daten

Test Object

Datenbank Tabelle

DVDBTIO   DV54002  (LinkDat)  

DV54004  (GetParm)  

DVDTI02  (IOParam)  

DV54005  (Zuweise)  

DV54006  (SaveData)  

DV54008  (Abgleich)  

DV54001  (TESTMON)  

$PUT  

IOPARAM LNMODNAM IOPARAM

DV54003 (ReadLnkt)

TESTDRU DV54009 (CONVEIN)

DV53003 (FormDat)

DVINDPR

DV53004 (GetElem)

Test Params

DV54011 (PrtDiff)

DV54010 ConvAus

DVPRNT ConvAus

Abgleichs Liste

PARM

ZEILE CONPAR

PDPARM DSPPAR ARBTAB COVPAR NAME IOPARAM

GNEPAR

Quelle Software Testsystem Testmonitor

Linkage Chart

QSTS  QAL  Testmonitor     SNEED-17 TAV-2016

Test Object DV54040  

(INTERUPT)  

DV54041  (PDUMP)  

DV54020  ($STUB)  

DV54025  ($GET)  

DV54035  ($IMS)  

DV54030  ($PUT)  

DV54025 (ZUWEISE)

TESTDRU

AUSGABE DATEIEN

PDUMP LISTE

DV54009 (CONVEIN)

DV54007 (GETDAT)

DVINDRPR

FEHLER LISTE

COVPAR R4 DSPPAR

STUBNAME DATEINAME SEGNAME DATEINAME

Quelle Software Testsystem Testmonitor

Linkage Chart

QSTS  QAL  Dynamischer  Analysator     SNEED-18 TAV-2016

Kienzle  Embedded  SoOware  Test  System    

•  Die  Kienzle  Apparate  GmbH  in  Villingen  stand  vor  dem  Problem  ihre  in  den  Geräten  eingebauten  SoZware  zu  testen.    

•  Die  SoZware  musste  in  einer  simulierten  Umgebung  unter  Echtzeitbedingungen  getestet  werden.    

•  Kienzle  haXe  von  der  TU  Karlsruhe  eine  eigene  Programmiersprache  für  embedded  SoZware  entwickeln  lassen  –  SPM  –  strukturierte  Programmierung  für  Mikroprozessoren.    

•  1981  erteilte  Kienzle  einen  AuZrag  an  die  SES  GmbH  ein  Mikro-­‐Testsystem  für  sie  zu  bauen.  Drei  Mitarbeiter  des  Szamok  InsTtuts  wurden  dem  Projekt  zugeteilt,  das  schon  nach  sechs  Monaten  abgeschlossen  war.      

•  In  diesem  Tool  war  die  Durchlaufzeit  entscheidend.  Der  Code  dürZe  deshalb  nicht  instrumenTert  werden.  Die  Testüberdeckung  wurde  auf  anderer  Weise  gemessen,  nämlich  über  die  CPU.    

•  Die  Ergebnisse  wurden  erst  nach  dem  Test  kontrolliert  und  Fehler    registriert,  auch  Fehler  im  Laufzeitverhalten  

TAV-2016 SNEED-19

INCOMING PARAMETER

Order

OUTGOING PARAMETER Confirmation

Error Message

GUI Output Panel

GLOBAL DATA Transaction

statistic

GUI Input Panel

GLOBAL DATA Transaction

statistic

DB- Retcode ArticleNr.

Article Attr.

DB- Function ArticleNr.

Article Attr.

Horizontal Data Flow

Input

Data Flow

Output

Persistent Data

Persistent Data

Results Arguments Verticle Data Flow

Test Object

Arguments Results

Transient Data Transient Data

Simulierten  Embedded  SoOware  SchniCstellen     SNEED-20 TAV-2016

KTDS  Testdatenzuweisung     SNEED-21 TAV-2016

KTDS  Preprozessor     SNEED-22 TAV-2016

KTDS  Prozessor     SNEED-23 TAV-2016

KTDS  Postprozessor     SNEED-24 TAV-2016

T e s t m o n i t o r

Output- Speicher

Input- Speicher

Gerät unter Test

Test- ergebnis-

Aggregator

Test- ergebnis-

Datenbank

Test- ergebnis- Validator

Test- zustands- Erzeuger

Test- Datenbank

Test- Compiler

Test- sprache

Ausgabe- protokoll

Validations- protokoll

SPEZIFIKATION INPUT Assertions PRE Assertions

Testplatz VERIFIKATION OUTPUT Assertions INPUT Assertions

Test  der  eingebeCete  SoOware  durch  KTDS    

Tester

SNEED-25 TAV-2016

MBB  Integra1onstestsystem  für    die  Tornado  Lagerhaltung    

•  Die  Firma  Messerschmidit-­‐Belkow-­‐Blöhm  –  MBB  –  war  Hauptlieferant  der  Bundeswehr,  vor  allem  was  Flugzeuge  anbetraf.      

•  Seit  1980  war  MBB  an  der  Herstellung  des  neuen  europäischen  Jägerbomber  –  Tornado  –  beteiligt.  Das  Flugzeug  wurde  in  dem  Werk  Augsburg  zusammengebaut.      

•  In  diesem  Werk  haXe  MBB  eine  miXelgroße  IBM  Anlage  mit  dem  Betriebssystem  DOS-­‐VSE.  Sie  haXe  für  die  Lagerhaltung  ein  Bill  of  Materials  Processing  System  entwickeln  lassen.  Dieses  System  bestand  aus  vielen  Teilsysteme,  die  einzeln  geliefert  wurden.  Das  Personal  in  Augsburg  musste  jede  neue  Release  wieder  testen.    

•  Um  den  Test  zu  beschleunigen  erteilte  MBB  einen  AuZrag  an  die  Firma  SES  einen  IntegraTonstestsystem  für  die  Lagerhaltung  zu  entwickeln.    

•  Die  IntegraTonstest-­‐Tools  wurden  in  Ungarn  entwickelt  und  in  Augsburg  getestet.  Als  es  heraus  kam  dass  ungarische  Staatsbürger  dort  testen  wurde  das  Projekt  auf  das  IBM  Rechenzentrum  in  München  verlagert.  Es  wurde  dort  ferTggestellt  aber  Harry  Sneed  dürZe  einen  deutschen  Rüstungsbetrieb  nie  wieder  betreten.  

TAV-2016 SNEED-26

Test- Monitor

System- Auditor Instrumentor

Programm- test

Datei/DB- Dokumen-

tator

Datei/DB- Validator

Datei/DB- Generator

Terminal- Simulator

Masken- Validator

Masken- Generator

DB-Test DC-Test

MBB INTTEST

Augau  des  MBB  Integra1onstestsystems    SNEED-27 TAV-2016

Batch- Terminal- Simulator

Test- monitor

Ausgabe- masken

Eingabe- masken

Masken- Validator

Masken- Validations-

protokoll Masken- generator

In/Out- Asserts

Trace- Tabellen

Instr.- Source

System- ablauf- Auditor

System- Deckungs-

bericht Instrumentor Source

Datei/DB- Validator

Datei/DB- Validations-

protokoll Datei/DB- Generator

In/Out- Asserts

Datei/DB- Dokumen-

tator

Datei/DB- Validations-

protokoll

Datei-DB

LOG

Im Test Vor dem Test Nach dem Test

Ablauf  des  MBB  Integra1onstestsystems    SNEED-28 TAV-2016

Testdaten- generierung Test Testergebnis-

validation Testdaten-

spezifikation Testjob-

erstellung

Testdaten- protokoll

Test- ergebnis- protokoll

Test- jobs

Test- fall-

Bank Test- DB

LOG- Datei

Include- LIB

Tester Tester

Dateien Sätze Felder

DOS-VSE

DOS Job Quelle VBOMP

VSAM

Integra1onstest  der  Batchjobs    SNEED-29 TAV-2016

Entlade- dienst

Datei- komparator

Dateire- formator

Entlade- dienst

Dateire- formator

Abweichungs- bericht

Datenbank vorher

Datenbank nachher

Datei vorher

Datei nachher

Reformatierter Inhalt vorher

Reformatierter Inhalt nachher

Abgleich  der  Daten  im  Regressionstest  SNEED-30 TAV-2016

Die  ACM  Konferenz  an  der    Bundeswehr  Hochschule  im  März  1982    

•  Am  25./26.  März  1982  fand  die  erste  wissenschaZliche  Tagung  zum  Thema  SoZwaretest  in  deutscher  Sprache  staX.  Veranstalter  waren  die  Bundeswehr  Hochschule  Neubiberg  und  die  Firma  SES.        

•  Keynote  Speaker  waren  Prof.  C.  Ramamoorthy  von  der  University  California  in  Berkley  und  Les  Belady  von  der  IBM  Watson  Labor.    

•  Es  gab  Beiträge  sowohl  aus  der  WissenschaZ  als  auch  aus  der  Praxis.  Hier  sind  alle  zu  Wort  gekommen  die  sich  damals  mit  der  jungen  Disziplin  „SoZware  Test“  befasst  haben,  u.A  –  Heinz  Bons  und  Rudolf  van  Megen  zum  Thema  Qualitätsziele  sowie  zum  

Thema  TEST-­‐COVER  für  die  TeststaTsTk  –  Werner  Schmied  von  Siemens  zum  Thema  SoZware  Prüffeld  –  P.  Ehrensberger  von  MBB  und  N.  Ramsperger  von  der  IABG  zum  Thema  

Qualitätssichung  in  großen  SoZwareprojekten.  –  L.  Gemeiner  und  U.  Voges  von  der  TU  Karlsruhe  zum  Thema  Erfahrung  

mit  dem  Einsatz  des  automaTschen  TestTools  SADAT  –  M.  Majoros  vom  Szamok  InsTtut  zum  Thema  SoZTest    

TAV-2016 SNEED-31

Test  Cover  zur  Messung  der  Testüberdeckung    SNEED-32

TAV-2016

Das  Testsystem  SADAT  von  der  TU  Karlsruhe      SNEED-33

TAV-2016

Das  Testsystem  SoOTest  vom  Szamok  Ins1tut      SNEED-34

TAV-2016

Test Bed

Test Auditor

Coverage reports

Test    DeviaTons  

Test Paths

Instru- mentor

Program  Source  

Assertion Compiler

AsserTon  Procedures  

Test data

Protocol

Drivers & Stubs

COBOL PL/1

SoftTest testet Module gegen eine formale Testspezifikation

Instrumented Sources

Test Procedures

Stand der Testautomation Im Jahre 1982

If (x > y) assert pre a = 2; assert pre b = 3; assert post c = 5; End,

Auf Statement Branch or Path Stufe

SNEED-35 TAV-2016

Eine neue Technologie ist entstanden

•  Die  ACM  Tagung  an  der  Bundeswehr  Hochschule  markierte  das  Ende  der  Pionierzeit  und  den  Beginn  einer  neuen  Technologie.        

•  Die  deutschen  Hochschulen  begannen  sich  mit  dem  Thema  SoZwaretest  zu  befassen.  Professionelle  Schulungsanstalten  wie  das  Control  Data  insTtute,  die  Integrata  und  die  GES  nahm  Kurse  über  SoZwaretest  in  ihr  Programm  auf.  Immer  mehr  Beratungsfirmen  fingen  an  Testberatung  an  zu  bieten.  Es  gab  sogar  Firmen,  wie  die  SQS  GmbH  in  Köln,  die  sich  ganz  auf  der  Qualitätssicherung  von  SoZware  spezialisiert  haben.  Es  würde  aber  noch  9  Jahre  vergehen  bis  die  GI-­‐Fachgruppe  TAV  ins  Leben  gerufen  wurde.    

•  Mit  diesem  Vortrag  wollte  ich  belegen,  dass  SoZwaretest  vom  Anfang  an  eng  mit  der  TestautomaTon  verstrickt  war.  TestautomaTon  in  aller  ihrer  Ausprägungen  von  der  Testüberdeckungsmessung  bis  zu  selbst  testenden  Programmen  ist  das  Fundament  auf  dem  die  TesXechnologie  aufgebaut  ist.  Ohne  AutomaTon  sind  Testverfahren  weder  durchsetzbar  noch  kontrollierbar.    

TAV-2016 SNEED-36