Qualitätssicherung - Gibt es eine fehlerfreie Softwareentwicklung?

Stel­len Sie sich mal vor, Sie legen beim Onli­neshop­ping einen Arti­kel in den Waren­korb. Wenn Sie dann zur Kasse gehen, ist der Arti­kel verschwun­den oder der Preis stimmt plötz­lich nicht mehr! Oder: Sie schauen sich auf ihrem Laptop im Fire­fox-Brow­ser eine Tabelle an. Auf ihrem Smart­phone in Safari sieht die Darstel­lung ganz anders aus und funk­tio­niert nicht rich­tig. Solche Fehler soll­ten nicht passie­ren, kommen in der Praxis aber doch vor.

Zum Glück gibt es Leute in der Soft­wa­re­ent­wick­lung, die sich von vorn­her­ein jede neu entwi­ckelte Funk­tion anse­hen und auf Herz und Nieren prüfen. Bei der HEC und neusta soft­ware deve­lop­ment sorgen die Soft­wa­re­tes­ter und -teste­rin­nen dafür, dass Anwen­dun­gen voll funk­ti­ons­fä­hig ausge­lie­fert werden.

Nicht jedes Projekt erfor­dert eine soge­nannte Quali­täts­si­che­rung (QS). Aber mit der Komple­xi­tät der Anwen­dun­gen steigt der Bedarf. Und das ist heute oft der Fall: Die moderne Soft­wa­re­ent­wick­lung ist ausge­spro­chen komplex – und die QS ein dement­spre­chend breit gefä­cher­tes Gebiet. Für Frank Heyden­reich, Soft­wa­re­tes­ter der HEC, ist die QS einfach unum­gäng­lich, um die Quali­tät eines Produkts zu erhö­hen: „Sie ist eine zusätz­li­che Instanz in der Entwick­lung, die einen ande­ren Blick auf umge­setzte Teile einer Soft­ware hat. Sie hilft, Fehler zu redu­zie­ren und die Quali­tät zu erhö­hen.“

Bei der moder­nen QS gibt es grob gesagt zwei Vorge­hens­wei­sen: Zum einen das explo­ra­tive, manu­elle Testen, bei dem sich der Tester oder die Teste­rin durch die Soft­ware klickt. Zum ande­ren das durch auto­ma­ti­sierte Programme abge­deckte Testen. In welchem Umfang welche Vari­a­nte zum Zuge kommt, hängt vom Projekt, aber auch von der QS-Person selbst ab.

Je komple­xer eine Soft­ware oder Anwen­dung wird, desto sinn­vol­ler sind auto­ma­ti­sche Tests. Dafür wird eigens ein Programm entwi­ckelt. So können die Tests regel­mä­ßig wieder­holt werden. Müsste man nach jedem Release erneut alles manu­ell testen, würde die Quali­tät des Testens jedes Mal sinken und somit auch der Erfolg der Quali­täts­si­che­rung.

Warum kann man dann nicht gleich alles auto­ma­ti­sie­ren? Stef­fen Lohmann, Tech­ni­scher Projekt­lei­ter bei neusta soft­ware deve­lop­ment, winkt ab: „Das ist zu viel Aufwand! Data­hubs oder E-Mail-Programme lassen sich zum Beispiel nur mit erheb­li­chem Aufwand testen.“

Wer früher in der Schule ein Diktat geschrie­ben hat, der weiß, dass selbst wenn man es drei­mal durch­liest, sich trotz­dem Fehler einschlei­chen. Je umfang­rei­cher ein Soft­wa­re­pro­jekt ist, desto unwahr­schein­li­cher ist es, dass keine Fehler auftre­ten. „Soft­ware ist heute zu komplex “, sagt Frank Heyden­reich. „Und Menschen machen Fehler.“

Werden die Projekte noch komple­xer, dann wird auch die Anfäl­lig­keit für Probleme größer. Wenn mein Vorha­ben „Schuhe anzie­hen“ ist, dann weiß ich ziem­lich genau was ich zu tun habe und es kann wenig schief gehen. Bei etwas größe­ren Vorha­ben muss viel mehr bedacht werden: Wenn ich zum Beispiel eine Hoch­zeit planen und durch­füh­ren möchte, ist auch mit bester Planung das Ergeb­nis nicht immer hundert­pro­zen­tig vorher­zu­se­hen – wenn zum Beispiel das Wetter schlecht ist oder Gäste einfach wegblei­ben.

Vincent Hinrichs, Entwick­ler bei neusta soft­ware deve­lop­ment, sagt mit Blick auf die Soft­wa­re­ent­wick­lung: „Ab einer gewis­sen Größe und Komple­xi­tät ist eine fehler­freie Soft­ware leider nicht möglich, so wünschens­wert es auch wäre.“

Teste­rin­nen und Tester haben meist den besten Über­blick über das gesamte Projekt oder über den aktu­el­len Sprint. „Ent­wick­ler:innen fehlt einfach ein ande­rer Blick auf die Soft­ware“, sagt Frank Heyden­reich. Die einzel­nen Entwick­ler bear­bei­ten jeweils nur einen Teil eines Tickets. Tester fassen dage­gen jedes Ticket an.

QS sorgt also nicht nur für Fehler­re­duk­tion, sondern auch für reibungs­lose Abläufe: Hat ein Entwick­ler eine Anfor­de­rung umge­setzt, schaut sich die QS diese genau an. Erst dann geht sie zur Abnahme an den Product Owner. „Für unser Projekt zum Beispiel bringt QS eine Entlas­tung der Product Owner durch Vorfil­tern von Tickets“, sagt Vincent Hinrichs. „Für den Endkun­den maxi­miert die QS die „expe­ri­ence“ einer Anwen­dung.“

Oft bildet die QS das Binde­glied zwischen dem Entwick­lungs­team und den Auftrag­ge­ben­den. Kunden besit­zen in der Praxis häufig nicht so viel tech­ni­sches Verständ­nis, um alle Dimen­si­o­nen abschät­zen zu können. Soft­wa­re­tes­ter sind dann die Über­set­zer zwischen der Tech­nik und der Fach­lich­keit.

Soft­wa­re­test ist kein Ausbil­dungs­be­ruf, sondern kann letzt­lich jeder Mensch mit einer gewis­sen IT-Affi­ni­tät machen. Doch je höher die Quali­fi­ka­tion ist, desto brei­ter kann die Tätig­keit ausge­übt werden. Als profes­si­o­nelle Tester und Teste­rin­nen brin­gen die meis­ten von uns ein hohes Maß an Eigen­ver­ant­wor­tung und einen Drang nach steti­ger Verbes­se­rung mit. Das sind aus unse­rer Sicht gute Eigen­schaf­ten für die Arbeit in der QS.

„QS fängt beim Code Review an und sorgt für eine bessere Wart­bar­keit des Codes“, sagt Stef­fen Lohmann. „Sie stärkt das Vertrauen des Kunden und der Benut­zer, denn wir korri­gie­ren Fehler proak­tiv. QS sorgt für doppelte Sicher­heit – zwei Paar Augen sehen mehr als eines.“