QA-Process

[sight011]

Hi

It has been a while!

Ich wollte mal in dem Forum meines vertrauens fragen, ob sich hier jemand tiefergehend mit QA-Prozessen auseinandersetzt.

Und zwar meine Idee das QA-Team nach jedem Sprint ein kurzes Reporting auf der Confluence-Seite eintragen zu lassen. Erstmal nur ganz rudimentär:



Hat irgendwer noch Vorschläge was für Informationen man noch "abfragen" könnte?

Beste Grüße euer
sight

 

[Matze]

Ganz simpel: "Wie ging es dem Team wärend des Sprints?". Gab es Stress? Wenn ja, warum?
So kommt man Dingen auf den Grund wie:
- Falsche Planung
- Unzufriedenheiten individueller Personen bis hin zu "möchte jemand kündigen?"
- Streiterreien innerhalb eines Teams
- Drohende BurnOuts

Auch interessant ist ein Blick auf die angefallenen Überstunden wärend eines Sprints:
- Müssen wir mehr oder weniger in einen Sprint stopfen?
- Reichen die Kapazitäten bei dem Ausfall von x-Mitarbeitern noch aus (wie viel Puffer müssen wir planen)
- Muss das Team vergrößert werden


Sind zwar alles keine harten Zahlen, aber dennoch ebenso wichtige.

 

[sight011]

Hey Matze, Danke erst einmal für deine Antwort!

Wovon du sprichst das sehe ich mehr als das “Retrospective Meeting” (Oder als Teil der “Sprint Review”).

Vielleicht macht es Sinn, noch einmal ein paar mehr Infos zu geben. Folgende Intention hatte ich bei dem benennen des Tabellen Headers:

Sprint // Sprint Nummer

Release Date // Wann wurde released (um eine Übersicht zu haben, würde immer in Time released über das Jahr)

Priority A Topics Tested // Wir haben Smoke Tests für alle möglichen Feature entwickelt. Wir schaffen es nicht komplett alle Tests in jedem Sprint zu erledigen, deshalb haben wir diese in Priority A, B und C Feature unterteilt. Mit dieser Übersicht soll auch Aufschluss darüber gegeben werden, wie viel Tests schaffen wir. Benötigen wir vielleicht eine weitere Ressource zum testen weil wir nur einen geringen Teil der Plattform schaffen zu testen? Müssen vielleicht die Tests “verkleinert” werden? Benötigen wir automatisierte Tests?

Priority B Topics Tested // das selbe für die weniger relevanten Test-Scenarios. (Priority A Smoke Tests = Happy Path / Priority B = Wichtige Kernfeature / Priority C = Filter, Archive, etc.)

Time Spend A / B // diese Angabe soll dabei helfen, die Planbarkeit dieser Tests einfacher zu gestalten. Wenn wir wissen wie lang wir brauchen, wissen wir wie viel Zeit vor dem Release müssen wir damit starten.

Amount of Bugs – Quantitative Zahl wie viele Bugs gab es pro Sprint (in dem Zusammenhang sollte vermutlich noch ein Feld hinzukommen mit Clickbaren Links zu den Tickets damit man auch protokolliert hat “Welche Bugs?”.

Percentage of the platform covered / Wie viele Smoke Tests haben wir geschafft? Nehmen wir an es gibt 12 wir haben 6 geschafft dann haben wir 50% der Plattform getestet. Vermutlich würde es Sinn machen einen weiteren QAer anzustellen.

Notes / Anmerkungen

Das QA-Reporting soll einzig und allein dazu dienen, eine Übersicht über das Testing zu bekommen. Und dies nicht nur in der Form von “war gut”, “war nicht gut” —> sondern quantitative Messbar (wenn möglich).

Freue mich auf mehr Feedback falls noch jemand etwas beizutragen hat.

Beste Grüße
simsalla-sight