Applied Software Engineering Master-Projekt - Exam

Aufgabe 1)

Du bist Teil eines Teams, das ein Softwareprojekt mit agilen Methoden durchführt. Nutze die Prinzipien des Agilen Manifests, um die folgenden Aufgaben zu bearbeiten:

a)

(a) Während des Sprints deines Teams stellt der Kunde eine wesentliche Anforderungsänderung für ein fast abgeschlossenes Feature. Erläutere, wie Du und Dein Team gemäß den Prinzipien des Agilen Manifests auf diese Änderung reagieren sollten und welche Schritte Ihr unternehmen werdet. Berücksichtige dabei mindestens drei der zwölf agilen Prinzipien.

Lösung:

(a) Während des Sprints deines Teams stellt der Kunde eine wesentliche Anforderungsänderung für ein fast abgeschlossenes Feature. Erläutere, wie Du und Dein Team gemäß den Prinzipien des Agilen Manifests auf diese Änderung reagieren sollten und welche Schritte Ihr unternehmen werdet. Berücksichtige dabei mindestens drei der zwölf agilen Prinzipien.

• Willkommen bei Änderungsanforderungen, selbst spät in der Entwicklung Das Agile Manifest betont, dass Änderungen willkommen sind, auch wenn sie spät in der Entwicklung stattfinden. Auf diese Weise wird der Wettbewerbsvorteil des Kunden durch kontinuierliche Verbesserung stets gesteigert. Deshalb sollte Dein Team die Anforderungsänderung des Kunden begrüßen und dies als eine Gelegenheit sehen, das Produkt noch besser an die Bedürfnisse des Kunden anzupassen.
• Enge tägliche Zusammenarbeit zwischen dem Entwicklungsteam und dem Kunden Um die Änderung effizient umzusetzen, solltet Ihr den Kunden eng einbeziehen und vielleicht ein Meeting organisieren. In diesem Meeting kann das Team die Änderungen und ihre Auswirkungen verstehen und priorisieren. Eine transparente Kommunikation sorgt dafür, dass alle Beteiligten auf dem gleichen Stand sind.
• Ausrichtung auf nachhaltige Entwicklung Laut des Agilen Manifests sollte das Entwicklungstempo nachhaltig und langfristig durchhaltbar sein. Dies bedeutet, dass Dein Team die Änderung so einplant, dass die Qualität der Arbeit und die Arbeitsbelastung für das Team vernünftig bleiben. Ein reaktives Arbeiten ohne Rücksicht auf das Team führt zu Burnout und sollte vermieden werden.

• Änderungsanforderung aufnehmen und bewerten: Das Team trifft sich und bespricht die vom Kunden gewünschte Änderung. Dabei ist es essentiell, die genauen Anforderungen zu verstehen und die Auswirkungen auf das bereits entwickelte Feature zu bewerten.
• Priorisierung und Planung: Zusammen mit dem Product Owner wird die Änderung priorisiert. Falls nötig, wird der Sprint-Backlog angepasst und die Änderung im laufenden Sprint oder im nächsten Sprint eingeplant.
• Durchführung und Testing: Das Entwicklungsteam beginnt mit der Umsetzung der Änderungen unter Berücksichtigung der bestehenden Aufgaben und des aktuellen Arbeitsaufkommens. Es wird darauf geachtet, die Änderungen gründlich zu testen, um die Qualität sicherzustellen.
• Review und Feedback: Nach der Umsetzung wird die Änderung dem Kunden vorgestellt und Feedback eingeholt. Dadurch wird sichergestellt, dass die Änderungen den Erwartungen entsprechen und gegebenenfalls weiter angepasst werden können.
• Retrospektive: Am Ende des Sprints wird in der Retrospektive bewertet, wie gut das Team die Änderungsanforderung bewältigt hat und was beim nächsten Mal verbessert werden kann.

b)

(b) Dein Team hat eine Phase erreicht, in der es Schwierigkeiten gibt, das Produkt in regelmäßigen, kurzen Intervallen zu liefern. Analysiere die möglichen Ursachen und stelle sicher, dass Deine Analyse sich auf mindestens vier der unten aufgeführten Prinzipien des Agilen Manifests bezieht:

• Individuen und Interaktionen über Prozesse und Werkzeuge
• Funktionierende Software über umfassende Dokumentation
• Zusammenarbeit mit dem Kunden über Vertragsverhandlung
• Nachhaltige Entwicklung durch gleichbleibendes Tempo

Schlage anhand dieser Prinzipien geeignete Maßnahmen vor, um die Probleme zu beheben und kontinuierliche Lieferungen zu gewährleisten.

