eingesendet von Thomas Reinwart

Gleichbleibende maschinelle Prozesse ermöglichen es, eine neutrale Qualitätssicherung der Softwareprodukte und des Software Auslieferungsprozesses sicherzustellen. Eine Automatisierung steigert die Qualität, diese wird dadurch auch messbar. Eine Vermeidung von immer gleichen manuellen Prozessen steigert die Motivation und spart letztlich Zeit bei der Auslieferung des Software Produkts. Denn seine eigene Ressource kann man für wichtigere Dinge nutzen.

Mit den Möglichkeiten modernen Software Entwicklung lassen sich sowohl Qualität als auch der gesamte Auslieferungsprozess Automatisieren.

Automatisieren bedeutet in diesen Zusammenhang

• Tatsächliche Qualitätsprüfung
• Geschwindigkeitssteigerung der Auslieferung
• Die Qualitätsprüfung wird historisch vergleichbar und dadurch messbar
• Ein einheitlicher und gleichbleibender Prozess

Voraussetzung für eine automatisierte Qualitätsprüfung sind Unit Tests. Diese müssen vom Entwickler selbst erstellt werden. Ob die Anzahl der erstellten Tests ausreichend ist, kann mit eine Code Coverage (Abdeckung Verhältnis Code zu Unit Tests) überprüft werden. Zusätzliche ebenfalls automatisierte UI (User Interface) Tests sind auch möglich.

Der Auslieferungsprozess an sich kann komplett automatisiert werden:

• Sourcecode Ablage z.B. TFS, GIT, Sicherung aller Sourcen
• Check: durch automatischen Build am Server: ist der Code komplett und kompilierbar
• Check: Code Analyse: wurden die Security Rules eingehalten: Report
• Check: Sind Unit Tests vorhanden, funktionieren diese
• Check: Code Coverage, wieviel Code wird durch Unit Tests überprüft: Report
• Check: Sind UI Tests vorhanden, Funktionstest, wieviel Code wird dabei überprüft: Report
• Automatische Erstellung einer Code Dokumentation: Ablage der Doku
• Check: Build Gesamtreport: Vergleich der Ergebnisse mit dem vorigen Builds / Versionen möglich: Einblick in welche Richtung sich der Code entwickelt
• Ablage des Qualitätsgesicherten SW Produkts

• 

• 

• 

• 

• 

• 

• 

TEIL 1: Qualitätsmaßnahmen bei der Entwicklung mit Visual Studio

Ein Teil der Sicherstellung des Qualitätslevels bei der Entwicklung von Programmen wird mit Unit Tests bei der Entwicklung selber abgedeckt. Mit Unit Tests lässt sich das Verhalten von Methoden in Komponenten testen. Das passiert entweder parallel zur Entwicklung (XP – Extreme programming und TDD test driven development ) oder im Nachhinein vom Ersteller, des zu testenden Codes.

Mittels Code Coverage, diese kann im Visual Studio selber ermittelt werden, lässt sich die Abdeckung, für welche Teile des Sourcecodes bereits Unit Tests vorhanden sind, feststellen. Ein Code Coverage Wert von 80% ist akzeptabel, 100% sind anzustreben.

Diese Maßnahmen zur Qualitätssicherung sind in Visual Studio Professional bereits inkludiert, es sind keine Zusatztools und Lizenzen mehr notwendig, es entstehen keine zusätzlichen Kosten.

Unit Tests

Das Bestreben nach ausgereifter Software gab es schon immer, daher kam die Idee einen möglich realistischen Qualitätstest aus Sicht des Anwenders durchzuführen. Der personelle Aufwand im Vergleich der Anzahl der Entwickler zu Testen lag je nach der Festlegung des Qualitätslevels und dem Zeitdruck des Projekts von 1:1 bis 1:3. Manuelles Testen ist also sehr teuer, die Tester müssen einerseits technisch qualifiziert sein um Fehler nachstellen zu können, den Fehler in seiner Umgebung eingrenzen und eine technisch möglichst gute Fehlerbeschreibung für die Behebung durch einen Entwickler erstellen, um doppelte Arbeitsvorgänge zu unterbinden. Andererseits müssen die Tester auch die Use Cases und die Funktionen der Applikation kennen, also laufend über die Erweiterungen informiert werden. Nun sollen die Tester immer die bestehenden und neu hinzugekommene Use Cases testen, im Falle eines Fehlers nach der Behebung durch den Entwickler wieder von vorne beginnen, ohne davon einen Gewöhnungseffekt zu bekommen und Dinge übersehen, eine Sisyphusarbeit also.

Daher werden Unit Test vom Entwickler selber geschrieben. Bestenfalls vor dem eigentlichen Codieren, da man sich hier zuvor überlegen muss, was der Code für eine Aufgaben haben soll. Das führt zu keinen Irrwegen.

In der Solution müssen ein oder mehrere Unit Test Projekte vorhanden sein. Diese Projekte lassen sich im Visual Studio mittels Wizzard anlegen. Unit Tests werden vom Build Server durch den Assemblyname *test* erkannt und als Unit Test ausgeführt. Unit Tests werden nicht im Setup ausgeliefert.

Vor dem Einchecken sind alle Unit Tests positiv zu absolvieren, das muss der Entwickler garantieren.

