Qualitätssicherung bei der Softwareentwicklung mit Christian Kranert – IT-Berufe-Podcast #164

Über verschiedene Möglichkeiten der Qualitätssicherung bei der
Softwareentwicklung spreche ich mit Christian Kranert in der
einhundertvierundsechzigsten Episode des IT-Berufe-Podcasts.
Inhalt Allgemeines zur Person

Wie ist dein Name und wo arbeitest du (falls gewünscht)?

Christian Kranert, 31 Jahre alt, Nürnberg, ich arbeite
bei der Head-on Solutions GmbH.

Wir entwickeln eine Software zum Cloud Management für
Frisöre, Kosmetikstudios usw. für eine moderne Organisation:
Terminbuchung, Kasse, Marketing.

Wir sind eine rein interne Entwicklungsabteilung.



An welchen Projekten arbeitest du zur Zeit in deinem
Tagesjob?

Die Software, die ich mit meinem Team der Head-on
Solutions GmbH entwickle: studiolution.



Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?

Ich war schon immer fasziniert von Computern und hatte
mit 12 Jahren meinen ersten eigenen PC

Darauf habe ich schnell ein erstes Programm erstellt mit
Visual Basic 6.

Ich habe mir nie erträumt, ohne Studium programmieren zu
können.

Zum Einstieg habe ich „Hello World“ programmiert und
danach einen Paint-Klon.



Welche Ausbildung bzw. welches Studium hast du im Bereich der
Informatik absolviert?

Nach der Schule (die war nervig, weil ich schon wusste
was ich will) habe ich die Ausbildung zum Fachinformatiker
Anwendungsentwicklung gemacht.

Ich bin in der Automobilindustrie gestartet und habe bei
der Brose Group eine sehr gute Ausbildung bekommen. Die
hatten 200 Leute in der IT und ich konnte viele Abteilungen
durchlaufen. Dort habe ich viel gesehen und gelernt.

Ich bin gestartet mit der SAP-Entwicklung, aber parallel
habe ich mit .NET begonnen.



Mit welcher/n Programmiersprache/n arbeitest du im Alltag?

Im Backend setzen wir auf C# in Kombination mit dem SQL
Server.

Im Frontend setzen wir JavaScript ein, aber in Form von
TypeScript. Für HTML/CSS nutzen wir SASS als Präprozessor.

TypeScript mag ich wegen der Typisierung.



Was ist deine Lieblingsprogrammiersprache und warum?

ABAP habe ich in SAP zwar auch gemacht, aber C# ist meine
Lieblingssprache. Ich mag die Typisierung und viele Features,
die konsistent umgesetzt sind.

Java habe ich mir angeschaut für die SAP-Entwicklung.

Ich bin kein Freund der „religiösen“ Gefolgschaft von
Programmiersprachen.



Qualitätssicherung bei der Softwareentwicklung

Warum sollten wir uns überhaupt Gedanken zur
Qualitätssicherung machen?

Das ist eine gute Frage, die man oft im Alltag
beantworten muss, z.B. bei Diskussionen mit Kunden oder dem
Chef.

Vergleich mit der Industrie: Teile müssen „perfekt“ sein,
der Kunde soll am Ende glücklich sein.

Bei Software ist es genauso: das Release soll den Kunden
zufrieden stellen.

Ansonsten muss man nachbessern und hat unzufriedene
Kunden.

Die Behebung von Fehlern ist sehr teuer im Nachhinein.

Außerdem ist Kosteneffizienz und Mitarbeiterzufriedenheit
wichtig für das Unternehmen.



Welche Maßnahmen gibt es grundsätzlich zur
Qualitätssicherung?

Wir setzen auf eine Art Stufensystem. Je früher Fehler
behoben werden, desto billiger ist es.

Das beginnt beim Entwickler: wir haben eine
Entwicklerselbstkontrolle, Stichpunkte, die die
Entwickler:innen selbst durchgehen, z.B. Diff checken vor dem
Commit. Das machen wir extra in einem externen Programm,
damit eine andere Schriftart für eine andere Denkweise sorgt
und Flüchtigkeitsfehler, vergessener Debugcode etc. vermieden
werden.

Danach kommen die Unit-Tests, die die Entwickler:innen
selbst schreiben.

Dann folgt ein Code Review durch eine andere Person.

Und zuletzt kommt noch ein manueller Test.



Welche technischen Maßnahmen zur Qualitätssicherung gibt es
auf Ebene einzelner Commits?

Die genannte Entwicklerselbstkontrolle.

Regelmäßige Routinen aus Checklisten sind auch in der
Industrie gängig, dort haben wir das abgeschaut.