Lösung:

(b) Dein Team hat eine Phase erreicht, in der es Schwierigkeiten gibt, das Produkt in regelmäßigen, kurzen Intervallen zu liefern. Analysiere die möglichen Ursachen und stelle sicher, dass Deine Analyse sich auf mindestens vier der unten aufgeführten Prinzipien des Agilen Manifests bezieht:

• Individuen und Interaktionen über Prozesse und Werkzeuge
• Funktionierende Software über umfassende Dokumentation
• Zusammenarbeit mit dem Kunden über Vertragsverhandlung
• Nachhaltige Entwicklung durch gleichbleibendes Tempo

• Individuen und Interaktionen über Prozesse und Werkzeuge Ein möglicher Grund für die Schwierigkeiten könnte sein, dass das Team zu sehr auf Prozesse und Werkzeuge fixiert ist, anstatt auf direkte Kommunikation und Zusammenarbeit. Dies könnte zu Missverständnissen und Verzögerungen führen, da wertvolle Zeit auf komplexe Prozesse und unflexible Werkzeuge verwendet wird.
• Funktionierende Software über umfassende Dokumentation Wenn das Team zu viel Zeit auf detaillierte Dokumentation anstatt auf die eigentliche Softwareentwicklung verwendet, kann dies ebenfalls zu Verzögerungen führen. Es ist wichtig, die Balance zu finden und den Fokus auf die Lieferung funktionierender Software zu setzen.
• Zusammenarbeit mit dem Kunden über Vertragsverhandlung Wenn die Zusammenarbeit mit dem Kunden nicht optimal ist, kann dies zu Missverständnissen hinsichtlich der Anforderungen führen und in der Folge zu Schwierigkeiten bei der pünktlichen Lieferung. Eine offene und regelmäßige Kommunikation mit dem Kunden ist daher essenziell.
• Nachhaltige Entwicklung durch gleichbleibendes Tempo Ein ungleichmäßiges Arbeitstempo kann ebenfalls ein Problem darstellen. Wenn das Team Phasen intensiver Arbeit und Phasen geringer Aktivität durchläuft, führt dies zu Stress und Burnout, was die Produktivität und die regelmäßige Lieferung beeinträchtigen kann.

• Förderung der Kommunikation im Team Organisiert regelmäßige tägliche Standup-Meetings, um den aktuellen Stand der Arbeiten zu besprechen und Probleme schnell zu identifizieren und zu lösen. Die direkte Kommunikation sollte über der Nutzung komplizierter Prozesse und Werkzeuge stehen.
• Fokus auf funktionierende Software Legt den Fokus auf die Entwicklung und Auslieferung funktionierender Software. Reduziert die Zeit, die für umfassende Dokumentation aufgewendet wird, indem Ihr nur die notwendigsten Dokumente erstellt und den Rest durch Code-Kommentare und die Software selbst dokumentiert.
• Enge Zusammenarbeit mit dem Kunden Stellt sicher, dass der Kunde regelmäßig in den Entwicklungsprozess eingebunden wird, zum Beispiel durch häufige Reviews und Feedback-Sessions. Eine starke Zusammenarbeit hilft, Anforderungen frühzeitig zu klären und Änderungen rechtzeitig zu integrieren.
• Nachhaltigeres Arbeitstempo Achtet darauf, ein gleichbleibendes Arbeitstempo zu bewahren. Plant die Sprints so, dass die Arbeitslast realistisch vertretbar ist und stellt sicher, dass es regelmäßige Pausen und ausreichende Erholung für das Team gibt. Dies verhindert Burnout und sorgt für eine kontinuierlich hohe Produktivität.

Aufgabe 2)

Du bist Teil eines Entwicklungsteams, das Scrum einsetzt, um eine neue Softwareanwendung zu entwickeln. Dein Team besteht aus einem Product Owner, einem Scrum Master und fünf Entwickler(innen). Gerade ist ein Sprint abgeschlossen und es stehen das Sprint Review und die Sprint Retrospektive an. Während des Sprints sind einige Probleme aufgetreten, darunter Kommunikationsprobleme im Team und Missverständnisse bezüglich der Anforderungen. Außerdem wurden einige Aufgaben nicht abgeschlossen, was zu einem nicht vollständigen Produktinkrement führte.

a)

Beschreibe die Aufgaben und Ziele des Sprint Reviews und der Sprint Retrospektive im Scrum-Framework. Erläutere im Detail, wie diese beiden Events deinem Team helfen könnten, die aufgetretenen Probleme zu lösen und Verbesserungen für zukünftige Sprints zu identifizieren.

Lösung:

