ANDREAS SPILLNER TESTEN...Unit-Tests und mit ihnen getestete Units werden stets parallel entwickelt....

TESTEN WAS WAR – WAS IST – WAS WIRD!

ANDREAS SPILLNER

TESTEN WAS WAR – WAS IST – WAS WIRD!

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

2011

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1999

1990

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1984

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1984

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1977

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1973

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1965

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1958

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1949

http://www.hnf.de/dauerausstellung/highlights-des-museums.html

1946

TESTEN - WAS WAR

… UND DAS TESTEN?

▸ Wie hat es sich entwickelt?

SOFTWAREENTWICKLUNGSPROZESS NACH BENINGTON

TESTEN NACH DER CODIERUNG IN TESTSTUFEN

Benington, Herbert D.:Production of Large Computer Programs

Proc. Symp. On Advanced Computer Programs for Digital Computers" sponsored by ONR, June 1956.http://portal.acm.org/citation.cfm?id=41799

1956

SOFTWAREENTWICKLUNGSPROZESS NACH BENINGTON

TESTEN NACH DER CODIERUNG IN TESTSTUFEN

Benington, Herbert D.:Production of Large Computer Programs

Proc. Symp. On Advanced Computer Programs for Digital Computers" sponsored by ONR, June 1956.http://portal.acm.org/citation.cfm?id=41799

1956

SOFTWAREENTWICKLUNGSPROZESS NACH ROYCE

TESTEN NACH DER CODIERUNG

Royce, W. W.: Managing the Development of Large Software Systems: Concepts and Techniques Proc. WESCON, IEEE, Los Alamitos, CA, 1970http://portal.acm.org/citation.cfm?id=41801

????

1970

V-MODELL

TESTEN NACH DER CODIERUNG IN TESTSTUFEN

Barry W. Boehm: Guidelines for Verifying and Validating Software Requirements and Design Specification.EURO IFIP 79, P.A. Samet (eds.) North-Holland, IFIP 1979, 711-7191979

EXTREME PROGRAMMING

TESTEN VOR DER CODIERUNG UND IM ZENTRUM

http://www.extremeprogramming.org/rules.html

http://www.extremeprogramming.org/map/code.html2000

EXTREME PROGRAMMING

TESTEN VOR DER CODIERUNG UND IM ZENTRUM

http://www.extremeprogramming.org/rules.html

http://www.extremeprogramming.org/map/code.html

TEST-DRIVEN DEVELOPMENT ERSETZT DIE ANFORDERUNGEN ?

2000

SCRUM

TESTEN VERSCHWINDET

https://en.wikipedia.org/wiki/Scrum_(software_development)#/media/File:Scrum_process.svg2005

SCRUM

TESTEN VERSCHWINDET

https://en.wikipedia.org/wiki/Scrum_(software_development)#/media/File:Scrum_process.svg

???

ALS SICHTBARE AKTIVITÄT

2005

SCRUM

TESTEN NACH ODER IN DEN SPRINTS

▸ Extra Test-Sprint

▸ Testen als mehrfache Aktivität im Sprint

▸ Testen parallel während des Sprints

2010

TESTEN WAS WAR – WAS IST – WAS WIRD!

TESTEN - WAS IST

UMFRAGE 2016

TESTEN - WAS IST

UMFRAGE 2016

Eine Kooperation der Hochschulen Bremerhaven und Bremen,

der Technischen Hochschule Köln, des German Testing Board

und des Swiss Testing Board

Swiss Testing Board

STB

Softwaretest İn Praxis und Forschung

Umfrage 2016http://softwaretest-umfrage.de/

UMFRAGE 2016

AGILES VORGEHEN HAT AUFGESCHLOSSEN

UMFRAGE 2016

Manager optimistischer nur

4% ohne Vorgehensmodell Tester/Entwickler

liegen bei 12%

AGILES VORGEHEN HAT AUFGESCHLOSSEN

UMFRAGE 2016

AGILE PRAKTIKEN

UMFRAGE 2016

AGILE PRAKTIKEN

Seit 2011 um 15-25%

gestiegen

UMFRAGE 2016

AGILE PRAKTIKEN Nutzung der Praktiken nahezu unabhängig vom Vorgehensmodell

Seit 2011 um 15-25%

gestiegen

TESTEN - WAS IST

MEINE SUBJEKTIVE SICHT AUF

