#QScamp Hamburg 2023: Ein kurzer Rückblick

Last Updated on 8. September 2023 by Hubert Mayer

Nachdem ich total motiviert von dem QScamp in Hamburg zurückgekommen bin, habe ich bei uns in der SDK eine Intranet-Community „User Group Test & Qualitätssicherung“ beantragt und nach Einrichtung derselben einen Blogpost vorbereitet. Denn zum einen mag ich natürlich meinem Arbeitgeber, der SDK etwas zurückgeben, nachdem mir das Ticket für das Barcamp, die Fahrtkosten und die Unterkunft gezahlt wurde.

Zum anderen mag ich gerne meine Erkenntnisse teilen, bei uns im Kulturentwicklungsprojekt wäre das der gelbe Aspekt: Wissen teilen, voneinander miteinander lernen. Und das betrifft sowohl den Inhalt des QScamps als auch meine Intention, mich mit den anderen Mitarbeitenden auszutauschen, die in Projekten oder in der Linie mit Testen, Testmanagement und Qualitätssicherung beschäftigt sind.

Hier also der leicht abgewandelte Artikel, der nach meinem jetzigen Urlaub dort in der Community erscheinen wird. Ja, eigentlich sollte er dort als Erstes erscheinen, doch wir wollen erst auf die Community aufmerksam machen und dann, wenn die Ersten drin sind, den Artikel veröffentlichen.

Wenn Du bislang nicht weißt, was ein Barcamp ist, hier habe ich schon lange eine Infoseite erstellt!

Das #QScamp ist ein themenspezifisches Barcamp rund um das Testen, Testmanagement und Qualitätsmanagement (in der Regel von Software).

2023 fand bereits das 7. QScamp statt, für mich war es nach 2021, als es digital stattfand, mein zweites. Aber gewiss nicht das Letzte.

Freitagabend – Keynote und Networking/Gegrille

Den Auftakt der Veranstaltung bildete am Freitagabend (01.09.2023) die Keynote von Shivani Gaba zu der Herausforderung, wie man eigentlich an das Testing von KI-Ergebnissen herangeht. Normalerweise folgt die Konzeption von Tests recht klaren Regeln: Basis ist die Frage, was will ich erreichen, was ist das gewünschte Ergebnis?!

Doch wie mache ich das, wenn ich möchte, dass meine Software basierend auf meinem bisherigen Leseverhalten neue wichtige Artikel aus einer riesengroßen Auswahl vorschlägt?

Dem Vortrag zu folgen fiel mir persönlich nicht ganz so leicht, da dieser auf Englisch stattfand und mir des Öfteren dann Fachbegriffe fehlten. Im Großen und Ganzen ging es aber und das war sehr interessant, wie man da herangehen kann.

Nach der Keynote wurde gegrillt und in entspannten Rahmen gab es so die Möglichkeit, viele der Teilgebenden bereits kennenzulernen. Und ganz eventuell sind aus diesen Gesprächen auch weitere Sessionideen entstanden für den Samstag.

Samstag – QScamp 2023

Nach dem optionalen Frühstücksangebot startete das QScamp mit einer kurzen Einführung und der Sessionplanung

und es kamen eine Menge spannender Sessions zusammen. Dieses Bild zeigt gar nicht das endgültige Angebot, es kamen spontan noch ein paar weitere Sessions hinzu, einige wurden zusammengelegt, einige umgehängt:

Meine Sessions (in Stichworten und Fragen festgehalten)

(Achtung: Das ist das, was ich verstanden habe, das muss nicht immer so gesagt worden sein…)

1. Wie werde ich Tester als No-Techie?