Aufgaben und Ziele des Sprint Reviews und der Sprint Retrospektive im Scrum-Framework

Im Scrum-Framework sind der Sprint Review und die Sprint Retrospektive zwei essentielle Ereignisse, die dazu beitragen, die kontinuierliche Verbesserung und Anpassung des Entwicklungsteams sicherzustellen. Jedes dieser Events hat spezifische Aufgaben und Ziele:

• Sprint Review:

  • Aufgaben:
    • Überprüfung und Präsentation des Produktinkrements: Das Team stellt die im Sprint erstellten Produktfunktionalitäten vor.
    • Demonstration des Fortschritts: Das Team demonstriert, wie das Produktinkrement aussieht und welche neuen Funktionen hinzugefügt wurden.
    • Einholen von Feedback: Stakeholder und der Product Owner geben Rückmeldungen und diskutieren über mögliche Anpassungen und Verbesserungen.
    • Planung der nächsten Schritte: Basierend auf dem Feedback werden die nächsten Schritte und Ziele für den kommenden Sprint überlegt und im Product Backlog angepasst.
  • Ziele:
    • Sicherstellen, dass das Produkt den Anforderungen und Wünschen der Stakeholder entspricht.
    • Transparenz und Einblick für alle Beteiligten schaffen.
    • Prioritäten und Ziele für den nächsten Sprint bestimmen.

• Sprint Retrospektive:

  • Aufgaben:
    • Reflexion des Sprints: Das Team reflektiert, was während des Sprints gut gelaufen ist und was verbessert werden kann.
    • Identifizierung von Problemen: Kommunikationsprobleme, Missverständnisse und nicht abgeschlossene Aufgaben werden analysiert und besprochen.
    • Schaffung von Verbesserungsvorschlägen: Das Team entwickelt konkrete Maßnahmen, um die identifizierten Probleme in zukünftigen Sprints zu vermeiden.
  • Ziele:
    • Kontinuierliche Verbesserung der Arbeitsprozesse und Zusammenarbeit im Team.
    • Steigerung der Produktivität und Effizienz durch das Lernen aus vergangenen Sprint-Erfahrungen.
    • Förderung einer offenen Kommunikation und eines vertrauensvollen Arbeitsumfelds.

Wie diese Events dem Team helfen könnten, die aufgetretenen Probleme zu lösen

• Kommunikationsprobleme:
  • Während der Sprint Retrospektive kann das Team spezifische Kommunikationshindernisse identifizieren und Lösungsstrategien wie regelmäßige Check-ins, klare Kommunikationskanäle oder die Einführung eines täglichen Stand-Ups diskutieren und implementieren.
• Missverständnisse bezüglich der Anforderungen:
  • Im Sprint Review können Missverständnisse durch sofortiges Feedback von Stakeholdern und dem Product Owner identifiziert und geklärt werden.
  • In der Sprint Retrospektive kann das Team überlegen, wie die Anforderungsdokumentation und das Verständnis verbessert werden können, z.B. durch detailliertere User Stories oder bessere Abstimmungsmeetings.
• Nicht abgeschlossene Aufgaben:
  • Durch die Analyse in der Sprint Retrospektive kann das Team herausfinden, warum Aufgaben nicht abgeschlossen wurden (z.B. fehlende Ressourcen, unklare Anforderungen, technische Schwierigkeiten) und Maßnahmen zur Verbesserung der Planung und Durchführung entwickeln.
  • Im Sprint Review kann der Product Owner die Prioritäten neu bewerten und notwendige Anpassungen im Product Backlog vornehmen.

Insgesamt ermöglichen der Sprint Review und die Sprint Retrospektive dem Team, transparenter zu arbeiten, effektiver zusammenzuarbeiten und kontinuierlich Verbesserungen in den Arbeitsabläufen und der Produktentwicklung zu identifizieren und umzusetzen.

b)

Du hast die Aufgabe, den „Product Backlog“ für den nächsten Sprint zu aktualisieren und vorzubereiten. Beschreibe den Prozess der Priorisierung von Product Backlog Items durch den Product Owner. Wie kann der Product Owner sicherstellen, dass die Anforderungen klar und verständlich sind und dass die höchst priorisierten Items im nächsten Sprint effektiv bearbeitet werden können? Gehe dabei auch auf mögliche Techniken zur Anforderungsklärung ein, wie beispielsweise User Stories und Akzeptanzkriterien.

Lösung:

Den „Product Backlog“ für den nächsten Sprint aktualisieren und vorbereiten

