Ich möchte meine Gedanken zu einer der Eigenschaften von Software teilen: Wartbarkeit.
Projekte achten nicht immer auf Wartbarkeit. Infolgedessen beginnen mit dem Teamwechsel Schwierigkeiten. Besonders wenn sich das Team unerwartet und mit einer großen Zusammensetzung ändert.
Bei Projekten spielte ich die Rolle der Qualitätssicherung. Unter anderem musste auf die Begleitung geachtet werden. Von Seiten der Programmierer wird zunächst impliziert, dass der Code von Kommentaren und einer guten Struktur begleitet sein sollte. Inzwischen ist Begleitung etwas mehr. Durch eine gute Wartbarkeit können Sie dem Hersteller des Softwareprodukts zugute kommen. Es ist nicht ohne Grund, dass Sie in großen Unternehmen alte Programme finden können, die weit von der freundlichsten Oberfläche entfernt sind, aber eine gute Wartbarkeit aufweisen. Aus diesem Grund haben sie es nicht eilig, die Entwicklung konkurrierender Unternehmen zu ersetzen.
Sie können eine Analogie zur Verlegung von Elektrik in einem Gebäude geben:
- Ein guter Elektriker stellt Ihnen die Schaltkreise zur Verfügung, bevor Sie die Verkabelung verlegen. Es wird auch nach vielen Jahren nicht notwendig sein, sich an ihn zu wenden, um zu verstehen, was wohin führt und wie es funktioniert. Während des Betriebs treten keine Probleme auf.
- Wenn der Elektriker den Schaltplan nicht erstellt, wird er ihn das nächste Mal nur kontaktieren, weil außer ihm weiß niemand, wie alles arrangiert ist - dann sollten Sie darüber nachdenken, ob es sich lohnt, mit ihm Geschäfte zu machen.
Als Tester kann ich Ihnen anbieten, die folgenden Aspekte zu beachten, um die Wartbarkeit zu verbessern.
Funktionsdokumentation.
Die Dokumentation wird nicht nur für „Benutzer irgendwo da draußen“ benötigt, sondern auch, damit jeder, der mit dem Produkt nicht vertraut ist, es um 12 Uhr mittags verwenden kann, ohne andere um Hilfe zu bitten. Zum Beispiel:
- Ein gestern eingestellter Programmierer könnte eine Funktion debuggen.
- Der technische Support könnte die Benutzerfrage beantworten
- Der Tester konnte überprüfen, ob etwas in einer unbekannten Funktion fehlerhaft war.
Infrastrukturdokumentation
Es ist am wahrscheinlichsten, dass viele Tools zum Erstellen des Produkts verwendet werden. Unter ihnen:
- Montagesystem. Vielleicht besteht es aus mehreren Maschinen, von denen jede viele Einstellungen hat;
- andere Infrastrukturdienste wie Dateiserver, Codespeichersystem (insbesondere wenn Bibliotheksabhängigkeiten von anderen Systemen bestehen) usw.;
- Prüfstände. Ihre Einstellungen und Beschreibung sollten in den Testplänen enthalten sein.
All dies ist an das Projekt gebunden. Und es wäre schön, eine detaillierte Beschreibung der Struktur zu haben, damit Sie sie leicht wiederherstellen können, wenn die Festplatte mit den Maschinen der Struktur ausfällt. Oder damit Sie mühelos Änderungen an der Infrastruktur vornehmen können, ohne Zeit damit zu verbringen, alles zu studieren.
Dokumentation von Problemen und Risiken
Bei der Erstellung und dem Betrieb des Produkts treten mit Sicherheit Probleme auf. Sie können als Lösungsbasis klassifiziert und beschrieben werden.
Einige Fehler können eine Problemumgehung haben. Wenn der Fehler schwerwiegend ist, sollte es möglich sein, in der Datenbank der Probleme einen Weg zu finden, um ihn zu umgehen. Zum Beispiel, wenn Einstellungen nur in einem bestimmten Browser vorgenommen werden können.
Wenn die Entwicklung Informationen enthüllt, dass in Zukunft Probleme auftreten können, sollten diese Informationen als Risiken bezeichnet werden. Wenn beispielsweise ein Modul in einem System mit 100 Benutzern verwendet wird, wird es wahrscheinlich mit 500 Benutzern kaputt gehen.
Kommentare und Codebeschreibungen
Möglicherweise gibt es ein Dokument mit einer technischen Beschreibung aller Module, einschließlich aller Architekturschemata.
Informationen zu den verwendeten Tools
Zum Beispiel, welche Tools und wie sie zum Debuggen und Testen verwendet werden.
Manchmal benötigt ein Programmierer Tester-Tools, um die Funktionalität zu debuggen. Oder der Tester benötigt möglicherweise Informationen zu den Tools des Entwicklers, um Informationen zu sammeln, wenn ein Fehler gefunden wird.
Es lohnt sich, auch auf die Verbreitung von Werkzeugen zu achten. Auch wenn ein Tool für die jeweilige Aufgabe gut geeignet ist, aber alt und nicht unterstützt wird, kann es schwierig sein.
Aufgabenerfüllung
Wie das Pareto-Prinzip sagt: Es dauert 80% der Zeit, um 20% der Arbeit zu erledigen.
Und wenn etwas nicht abgeschlossen ist, muss es einen Grund gegeben haben. Höchstwahrscheinlich war es teuer.