Software Quality Days 2017 Wien Recap~ 8 min.

Software Quality Days 2017 - Katjasays.com

Die Software Quality Days 2017 fanden im schönen Wien statt. Nicht mal 2 Stunden und der Flieger von Hamburg ist in Wien gelandet. Dies war die erste richtige Konferenz aus dem Bereich Softwarequalität für mich – umso gespannter war ich daher darauf. Und was soll ich sagen? Ich wurde nicht enttäuscht. Die Talks waren größtenteils interessant und ich konnte an den Ständen erste Einblicke in gängige Tools erhaschen. Hier mal einige Talks zusammengefasst:

Keynote

(Jurgen Appelo)
Die Keynote wurde von Jurgen Appelo gehalten. Er hat es direkt geschafft, das Publikum zu fesseln und zu motivieren. Sein Leitsatz war es, dass man als Manager seine Mitarbeiter glücklich machen soll. Oftmals wüssten Manager nicht, wie man mit Menschen arbeitet und sie würden ihr Business wie eine Maschine führen. Allerdings sollte man es schaffen, dass die Mitarbeiter Spaß bei der Arbeit haben, denn erst dann bringen sie wirklich gute Arbeit und sind motivierter. Ein Ansatz dafür ist es, z.B., Leuten einen Grund zum Feiern zu geben, um die Verspieltheit zu vergrößern. So kann man eine Glocke im Büro aufstellen, die bei bestimmten erreichten Zielen oder erfolgreichen Projekten von den Mitarbeitern geläutet werden kann, um den Rest der Firma darauf hinzuweisen, dass etwas besonders gut gelaufen ist. Man sollte versuchen, eine mentale Annäherung zwischen einzelnen Teammitgliedern zu schaffen. Dafür könnte man diese dazu auffordern, persönliche Mindmaps über sich zu erstellen. Die anderen Teammitglieder sollen dann Fragen darüber stellen und so soll man sich besser kennenlernen. Was ebenfalls hilfreich sein kann, ist die Methode, ein Delegation Board zu haben, auf dem einzelne Bereiche den 7 Delegation-Levels hinzugeordnet werden oder die Teams mit dem Delegation Poker selber Bereiche zu Levels zuordnen zu lassen. Damit kann das Verständnis für einzelne Aufgaben verbessert werden. Andere Ansätze, um seine Mitarbeiter glücklicher zu machen, sind:

  • Kultur und Werte im Unternehmen verfolgen
  • Boni für besondere Erreichungen zu verteilen
  • Komplimente zu geben
  • das Gehalt zu zahlen, was der Mitarbeiter verdient
  • Bonuspunktesysteme einzuführen, mit denen sich Mitarbeiter gegenseitig belohnen können

Keynote Software Quality Days - Katjasays.com

Software engineering complexity and challenges of software engineering

(Tom Gilb)
Bei der Software-Entwicklung gibt es immer wieder Probleme, für die es nicht DIE EINE Lösung gibt. Manchmal muss man einfach in mehreren Dimensionen auf ein Mal denken und dabei versuchen, die Auswirkungen des Problems zu messen. Die Komplexität muss dann herunter gebrochen werden und Inkremente sollten gebildet werden. Projekte werden mit einem gewissen Wert und einer gewissen Qualität fertig gestellt. Einigen Leuten fällt es dabei schwer, diese beiden Bereiche sinnvoll zu messen. Daher gibt es oft Schwierigkeiten dabei, einen angemessenen Preis für bestimmte Leistungen zu berechnen. Man sollte daher versuchen, agile Verträge zu machen, bei denen die Ergebnisse und deren Wert bezahlt werden.

Software Engineering Complexity SWQD - Katjasays.com

Testing a moving target

(Peter Varhol und Gerie Owen)
Peter und Gerie haben über die Problematik gesprochen, Machine Learning Systeme zu testen. Diese sind nichtdeterministisch und geben nie das gleiche Ergebnis zurück. Daher müssen wir verstehen, wie solche Maschinen lernen. Um diese Maschinellen Lernsysteme zu testen, sollte man dies beachten:

  • man sollte objektive Akzeptanzkriterien haben
  • es sollte mit neuen Daten getestet werden
  • man sollte sich nicht darauf verlassen, dass alles akkurat ist
  • die Architektur des Netzwerks sollte verstanden werden
  • man sollte ein Konfidenzintervall für seine Ergebnisse kommunizieren