▸ Entwicklertest

▸ Test-Driven Development

▸ Continuous Integration / Integrationstest

▸ Design by Contract

TESTEN - WAS IST

ENTWICKLER TESTEN

▸ … schon immer

▸ Jeder Entwickler wird seine Software testen/ausprobieren, bevor er sie weiter- bzw. frei gibt

ENTWICKLER TESTEN

PROGRAMMIERUNG UND TEST ENGER ZUSAMMEN

Programmierung Test

� �

ENTWICKLER TESTEN

PROGRAMMIERUNG UND TEST ENGER ZUSAMMEN

Programmierung Test

� �

ENTWICKLER TESTEN

PROGRAMMIERUNG UND TEST ENGER ZUSAMMEN

ProgrammierungTest

���

ENTWICKLER TESTEN

PROGRAMMIERUNG UND TEST ENGER ZUSAMMEN

ProgrammierungTest

TESTEN UNGELIEBTE TÄTIGKEITBEI DEN ENTWICKLERN���

ENTWICKLER TESTEN

SICHT DER ENTWICKLER AUF DAS TESTEN

▸ »Using a testing technique, you would seek to exhaustively analyze the specification in question (and possibly the code) and devise tests that exhaustively cover the behavior.«

▸ Testen bringt Nichts

▸ Fehlerfreiheit kann ja nicht nachgewiesen werden

▸ Deshalb bleibt es oft beim »Ausprobieren«

Jeff Langr: Modern C++ Programming with Test-Driven Development. O’Reilly 2013

�

ENTWICKLER TESTEN

EXHAUSTIVELY? NICHT ERFORDERLICH, WEIL …

▸ Beispiel: Ein einfaches Programm hat drei ganzzahlige Eingabewerte. Jeder Eingabewert kann bei 16 Bit Integerzahlen 216 unterschiedliche Werte annehmen. Jede Kombination ist möglich, es ergeben sich somit 216 * 216 * 216 = 248 Kombinationen.

248 Kombinationen sind 281.474.976.710.656 Möglichkeiten!

Soll jede Kombination zur Ausführung kommen und werden 100.000 Kombinationen in jeder Sekunde ausgeführt, dann dauert es ca.

ENTWICKLER TESTEN

EXHAUSTIVELY? NICHT ERFORDERLICH, WEIL …

▸ Beispiel: Ein einfaches Programm hat drei ganzzahlige Eingabewerte. Jeder Eingabewert kann bei 16 Bit Integerzahlen 216 unterschiedliche Werte annehmen. Jede Kombination ist möglich, es ergeben sich somit 216 * 216 * 216 = 248 Kombinationen.

248 Kombinationen sind 281.474.976.710.656 Möglichkeiten!

Soll jede Kombination zur Ausführung kommen und werden 100.000 Kombinationen in jeder Sekunde ausgeführt, dann dauert es ca. 89 Jahre

ENTWICKLER TESTEN

ANGEMESSEN STATT AUFWENDIG TESTEN

▸ Kein Programm nutzt alle Möglichkeiten der Eingabe,warum dann beim Testen den Anspruch haben?

▸ Angemessen Testen:

▸ Häufige Nutzung,

▸ risikoreiche Fehler,

▸ Ausnahmefälle

▸ Testentwurfsverfahren / Teststandards helfen

ENTWICKLER TESTEN

UMFRAGE 2016

▸ Entwickler sind unsicher, ob aus- reichend genug getestet wird!

▸ Woran liegt es?

K. Vosseberg, A. Spillner, M.Winter: Umfrage 2016 - Softwaretest in Praxis und Forschung, dpunkt.Verlag, 2017

TESTEN - WAS IST

TEST-DRIVEN DEVELOPMENT

▸ Tests werden vor der Programmierung geschrieben

▸ Tests werden automatisiert durchgeführt (X-Unit-Tools)

▸ bis der Balken grün ist, also alle spezifizierten Tests ohne Fehler durchlaufen

▸ Keine Teststrategie, sondern eine Designstrategie

▸ Festlegung der Schnittstelle

https://www.it-agile.de/de/wissen/agiles-engineering/testgetriebene-entwicklung-tdd/

TEST-DRIVEN DEVELOPMENT

TEST-DRIVEN DEVELOPMENT

