Softwaretest

Alpha-Test oder Beta-Test? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Alpha-Test und Beta-Test wer­den beim → Soft­ware­test ver­wen­det, um bestimm­te Abnah­me­tests zu cha­rak­te­ri­sie­ren.In die­sem Bei­trag wer­den bei­de Begrif­fe vor­ge­stellt und ein­ge­ord­net. Die bei­den Begrif­fe kön­nen wie folgt cha­rak­te­ri­siert wer­den: Das → ISTQB defi­niert die Begrif­fe Alpha-Test und Beta-Test wie folgt /ISTQB-→ Glos­sar/:“Alpha-Test: Eine Art → Abnah­me­test, der in der Test­um­ge­bung des … 

Wei­ter­le­sen …

Ausführung, Durchführung, Realisierung oder Umsetzung? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Aus­füh­rung, Durch­füh­rung, Rea­li­sie­rung und Umset­zung wer­den in ver­schie­de­nen Manage­ment­dis­zi­pli­nen ver­wen­det. In die­sem Bei­trag wird eine Beschrei­bung der vier Begrif­fe gelie­fert. Die vier Begrif­fe kön­nen fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: Das deut­sche Wik­tio­na­ry defi­niert Aus­füh­rung fol­gen­der­ma­ßen /#Wiktionary-Ausführung/:”[1] Umset­zung einer Tat, eines Plans, einer Arbeit (…)” und gibt als Syn­ony­me an:”[1] Durch­füh­rung, Umset­zung, Ver­wirk­li­chen, Realisieren (…)”. … 

Wei­ter­le­sen …

Fehlverhalten oder Fehlerverhalten? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Fehl­ver­hal­ten und Feh­ler­ver­hal­ten wer­den im → Qua­li­täts­ma­nage­ment und beim → Soft­ware­test ver­wen­det.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die Begrif­fe Fehl­ver­hal­ten oder Feh­ler­ver­hal­ten wer­den in der Pro­jekt­durch­füh­rung / im → Pro­jekt­ma­nage­ment, beim Qua­li­täts­ma­nage­ment und beim Soft­ware­test benutzt. Bei­de Begrif­fe fin­den sich jedoch nicht in dem → Glos­sar des … 

Wei­ter­le­sen …

Softwarekosten Die Kosten der Software über die gesamte Lebenszeit erfassen

Die Kos­ten einer Soft­ware soll­te gene­rell ermit­telt wer­den, um so sicher­zu­stel­len, dass das Kos­­ten-Nut­­zen-Ver­­häl­t­­nis gut genug ist. Dabei müs­sen die sowohl die Kos­ten für die → Soft­ware­ent­wick­lung (Kos­ten für das → Soft­ware Engi­nee­ring) als auch die Soft­ware­kos­ten über den gesam­ten Pro­dukt­le­bens­zy­klus (von der Idee über den Betrieb bis zum Lebens­en­de der Soft­ware) betrach­tet wer­den. Abbil­dung 1 … 

Wei­ter­le­sen …

Nicht-funktionale Anforderungen Wichtig und häufig unterschätzt

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Unter nicht-fun­k­­tio­na­­len Anfor­de­run­gen (abge­kürzt: NFAs, sel­te­ner NFAen, eng­lisch: Non-fun­c­­ti­on­al Requi­re­ments — NFRs) wer­den Anfor­de­run­gen ver­stan­den, die sich aus tech­ni­schen Erfor­der­nis­sen und Rand­be­din­gun­gen erge­ben und kei­ne funk­tio­na­len Anfor­de­run­gen dar­stel­len.In die­sem Bei­trag wer­den die nicht-fun­k­­tio­na­­len Anfor­de­run­gen beschrie­ben. Anfor­de­run­gen wer­den im → Requi­re­ments Engi­nee­ring in funk­tio­na­le und nicht-fun­k­­tio­na­­le Anfor­de­run­gen (NFAs) unter­teilt (Abbil­dung 0.1). Funk­tio­na­le Anfor­de­run­gen beschreiben … 

Wei­ter­le­sen …

Qualität oder Güteklasse? (Quality or Grade?) Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe → Qua­li­tät (eng­lisch: Qua­li­ty) und Güte­klas­se (eng­lisch: Gra­de) wer­den im → Qua­li­täts­ma­nage­ment ver­wen­det und teil­wei­se ver­wech­selt. In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die Begrif­fe Qua­li­tät und Güte­klas­se sind in ers­ter Linie im Qua­li­täts­ma­nage­ment zu fin­den, aber auch im → Pro­jekt­ma­nage­ment oder im → Sys­tems Engi­nee­ring. Die beiden … 

Wei­ter­le­sen …

Releaseplan oder Roadmap? Welcher Begriff steht wofür?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Release­plan und → Road­map wer­den im agi­len und klas­si­schen → Pro­jekt­ma­nage­ment sowie im → Pro­dukt­ma­nage­ment ver­wen­det.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert und der Unter­schied auf­ge­zeigt. Release­plan und Road­map wer­den im Pro­­dukt- und Pro­jekt­ma­nage­ment genutzt, um im Vor­hin­ein das Ergeb­nis von Ent­wick­lungs­tä­tig­kei­ten zu kenn­zeich­nen. Die bei­den Begrif­fe können … 

Wei­ter­le­sen …

Abnahmekriterien oder Akzeptanzkriterien? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Abnah­me­kri­te­ri­en und Akzep­tanz­kri­te­ri­en wer­den bei der abschlie­ßen­den Bewer­tung von Pro­duk­ten oder → Dienst­leis­tun­gen ver­wen­det, um Pro­duk­te oder Dienst­leis­tun­gen ein­set­zen zu kön­nen. In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die bei­den Begrif­fe kön­nen fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: Hin­weis:In der Pra­xis wird zwi­schen den bei­den Begrif­fen nicht unter­schie­den, Abnah­me­kri­te­ri­en und Akzep­tanz­kri­te­ri­en wer­den synonym … 

Wei­ter­le­sen …

Die Requirements Traceability Matrix (RTM) Verbindungen zwischen Requirements-Artefakten erfassen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Requi­re­ments → Tracea­bi­li­ty → Matrix (RTM, sel­te­ner auf Deutsch auch Anfor­de­rungs­nach­ver­fol­gungs­ma­trix) ist eine Matrix, die die Ver­bin­dung von ein­zel­nen Requi­re­ments / Anfor­de­run­gen erfasst.In die­sem Bei­trag wird die Requi­re­ments Tracea­bi­li­ty Matrix kurz beschrie­ben. Die RTM ist ein ein­fa­ches Instru­ment zur Erfas­sung der → Traces. Sie steht damit als tex­tu­el­ler Ansatz neben einer → … 

Wei­ter­le­sen …

Fehlerkultur Mit Fehlern richtig umgehen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Eine Feh­ler­kul­tur (engl. Fail­ure Cul­tu­re) ist in Orga­ni­sa­tio­nen → wich­tig, um den Umgang mit Feh­lern so zu gestal­ten, dass ein­zel­ne Mit­ar­bei­ter an der Feh­ler­re­du­zie­rung und damit an der Qua­li­täts­ver­bes­se­rung teil­ha­ben kön­nen.In die­sem Bei­trag wird eine Beschrei­bung der Feh­ler­kul­tur in Orga­ni­sa­tio­nen gelie­fert. Der Umgang mit Feh­lern ist in Orga­ni­sa­tio­nen unter­schied­lich. Eine “gute”, kon­struk­ti­ve Fehlerkultur … 

Wei­ter­le­sen …