Um den „Product Backlog“ für den nächsten Sprint zu aktualisieren und vorzubereiten, ist es wichtig, dass der Product Owner einen klaren und systematischen Ansatz zur Priorisierung und Klärung der Anforderungen verfolgt. Im Folgenden wird der Prozess beschrieben:

1. Priorisierung von Product Backlog Items durch den Product Owner

• Sammeln und Bewerten von Anforderungen: Der Product Owner sammelt alle eingegangenen Anforderungen und bewertet sie hinsichtlich ihrer Bedeutung, des geschäftlichen Wertes und des Aufwands, der für ihre Umsetzung erforderlich ist.
• Geschäftlicher Wert: Die Anforderungen werden nach ihrem potenziellen Nutzen für den Benutzer und das Unternehmen bewertet. Items, die den höchsten Geschäftswert bieten, werden höher priorisiert.
• Dringlichkeit und Abhängigkeiten: Dringende Aufgaben und solche, die von anderen abhängen, werden entsprechend priorisiert. Die Reihenfolge kann angepasst werden, um Abhängigkeiten zu berücksichtigen.
• Teamkapazität und Schätzungen: Der Product Owner schätzt den Aufwand ein, der für die Umsetzung der einzelnen Items erforderlich ist und berücksichtigt die Kapazität des Teams für den kommenden Sprint.

2. Sicherstellen, dass Anforderungen klar und verständlich sind

• Erstellen von User Stories: Anforderungen sollten als User Stories formuliert werden. Eine User Story beschreibt, was der Benutzer möchte und warum dies wichtig ist. Eine typische Struktur könnte wie folgt aussehen: „Als [Benutzertyp] möchte ich [Ziel] erreichen, um [Nutzen].“
• Definieren von Akzeptanzkriterien: Um sicherzustellen, dass die Anforderungen klar und überprüfbar sind, sollten Akzeptanzkriterien hinzugefügt werden. Diese Kriterien beschreiben die Bedingungen, unter denen eine User Story als abgeschlossen betrachtet wird. Sie geben dem Entwicklungsteam klare Anweisungen darüber, was erwartet wird. Beispiel für Akzeptanzkriterien:
  • Die Anwendung muss dem Benutzer ermöglichen, sich zu registrieren.
  • Der Benutzer muss eine Bestätigungs-E-Mail nach der Registrierung erhalten.
• Konsistenz und Transparenz: Der Product Owner sollte sicherstellen, dass alle User Stories konsistent und transparent sind. Er kann regelmäßige Abstimmungsmeetings mit dem Entwicklungsteam abhalten, um Unklarheiten zu vermeiden und sicherzustellen, dass alle Beteiligten die Anforderungen vollständig verstehen.
• Feedback-Schleifen und Anpassung: Der Product Owner sollte kontinuierlich Feedback vom Team einholen und gegebenenfalls die User Stories und Akzeptanzkriterien anpassen.

3. Effektive Bearbeitung höchst priorisierter Items im nächsten Sprint

• Klärung vor Sprintbeginn: Vor dem Start des nächsten Sprints sollte der Product Owner sicherstellen, dass alle für den Sprint eingeplanten User Stories vollständig geklärt und priorisiert sind.
• Backlog Refinement Meeting: Regelmäßige Backlog Refinements helfen dem Team, die anstehenden Aufgaben zu verstehen und zu schätzen. Der Product Owner kann während dieser Meetings direkte Fragen beantworten und sicherstellen, dass alle Anforderungen klar definiert sind.
• Ständige Abstimmung: Der Product Owner sollte auch während des Sprints in ständigem Kontakt mit dem Team bleiben, um bei Bedarf sofortige Klärungen vorzunehmen und Anpassungen vorzunehmen.

Durch die Anwendung dieser Techniken und Prozesse kann der Product Owner sicherstellen, dass die Anforderungen klar und verständlich sind, die höchsten Prioritäten effektiv bearbeitet werden können und das Team optimal auf den nächsten Sprint vorbereitet ist.

Aufgabe 3)

In der modernen Softwareentwicklung spielt die Testautomatisierung eine entscheidende Rolle zur Sicherstellung der Softwarequalität. Zwei der hauptsächlich genutzten Frameworks sind Selenium und JUnit. Selenium ermöglicht die Automatisierung von Webanwendungen und ist somit plattformunabhängig, während JUnit ein Unit-Testing-Framework für Java ist, das die Entwicklung testgesteuert unterstützt. Beide Tools sind essenziell für die Reduzierung manueller Testaufwände, die Verbesserung der Testabdeckung und die Sicherstellung der Wiederholbarkeit. Sie werden häufig in CI/CD-Pipelines integriert, um kontinuierliche Integration und Bereitstellung zu gewährleisten.