Solche Systeme werden im Transportwesen (selbst fahrende Autos, Flugzeuge), im Ecommerce (Empfehlungsalgorithmen) und im Finanzwesen (Aktienhandel) genutzt. Im Gegensatz dazu gibt es auch noch adaptive Systeme, die beim Pricing von Flügen (Änderungen basierend auf Nachfrage, Distanz, Datum, etc.) und in Ecommerce-Systemen Anwendung finden. Um sie zu testen sollte man beachten, dass:

  • Testszenarios gebraucht werden
  • keine mathematische Optimierung erfolgt
  • Defekte des Systems in der Nichterreichung von Zielen liegen

Was bedeutet es bei beiden Systemen korrekt zu sein? Beim maschinellen Lernen ist es der Fokus auf die Performance, Usability und ähnliche Dinge und sie müssen wie eine Black Box behandelt werden. Adaptive Systeme bringen Geld und sind Empfehlungen, die angenommen werden.
Testing a moving target SWQD - Katjasays.com

Mehr Vertrauen in Testergebnisse schaffen

(Martin Koch)
Da heutzutage durch Industrie 4.0, Big Data und dem Internet of Things die Komplexität steigt, ist die Verlässlichkeit umso wichtiger. Dadurch, dass die Releasezyklen immer kürzer werden, steigt der Testaufwand und ist manuell kaum noch möglich. Automatisierte Tests sind also notwendig. Ein Spannungsfeld ist dabei, dass es zu falschen Alarmen kommen kann, also dass Tests fehlschlagen, obwohl gar kein Fehler vorhanden ist. Unzuverlässige Tests können dann sogar schlimmer sein als gar keine Tests, da sie Frustration und Vertrauensverlust bringen. Entwickler schauen dann nicht mehr durch und echte Fehler rutschen durch. Um dies zu umgehen, könnte man z.B. einführen, dass es erst ein echter Fehler ist, wenn der Test auch noch nach 3 Durchgängen rot bleibt. Man sollte zuerst Timing-Probleme lösen, denn Automatisierungstools führen Benutzeraktionen schneller durch als echte Menschen. Ursachen für die so genannten flaky tests können asynchronous waits, concurrency oder test order dependency sein. Insgesamt gibt es 3 Kategorien von Tests. Tests, denen wir…

  • …noch nicht vertrauen
  • …vertrauen
  • …nicht mehr vertrauen

Mehr Vertrauen in Testergebnisse schaffen SWQD - Katjasays.com

Competition-driven quality boost

(Marc Kurz und David Stöger)
Was bedeutet Qualität? Es könnte so etwas sein wie:

  • gutes Design
  • keine Bugs
  • schnelle Applikation
  • kaum Kundenbeschwerden

Das Problem ist, dass man all diese Dinge nicht mit Metriken belegen kann, denn wo will man Grenzen setzen? Man könnte eher dazu gehen, den Trend der gewichteten offenen Issues mit der Gesamtanzahl der offenen Issues zu vergleichen und dafür Schwellenwerte zu definieren. Es sollte Eskalationsstufen geben und festgelegt werden, wer wann bei welchem Schwellwert informiert werden und was er machen soll. Auch die Codequalität sollte gemessen werden, was mit Hilfe von code duplication und cyclomatic complexity (Abzweigungen im Code wie if, while, for,…) gemacht werden kann. Doch wer soll das alles monitoren? Wie kann man seine Mitarbeiter dazu motivieren? Mit Reward-Systemen? Indem man Challenges macht? Indem man einen Wettkampf einrichtet? Ein Ansatz wäre es, ein von allen Mitarbeitern einzusehendes Ranking der Qualität-Verbesserung einzuführen, denn jede Abteilung und jedes Projekt kann sich verbessern. Wenn man dadurch eine höhere Motivation und mehr Drive schafft, erreicht man auch eine bessere Qualität der Projekte und damit auch ein besseres Unternehmensergebnis.
Competition driven quality boost SWQD - Katjasays.com

