Valid Code = happy customer
Wieso System- und Usertestings sinnvolle Instrumente sind.
Die Entwicklung von validem Code ist die Basis Ihres geschäftlichen Erfolgs. Indem wir Business-kritische Anwendungen performant umsetzen, stellen wir Ihre Kunden zufrieden. Und damit Sie.
Qualität ist das Ziel, Testing ist das Werkzeug
Da der fachliche Laie die Qualität von Software nicht vollständig beurteilen kann, wird diese von uns intensiv überwacht. Unsere Philosophie ist es, die Qualität schon dort zu sichern, wo die Software entsteht: je früher ein Fehler auffällt, umso schneller und kostengünstiger kann er auch durch uns behoben werden. Dazu setzen wir auf Automatisierung, weil wir wissen, dass ein Automat weniger fehleranfällig ist und effizienter arbeitet.
Jeder Entwickler ist für die Qualität seiner Software verantwortlich
Unsere Kunden haben höchste Ansprüche an unsere technischen Lösungen. Um diese im gesamten Entwicklungsprozess zu gewährleisten, setzen wir auf mehrere Stufen der Qualitätssicherung. Jeder Entwickler testet seine Software zunächst auf seinem Arbeitsplatzrechner, ehe er sie dem Projektteam zur Verfügung stellt. Durch diese Entwicklertests werden bereits zahlreiche Fehler entdeckt. Dort, wo es das Umfeld erlaubt, wird bereits dieser Test automatisiert.
Zusammen mit dem dezidierten Code entsteht ein Stück Software, das die Funktionalität automatisch testet. Dadurch entfällt bei Änderungen am Code die Notwendigkeit für einen erneuten manuellen Test.
Sobald ein Stück Software die Prüfung durch den Entwickler besteht, wird es in den zentralen Codestamm übergeben. Dort wird es- selbstverständlich automatisch- mit den Komponenten der anderen Entwickler zusammen gesteckt und wiederum automatisch getestet. Dadurch bekommt der Entwickler innerhalb weniger Minuten Feedback, ob er mit seiner Entwicklung möglicherweise die Komponente eines Kollegen in seiner Funktionsweise stört.
Auch der Kunde ist mit im Boot: Integrationstests
Letzlich funktioniert auch das gesamte entwickelte Stück Software nicht für sich alleine, sondern ist in eine Systemlandschaft eingebettet. Dazu sind Testsysteme auf den Plattformen unserer Kunden erforderlich. Beispielsweise simulieren wir für ein Shop-System eine Bestellung, ohne dass tatsächlich Ware versandt wird oder eine Kreditkarte belastet wird. In dieser Phase, dem sogenannten Integrationstest, ist unsere Interaktion und Kommunikation mit unserem Kunden besonders eng.
Neben den Tests auf die Erfüllung der funktionalen Anforderungen empfehlen wir, auch die nicht-funktionalen Anforderungen zu testen. Der genaue Umfang der Tests sollte im Projekt anhand der Risiken abgestimmt werden. Bei grösseren Installationen bevorzugen wir die Durchführung eines Last-Tests mit dem Ziel, ein gutes Antwortzeitverhalten sicherzustellen. Bei Systemen mit sicherheitsrelevanten Komponenten unterziehen wir die Sicherheit der implementierten Lösung einem speziellen Test.
Sobald die Testphase bestanden ist, ist das System aus technischer Sicht getestet. Der Code ist dann bereit für den wichtigsten Test: den Test aus Nutzersicht (-> User Testing).
Klare Regeln für eine konstruktive Zusammenarbeit
Vorrausetzung für ein strukturiertes Testing ist die Erstellung von Testfällen. Sofern im Projekt ein Anforderungsmanagement durchgeführt wurde, sind die erhobenen Anforderungen ein guter Ausgangspunkt für das Testing. Gerade in der letzten Projektphase geht es häufig heiss her, und es wird auch einmal emotionaler bei der Diskussion gefundener Fehler.
Die Erstellung von klaren Testkriterien auf Grundlage der Anforderungen ist ein zusätzlicher Arbeitsschritt, der dem Testing voraus gehen sollte. Sofern dies nicht geschieht, besteht die Gefahr von Unstimmigkeiten hinsichtlich der Umstände, unter denen ein Test als bestanden gilt. In diesem Zusammenhang vereinbaren wir eine Kategorisierung der Fehler: nicht jeder Fehler begründet eine Verschiebung der Inbetriebnahme der Software.
Hierbei muss nicht jede Anforderung singulär getestet werden. Es besteht auch die Möglichkeit, aus Effizienzgründen oder fachlichen Gründen, auf einzelne Tests zu verzichten. Man spricht dann von einer unvollständigen Testabdeckung, die als Risiko im Projekt gemanaged werden kann.