a)

Erkläre den grundlegenden Aufbau eines JUnit-Tests und gehe darauf ein, wie er in einer CI/CD-Pipeline genutzt werden kann, um die Softwarequalität sicherzustellen. Diskutiere die Vorteile der Einbindung von JUnit-Tests in eine CI/CD-Pipeline.

Lösung:

Grundlegender Aufbau eines JUnit-Tests:

• JUnit-Abhängigkeiten: Um JUnit zu verwenden, musst Du die JUnit-Bibliothek in deinem Projekt einbinden. Bei Maven-Projekten sieht dies beispielsweise so aus:

<dependency>  <groupId>junit</groupId>  <artifactId>junit</artifactId>  <version>4.13.2</version>  <scope>test</scope> </dependency>

• Testklasse und -methoden: Eine JUnit-Testklasse enthält eine oder mehrere Testmethoden, die mit der Annotation @Test markiert sind. Hier ein einfaches Beispiel:

import static org.junit.Assert.*; import org.junit.Test; public class CalculatorTest {    @Test    public void testAddition() {        Calculator calc = new Calculator();        assertEquals(5, calc.add(2, 3));    } }

• In diesem Beispiel wird die Methode testAddition getestet, indem überprüft wird, ob das Ergebnis der Addition von 2 und 3 gleich 5 ist.
• Annotations: Es gibt andere nützliche Annotationen wie @Before, @After, @BeforeClass und @AfterClass, um Initialisierungen oder Aufräumarbeiten durchzuführen.
• Assertions: Die Klasse Assert bietet verschiedene Methoden wie assertEquals, assertTrue, assertFalse, um Bedingungen zu überprüfen und die Tests anhand dieser Bedingungen zu validieren.

Integration von JUnit-Tests in einer CI/CD-Pipeline:

• JUnit-Tests können einfach in CI/CD-Pipelines integriert werden, etwa durch Build-Tools wie Jenkins, GitLab CI/CD oder Travis CI.
• Ein typischer CI/CD-Workflow könnte folgende Schritte umfassen:
  • Source-Code-Änderungen werden in ein Versionskontrollsystem (z. B. Git) eingecheckt.
  • Ein Trigger-Event (z. B. ein neuer Commit) startet die Pipeline.
  • Der Code wird gebaut und die JUnit-Tests werden ausgeführt.
  • Bei Erfolg werden die Artefakte (z. B. JAR-Dateien) erstellt und ggf. in ein Repository wie Nexus oder Artifactory hochgeladen.
  • Ein Deployment-Schritt kann die Artefakte auf Test- oder Produktionsumgebungen bereitstellen.

Vorteile der Einbindung von JUnit-Tests in eine CI/CD-Pipeline:

• Automatisierte Tests: JUnit-Tests werden automatisch bei jedem Build ausgeführt, was die manuelle Testarbeit reduziert.
• Früherkennung von Fehlern: Durch kontinuierliche Tests können Fehler frühzeitig im Entwicklungszyklus erkannt und behoben werden, was die Kosten der Fehlerbehebung reduziert.
• Verbesserte Softwarequalität: Eine höhere Testabdeckung durch automatisierte Tests trägt zur Stabilität und Zuverlässigkeit der Software bei.
• Kontinuierliche Integration: Durch die Integration in eine CI/CD-Pipeline wird sichergestellt, dass der Code ständig getestet und integriert ist, was die Zusammenarbeit im Team verbessert und die Freigabezyklen verkürzt.
• Wiederholbarkeit: Die Tests sind wiederholbar und konsistent, was die Zuverlässigkeit der Testresultate sicherstellt.

b)

Entwickle ein einfaches Selenium-Skript in Java, das die folgenden Aktionen ausführt:

• Öffnet eine Webanwendung Deiner Wahl.
• Füllt ein Textfeld mit einem vordefinierten Wert aus.
• Klickt auf einen Button, um ein Formular abzusenden.
• Prüft, ob eine bestimmte Seite nach dem Absenden geladen wird.

Lösung:

Selenium-Skript in Java:

Hier ist ein einfaches Selenium-Skript, das die beschriebenen Aktionen durchführt:

 import org.openqa.selenium.By; import org.openqa.selenium.WebDriver; import org.openqa.selenium.WebElement; import org.openqa.selenium.chrome.ChromeDriver; import org.junit.Assert; import org.junit.Test; import io.github.bonigarcia.wdm.WebDriverManager; public class SeleniumTest {     @Test     public void testFormSubmission() {         // Setup the ChromeDriver using WebDriverManager         WebDriverManager.chromedriver().setup();         WebDriver driver = new ChromeDriver();         try {             // Öffnet die Webanwendung             driver.get("http://example.com");             // Findet das Textfeld und füllt es mit einem vordefinierten Wert aus             WebElement textField = driver.findElement(By.id("textFieldId"));             textField.sendKeys("vordefinierter Wert");             // Findet und klickt auf den Submit-Button             WebElement submitButton = driver.findElement(By.id("submitButtonId"));             submitButton.click();             // Prüft, ob eine bestimmte Seite geladen wird             String expectedUrl = "http://example.com/confirmation";             Assert.assertEquals(expectedUrl, driver.getCurrentUrl());         } finally {             // Schließt den Browser             driver.quit();         }     } } 

Integration des Skripts in eine CI/CD-Pipeline:

Um dieses Selenium-Skript in eine CI/CD-Pipeline zu integrieren, befolge die folgenden Schritte:

• Setup der CI/CD-Umgebung: Nutze eine Plattform wie Jenkins, GitLab CI/CD oder Travis CI.
• Konfiguration der Build-Umgebung: Stelle sicher, dass der CI/CD-Server über die erforderlichen Bibliotheken und Treiber (z. B. ChromeDriver) verfügt.
• Testschritte hinzufügen: Füge Schritte hinzu, um die Tests auszuführen. Beispiel für eine GitLab CI/CD-Konfiguration:

stages:   - test test:   stage: test   image: maven:3.6.3-jdk-8   script:     - mvn test

• Erstelle ein .gitlab-ci.yml Datei im Root-Verzeichnis Deines Projekts. Diese Datei beschreibt die Schritte und Abhängigkeiten für Deine Pipeline.
• Ausführung der Tests: Bei jedem neuen Commit oder Merge-Request startet die Pipeline automatisch und führt die Tests aus. Die Ergebnisse werden im CI/CD-Dashboard angezeigt.
• Vorteile der Integration:
  • Automatisierungstestlauf: Selenium-Tests werden bei jedem Build ausgeführt.
  • Früherkennung von Fehlern: Probleme werden schnell identifiziert und behoben.
  • Verbesserte Qualität: Durch kontinuierliche Tests wird die Stabilität der Anwendung sichergestellt.
  • Wiederholbarkeit: Die Tests sind konsistent und reproduzierbar, was die Zuverlässigkeit erhöht.

c)

Vergleiche die Anwendungsmöglichkeiten von Selenium und JUnit. In welchen Szenarien wäre der Einsatz von Selenium gegenüber JUnit vorteilhaft und umgekehrt? Verwende konkrete Anwendungsfälle zur Unterstreichung Deiner Argumentation.

Lösung:

Vergleich der Anwendungsmöglichkeiten von Selenium und JUnit:

• Selenium: Selenium ist ein Tool zur Automatisierung von Webanwendungen. Es ermöglicht das Interagieren mit einer Webseite auf die gleiche Weise, wie ein Benutzer es tun würde, einschließlich Klicks, Eingaben und Navigation.
• JUnit: JUnit ist ein Unit-Testing-Framework für Java. Es wird verwendet, um einzelne Codeeinheiten bzw. Methoden zu testen und stellt sicher, dass die Methoden erwartungsgemäß funktionieren. JUnit wird hauptsächlich für Backend-Tests verwendet.

Anwendungsszenarien und Vorteile:

• Einsatz von Selenium:
  • Funktionale Tests von Webanwendungen: Selenium eignet sich hervorragend für funktionale Tests, bei denen die Benutzerinteraktionen mit der Webanwendung getestet werden. Beispielsweise kann Selenium verwendet werden, um zu überprüfen, ob ein Benutzer erfolgreich ein Formular auf einer Webseite abschicken kann.
  • End-to-End-Tests: Selenium ermöglicht es, End-to-End-Tests durchzuführen, die den gesamten Workflow einer Anwendung abdecken. Zum Beispiel kann Selenium getestet werden, ob der gesamte Kaufprozess in einem Online-Shop - vom Hinzufügen eines Artikels in den Warenkorb bis zur Zahlung - korrekt funktioniert.
  • Cross-Browser-Tests: Mit Selenium können Tests in verschiedenen Browsern (z.B. Chrome, Firefox, Internet Explorer) und auf verschiedenen Plattformen durchgeführt werden, um die Kompatibilität sicherzustellen.
• Einsatz von JUnit:
  • Unit-Tests: JUnit wird hauptsächlich verwendet, um einzelne Methoden oder Klassen im Backend zu testen. Zum Beispiel kann ein Entwickler mithilfe von JUnit sicherstellen, dass eine Methode zur Berechnung von Rabatten auf einen Einkauf korrekte Ergebnisse liefert.
  • Integrationstests: JUnit kann auch für Integrationstests verwendet werden, um sicherzustellen, dass verschiedene Komponenten des Systems korrekt zusammenarbeiten. Beispielsweise kann JUnit verwendet werden, um zu prüfen, ob eine Datenbankabfrage von einer Service-Klasse korrekt verarbeitet wird.
  • Testgetriebene Entwicklung (TDD): Im Rahmen der testgetriebenen Entwicklung schreiben Entwickler zuerst Tests und implementieren dann den Code, der diese Tests besteht. JUnit ist ein gängiges Werkzeug für diesen Ansatz.

Konkrete Anwendungsfälle:

• Webformular-Validierung:
  • Selenium: Ein Suchfeld und Submissionsbutton auf einer Webseite testen, indem man verschiedene Eingaben durchführt und sicherstellt, dass die erwarteten Suchergebnisse angezeigt werden.
  • JUnit: Methoden zur Validierung von Eingabedaten auf Fehler testen. Beispielsweise überprüfen, ob eine Methode zur Überprüfung von E-Mail-Formaten korrekt arbeitet.
• REST-API-Überprüfung:
  • Selenium: Nicht geeignet.
  • JUnit: REST-API-Services testen, indem HTTP-Requests an den Service gesendet und die Antworten überprüft werden.
• Benutzerregistrierung:
  • Selenium: Einen Benutzerregistrierungsprozess auf einer Webseite automatisieren und sicherstellen, dass der Benutzer nach der Registrierung auf die richtige Bestätigungsseite weitergeleitet wird.
  • JUnit: Backend-Logik zur Erstellung eines neuen Benutzers in der Datenbank testen, einschließlich der Überprüfung der Eindeutigkeit von Benutzernamen und E-Mail-Adressen.

Fazit: Beide Tools haben ihre spezifischen Einsatzgebiete und ergänzen sich gut. Selenium ist ideal für Tests, die Benutzerinteraktionen simulieren und die Oberfläche einer Webanwendung testen, während JUnit für Unit-Tests und Integrationstests im Backend verwendet wird. Die Wahl des richtigen Werkzeugs hängt von den spezifischen Anforderungen und dem Kontext des Tests ab.

Aufgabe 4)