• Nicht mit der Frage nach Tools anfangen, stattdessen in aller Ruhe die Testziele erarbeiten
• Was ist mein Ziel?
• Wie komme ich dahin?
• Es handelt sich um Tester aus Fachbereichen? Dann lass sie gerne explorativ anfangen mit Testen, die wissen am besten, was sie erst mal herausfinden wollen und stolpern schnell über die offensichtlichen Fehler
• Non-Techies sind zudem sehr gut für Usability Tests geeignet
• Es lohnt oft, auch mal das Handbuch zu testen
• Wichtig ist es, den Testern von Beginn an klar zu machen, dass es ihr Job ist, Fehler zu finden. Fehler, über die der Endanwender am Ende nicht mehr stolpern muss. Tester nerven nicht mit Fehlern, sie tragen dazu bei, User glücklich zu machen (na ja, so ähnlich zumindest ;))
• Einige haben die Erfahrung gemacht, dass es besonders gut funktioniert, wenn Entwickler, Tester und ggf. weitere Personen wie der PO gemeinsam vor einem Bildschirm testen. Damit kann teilweise umfangreiche Fehlerdokumentation vermeiden werden, da Entwickler selbst sehen, was nicht funktioniert und Testende sich keinen abbrechen müssen beim Formulieren
• Tester: Problemfinder <-> Entwickler: Problemlöser
• Buchempfehlung: „Explore it“ von Elisabeth Hendrickson
• Testen sollte vor der ersten Zeile Code beginnen: Ideen challengen -> Aufmalen, fragen, wie würdest Du vorgehen (wollen) in einer Anwendung?

2. Wie man Qualität (nicht) misst!

• Zentrale Frage: Was soll eine Metrik wirklich abbilden (oft wird das Gegenteil abgebildet)
• „Wann auch immer man eine Metrik zum Ziel erhebt, hört sie auf, eine zu sein“
• Sonar Cube bewertet Code, nicht ob ein sinnvolles Ergebnis am Ende raus kommt (statische Codeanalyse), keine fachlichen Ansprüche, keine UX
• Fragestellung kann sein: Was interessiert das Management?
• Wie schnell bekomme ich Änderungen?
• Wird der Prozess schneller/langsamer?
• Wie oft bringen wir Fehler in Produktion?
• Rollen (können nur begrenzt beeinflussen):
  Entwickler: Code, UX
  Management: richtige Personen an richtiger Stelle im richtigen Umfeld
  Tester: Fehler finden
  PO: richtige Features auswählen
• Wenn Du drei Personen fragst, was Qualität für diese Personen ist, wirst Du drei Antworten bekommen, die nicht deckungsgleich sind
• Vorsicht vor Metriken, die Mitarbeitenden das Gefühl geben, überwacht zu werden. Sie werden alles dafür tun, diese zu manipulieren
• Taugt die Metrik „Anzahl Supporttickets“ etwas? Eher nein, zwar gut zum draus lernen, misst aber nur Unzufriedenheit (Bias!) und birgt das Risiko, etwas anzupassen, was einzelne wollen und damit aber das Produkt für andere unbrauchbar zu machen/sie unzufrieden werden lässt.
• Lieber Fragebogen mit offenen Fragen und Antwortmöglichkeit verwenden

3. Keyword Driven Testing

• Verwenden von Schlagwörtern und Sätzen. In jedem Keyword steckt eine Funktion
• Verkürzte Merkphrase von der Signal Iduna gegenüber der Lehre: SEV
• Setup: Wo seid ihr gerade?
• Execute: Diese Schritte musst Du machen
• Verifying: Was willst Du erreicht haben?
• Projektsprache: Einigung erforderlich, beispielsweise „Anwender macht…“
• Strikte Trennung von Testfall und Testdaten
• Testschritte werden gemeinsam von Entwickler und Testern entwickelt
• Tool: Sahi pro – Testframework für Testing mit mobilen Designs aus Anwendersicht, bietet wohl herausragend schnellen Service; Kostet ca. $980 Pro Person
• BDTA: Business Driven Test Automatisation
• Testautomatisierung ist vor allem dazu da, Regressionstest zum machen, findet alte Fehler
• Buchempfehlung für die Prinzipen: Keyword Driven Testing: Grundlage für effiziente Testspezifikation und Automatisierung (Matthias Daigl und Rene Rohner)

4. Firmenwissen in lokalen offenen LLMs