▸ » … Unit-Tests und mit ihnen getestete Units werden stets parallel entwickelt. Die eigentliche Programmierung erfolgt in kleinen, wiederholten Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, hat drei Hauptteile: 1. Schreibe einen Test …

2. Ändere den Programmcode …3. Räume dann im Code auf …«

https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung 8.3.2017

TEST-DRIVEN DEVELOPMENT

TEST-DRIVEN DEVELOPMENT

▸ » … Diese drei Schritte werden so lange wiederholt, bis die bekannten Fehler bereinigt sind, der Code die gewünschte Funktionalität liefert und dem Entwickler

keine sinnvollen weiteren Tests mehr einfallen, welche vielleicht noch scheitern könnten. … «

▸ Es gibt bessere und nachvollziehbare Kriterien zur Beendigung des Testens

https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung 8.3.2017

TEST-DRIVEN DEVELOPMENT

SQ-MAGAZIN 03/17

▸ »Der Vorteil von Test-Experten in TDD

… In einem agilen Projekt existiert zwar keine absolute Abgrenzung zwischen den Aufgabengebieten, trotzdem sollte die Rolle des Testers Beachtung finden. Die Erfahrung zeigt, dass eine Rolle, welche sich primär um das Erkennen von Risiken und Fehlern in der Software kümmert, auch bessere Ergebnisse liefert als eine gemischte Rolle, der diese Aufgabe nur zufällig zugeteilt wurde. … werden die Testfälle allerdings ausführlich und methodisch geschrieben, ergibt sich hierdurch ein roter Faden, … «

Sacha Rezagholinia: Hohe Qualität durch eine testgetriebene Entwicklung, Vor- und Nachteile von Test Drive Development (TDD), SQMagazin, 42, März 2017, S. 34-37

TEST-DRIVEN DEVELOPMENT

»DIE TRÜGERISCHE SICHERHEIT DES GRÜNEN BALKENS«

▸ »Test-Driven Devleopment wird derzeit zwar in mancher Hinsicht kontrovers diskutiert, dessen ungeachtet jedoch immer häufiger in der Praxis eingesetzt. Ein wichtiger Aspekt dieses Vorgehens ist der weitgehende Verzicht auf eine umfassende Dokumentation, an deren Stelle die Erstellung der Tests vor der Programmierung tritt. In dem Artikel wird an einem Beispiel demonstriert, welche Vorteile gerade hier eine systematische

Erstellung der Testfälle mit sich bringt.«

Falk Fraikin, Matthias Hamburg, Stefan Jungmayr, Thomas Leonhardt, Andreas Schönknecht, Andreas Spillner und Mario Winter : Die trügerische Sicherheit des grünen Balkens. OBJEKTspektrum, Heft 1, Januar/Februar 2004, S. 25-29.

OBJEKTSPEKTRUM 01/2004

LEAN TESTING

LEAN TESTING

▸ … unterstützt Entwickler einen angemessenen und nicht zu aufwendigen Test durchzuführen

▸ alle wichtigen Testfälle zur Prüfung der Software zu berücksichtigen

▸ nachvollziehbare Testendekriterien zu definieren

▸ aber den Testaufwand in einem überschaubaren Rahmen zu halten

▸ Angemessen statt aufwendig Testen

ACHTUNGWERBUNG

TESTEN - WAS IST

CONTINUOUS INTEGRATION

▸ Nach der Programmierung und den erfolgreich durchgeführten Unit-Test wird eingecheckt

▸ und die System-/Regressionstests werden durchlaufen

▸ Scheint derzeit den Integrationstest zu ersetzten

▸ Vorsicht!

CONTINUOUS INTEGRATION

INTEGRATIONSTEST

▸ Vom Unit-Test zum Integrationstest

CONTINUOUS INTEGRATION

INTEGRATIONSTEST

▸ Vom Unit-Test zum Integrationstest

�

CONTINUOUS INTEGRATION

INTEGRATIONSTEST

▸ Alle Möglichkeiten einer Schnittstelle

▸ Alle Aufrufstellen zwischen zwei Programmmodulen

▸ Alle Aufrufstellen zu einem Programmmodul

▸ Kontrollfluss &Datenfluss

CONTINUOUS INTEGRATION

INTEGRATIONSTEST

▸ Alle Möglichkeiten einer Schnittstelle

▸ Alle Aufrufstellen zwischen zwei Programmmodulen