Versionierungssysteme wie Git und SVN sind unerlässlich für die Softwareentwicklung, da sie die Verwaltung und Nachverfolgung von Änderungen an Projektdaten ermöglichen. Während Git ein dezentralisiertes Versionierungssystem ist und die gleichzeitige Arbeit mehrerer Entwickler mit Fokus auf Branching und Merging unterstützt, ist SVN ein zentralisiertes System, das einfacher zu verwenden ist und sich für kleinere Teams oder Projekte eignet.

Ein wichtiger Aspekt beider Systeme ist der Umgang mit Branches, Commits und Merging, sowie das Verständnis der jeweiligen Workflows (zentralisiert bei SVN und dezentralisiert bei Git).

a)

Teilaufgabe 1: Angenommen, Du arbeitest in einem Team, das ein Projekt mit Git als Versionierungssystem verwaltet. Erkläre den Ablauf und die relevanten Git-Befehle, um eine vollständige Feature-Entwicklung bis zu deren Integration in den Hauptbranch (master) umzusetzen. Dein Erklärung sollte Folgendes umfassen:

• Erstellung und Wechsel in einen neuen Branch für das Feature
• Durchführung von Änderungen und Speicherung mit Commits
• Synchronisation mit dem Remote-Repository
• Zusammenführung der Änderungen in den Hauptbranch unter Berücksichtigung möglicher Konflikte

Lösung:

Teilaufgabe 1: Angenommen, Du arbeitest in einem Team, das ein Projekt mit Git als Versionierungssystem verwaltet. Hier ist eine Schritt-für-Schritt-Anleitung mit den relevanten Git-Befehlen, um eine vollständige Feature-Entwicklung bis zu deren Integration in den Hauptbranch (master) umzusetzen:

• Erstellung und Wechsel in einen neuen Branch für das FeatureUm einen neuen Branch für das Feature zu erstellen und direkt zu diesem zu wechseln, kannst Du folgende Befehle verwenden:

  git checkout -b feature-branch-name

  Mit diesem Befehl wird ein neuer Branch namens feature-branch-name erstellt und Du wechselst direkt zu diesem Branch.
