In kurzen Worten würde ich sagen, nicht überfordernd oder unterfordernd und sehr informativ. In der ersten Vorstellungsrunde haben sich alle erst mal kurz vorgestellt. Dabei war es schön zu sehen, dass unser Team ein bunter Mix aus Personen mit unterschiedlichen Hintergründen ist. Es gibt Teilnehmer mit und ohne IT Know-How. Francesco und Jakob haben dann beim ersten Zusammentreffen des neuen Teams, das Lernkonzept hinter der Qcademy vorgestellt.
Mein erster Workshop in der Qcademy
Dann folgte schon der erste Workshop zum Thema: „Agile Basics“. Francesco hat uns in diesem Workshop das SCRUM-Modell vorgestellt. Moderne Software wird heutzutage in der Regel nach SCRUM entwickelt. Im Gegensatz zu traditionellen Softwareentwicklungsverfahren wie z.B. dem Wasserfallmodell, wird bei SCRUM viel Wert auf die Teamarbeit gelegt. Software soll iterativ und inkrementell wachsen. Doch wie funktioniert das genau?
Werde jetzt in 6-12 Monaten Software-Tester!
Die Rollen eines Scrum Teams
Beim SCRUM Modell gibt es zunächst einmal das sogenannte SCRUM Team. Das Team besteht aus dem Dev-Team. Im Dev-Team befinden sich die Software-Entwickler:innen, die Software-Tester:innen und unter Umständen auch ein Business Analyst oder UX-Designer. Das Dev-Team ist dafür verantwortlich, die geplanten Aufgaben umzusetzen z.B. neue Features für eine Webseite. Dann gibt es den SCRUM-Master. Er oder sie ist sozusagen ein Mittelsmann/frau.
Der Scrum-Master sorgt dafür, dass die Scrum-Prozesse eingehalten werden und sollte es Hindernisse geben, ist er/sie dafür zuständig, dabei zu unterstützen diese aus dem Weg zu räumen. Sollte es mal Streitigkeiten im Team geben, sollte ein guter Scrum-Master auch in der Lage sein, die Wogen zu glätten. Neben dem Dev-Team und dem Scrum-Master gibt es noch den Product Owner.
Der Product Owner ist der Stellvertreter für die Interessen des Kunden. Falls das Dev-Team fachliche Fragen zu den einzelnen Aufgaben hat, so sollte der Product Owner in der Lage sein, diese zu beantworten oder die Information zu beschaffen.
Im Scrum Modell gibt es noch sogenannte Artefakte. Dazu zählen:
- Das Product Backlog
- Das Sprint Backlog
- Das Inkrement
Im Product Backlog befinden sich die priorisierten Aufgaben. Der Product Owner ist für das Product Backlog zuständig. Er/sie definiert die Aufgaben und priorisiert diese. Das Sprint Backlog ist sozusagen die kleine Schwester vom Product Backlog.
Die 5 Scrum-Zeremonien
Es gibt zunächst das „Sprint Planning“. In diesem werden die Ziele für den kommenden Sprint festgelegt. Die Aufgaben vom Product Backlog werden in das Sprint Backlog gezogen. Sollte es Fragen zu den einzelnen Aufgaben geben, so werden diese diskutiert und offene Fragen geklärt.
Dann folgt der eigentliche „Sprint“. Dies ist ein klar festgelegter Zeitraum. Ein Sprint kann 1-4 Wochen lang sein. In der Praxis haben sich 2-Wochen Sprints als gute Größe etabliert. In diesen Zeitraum werden dann die geplanten Aufgaben vom Dev-Team implementiert und getestet. Das Dev-Team versucht dabei, alle geplanten Features umzusetzen.
Während der „Sprint“-Phase gibt es jeden Tag sogenannte „Dailys“. Das Scrum Team tauscht sich jeden Tag aus und jeder berichtet was er/sie gestern getan haben, was heute ansteht und ob es irgendwelche Hindernisse bei der Arbeit gibt.
Nach dem Sprint folgt dann das „Sprint Review“. Das Dev-Team stellt dem Product owner alle Features vor, die umgesetzt werden konnten. Nach der Demonstration entscheidet, dann der Product owner, welche Aufgaben wirklich fertig sind und welche doch noch weiterbearbeitet werden müssen.
Danach folgt die „Sprint Retrospective“. In diesem Workshop wird der letzte Sprint besprochen und zusammen mit dem Scrum-Master wird besprochen, was im letzten Sprint nicht so gut lief und wo Verbesserungsmöglichkeiten bestehen.
Ist die „Sprint Retrospective“ abgeschlossen, dann folgt die Planung für den nächsten Sprint und der Kreislauf startet wieder von vorne. So wird stetig gewährleistet, dass das Produkt z.B. die Webseite stetig wächst und zeitgleich gibt es schon sehr früh Feedback über neue Funktionen.
Workshop: Basic Frontend & Backend
In unserem 1. Lernsprint bei der Qcademy gab es dann noch einen zweiten Workshop. Dieser wurde von Jakob präsentiert. Thema dieses Workshops waren die Grundlagen der Webentwicklung in Hinblick auf Frontend und Backend. Zunächst mussten wir in Gruppenarbeit ausarbeiten, was ein Frontend und was ein Backend ist.
Als Frontend versteht man den Teil der Webapplikation, der für die Interaktion mit dem User gedacht ist z.B. die Homepage von trivago. Das Backend ist der nicht für den User sichtbare Teil der Webapplikation. Es ist für die Verarbeitung der Daten zuständig. Das Backend besteht auf Webservices und Datenbanken, doch dazu später mehr.
Aufbau des Frontends
Dann haben wir besprochen, wie ein Frontend grundlegend aufgebaut ist. Es hat 3 Bestandteile. Mit HTML wird der Inhalt und die Struktur des Frontends definiert, z.B. Absätze, Überschriften. Mit CSS wird das Design der Webseite definiert z.B. bestimme Farben für Buttons. Mit Javascript wird die Webseite dann zum Leben erweckt. Javascript ist eine Programmiersprache und erlaubt es uns z.B. Alerts oder Inputfelder in Webseiten einzubauen.
Das Backend
Ein User kann z.B. auf der Seite Trivago interagieren und eine Suchanfrage stellen. Das Frontend sendet dann eine Anfrage (Request) an das Backend (genauer gesagt an einen Webservice). Einen Webservice kann man sich quasi als Gehirn vorstellen. Ein Webservice kann mit anderen Webservices und mit verknüpften Datenbanken kommunizieren. Nach dem die Anfrage vom Frontend bearbeitet wurde, sendet der Webservice eine Antwort (Response) zurück ans Frontend. Es gibt dabei verschiedene Status Codes für die Responses z.B. 200 oder 404. Wobei 200 bedeutet alles OK und 404 wäre ein Fehler. In der Regel folgt die Kommunikation zwischen Frontend und Webservice im json-Format. Es gibt auch sogenannte http Verben. Diese lassen den Service wissen, ob Daten erstellt (POST), gelesen (GET), upgedatet (PUT) oder gelöscht (DELETE) werden sollen.
Dieses grobe Verständnis über den Aufbau von Webapplikationen hilft uns Testern, Risiken besser zu identifizieren, Bugs zu finden oder geeignete automatisierte Testfälle für das Frontend oder das Backend zu erstellen
Weitere Sprint-Aufgaben
Neben den Workshops hatten wir noch eigenständige Aufgaben für unseren ersten Lernsprint zu erledigen. Alle Aufgaben mussten wir im Vorfeld schätzen und in unser eigenes Lernsprint-Backlog ziehen.
Eine Aufgabe war es z.B. sich bei verschiedenen Crowd-Testing Anbietern anzumelden und Tests auf den jeweiligen Plattformen durchzuführen. Das hat sehr Spaß gemacht und bei einigen Crowd-Testing Anbietern gab es wirklich eine Menge gutes Lernmaterial rund um das Thema Software-Testing.
Eine weitere Aufgabe war eine erste explorative Testsession auf einer speziellen Testseite. Hier sollten wir 40–60 Minuten explorativ Testen und unseren Teamkollegen zeigen, wie wir bei unseren Tests vorgegangen sind.
In einem anderen Ticket war die Aufgabe verschiedene Blogs, Webseiten oder Video Channels zum Thema Software-Testing im Web rauszusuchen in diese dem Team zu präsentieren. Es sollte dabei darauf geachtet werden, dass die jeweiligen Quellen aktuelle Informationen enthielten. Da ich schon einige Jahre als manueller Software Tester unterwegs war, habe ich dem Team, die Quellen vorgestellt, die mir am Anfang meiner Karriere viel geholfen hatten.
Mein Fazit zum ersten Sprint
Der erste Lernsprint war sehr intensiv und dennoch super informativ. Gerade wenn man noch nicht mit der agilen Arbeitsmethodik nach SCRUM vertraut ist, versteht man nach dem 1. Sprint genau was SCRUM bedeutet. In unserer ersten Review Sitzung sind wir noch mal die Inhalte der Workshops in Gruppenarbeit durchgegangen. So konnte unser Wissen nochmals gefestigt werden.
Zum Abschluss des 1. Sprints haben wir noch eine Retrospective durchgeführt. Hier konnte jeder noch mal Feedback zum 1. Sprint geben und feststellen, was er/sie für den nächsten Sprint verbessern möchte.
Es ist natürlich für alle Beteiligten eine Herausforderung neben dem Hauptberuf noch die Qcademy Tasks zu absolvieren, doch die zusätzliche Arbeit lohnt sich sehr und man lernt sehr praxisnah stetig dazu. Wie mein zweiter Sprint verlaufen ist, kannst Du im folgenden Artikel lesen: Mein zweiter Sprint im Lernkonzept der Qcademy
Meine Geschichte und warum ich am Programm der Qcademy teilnehme, erfährst Du in meinem Artikel: Vom manuellen Softwaretester zum Testautomatisierer
Welche Meilensteine und Herausforderungen ich beim Programmieren lerne hatte, erfährst Du in meinem Artikel: Meine ersten Schritte in der Programmierung