From pair programming to mob architecting

(Carola Lilienthal)
Man kann Software-Entwicklung wie eine Expedition sehen, denn man weiß, wo man hin möchte, es ist manchmal allerdings unklar, wie man dort hinkommt. Man sollte in kleinen Schritten bauen und immer so, dass die einzelnen Schritte funktionieren (aus klein wird groß). Es gibt 2 Ansätze, um die Software Entwicklung so effizient wie möglich zu gestalten. Das Pair Programming und das Mob Architecting. Beim Pair Programming gibt es einen Piloten und einen Navigator. Auch wenn die Entwicklungszeit etwas länger sein kann, gibt es weniger Fehler, mehr Spaß beim Coden und weniger Code-Zeilen. Es gibt auch Unternehmen, die über Skype pairen. Das Mob Programming bringt das gesamte Team an einen Rechner, was besonders bei Problemen und kritischen Dingen hilfreich ist, da alle an einem Strang ziehen. So kann man die Architektur-Analyse (Refactoring, technische Schuld, etc.) gut im Team machen. Die Soll-Architektur sollte mit der Ist-Architektur verglichen werden. Gute Architektur ist:

  • erweiterbar
  • handlungssicher
  • schnell veränderbar
  • stabil
  • serviceorientiert
  • skalierbar
  • nach dem Baukastenprinzip aufgebaut
  • kommt mit Veränderungen klar
  • Fehler sind schnell zu finden

Die Zeit eines Entwicklers fällt zu 70% darauf, den Code zu verstehen, zu 20% löst er Probleme und zu 10% schreibt er Code. Daher sollte die Architektur so einfach wie möglich gestrickt sein. Sie sollte also chunkbar gemacht werden, Modularität sollte eine Rolle spielen (sinnvolle Klassennamen, ausgewogene Größenverhältnisse, etc.) und Schemata sollten gebildet werden (für Assoziationen, Wiedererkennbarkeit und schnelleres Arbeiten). Auch sollten Hierarchien gebildet werden.
From pair programming to mob architecting SWQD - Katjasays.com

Scaling agile – the disconnect between agile development and wider business needs

(Martin Kochloefl)
Beim agilen Scrum Prozess hat man ein Produkt-Backlog, ein Sprint-Backlog, den eigentlichen Sprint und danach ein potenziell nutzbares Produkt-Inkrement. Die Vorteile davon sind:

  • frühes Feedback
  • Anpassungen basierend auf Feedback möglich
  • iterative, time-boxed Auslieferung
  • Planung basierend auf User-Stories (Wert-Chunks)
  • DevTeams stehen zu dem Wert der erbrachten Arbeit
  • kontinuierliches Hinzufügen von Wert

Das agile Planen differenziert oft allerdings vom geschäftlichen Planen. D.h. eine Release-/Sprint-Planung steht gegenüber einer Planung in Quartalen oder Geschäftsjahren, Kosten-Nutzen-Analysen und Roadmaps. Das kontinuierliche Hinzufügen von Wert steht gegenüber einer langfristigen geschäftlichen Planung. Was könnte die Lösung sein?

  • ein integrierter end2end-Prozess
  • rationalisierte Tools und Repos
  • High-Level-Planung auf Geschäftsebene
  • Low-Level-Planung auf agile Teams ausgelagert
  • einfaches end2end Feedback
  • nahtlose end2end Rückverfolgbarkeit

Disconnect between agile development and wider business needs SWQD - Katjasays,com

Es gab noch weitere Talks auf die ich in diesem Beitrag allerdings nicht eingehen werde.
Für mich steht fest, dass ich wieder zu einer Software-Qualitäts-Konferenz möchte, um noch mehr über das agile Entwickeln und das Testen zu lernen. Ob es noch einmal die Software Quality Days werden, wird man sehen, ich kann mir auch vorstellen zu den Agile Testing Days oder dem QS-Tag zu gehen.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert