Ü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,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.