Software-Qualität durch Test-Mix und Transparenz

Jedes Softwareprojekt ist anders und benötigt eine eigene Teststrategie sowie den richtigen Mix aus verschiedenen Testarten. Die besten Tests nutzen jedoch wenig, wenn nicht beweisbar ist, was tatsächlich getestet wurde. Diese notwendige Transparenz kann von UWS mit verschiedenen Test-Metriken z.B. bis auf die getestete Code-Zeile (Code-Coverage) nachgewiesen werden. UWS Testumgebungen bieten Transparenz angefangen beim eigentlichen Requirement bis hin zum Code und seinen Änderungen.

 
 
 
 
 
 
 
 
 
 
 
 
 
 

Qualität gibt Sicherheit

Testgetriebene Entwicklung, modellgetriebene und automatische Testgenerierung, schnell durch den Entwickler ausführbare Unit-Tests, kontinuierlich ausgeführte Integrationstests und funktionale Tests sowie die stetige automatisierte Ermittlung und Wahrnehmung von Test-Metriken geben unseren Entwicklern Sicherheit und Mut. Mut zu Restrukturierungen auf Code-Ebene, dem sogenannten Refactoring. Denn Software wächst stetig und nicht ausgeführtes Refactoring führt zu fehleranfälligen, unwartbaren und schlecht testbaren Code. Verschiedene Granularitäten von Tests geben unseren Entwicklern schnelles Feedback wo und wie sich Code-Änderungen auswirken. Eventuelle Fehler werden schnell gefunden und können früh behoben werden.

Tests sind Kommunikation, ein Werkzeug mit dem Entwickler Annahmen formulieren können und für jede Annahme kennen unsere Entwickler den richtigen "Ort" bzw. die richtige Art von Test.

 

Unit-Tests und Test-Driven-Development (TDD)

Ein Unit-Test bzw. Unit-Testing ist eine Methode mit der individuelle Einheiten von Quellcode (Unit / Modul) zusammen mit Testdaten auf ein bestimmtes Verhalten hin getestet werden. Mit einem Unit-Test kann der Entwickler also ein bestimmtes, erwartetetes Verhalten eines Moduls formulieren. Module sind dabei Bestandteile von Programmen wie Funktionen, Methoden, Schnittstellen, Klassen oder Closures.

Der Entwickler programmiert die Unit-Tests unabhängig voneinander, so dass die Ablaufreihenfolge keine Rolle spielt. Auch testet er nur das jeweilige Modul und ersetzt direkte und indirekte Abhängigkeiten durch sogenannte Mock-Objekte oder Fakes. So kann ein Modul in Isolation getestet werden.

Frameworks wie JUnit, TestNG, Spring-Testing, Mockito oder EasyMock unterstützen uns bei der Erstellung von Testfällen und machen das Schreiben von Tests so einfach, dass viele unserer Entwickler test-getrieben entwickeln. Bei der test-getriebenen Entwicklung ("test-driven-development", TDD) werden die Tests vor der Implementierung geschrieben was zu einer deutlichen Verbesserung bzgl. Modularisierung und Testabdeckung führt, ohne dabei erheblichen Mehraufwand zu verursachen.

 

Integration-Tests und Test-Driven-Development (TDD)

Ein Integration-Test bzw. Integration-Testing ist eine Methode in der einzelne Module in Kombination miteinander als Verbund getestet werden. Integration-Tests werden daher nach dem Unit-Testing ausgeführt.

Integration-Tests gehen von den Modulen als "Black-Box" aus, so dass sich in diesen Tests keinerlei Details über die Implementierung wiederfinden. Typischerweise werden daher implementierungs-unabhängige Schnittstellen auf Faktoren wie Funktion, Fehlerbehandlung, Performance und Zuverlässigkeit abgetestet.

Oben genannte Frameworks und Zusätzliche wie JMeter und SoapUI vereinfachen ebenfalls die Erstellung von Testfällen, so dass unsere Entwickler beim Schreiben von Integrations-Tests bei der test-getriebenen Entwicklung unterstützt werden.

 

Functional-Tests und Akzeptanz-Tests

Ein Functional-Test, Functional-Testing bzw. Akzeptanz-Tests sind Methoden, um die Funktionalität beim Endnutzer zu testen. Oft, aber nicht notwendigerweise werden funktionale Tests durch eine Spezifikation z.B. durch ein Lastenheft vorgegeben. UWS stellt Umgebungen bereit mit denen Functional-Tests auch durch nicht-technische Projektmitarbeiter erstellt werden können. So können z.B. die späteren Anwender der zu erstellenden Software funktionale Tests oft einfach zusammenklicken. Dies führt zu einer deutlichen Präzisierung der Projektkommunikation, Verringerung des gesamten Testaufwandes und zu ausführbaren Spezifikationen.

 

Test-Metriken

Test-Metriken wie z.B. die Testabdeckung ("Code-Coverage") geben Auskunft darüber, zu welchem Grad der Quellcode bei der Ausführung von Tests genutzt wurde. Die Testabdeckung kann dabei bis auf die Code-Zeilen zurückverfolgt werden, so dass genaue Analysen möglich sind und Fragen beantwortet werden können:

  • Wo sind Test-Risiken?
  • Wie hoch ist die Testabdeckung? Welche Module profitieren am meisten von zusätzlichen Tests?
  • Wie sind die Auswirkungen durch Quellcode-Änderungen?

Test- und Code-Metriken werden durch UWS Testumgebungen automatisch ermittelt und in erster Linie an die Entwickler kommuniziert, so dass diese potentielle Fehler sogar noch vor ihrer Entstehung antizipieren können.

 

Haben Sie Fragen zu diesem Thema? Herr Kunst steht Ihnen zur Verfügung.