Dieses Konzept beschreibt Ansätze zur Sicherung der Softwarequalität während der gesamten Entwicklungsphase dieses Projekts. Da es sich um ein kleines Projekt handelt, soll der Qualitätsmanagementaufwand überschaubar bleiben. Es werden daher nur ausgewählte Methoden, Werkzeuge und Prozesse angewandt, die mit minimalem Aufwand eine hohe Qualität sicherstellen können.
Qualitätsmaßnahmen im Entwicklungsprozess
Statische Codeanalyse
Die statische Codeanalyse ist eine zentrale Maßnahme zur Früherkennung von potenziellen Problemen im Code. Die statische Codeanalyse sollte manuell mit Hilfe der in der IDE integrierten Mittel vor jedem Commit durchgeführt werden, um sicherzustellen, dass die wichtigsten Kodierungsstandards eingehalten werden.
Die Formatierung der Codes soll dem Standard der IDE PHPStorm entsprechen.
Technische Schulden reduzieren
- Code-Duplikationen vermeiden: Es sollte darauf geachtet werden, Code-Duplikationen zu minimieren. Gemeinsame Layoutkomponenten oder Stile sollten, sofern möglich, in wiederverwendbaren CSS-Klassen ausgelagert werden.
- Gelegentliches Refactoring: Während der Implementierungsphase sollte darauf geachtet werden, dass technischer Schuldenaufbau vermieden wird. Falls nötig, sollte gezieltes Refactoring während der Testphase erfolgen, um den Code für zukünftige Wartungen besser vorzubereiten.
Dynamische Codeanalyse und Testing
Für eine statische Webseite ohne interaktiven Elementen und ohne komplexer Logik wird Blackbox-Testing ausreichend sein, da die Überprüfung auf die sichtbaren Inhalte und Funktionen beschränkt ist.
- Visuelle Tests: Es handelt sich um eine statische Webseite ohne JavaScript, daher sollte der Fokus auf visuellen Tests liegen. Diese können manuell durchgeführt werden, indem die Webseite in verschiedenen Browsern und auf verschiedenen Geräten betrachtet wird, um sicherzustellen, dass das Layout konsistent ist und alle Inhalte korrekt dargestellt werden.
- Responsiveness-Tests: Überprüfen Sie, ob die Webseite auf verschiedenen Bildschirmgrößen (z.B. Mobilgerät, Tablet, Desktop) ordnungsgemäß dargestellt wird.
- Link-Prüfungen: Alle internen und externen Links sollten überprüft werden, um sicherzustellen, dass sie korrekt funktionieren und keine „toten Links“ vorhanden sind.
Vorgehensweise:
- grundlegende Layout-& Funktions-Checks sollen mit dem Fragebogen_zum_Testing.xlsx vor dem Code-Review und Pull Request vorgenommen werden um gröbere Fehler vor dem Zusammenführen früh zu umgehen
- die DOD sollen bei der Implementierung und beim anschließendem Testen immer im Fokus stehen.
Code-Reviews und Pull Requests
Code-Reviews sind wichtig zur Qualitätssicherung, sollten jedoch pragmatisch eingesetzt werden.
- Informelle Walkthroughs: Einfache Code-Walkthroughs im Team sind nützlich, um grundlegende Fehler frühzeitig zu erkennen. Sie können eine Ergänzung zu formellen Pull-Request-Reviews sein.
- Pull Requests und Merge-Kontrollen: Entwickler erstellen Pull Requests, wenn das Feature fertig entwickelt ist, welche dann von anderen Teammitgliedern kontrolliert und kommentiert werden können. Dieser Prozess bietet eine zusätzliche Sicherheitsschicht, da alle Änderungen erst nach einer Überprüfung und Genehmigung in den Hauptzweig gemergt werden.
flowchart LR
A(Entwicklung\ndes Features)
B(MR erstellen)
C{Entspricht\nQualitätsstandard}
D(MR freigeben)
E(Feedback geben)
F(Anpassung\ndurch Entwickler)
Start(( )) --> A
A --> B
B --> C
C -- Nein --> E
E --> F
F --> C
C -- Ja --> D
D --> End(( ))
Vorgehensweise:
- vor dem Merge Requests (MR) werden die Funktionalitäten vom Entwickler mit dem Fragebogen_zum_Testing.xlsx geprüft.
- bei Fertigstellung der Implementierung des Features und des Testings wird der MR erstellt. Der Fragebogen wird im MR als PDF Anhang in der Beschreibung beigefügt.
- Wenn der Code nicht den Qualitätsstandards (DOD und Fragebogen_zum_Testing.xlsx) entspricht,
- ❌ dann wir der MR nicht freigegeben. Der Entwickler erhält Feedback und korrigiert die Fehler. Anschließend wieder Schritt 2
- ✅ sonst wird der MR freigegeben
- nach dem der Pull Request erfolgreich abgeschlossen ist, müssen alle anderen Entwickler einen Rebase machen, damit sie auf dem aktuellen Stand sind.
Exemplarische Git-Historie
%%{init: { 'logLevel': 'debug', 'theme': 'default' } }%%
gitGraph
commit id: "init"
branch dev
checkout dev
commit id: "init Codebase"
branch dev/feature1
branch dev/feature2
checkout dev/feature1
commit id: "f1-Com1"
commit id: "f1-Com2"
commit id: "f1-Com3"
checkout dev
merge dev/feature1
checkout dev/feature2
commit id: "f2-Com1"
commit id: "f2-Com2"
checkout dev
merge dev/feature2
branch dev/feature3
checkout dev/feature3
commit id: "f3-Com1"
commit id: "f3-Com2"
commit id: "f3-Com3"
checkout dev
merge dev/feature3
checkout main
merge dev
commit id: "main-Com1"