Safak/SWE
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Update Qualitätsmanagement

Safak Hazinedar
2024-11-12 16:01:01 +01:00
parent 313108e4eb
commit 9eab2e33db
1 changed files with 26 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
Qualitätsmanagement.md

@@ -21,7 +21,7 @@ Für eine statische Webseite ohne interaktiven Elementen und ohne komplexer Logi
**Vorgehensweise**:
* In der Implementierungsphase sollten grundlegende Layout-& Funktions-Checks direkt mit dem [Fragebogen_zum_Testing.xlsx](uploads/085ac4726a7c2f96935ff383c4ec01af/Fragebogen_zum_Testing.xlsx) beim Code-Review und Pull Request vorgenommen werden um gröbere Fehler vor dem Zusammenführen früh zu umgehen
* In der Implementierungsphase sollten grundlegende Layout-& Funktions-Checks direkt mit dem [Fragebogen_zum_Testing.xlsx](uploads/085ac4726a7c2f96935ff383c4ec01af/Fragebogen_zum_Testing.xlsx) beim [Code-Review und Pull Request](https://git.fh-aachen.de/eb2342s/swe-b1-a/-/wikis/Qualit%C3%A4tsmanagement#code-reviews-und-pull-requests) vorgenommen werden um gröbere Fehler vor dem Zusammenführen früh zu umgehen
* In der dedizierten Testphase umfassende visuelle Überprüfungen und Responsiveness-Tests unter strenger Berücksichtigung der DOD durchgeführt werden.
### Code-Reviews und Pull Requests
@@ -31,10 +31,30 @@ Code-Reviews sind wichtig zur Qualitätssicherung, sollten jedoch pragmatisch ei
* **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.
```mermaid
flowchart TD
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**:
1. vor dem Pull Requests werden die Funktionalitäten vom Entwickler mit dem [Fragebogen_zum_Testing.xlsx](uploads/085ac4726a7c2f96935ff383c4ec01af/Fragebogen_zum_Testing.xlsx) geprüft.
2. bei Fertigstellung der Implementierung des Features und des Testings wird der Pull Request erstellt. Der Fragebogen wird im Pull Request als PDF Anhang in der Beschreibung begefügt.
* Entwickler können so ihre Änderungen anderen präsentieren, insbesondere bei größeren oder kritischen Änderungen, und zusätzliches Feedback erhalten.
* Die Verwendung von Pull Requests bietet eine klare Nachverfolgbarkeit der Änderungen und erhöht die Codequalität vor der Integration in den Hauptzweig.
3. nach dem der Pull Request erfolgreich abgeschlossen ist, müssen alle anderen Entwickler einen Rebase machen, damit sie auf dem aktuellen Stand sind.
1. vor dem Merge Requests (MR) werden die Funktionalitäten vom Entwickler mit dem [Fragebogen_zum_Testing.xlsx](uploads/085ac4726a7c2f96935ff383c4ec01af/Fragebogen_zum_Testing.xlsx) geprüft.
2. 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.
3. Wenn der Code nicht den Qualitätsstandards 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
4. nach dem der Pull Request erfolgreich abgeschlossen ist, müssen alle anderen Entwickler einen Rebase machen, damit sie auf dem aktuellen Stand sind.