▸ Alle Aufrufstellen zu einem Programmmodul

▸ Kontrollfluss &Datenfluss

��

CONTINUOUS INTEGRATION

INTEGRATIONSTEST

▸ Alle Möglichkeiten einer Schnittstelle

▸ Alle Aufrufstellen zwischen zwei Programmmodulen

▸ Alle Aufrufstellen zu einem Programmmodul

▸ Kontrollfluss &Datenfluss

CONTINUOUS INTEGRATION

INTEGRATIONSTEST

▸ Alle Möglichkeiten einer Schnittstelle

▸ Alle Aufrufstellen zwischen zwei Programmmodulen

▸ Alle Aufrufstellen zu einem Programmmodul

▸ Kontrollfluss &Datenfluss ��

CONTINUOUS INTEGRATION

INTEGRATIONSTEST

▸ Alle Möglichkeiten einer Schnittstelle

▸ Alle Aufrufstellen zwischen zwei Programmmodulen

▸ Alle Aufrufstellen zu einem Programmmodul

▸ Kontrollfluss &Datenfluss

�einchecken

✔

TESTEN - WAS IST

SCHNITTSTELLENSPEZIFIKATION

▸ TDD reicht nicht aus

▸ Integrationstest ist sehr aufwendig

▸ Was kann helfen?

▸ Design by Contract

DESIGN BY CONTRACT

DESIGN BY CONTRACT

▸ Ziel: reibungsloses Zusammenspiel einzelner Programmmodule (oder Klassen, Methoden, Funktionen)

▸ Zu jeder Schnittstelle wird ein Vertrag geschlossen, der bei der Verwendung der Schnittstelle einzuhalten ist

▸ Vorbedingungen (pre-conditions) Zusicherungen, die vom Aufrufer einzuhalten sind

▸ Nachbedingungen (post-conditions) Zusicherungen, die der Aufgerufene garantiert, und

▸ Invarianten (invariants)Bedingungen, die durch den Aufruf unverändert bleiben

DESIGN BY CONTRACT

BEISPIEL: VERWALTUNG VON MIETSHÄUSERN