Das nimmt Komplexität aus dem Prozess und führt zu
weniger „Mental Load“.

Wir haben auch weitere Checklisten, z.B. für Releases
etc.



Wo sind die Checklisten abgelegt?

Wir haben den DevBuddy, unsere interne
Entwicklungsplattform für die Ablage. Dort haben wir auch mit
HTML/JavaScript einen „Fortschrittsbalken“ gebaut, um ein
wenig Gamifaction einzubauen.



Wann und wofür verwendest du welche Tests: Unit-Tests,
Snapshot-Tests, manuelle Tests?

Wir setzen kein TDD ein, die Mehrheit im Team glaubt
nicht daran.

Aber unser Code muss immer mit Tests abgedeckt werden,
auch wenn die Tests erst nach dem Code geschrieben werden.



Warum setzt ihr nicht TDD ein?

Wir entwickeln agil und auch bei der Konzepterstellung
wirkt das Team mit.

In diesem Prozess wird gerade zu Beginn viel am Code
angepasst, daher hemmt TDD uns eher, z.B. bei Prototypen, bei
denen der Test erstmal nicht implementiert wird.

TDD ist aktuell einfach nicht zuträglich, aber wir haben
es auch nur einmal ausprobiert.



Achtet ihr auf die Code Coverage?

Sie wird noch nicht automatisch ermittelt, geht aber mit
Visual Studio ganz gut.

Bei der Line-/Branch-Coverage peilen wir 95% an. Durch
wenig Boilerplate-Code schaffen wir das auch.



Wie (gut) lassen sich Code Reviews in den Entwicklungsprozess
integrieren?

Bei uns wird jede Zeile geprüft, alles braucht ein
4-Augen-Prinzip.

Direkt nach Implementierung folgt das Review, niemand
darf länger als einen Tag entwickeln ohne Review.

Bei anderen Unternehmen wird oft nur über die Findings
gesprochen und dann aber nichts gemacht. Wir erzwingen aber
die Änderungen aus dem Review.



Macht ihr das auch mit Checklisten?

Ja, aber sie dienen nur zur Einarbeitung neuer
Kolleg:innen. Danach sind die Konventionen dann bekannt.

Alle Mitarbeiter machen ein Code Review, sogar
Praktikanten bei erfahrenen Entwicklern. Das fördert die
Teamkultur: viel und häufiges Feedback. Die Kritikfähigkeit
wächst dadurch stark.



Macht ihr Pull Requests? Oder wo/wie läuft das Review?

Das Review wird direkt auf dem Branch durchgeführt. Durch
eine Verknüpfung zwischen Work Items und Commits geht das
sehr gut.

Wir überlegen gerade, Pull Requests einzuführen, aber
wegen der kurzen Zyklen hätten wir dabei wohl zu viel zu
mergen.



Wie sieht das Ergebnis der Reviews aus?

Die Findings werden im persönlichen Gespräch geklärt.
Kleinigkeiten werden auch direkt von Reviewer gefixt,
abhängig von Skill des Gereviewten (z.B.
Flüchtigkeitsfehler).

Eine Diskussion über mögliche Alternativen geht
persönlich besser und die Begründung ist enorm wichtig, da
nur so ein Diskurs und eine bessere Lösung entsteht.



Dann ist aber viel Zeit für Gespräche nötig, oder?

Kurze Wege sind dafür unbedingt nötig! Das Review muss
beim Team akzeptiert sein und die Arbeitszeiten müssen
zusammen passen.



Dann kommen die manuellen Tests?

Unser Ziel ist die Automatisierung, aber komplett
wegkommen werden wir nicht von den manuellen Tests. Sie
decken Dinge auf wie Wording oder fachliche Fehler (z.B.
negative Umsatzsteuer).

Manuelle Testfälle werden bei uns schon von den
Entwicklern erstellt, da Tester den Code nicht kennen.

Jeder Entwickler ist verpflichtet, Tests zu formulieren,
weil sonst Tests „verloren gehen“.

Ursprünglich haben wir das mit Excel gemacht, jetzt haben
wir DevBuddy um ein Testtool erweitert mit Testrunner für ein
wenig Gamification.

Das fördert auch die Kommunikation mit dem Kunden.



Und dann sind wir schon beim Release?

Ja, danach kommt das Deployment, aber wir sind dann noch
nicht fertig! Stichwort: Exception Logging.



Wie behandelt/protokolliert ihr Laufzeitfehler?

Wir haben eine ganz einfache Methode: ein globaler
Exception-Handler schickt Stacktraces per Mail an ein
Postfach, das rotierend von Entwicklern beobachtet wird.