• Durchführung von Änderungen und Speicherung mit CommitsNachdem Du deine Änderungen an den Dateien vorgenommen hast, speicherst Du diese mit Commits. Die relevanten Befehle sind:

  git add dateiname

  Dieser Befehl fügt die geänderte Datei zum Staging hinzu. Um alle geänderten Dateien hinzuzufügen, kannst Du . (Punkt) verwenden:

  git add .

  Danach speicherst Du die Änderungen mit einem Commit:

  git commit -m 'Beschreibung der Änderungen'

  Ersetze 'Beschreibung der Änderungen' durch eine sinnvolle Beschreibung dessen, was Du geändert hast.
• Synchronisation mit dem Remote-RepositoryUm sicherzustellen, dass Deine Änderungen auch im Remote-Repository verfügbar sind, pushe Deinen aktuellen Branch:

  git push origin feature-branch-name

• Zusammenführung der Änderungen in den Hauptbranch unter Berücksichtigung möglicher KonflikteWechsel zunächst zurück in den Hauptbranch (master):

  git checkout master

  Ziehe die neuesten Änderungen vom Remote-Repository in den Hauptbranch:

  git pull origin master

  Führe die Änderungen deines Feature-Branches in den Hauptbranch zusammen:

  git merge feature-branch-name

  Falls es Konflikte gibt, zeigt Git diese an. In diesem Fall musst Du die betroffenen Dateien manuell bearbeiten, um die Konflikte aufzulösen. Dies kann durch das Öffnen der Dateien und die Entscheidung für die richtige Version oder das manuelle Zusammenführen der Code-Änderungen geschehen. Nachdem alle Konflikte gelöst sind, markiere sie als gelöst und führe erneut einen Commit aus:

  git add git commit

  Schließlich pushe den aktualisierten Hauptbranch ins Remote-Repository:

  git push origin master

Mit diesen Schritten hast Du eine vollständige Feature-Entwicklung bis zur Integration in den Hauptbranch abgeschlossen und die relevanten Befehle für die Nutzung von Git kennengelernt.

b)

Teilaufgabe 2: Eine Firma verwendet SVN als Versionierungssystem und hat das Projekt in verschiedenen Branches organisiert. Erläutere die Schritte und Befehle, mit denen eine Entwicklerin einen kritischen Bugfix aus dem develop-Branch in den release-Branch mergen würde, einschließlich der Vorgehensweise bei der Behandlung potentieller Konflikte, die dabei auftreten könnten.

Lösung:

Teilaufgabe 2: Eine Firma verwendet SVN als Versionierungssystem und hat das Projekt in verschiedenen Branches organisiert. Hier sind die Schritte und Befehle, die eine Entwicklerin befolgen würde, um einen kritischen Bugfix aus dem develop-Branch in den release-Branch zu mergen, einschließlich der Behandlung potentieller Konflikte:

• Wechsel zum Release-BranchZuerst wechselt die Entwicklerin zum release-Branch, um die weiteren Schritte auszuführen:

  svn switch ^/branches/release

• Aktualisieren des Release-BranchEs ist wichtig sicherzustellen, dass der Arbeitskopie (Working Copy) des release-Branches aktuell ist:

  svn update

• Mergen des Bugfix aus dem Develop-Branch in den Release-BranchNun wird der Bugfix vom develop-Branch in den release-Branch gemergt. Hierfür wird der svn merge-Befehl verwendet:

  svn merge ^/branches/develop

  Dieser Befehl wendet die Änderungen aus dem develop-Branch auf den aktuellen, in der Arbeitskopie befindlichen release-Branch an.
• Behandlung potentieller KonflikteFalls Konflikte auftreten, gibt SVN eine entsprechende Meldung aus. Die Entwicklerin muss dann die entsprechenden Dateien öffnen und die Konflikte manuell lösen. Nach der Behebung der Konflikte markiert sie diese als gelöst:

  svn resolve --accept working dateiname

  Tausche dateiname gegen den tatsächlichen Dateinamen aus, bei dem der Konflikt aufgetreten ist. Dieser Befehl zeigt SVN, dass der Konflikt in dieser Datei behoben wurde.
• Commit der gemergten ÄnderungenNachdem alle Konflikte behoben und als gelöst markiert wurden, führt die Entwicklerin einen Commit durch, um die Änderungen im release-Branch zu speichern:

  svn commit -m 'Merged bugfix from develop branch into release branch'

  Hierbei kann die Commit-Nachricht natürlich angepasst werden, um eine präzisere Beschreibung des Bugfixes zu geben.

Mit diesen Schritten und Befehlen kann die Entwicklerin einen kritischen Bugfix erfolgreich vom develop-Branch in den release-Branch mergen und dabei auftretende Konflikte behandeln.