Merkregeln für den Softwaretest Leitlinien für die Umsetzung

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Es gibt eini­ge Merkregeln(-Sammlungen) zum → Soft­ware­test, die bei der Umset­zung von Soft­ware­tests beach­tet wer­den soll­ten.
Eini­ge die­ser Merk­re­geln wer­den in die­sem Bei­trag vorgestellt.

Merk­re­geln hel­fen, wesent­li­che Aspek­te des Soft­ware­tes­tens zu berück­sich­ti­gen. Die Merk­re­geln kön­nen als Check­lis­te betrach­tet werden.

Bei den Merk­re­geln wird häu­fig zwi­schen Erfolgs­fak­to­ren (“das soll­ten Sie unbe­dingt beach­ten”) und Miss­erfolgs­fak­to­ren (“wenn Sie dies tun, wer­den Sie Schwie­rig­kei­ten bekom­men”) unter­schie­den (Abbil­dung 1).

Merkregeln für den Softwaretest: Unterteilung, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 1: Merk­re­geln für den Soft­ware­test: Unterteilung

In der Regel wer­den eher die Erfolgs­fak­to­ren genannt.

1. Meine Merkregeln für den Softwaretest

Mei­ne Merk­re­geln resul­tie­ren aus mei­nen Erfah­run­gen zum Softwaretest.

  • Soft­ware­test kos­tet Zeit und Geld: Dies muss Ihnen (und Ihren Geld­ge­bern) bewusst sein
  • Ent­wick­ler → tes­ten nicht ger­ne: Daher soll­ten die Tests durch aus­ge­bil­de­te Soft­ware­tes­ter durch­ge­führt werden
  • Tren­nen Sie → Test­ma­nage­ment und → Test­durch­füh­rung: Es ist sinn­voll, das Test­ma­nage­ment von der Test­durch­füh­rung zu trennen
  • “Soft­ware­test und Soft­ware­qua­li­tät endet nie”: Das Soft­ware­tes­ten ist eine kon­ti­nu­ier­li­che Auf­ga­be und ein Soft­ware­test endet erst, wenn das betrach­te­te Test­ob­jekt aus dem Markt genom­men wird

2. Merkregeln anderer Autoren

In eini­gen Büchern / von eini­gen Autoren gibt es Merk­re­geln zum Soft­ware­test. In die­sem Kapi­tel sind eini­ge davon aufgeführt.

2.1 Die sieben Grundsätze nach ISTQB

Das → ISTQB /#GTB-CTFL-Lehrplan, #IST­QB-CTFL-Syl­labus/ benennt fol­gen­de sie­ben Grund­sät­ze zum Soft­ware­test, die als gene­rel­le Leit­li­ni­en beim Tes­ten ange­se­hen wer­den können:

  1. Tes­ten zeigt die Anwe­sen­heit von → Feh­ler­zu­stän­den, nicht deren Abwe­sen­heit (Test­ing shows the pre­sence of defects, not their absence)
  2. Voll­stän­di­ges Tes­ten ist nicht mög­lich (Exhaus­ti­ve test­ing is impos­si­ble)
  3. Frü­hes Tes­ten spart Zeit und Geld (Ear­ly test­ing saves time and money)
  4. Häu­fung von Feh­ler­zu­stän­den (Defects clus­ter tog­e­ther)
  5. Vor­sicht vor dem Pes­ti­zid-Para­do­xon (Bewa­re of the pesti­ci­de para­dox)
  6. Tes­ten ist kon­text­ab­hän­gig (Test­ing is con­text depen­dent)
  7. Trug­schluss: “Kei­ne → Feh­ler” bedeu­tet ein brauch­ba­res Sys­tem (Absence-of-errors is a fall­a­cy)

Anmer­kung:
Die­se sie­ben Grund­sät­ze sind bei vie­len Autoren (so z.B. /Schlich22, Schmerler20, Spillner19/) zu fin­den, wenn auch teil­wei­se mit geän­der­ter Wortwahl.

2.2 Die zehn goldenen Regeln des Softwaretestens nach Perry

Per­ry /Perry02/ benennt fol­gen­de zehn gol­de­ne Regeln zum Soft­ware­test für Softwaretester:

  1. Ler­nen Sie, Nein zu sagen
  2. Bekämp­fen Sie Situa­tio­nen, in denen Sie nur ver­lie­ren können
  3. Fixie­ren Sie ein beweg­li­ches Ziel
  4. Betrach­ten Sie den Test­ge­gen­stand nicht als etwas, das von der ande­ren Sei­te kommt
  5. Machen Sie das Bes­te aus der Zeit, die zum Tes­ten zur Ver­fü­gung steht
  6. Kom­mu­ni­zie­ren Sie mit Kun­den und Anwendern
  7. Erklä­ren Sie den Mana­gern das Testen
  8. Ver­wen­den Sie Testtools
  9. Bau­en Sie eine Bezie­hung zu den Ent­wick­lern auf
  10. Las­sen Sie sich für das Tes­ten ausbilden