User Interface (UI) Tests in Visual Studio

• 

• 

• 

• 

Unit Test testen möglichst kleine Teile von Klassen oder auch zusammenhängende Programmabschnitte ab, kein User Interface und unabhängig von der UI Plattform.

UIA Test testen aus Sicht des User Interface auf der konfigurierten UI Plattform ab, dabei spielen sie den zuvor generierten Code wieder ab. Beide Tests können automatisiert werden und zeigen das Ergebnis an.

Die Test Tools verwenden unterschiedliche Methoden ihre Test Cases aufzuzeichnen, diese haben sich im Laufe der Zeit verändert und mussten an die neuen Plattformen wie Web Seiten für unterschiedliche Browser angepasst werden.

Es gibt also immer auch einen organisatorischen Zusammenhang zwischen der Use Case Definition, der tatsächlichen Umsetzung und dem UIA Test, der UIA Test muss der Umsetzung angepasst werden.

Bei der Auswahl und dem Einsatz eines Test Tools sollte man sich auch überlegen, wie man beim Test vorgehen möchte. Soll es ein „Monkey Test“ sein, bei dem das Tool drauflos klickt bis es keine Funktion mehr gibt und dies als ziemlichen breiten Baum im Ergebnis darstellt, den es zu interpretieren gilt. Es hat auch seine Vorteile, wenn man erkennt, was ein User alles anstellen könnte – woran man beim Entwickeln des Codes nicht gedacht hat. Oder aber soll ein bestimmter definierter Use Case getestet werden, wie er bereits in den Anforderungen beim Auftraggeber besprochen wurde. Also z.B. das Erfassen einer Transaktion, Eingabe der Pflichtfelder und speichern des Datensatzes.

Code Analyse im Visual Studio aktivieren

Der Sourcecode kann bereits durch den Entwickler in Visual Studio überprüft werden.

In den Microsoft Security Rules sind die wichtigsten Überprüfungen, wie etwa SQL Injection, enthalten. Wird ein potentielles Risiko erkannt, erhält man ausreichend Hilfe das Problem zu lösen. Auf einer Webseite werden das Problem und ein Lösungsweg erklärt.

Eine aktivierte Code Analyse gibt beim Build die potenziell erkannten Probleme als Warnung aus.

TEIL 2: Build Automatisierung

Ermöglicht wird dies durch den TFS (Team Foundation Server), seit 2019 unter dem Namen Azure Dev Ops Server.

Es besteht folgende Upgrade Möglichkeit von älteren TFS Versionen Richtung 2018 und von der Richtung DevOps Server:

Der TFS Server steuert den automatisierten Auslieferungsprozess, dieser ist für jedes Projekte als individuelle definierbaren Workflow konfigurierbar.

Definieren einer Build Definition durch den Entwickler in Visual Studio und im TFS Web Browser.

Source Quelle angeben

Der erste Schritt ist die Angabe der Source Code Quelle, TFS, GIT, oder SubVersion.

Build

Das Kompilieren des zuvor angegebenen Sourcecode, die Solution oder das Projekt.

Unit Tests

War der Build erfolgreich, können die Unit Test ausgeführt werden. Aus dem Testergebnis wird am Ende ein Report erzeugt, der TFS Build Server versendet den Report als eMail an den Entwickler. Der Report wird später für die QS benötigt.

Ablegen des erzeugten Software Produkts

Ein WebService oder ein Webanwendung kann etwa durch publish auf einen IIS deployed werden, um hier weitere UI Teste am fertigen Produkt durchzuführen.  Es ist aber auch möglich direkt ein Docker Image zu erstellen, und dieses dann lokal oder in der Cloud abzulegen,

• 

• 

• 

• 

• 

• 

• 

• 

Test Ergebnisse publizieren

Das Testergebnis enthält eine Auflistung der Unit Tests (pos/neg), einen Wert für die Abdeckung der vorhandenen Tests auf den bestehenden Sourcecode, die Code coverage. Die Testergebnisse der Builds sind historisch gespeichert, dadurch ergeben sich weitere Aussagen über die Code Qualität – Anzahl der Tests, Verhältnis Abdeckung der Tests zum erzeugten Code, ob steigend oder fallend.

Der TFS Build Prozess unterstützt zahlreiche Systeme über bereits vorhandene PlugIns, sowie über einen Marketplace mit zusätzlichen PlugIns.

Fazit

Keiner möchte sich eigentlich gerne mit langweiligen Tätigkeiten auseinandersetzen und lieber seine Energie besser einsetzen. Mit der Möglichkeit seine Software automatisiert und maschinell qualitätsgesichert mit diesen Tools auszuliefern, wird dies selbst für den kleinen Individualentwickler möglich. Also Modernisierung der eigenen Tätigkeiten durch wesentlich mehr Automatisierung.

Autorenbox

Thomas Reinwart verfügt über umfangreiche Berufserfahrung auf dem IT Sektor. In den letzten 25 Jahren war er in den Bereichen Softwareentwicklung, Softwaredesign, Architekt und als Consultant tätig. Technischer Fokus ist derzeit Microsoft .net und SQL Server, wo er alle aktuellen Microsoft Zertifizierungen hat.

Email: office@reinwart.com