Das motiviert die Mitarbeiter, Fehler zu
vermeiden/beheben.

Vorteile des Postfachs: man kann die Mails einfach
weiterleiten und viele Infos transportieren.

Eigentlich war die Lösung nur ein Provisorium, aber
inzwischen bleiben wir gerne dabei.



Wie integrierst du Fehlersuche und Bugfixing in deine Arbeit?

Die Fehlerbehebung ist bei uns nur in bestimmten Phasen
möglich, viele Fehler sind nicht „dringend“.

Teilweise beschäftigen wir uns wochenlang nicht mit
Fehlern. Wir bündeln sie stattdessen und bearbeiten sie z.B.
in separaten Sprints.

Wir legen den Fokus entweder auf Fehler oder die
Entwicklung.

Fehler sind sehr teuer und müssen vermieden werden.



Wer dokumentiert die Software und wann ist der beste
Zeitpunkt dafür?

Viele Entwickler mögen Dokumentation nicht, aber sie ist
das wichtigste Instrument, um Komplexität im Griff zu halten.

Wir entwickeln eine komplexe Anwendung mit vielen Teilen
und Schnittstellen.

Daher ist Dokumentation enorm wichtig, weil man als
Entwickler viel vergisst in 2-3 Monaten nach der
Implementierung.

Das läuft bei uns auch im DevBuddy mit plain HTML, da
unsere FullSTack-Devs damit gut klarkommen. Das ist selbst
gestaltbar (Code-Highlighting, TOC etc.) und eine recht
angenehme Arbeit. Außerdem befolgen wir die Idee des „eat
your own dog food“.

Dokumentation muss schnell und kurzfristig erfolgen, da
man sonst wieder viel vergisst. Die Dokumentation sieht
anders aus, wenn sie erst rückblickend geschrieben wird.

Das zentrale Problem ist: Entwickler:innen werden dabei
rausgerissen aus der Entwicklung (Flow), wenn sie sich
zwischendruch und Dokumentation, Rechtschreibung usw. kümmern
müssen. Das ist ineffizient durch einen nötigen
Kontextwechsel im Gehirn.

Während des Codens werden daher nur Stichpunkte erfasst,
damit es schnell geht. Die werden dann später ausformuliert.



Welche Rolle spielen Best Practices und Pattern bei dir?

Im Rahmen des Produktkonzeptes wird das bei uns
mitgemacht.

Wir bekommen nur lose Vorgabe aus dem Fachbereich, um das
zu lösende Problem zu zeigen.

Die konkrete Lösung wird dann vom Team geschaffen und
dabei wird die Architektur festgelegt.

Wir verwenden zwei Arten von Mustern: Design Pattern und
Company Pattern, die wir selbst „gefunden“ haben für immer
wieder auftretende Probleme.

Das kürzt die Kommunikation ab, denn jedem im Team sind
die Pattern klar. Dadurch müssen nur nicht abgedeckte
Bereiche diskutiert werden, wobei schon Namen von Methoden
festgelegt werden usw.



Wie gelangst du zu Konventionen, die vom gesamten Team
mitgetragen werden?

Das Team legt die Pattern gemeinsam fest. Irgendjemandem
fällt etwas auf und es gibt dann einen Impuls ans Team. Meist
sind zwei verschiedene Lösungen für ein Problem der Anlass.

Beispiel: Es gibt viele Einstellungen in unserer
Software, z.B. Default-Einstellungen vom Hersteller und
Kunden-Einstellungen, die davon abweichen. Wie fragt man das
im Code ab? Dieses Problem wurde nur einmal gelöst (das war
gar nicht so einfach) und das Ergebnis ist unser
Settings-Pattern, das seitdem fast überall genutzt wird und
viel Erleichterung bringt.



Welche Tipps zum Umgang mit wachsender Komplexität hast du?

Alle obigen Maßnahmen zahlen darauf ein, Komplexität zu
vermeiden.

Komplexität ist eine große Gefahr bei großer Software.
Sie wird schnell zu groß, die Entwicklung dauert dann länger
und macht keinen Spaß mehr.

Unser Mantra ist: Keine unnötige Komplexität! Das gesamte
Team muss Komplexität richtig hassen, auch im Kleinen, da sie
schnell wachsen kann.

Beispiel: Schon ein ungünstiger Variablenname zählt dazu,
lässt sich aber leicht beheben.

Diese Idee muss man tief im Prozess und im Team
verankern.

Jede Erweiterung der Software führt zu mehr Komplexität.

Aussagekräftige Namen sind ein großer Hebel gegen
unnötige Komplexität, denn sonst kann es zu aufwändigen
Umbenennungen kommen.