▸ Vorbedingung: Eine Wohnung kann nur vermietet werden, wenn sie zum Mietshaus gehört („nr" im entsprechenden Bereich) und nicht bereits vermietet ist

▸ Nachbedingung: Die Wohnung ist dann vermietet und es gibt eine Wohnung weniger zu vermieten

▸ Invarianten: Anzahl der Wohnungen > 0 und Summe aus leeren + vermieteten Wohnungen = Anzahl der Wohnungen

•Wolffram, J.: „Desing by Contract“: Verträge schaffen Qualität. OBJEKTspektrum, Nov/Dez. 1996, Nr. 6, 63-67

DESIGN BY CONTRACT

BEISPIEL IN EIFFEL

vermiete (nr: INTEGER) is --vermiete Wohnung mit Nummer nr

require nr_zulaessig: 1 <= nr and nr <= wohnungen wohnung_leer: leer(nr)

ensure vermietet: not leer(nr) weniger_leere_Wohnungen: leere_wohnungen = old leere_wohnungen -1 end --vermiete

•Wolffram, J.: „Desing by Contract“: Verträge schaffen Qualität. OBJEKTspektrum, Nov/Dez. 1996, Nr. 6, 63-67

DESIGN BY CONTRACT

VORTEILE

▸ Durch die im Vertrag festgelegten Zuständigkeiten lässt sich der Testaufwand unter Verwendung von Testverfahren angemessen gestalten.

▸ Beispielsweise schränkt die Vorbedingung nr_zulaessig: 1 <= nr and nr <= wohnungen den zulässigen Datenbereich ein

▸ Tests mit negativen Zahlen, Sonderzeichen usw. können entfallen

▸ Der Aufrufer muss sicherstellen, dass nur zulässige Werte übergeben werden

DESIGN BY CONTRACT

POSITIVE AUSWIRKUNGEN

▸ auf den Unit-

▸ und den Integrationstest

▸ Sicherstellung, dass Vor-& Nachbedingung eingehaltenwerden und Invariantenunverändert bleiben

TESTEN - WAS IST

EMPFEHLUNG

▸ Entwicklertest - jaABER Testwissen ist hilfreich

▸ TDD - ja ABER Testfälle systematisch herleiten

▸ Continuous Integration - jaABER Integrationstest nicht vernachlässigen

▸ TDD als Schnittstellenspezifikation - jaABER durch Design by Contract ergänzen

✔

✔

✔

✔

TESTEN - WAS IST

EMPFEHLUNG

▸ Entwicklertest - jaABER Testwissen ist hilfreich

▸ TDD - ja ABER Testfälle systematisch herleiten

▸ Continuous Integration - jaABER Integrationstest nicht vernachlässigen

▸ TDD als Schnittstellenspezifikation - jaABER durch Design by Contract ergänzen

✔

✔

✔

✔

»ES« IST ALLES DA! »ES« MUSS NUR

GENUTZT WERDEN!

TESTEN - WAS IST

EMPFEHLUNG

▸ Entwicklertest - jaABER Testwissen ist hilfreich

▸ TDD - ja ABER Testfälle systematisch herleiten

▸ Continuous Integration - jaABER Integrationstest nicht vernachlässigen

▸ TDD als Schnittstellenspezifikation - jaABER durch Design by Contract ergänzen

✔

✔

✔

✔

»ES« IST ALLES DA! »ES« MUSS NUR

GENUTZT WERDEN!

PROBIEREN SIE »ES« DOCH MAL AUS!

TESTEN WAS WAR – WAS IST – WAS WIRD!

TESTEN - WAS WIRD

BLICK IN DIE ZUKUNFT

TESTEN - WAS WIRD

2005 UM PROGNOSEN GEBETEN

▸ Einige der Prognosen von vor 12 Jahren

PROGNOSEN AUS DEM JAHR 2005

HANS SCHÄFER, SOFTWARE TEST CONSULTING, NORWEGEN

▸ »Testen verschwindet nicht. Im Gegenteil, es wird mehr

werden. Die Ursache ist mehr Komplexität und mehr Globalisierung, Outsourcing etc. Der Fokus des Testens wird mehr und mehr die Beschaffung von Information über das zu testende Objekt.

▸ Ich denke auch, dass es mehr normal wird, das Prüfen und Testen wie bei anderen Ingenieurdisziplinen zu betreiben. Das bedeutet vor allem, dass man früher daran denkt, es

mehr systematisch betreibt und mit Ressourcen ausstattet.«

PROGNOSEN AUS DEM JAHR 2005

PROGNOSEN FÜR 2010

PROGNOSEN AUS DEM JAHR 2005

PROGNOSEN FÜR 2010

EINGETRETEN?

PROGNOSEN AUS DEM JAHR 2005

HANS SCHÄFER, SOFTWARE TEST CONSULTING, NORWEGEN

▸ »Es wird sich durchsetzen, dass auf jeden Fall ein gewisser

Komponententest durchgeführt werden sollte und mitgeliefert

wird. Werkzeuge wie Junit werden mehr und mehr zum Standard bei der Entwicklung von Komponenten.

▸ Auf der anderen Seite sehe ich keine Tendenz dazu, dass dieser Test auch den notwendigen Umfang erreicht, die notwendige Gründlichkeit, denn die tonangebenden Mitarbeiter werden auch weiterhin nur sehr wenig im Testen ausgebildet. Ich denke, dass trotz der Initiativen wie ISTQB und dem Buch "Basiswissen Softwaretest" das Fachgebiet weiterhin ein Stiefkind sein wird.«

PROGNOSEN AUS DEM JAHR 2005

KAROL FRÜHAUF, INFOGEM, SCHWEIZ

▸ »Ich befürchte, es wird so aussehen wie heute.

▸ Ich hoffe, dass automatischer Unit Test für die Absolventen irgendeiner Informatik-Ausbildung so selbstverständlich

ist wie das Zähneputzen. Reviews in irgendeiner Form auch.«

PROGNOSEN AUS DEM JAHR 2005

INA SCHIEFERDECKER, FRAUNHOFER FOKUS

▸ »Noch immer werden alle sagen, wie wichtig Testen ist, aber nicht die notwendigen Ressourcen (Zeit, Werkzeuge,

Personal) zur Verfügung stellen und sich mit im Wesent-lichen mit Unit-Level Tests beruhigen und begnügen.

▸ Es wird aber ein Umdenken stattfinden, da einige größere Systemausfälle wegen fehlerhafter Software zu verzeich-nen sein werden - auch in der Ausbildung rückt das Thema immer mehr in den Blickwinkel.«

PROGNOSEN AUS DEM JAHR 2005

ANDREAS SPILLNER, HOCHSCHULE BREMEN

▸ »Softwareentwicklung erfolgt in Komponenten,

Produktlinien (konstruktive Wiederverwendung!).Zu jeder Komponenten werden die Testfälle mitgeliefert

▸ als Nachweis des sorgsam durchgeführten Tests und

▸ als zusätzliche Spezifikation!

▸ Es ist kein Grund erkennbar, warum die Testfälle nicht mitgeliefert werden sollten, es sei denn, es wurde nicht ausreichend getestet!«

PROGNOSEN AUS DEM JAHR 2005

PROGNOSEN FÜR 2020

PROGNOSEN AUS DEM JAHR 2005

PROGNOSEN FÜR 2020

IN 3 JAHREN!

PROGNOSEN AUS DEM JAHR 2005

KAROL FRÜHAUF, INFOGEM, SCHWEIZ

▸ »Ich befürchte, nicht viel anders als heute.

▸ Ich hoffe, dass Software-Entwicklung kein single, kein pair

sondern team programming ist. Das Team sitzt in einem (virtuellen) Raum und erarbeitet die Lösung in dem alle Aspekte ausdiskutiert werden, laufend mit einer cleveren

Notation auf einer hohen Abstraktionsebene für alle

sichtbar fest gehalten werden und unmittelbar auf eine ganze Menge syntaktischer und einige semantische

Mängel hin automatisch geprüft werden.«

PROGNOSEN AUS DEM JAHR 2005

INA SCHIEFERDECKER, FRAUNHOFER FOKUS

▸ »Parallel dazu haben wir Tester aber die Technologie

vorangebracht und können sie dann bei Bedarf aus der Tasche ziehen und anwenden.

▸ Sowieso wird nun im Wesentlichen modell-basiert

entwickelt - und getestet - in einem durchgängigen

Prozess: es gibt dabei aber vielfältige Prozesse, die auf

den Bedarf der Technologien, Systeme, etc. angewendet

werden.«

PROGNOSEN AUS DEM JAHR 2005

EIKE RIEDEMANN, UNIVERSITÄT DORTMUND

▸ »Die EU hat eine Software-Test-Richtlinie erlassen. Danach muss für ausgelieferte Software offengelegt werden,

welche Tests mit welcher Qualität (z.B. Überdeckungsrate) absolviert wurden.

▸ Einige Firmen haben den Model Maturity Level 5 ("models only") erreicht, d.h. der Code wird automatisch aus den

präzisen Modellen erzeugt, die z.B. mit UML 9.0 beschrie-ben sind. Tester müssen also nur noch die Modelle

gegenüber den Kundenanforderungen validieren.«

PROGNOSEN AUS DEM JAHR 2005

ANDREAS SPILLNER, HOCHSCHULE BREMEN

▸ »Einbau von Plausibilität (nicht nur bei Übergabe von Parametern) sondern auch in den „Berechnungen",

▸ was wir Menschen auch machen (Bei Ergebnissen fragen wir: „Kann das stimmen?“

▸ Leider zu nehmend aus der Mode gekommen bzw. es kann kaum noch einer! Überschlagsrechnung!)«

PROGNOSEN AUS DEM JAHR 2005

MARTIN GLINZ, UNIVERSITÄT ZÜRICH

▸ »Gesellschaftlich: In der Rubrik "Vermischtes" der Zeitungen werden neben den Verkehrstoten auch die Softwaretoten gemeldet. Nur in besonders krassen Fällen gibt es öffentlichen Aufschrei und Bestrafung der Schuldigen (genau wie heute im Straßenverkehr).«

PROGNOSE AUS DEM JAHR 1954

PROGNOSE FÜR 2004

PROGNOSE AUS DEM JAHR 1954

PROGNOSE FÜR 2004

AUS DEM JAHR 1954

PROGNOSEN AUS DEM JAHR 1954

PROGNOSEN SIND SCHWIERIG

▸ Home-Computer-Vision(kommt aus dem Internet - also ohne Gewähr!)

https://www.computerbase.de/2004-12/computervision-des-jahres-1954-fuer-2004/

DANKE FÜR IHRE AUFMERKSAMKEIT

FRAGEN

▸ jetzt oder auch später

▸ andreas.spillner@hs-bremen.de