• Grundsätzlich 3 Methoden:
• Neutraining (sehr aufwändig)
• Generalisiertes Raw-Modell
• Finetuning mit 200-2000 internen Datensätzen
• Unternehmensdaten kommen in vektorisierte Datenbanken und es werden Token gebildet
• 20 % Überlagerung
• Finetuning findet auf Unternehemnssprache und -inhalte hin statt
• Aufsetzen von so etwas ist die Aufgabe von Data Scientists

5. Risk Storming für Nicht-Tester und Nicht-Techies (Ich habe ein deutsches Kartenset von oose erhalten!)

• Mindestens 3 Personen, Tester, PO und Entwickler
• Blaue Karten Qualitätskriterien (hier einigt sich das Team auf die 6 wichtigsten)
• Anschließend werden Risiken mit Zetteln formuliert, die dem Erreichen der Qualitätskriterien entgegenstehen
• Reduzierung von Risiken, nicht Eliminierung ist das Ziel
• Dann Nutzung der weiteren Karten, die Hilfe anbieten zu Heuristiken, Gefühlen, Techniken und Muster

6. Top 10 Tools für Tester, die in den meisten Projekten nützlich sind

• Bug Magnet (Ideen für Tests)
• Kali Linux (Security Werkzeug; 50 Tools zum Hacken)
• Load Runner
• Notepad ++
• Postman (Vorsicht, evtl. Datenspeicherung auf US-Server?)
• Dev Mate
• Sahi pro
• Squirrel SQL
• Greenmail (E-Mail Serverin Containern?)
• Success Suite (Testdaten)

Natürlich mussten wir auch am Samstag nicht hungern, es gab Nudeln, Spinat mit Kokosmilch (sehr spannende Mischung) und Pute!

Und hier noch ein paar Eindrücke aus Sessions, die ich nicht besucht habe, weil ich in parallel dazu stattfindenden Sessions war…:

Fazit zum #QScamp

Mich hat es unheimlich inspiriert, das Testen noch ernster zu nehmen und das Testen und die Qualitätssicherung in der SDK unter dem Aspekt der Nützlichkeit neu zu bewerten. Dazu kommt, dass es eine unglaublich aktive und hilfreiche Community ist.

Für mich ist klar, dass ich 2024 wieder dabei sein will. Und wer weiß, vielleicht bin ich dann ja nicht allein von der SDK dabei und wir nehmen noch mehr mit an Wissen?

Natürlich schließe ich den Beitrag nicht ohne einen Dank an die Sponsoren des QScamps 2023:

Und möchte dabei explizit oose meinen Dank aussprechen, die nicht nur die Räumlichkeiten bereitgestellt haben, sondern auch das QScamp maßgeblich organisiert haben und vor Ort aktiv Sessions gestaltet, gegrillt und sich um alles gekümmert haben!

Anzeigen:

Ich bin ja echt Fan von Amazon Prime. Meist keine Versandkosten, ordentliche Serien- und Filmauswahl (mein Netflixersatz) und Amazon Music als Ergänzung.

• Über
• Letzte Artikel

Folge mir:

Hubert Mayer

Blogger; Fachreferent Grundsatz (Lebensversicherung), Kommunikationsteam Kulturwandel bei SDK

Versicherungsmensch, Blogger, Netzwerker. Auf dem Papier: Jurist LL.B (Fernuni Hagen) und Versicherungsbetriebswirt (DVA) - tatsächlich quasi in Dauerweiterbildung. Ehrenamtlich in Stuttgart engagiert, Onlinejunkie. Reiseblogger auf dem Travellerblog.
Wer diesen Blog unterstützen möchte: Mein Amazon Wunschzettel ist lang

Folge mir:

Letzte Artikel von Hubert Mayer (Alle anzeigen)

• KW46-24 Vorsorgeuntersuchung, Bewegung, To-dos abarbeiten, Thermalbad, Wochenende - 17. November 2024
• KW45-24 Nacharbeiten, Bewegung, Abschied, VVB, Stuttgart, Wein mit Torsten - 10. November 2024
• KW44-24 Montagsstress, DHDL, Apple Watch, Beisetzung, langes Wochenende, iPad und Babyschabrackentapir - 3. November 2024