Anmer­kung:
Die­se zehn Regeln stam­men aus dem Jahr 2002 und damit aus einer Zeit, als das Soft­ware­tes­ten noch wenig stan­dar­di­siert war.

2.3 Die acht Lektionen zur Softwarequalität nach Wiegers

Wie­gers /Wiegers21/ benennt acht Les­sons / Lek­tio­nen zur Soft­ware­qua­li­tät, die auf sei­ner lan­gen Erfah­rung in Soft­ware­ent­wick­lungs­pro­jek­ten beruhen:

  1. When it comes to soft­ware qua­li­ty, you can pay now or you can pay more later
  2. High qua­li­ty natu­ral­ly leads to hig­her productivity
  3. Orga­niza­ti­ons never have time to build soft­ware right, yet they find resour­ce to fix it later
  4. Bewa­re the crap gap
  5. Never let your boss or your cus­to­mer talk you into doing a bad job
  6. Stri­ve to have a peer, rather than a cus­to­mer, find a defect
  7. Soft­ware peo­p­le love tools, but a fool with a tool is an ampli­fied fool
  8. Today’s “got­ta get is out right away” deve­lo­p­ment pro­ject is tomorrow’s main­ten­an­ce nightmare

Die deut­sche Über­set­zung der acht Lek­tio­nen stammt von mir:

  1. Wenn es um Soft­ware­qua­li­tät geht, kann man ent­we­der jetzt oder spä­ter mehr bezahlen
  2. Hohe → Qua­li­tät führt natür­lich zu höhe­rer → Pro­duk­ti­vi­tät
  3. Orga­ni­sa­tio­nen / Unter­neh­men haben nie die Zeit, Soft­ware rich­tig zu ent­wi­ckeln, aber sie fin­den Res­sour­cen, um sie spä­ter zu reparieren
  4. Vor­sicht vor der Schrottlücke
  5. Las­sen Sie sich nie­mals von Ihrem Chef oder Ihrem Kun­den dazu über­re­den, eine schlech­te Arbeit zu machen
  6. Bemü­hen Sie sich dar­um, dass ein Kol­le­ge und nicht ein → Kun­de einen Feh­ler findet
  7. Soft­ware-Leu­te lie­ben Tools, aber ein Narr mit einem Tool ist ein noch grö­ße­rer Narr
  8. Das Ent­wick­lungs­pro­jekt von heu­te, das sofort fer­tig wer­den muss, ist der War­tung­s­alp­traum von morgen

A. Präsentationen, Literatur und Weblinks

A.1 Präsentationen

  • -

A.2 Literatur

  1. /Perry02/ Wil­liam E. Per­ry, Rand­all W. Rice: Die zehn gol­de­nen Regeln des Soft­ware-Tes­tens, mitp, Bonn 2002, ISBN 978–3‑8266–0928‑2
  2. /Schlich22/ Maud Schlich: Soft­ware­tes­ten nach ISTQB für Dum­mies, Wiley-VCH, Wein­heim 2. Auf­la­ge 2022, ISBN 978–3‑527–72019‑4
  3. /Schmerler20/ Ste­fan Schmer­ler: Soft­ware­test in der Pra­xis. Grund­la­gen, Metho­den und Tech­no­lo­gien, epu­b­li, Ber­lin 2020, ISBN 978–3‑7531–2481‑0
  4. /Spillner19/ Andre­as Spill­ner, Tilo Linz: Basis­wis­sen Soft­ware­test: Aus- und Wei­ter­bil­dung zum Cer­ti­fied Tes­ter – Foun­da­ti­on Level nach ISTQB-→ Stan­dard, dpunkt, Hei­del­berg 6. Auf­la­ge 2019, ISBN 978–3‑86490–583‑4
  5. /Wiegers21/ Karl Wie­gers: Soft­ware Deve­lo­p­ment Pearls. Les­sons from Fif­ty Years of Soft­ware Expe­ri­ence, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2021, ISBN 978–0‑13–748777‑6

A.3 Weblinks

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (all­ge­mein)
/*/ Ver­weis auf eine Web­site, die als Ergän­zung zu einem Buch dient
/#/ Ver­weis auf ein ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website 

Letz­te Aktua­li­sie­rung: 26.02.2023 © Peter­jo­hann Con­sul­ting, 2005–2024

Ähnliche Beiträge