Schlaues zur Softwarequalität

Standard

Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.

auch wieder von Steve McConell aus Code Complete

Advertisements

Clean Code Zitat

Standard

Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‚How can I improve the code so that this comment isn’t needed?‘ Improve the code and then document it to make it even clearer.

Steve McConell

aus Code Complete (ein wirklich empfehlenswertes Werk für Softwareentwickler)

Spruch zum Wochenanfang – Entwurf komplexer Systeme

Standard

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple System.

von John Gall

 

Über die Kunst Software anwendergerecht zu testen

Standard
Es gibt sie, die Anwender mit den „goldenen“ Fingern. Alles ist fertig. Die Software ist getestet und abgenommen. Dann passiert’s. Die Anwender klagen über Fehler. Der Kundenbetreuer ist verzweifelt, der Projektleiter wütend über die Entwickler, die Entwickler verstehen das nicht. Geht doch alles.
Woran liegt’s, das ist hier die Frage.
Oder doch nicht? Lag’s nur am Softwareerstellungsprozess?
Muss: der Anwender-Stakeholder beschreibt vor Beginn der Implementierung zusammen mit dem Softwareprojektleiter was rauskommen soll. D.h., Anwenderprozess, Use cases. Was soll an Bedienung möglich sein, was nicht. Der Softwareprojektleiter achtet auf das „Außenherum“ und macht den Stakeholder auf Abhängigkeiten und Einschränkungen aufmerksam.
Muss: der Softwareprojektleiter gibt dem Entwickler die Beschreibung weiter, ergänzt und erläutert diese. Weißt auf Abhängigkeiten hin. Prüft, ob der Entwickler das verstanden hat. Er definiert Tests, die eine Verifikation der Realisierung der neuen Anforderung zulassen.
Muss: Code review mit einem erfahrenen Entwickler. Der Ersteller des neuen Codes erklärt, was dieser tun soll.
No go: der Entwickler checkt sein Werk ein. Es compiliert ja.
Muss: der Entwickler testet, dass das, was er entwickelt hat, prinzipiell geht.
Herausforderung: Automatisierung von Tests zur Minimierung des Aufwandes und für Nachvollziehbarkeit. Interne Algorithmik gerne mit Unit Tests. Die müssen allerdings vor der Implementierung geschrieben sein und auch verifiziert werden. Sonst nutzen sie dem Entwickler nichts. Anwenderprozesse, schwierig. Aufgezeichnet über Makros. Zwar nachvollziehbar, aber sie können nicht die Umgebung und die Kreativität von Anwendern abbilden. Daher aufwendig und weniger brauchbar.
No go: nur der Entwickler testet. Denn, der weiß, welche Algorithmik er programmiert hat und deshalb testet er nur auch den Weg, der funktioniert.
Muss: Test durch einen Softwaretester. Der Projektleiter erklärt die Anforderung und die Use Cases, sowie die Abhängigkeiten und in welchen Prozess beim Kunden das Ganze eingebettet ist. Ebenso übergibt er die Liste der definierten Tests. Der Softwaretester verifiziert an Hand der Tests und muss dann in einem begrenzten Zeitraum versuchen, mögliches und unmögliches zu tun, um Fehler zu provozieren. Alles sollte nachvollziehbar dokumentiert werden.
No go: Damit wird die Software für die produktive Umgebung freigegeben.
Muss: Anwendertest mit echten Endkundenanwendern auf einem Testsystem. Beurteilung der Bedienbarkeit und testen durch ganz normales Arbeiten.
No go: Anwender testen nicht, weil zu mühsam, keine Zeit, keine Lust, eh unnötig.
Muss: alle Beteiligen (Stakeholder, testende Key User, Projektleiter Softwaretester) müssen aus ihrer Sicht das Go geben.
Ergebnis: einen Monat später Fehlermeldung durch Anwender im fernen Timbuktu. Feststellung Daten korrupt. Nicht erklärbar, oder doch. Andere Länder, andere Denkweisen. Wurde leider nicht in den Key User Test einbezogen. Hat ganz andere Vorgehensweise. Wurde im Test nie überprüft und genau da sitzt der Bug.