Über verschiedene Möglichkeiten der Qualitätssicherung bei der
Softwareentwicklung spreche ich mit Christian Kranert in der
einhundertvierundsechzigsten Episode des IT-Berufe-Podcasts. TL;DR
Ich gehe mit Christian Kranath einen mehrstufigen Prozess durch,
mit dem du als IT-Azubi Softwarequalität sichern kannst: vom
eigenen Codecheck über Unit-Tests und kurze Code-Reviews bis zu
manuellen Tests und Exception-Logging im laufenden Betrieb. Früh
entdeckte Fehler kosten weniger, während klare Namen und gemeinsam
entwickelte Patterns die Komplexität begrenzen. Zum Prozess gehören
außerdem zeitnah festgehaltene Dokumentation und begründetes
Feedback im Team, in das auch IT-Azubis früh eingebunden werden.
Kapitelmarken [00:00:00] Thema und Bezug zur Abschlussprüfung
[00:01:58] Christian Kranath und sein Arbeitsumfeld [00:02:46]
Technologie-Stack und TypeScript [00:04:38] Einstieg in die
Programmierung und Ausbildung [00:07:29] C# und die Wahl einer
Programmiersprache [00:09:13] Warum Softwarequalität gesichert wird
[00:11:41] Die Stufen des Qualitätsprozesses [00:13:29] Eigener
Codecheck vor dem Commit [00:15:05] Checklisten und DevBuddy
[00:17:29] Unit-Tests und 95 Prozent Testabdeckung [00:20:05]
Erfahrungen mit Test-Driven Development [00:22:02] Code-Reviews
nach spätestens einem Tag [00:24:09] Review-Checkliste und offene
Teamkultur [00:25:36] Reviews auf Branches und persönliche
Rückmeldungen [00:30:24] Manuelle Tests und Testfälle aus dem
Entwicklungsteam [00:33:27] Kommunikation in der
Softwareentwicklung [00:34:27] Release und Exception-Logging im
laufenden Betrieb [00:37:48] Bugfixes priorisieren und bündeln
[00:40:22] Dokumentation in DevBuddy und zeitnahe Stichpunkte
[00:45:40] Architektur und Company-Patterns [00:49:17] Gemeinsam
ein Settings-Pattern entwickeln [00:52:12] Komplexität begrenzen
und klare Namen wählen [00:56:52] Legacy-Code, Refactoring und
Rewrite [01:01:15] Mehrwert für Benutzer:innen bei Releases
[01:03:27] Ausbildung und Praxissemester im Unternehmen [01:05:42]
Früh am echten Produkt lernen [01:07:55] Bücher und Videokurse zum
Weiterlernen [01:10:04] Weiterbildung im Arbeitsalltag [01:11:45]
Diversität im Entwicklungsteam [01:13:16] Kontakt zu Christian und
weitere Ressourcen [01:14:15] Shownotes zur Episode 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? ...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.