Wie gehst du mit Legacy Code um, der (noch) nicht den
Qualitätsanforderungen entspricht?

Bevor wir die Software übernommen haben, wurde viel
extern entwickelt. Seit 5 Jahren entwickeln wir nun inhouse,
aber es ist noch viel Code von früher übrig, der nicht den
Pattern entspricht.

Daran wird nicht weiter entwickelt, sondern er wird in
die „neue Welt“ überführt, was eigentlich immer einen Rewrite
bedeutet.

Auch alte Anwendungen müssen sich weiterentwickeln, da
die Kunden neue Anforderungen haben.



Refactoring oder Rewrite: Worauf achtest du bei der
Entscheidung?

Rewrites machen wir eigentlich immer für nicht
selbstgeschriebenen Code. Für der Erfolg ist aber wichtig zu
wissen, wie man es grundsätzlich besser machen kann.

„Nur“ neu machen reicht nicht aus! Das ist kein Grund für
einen Rewrite.

Ein Mittelweg ist auch möglich: nur ein Teil des Codes
zieht um, wird refaktorisiert und Konventionen/Pattern werden
eingeführt.

Reine Refactoring-Releases werden bei uns vermieden. Es
muss immer der Mehrwert für den Benutzer erkennbar sein.

In den letzten 5 Jahren gab es max. drei Releases mit
reiner Technik.



Haben wir noch Themen vergessen, die wir unbedingt besprechen
sollten?

Das Team ist am wichtigsten! Nach 13 Jahren ist das eine
zentrale Erkenntnis. Nur gemeinsam kommt ein gutes Ergebnis
raus!



Aus- und Weiterbildung

Bildest du selbst Entwickler-Nachwuchs aus und wenn ja, wie
ist das Vorgehen?

Wir sind IHK-Ausbildungsbetrieb, haben aber erst einen
Azubi (FIAE) komplett ausgebildet.

Die dauerhafte Ausbildung ist aber in Arbeit, wir sind
noch in der Findungsphase.

Meine eigene sehr gute Ausbildung bei der Brose Group
(Fahrzeugteile) in Coburg ist jetzt auch mein eigener
Anspruch.

Wir haben eine Kooperation mit der Hochschule Nürnberg.
Jedes Semester haben wir Praktikant:innen für ein
Praxissemester, wovon beide Seiten profitieren!



Hast du Tipps für Ausbilder/-innen im IT-Bereich?

Viel Praxis! Kurze Theoriephase, dann früh ran ans echte
Produkt! Es sollen alle Prozesse mitgemacht werden, insb.
Code-Reviews usw.

Viele Erfolgserlebnisse gerade zu Beginn sind wichtig.

Feedback am Ende des Praktikums ist immer gut.



Welche Quellen kannst du für die Aus- und Weiterbildung im
Bereich Programmierung empfehlen und warum?

Das ist bei mir ein bunter Mix, für bestimmte Themen sind
aber Bücher gut geeignet.

Das Buch Clean Code* hat mir am meisten gebracht.

Ich bin auch großer Fan von Videokursen, wie z.B.
Pluralsight* und Rheinwerk*.

Wir haben Premium-Accounts bei Pluralsight für alle
Entwicker:innen. Das ist auch hilfreich für Praktikant:innen.

Wir haben z.B. den Bedarf aus einem konkretem Projekt an
VueJS direkt über einen Kurs auf der Plattform gelöst.

Am besten lernt man aber wohl „am lebenden Objekt“.

Auch die Effizienz durch die Kurse ist besser, als wenn
Kolleg:innen das alles selbst erklären.



Abschluss

Haben wir noch etwas vergessen?

Wir haben aktuell nur (männliche) Entwickler in unserem
Team, aber diverse Teams sind sehr wichtig!

Wir hätten gerne mehr Entwicklerinnen!
Also nichts wie los und bewerben!



Wo können die Hörer mehr über dich erfahren bzw. dich
kontaktieren?

Am besten bei LinkedIn.



Literaturempfehlungen

Ein sehr empfehlenswertes Buch laut Christian ist Clean Code von
Robert C. Martin*. Es ist sprachunabhängig und vermittelt viele
grundlegende Techniken, um Code qualitativer zu machen.


*


Bei Pluralsight* hat sein ganzes Team Accounts. Dort kann man
professionelle Videokurse zu zahlreichen Technikthemen (auf
Englisch) absolvieren.


Auch beim Rheinwerk-Verlag* gibt es hervorragende Literatur und
Videokurse (auf Deutsch).
Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Christian Kranert bei LinkedIn

studiolution

Brose Group bei LinkedIn