De ultieme gids voor risicogebaseerd testen: risicobeheer bij softwaretests

ultimate guide risk based testing

De ultieme gids voor risicogebaseerd testen, risicobeheer en de aanpak ervan met voorbeelden:

Wat is op risico gebaseerd testen?

Risicogebaseerde tests zijn het uitvoeren van tests of het ontwerpen en uitvoeren van scenario's, zodat de belangrijkste bedrijfsrisico's die een negatieve impact hebben op het bedrijf, zoals geïdentificeerd door de klant, vroeg in de levenscyclus worden ontdekt in hun product of functie en verzacht door mitigerende maatregelen te implementeren.

​ Klik hier voor een complete serie testplannen

De negatieve impact kan kostenimpact, ontevreden klant, slechte gebruikerservaring en zelfs het verlies van klanten omvatten.

Met andere woorden, de RBT-aanpak is om ervoor te zorgen dat het testen op een zodanige manier wordt gedaan dat zelfs als een gebruiker vindt een bug in de productie, dat weerhoudt hem / haar er niet van om de software te gebruiken of heeft geen serieuze impact op het bedrijf.

RBT voert testen uit op basis van productrisico's. RBT is om ruim van tevoren uit te zoeken wat het risico is van het falen van een bepaalde functie of functionaliteit in de productie en de impact ervan op het bedrijf in termen van kosten en andere schade door een prioriteringstechniek te gebruiken voor de testgevallen.

Daarom wordt bij risicogebaseerd testen het principe van prioriteit geven aan de tests van de kenmerken, modules en functionaliteiten van een product of software. De prioriteitstelling is gebaseerd op het risico van de waarschijnlijkheid van uitval van die functie of functionaliteit in de productie en de impact ervan op de klanten.

Wat je leert:

• Risicogebaseerd testen en de relevantie ervan voor Agile en DevOps
  • Op risico gebaseerde testaanpak
    • Wanneer gebruiken we de RBT-benadering?
    • Voorbeeld van een RBT-aanpak
  • Manieren om risicoanalyse uit te voeren
  • Risicoanalyseprocedure
  • Methodologie voor risicoanalyse
    • Stap # 1) Met behulp van een 3X3-raster
    • Stap 2) Waarschijnlijkheid en impact van een mislukking
    • Stap 3) Prioriteitsraster testen
    • Stap # 4) Details van testen
  • Hoe is RBT relevant voor Agile en DevOps?
  • Voordelen van op risico gebaseerde testaanpak
• Risicobeheer tijdens testplanning
  • Risicobeheerproces
    • # 1) Risico-identificatie
    • # 2) Risicobeoordeling / risico-impactanalyse
    • # 3) Risicobeperking
  • Gevolgtrekking
• Risicobeheer tijdens de testuitvoeringsfase (met voorbeeld)
  • Risicobeheer - met een focus op de AUT
  • Hoe vindt testen op risicobasis plaats?
  • Gevolgtrekking
  • Aanbevolen literatuur

Risicogebaseerd testen en de relevantie ervan voor Agile en DevOps

Driehonderd uur besteed aan het ontwikkelen van software kan in slechts 30 seconden nutteloos worden gemaakt met een enkel defect dat in de productie wordt vastgesteld.

Dit kan op zijn beurt het doel van het hele product ruïneren zonder andere optie dan het gewoon van de markt te halen. En dat is het belang en de noodzaak van ‘kwaliteitstesten’.

Met de snelle groei in technologie wordt de software gehost in de cloud en ondersteunt meerdere besturingssystemen, meerdere platforms, complexe IT-infrastructuren, enz., De eindgebruikers worden steeds kieskeuriger over de functies en opties en sluiten nooit compromissen voor de klanttevredenheid. .

Tegenwoordig wordt ‘Kwaliteit’ een cruciale factor in de levering van software, waar continue verbeteringen plaatsvinden om de kwaliteit te verbeteren om de klanten tevreden te houden.

We merken vaak dat het een veelvoorkomend probleem is voor bijna alle testers om onder enorme druk te staan ​​dat hun testvenster wordt ingedrukt en meestal wordt de build aan hen overgedragen om op het laatste moment te testen. Ze hebben niet genoeg tijd en middelen om alle tests uit te voeren die ze hebben ontworpen en de automatiseringsdekking is niet altijd 100% en het heeft zijn eigen uitdagingen.

De leveringstermijn kan niet worden gemist en tegelijkertijd kan ook de kwaliteit niet worden aangetast. Wat het plan B ook is, om extra testmiddelen toe te voegen door zich terug te trekken uit de andere teams, werkt niet, Plan C, stop met alle andere activiteiten doen en de moeite alleen hieraan besteden, helpt niet echt. Maar veel toevoeging van testmiddelen lukt uiteindelijk niet.

Er is geen andere optie dan slechts beperkte en belangrijke tests uit te voeren binnen de beschikbare tijd en middelen.

Dus, hoe beslissen we welke test in dit stadium belangrijk is? Wat een tester ook belangrijk vindt, is misschien niet echt belangrijk voor de klanten. Vanuit wiens perspectief wordt het belang van de functie of een functionaliteit bepaald? Wie beslist welke belangrijke tests zijn? En er blijven nog veel andere vragen rijzen.

Om al deze vragen te beantwoorden en de bovenstaande situatie effectief aan te pakken werd een testaanpak opgeroepen ‘Risicogebaseerd testen’ , binnenkort gebeld 'RBT' , is ontstaan, waar het team de testscenario's duidelijk heeft gepland en geïdentificeerd op basis van de ‘Projectrisico’ -criteria.

Hoewel het QA-team een ​​duidelijk beeld heeft van de belangrijke tests, is RBT een bewezen methode om de cruciale en belangrijke tests vanuit het klant- en bedrijfsperspectief te identificeren door middel van een 'Risico analyse' procedure ​

Dus, in tegenstelling tot de traditionele manier om eenvoudig de defecten in de software te identificeren, zijn de QA-benadering en het doel in de loop van de tijd veranderd als gevolg van de verandering in de technologie, toename van de concurrentie op de markt om kwaliteitssoftware uit te brengen, introductie van 'Automate Everything', en in zijn totaliteit introductie van Agile en DevOps praktijk van het leveren van de software over een periode van enkele uren.

Daarom is de huidige trend van ‘Testprincipe’ niet alleen ‘het identificeren van de gebreken’, maar ook

# 1) Concentreer u op het gebied van het product waar er een grote impact is op het bedrijf vanwege uitval of een grote kans op uitval in de productie.

#twee) Focussen op het identificeren van de gebreken vroegtijdig en een team in staat stellen om het zo vroeg mogelijk op te lossen en dus de software / het product of de functie toestaan ‘Fail Fast’.

# 3) Het belangrijkste aspect van de service van het QA-team is nu om zich te concentreren op de klant bij het creëren van waarde voor de klant door de focus op ‘End-to-end klantervaring’.

Op risico gebaseerde testaanpak

Het is altijd alsof je je op een tentamen voorbereidt, dat je niet kunt zeggen dat testen voldoende is en dat er geen defecten meer in de software zitten, ook al ontwerpen en voeren ze een groot aantal testen uit.

Er is een punt waarop softwarestabiliteit niet dubbel zal worden verzekerd door alleen het aantal testgevallen te vergroten. Op dit moment is het niet alleen om te focussen op het aantal tests, maar ook op wat de klant eigenlijk verwacht van de release.

Daarom is het essentieel om een ​​evenwicht te vinden bij het optimaliseren van het testen om het maximale voordeel te behalen met de redelijke testinspanning. En dit is nog belangrijker wanneer de testtijdlijnen erg krap zijn en er onvoldoende middelen beschikbaar zijn om voldoende testen uit te voeren.

In dit geval speelt de RBT-benadering dus een sleutelrol bij het optimaliseren van de QA-inspanning en het maximaliseren van het testvoordeel met een minimaal bedrijfsrisico.

Dus als we ons concentreren op het bovenstaande aspect, dan zal het werk van een QA veel worden verlicht. Ze hoeven hun weekenden niet op kantoor te branden, de software continu te testen en zich zorgen te maken over elke S4 (Severity 4) en P4 (Priority 4) defecten die uit het testen naar voren komen.

Welnu, 4 wordt beschouwd als de laagste prioriteit en ernst van de defecten bij het testen. Ze kunnen hun tijd beter investeren in andere nuttige aspecten van het project.

Om de belangrijkste drijfveren van de ‘Risicogebaseerde test’ benadering samen te vatten:

• Om het testen van ‘wat klanten willen’ mogelijk te maken vanuit een zakelijk perspectief.
• Om aan het tijdschema te voldoen met de verwachte kwaliteit.
• Om de QA-inspanning te optimaliseren.

Wanneer gebruiken we de RBT-benadering?

Dit wordt gebruikt in de onderstaande scenario's:

• De RBT-benadering kan worden gebruikt wanneer er een beperking of beperking is op tijd, kosten en middelen van een project en wanneer het nodig is om de middelen te optimaliseren.
• De RBT-benadering wordt gebruikt wanneer het programma complexer is en nieuwe technologie aanpast en dus veel uitdagingen met zich meebrengt.
• Als het programma een R & D-project is en het van een eerste soort is en er een aantal onbekenden en risico's in het project zit.

Voorbeeld van een RBT-aanpak

In de IT-industrie worden verschillende op risico gebaseerde analysebenaderingen gebruikt om de risico's van productie en de impact ervan te overwinnen.

Hieronder wordt een dergelijke benadering gegeven:

Deze benadering van RBT omvat het identificeren van de ‘Vitale functies of belangrijkste kenmerken’ van het product en het beoordelen van de risico's waaraan elk van deze functionaliteiten wordt blootgesteld tijdens de productie en het implementeren van gepaste risicobeperkende maatregelen om het risico te verkleinen of te beperken.

Daarom omvat de RBT-aanpak het testen van de functionaliteiten die de kans op mislukking en de grootste impact op het bedrijf hebben. De soorten storingen kunnen operationeel of zakelijk zijn, technisch, extern, enz.

Manieren om risicoanalyse uit te voeren

Er is geen standaardproces of sjabloon gedefinieerd als zodanig om de risicoanalyse in Softwaretests uit te voeren voor elk kenmerk van een product. Diverse organisaties hanteren hun eigen benadering van risicoanalysemethoden.

Risicoanalyse kan worden uitgevoerd op verschillende projectitems om de risico's te identificeren en om een ​​RBT-aanpak voor analyse te implementeren. Die items omvatten,

• Kenmerken
• Functionaliteiten
• Gebruikersverhalen
• Vereisten
• Gebruik cases
• Testgevallen

Laten we ons in dit geval alleen richten op testcases om de implementatie van de op risico gebaseerde testbenadering te begrijpen.

Risicoanalyseprocedure

Risicoanalyse omvat de betrokkenheid van relevante belanghebbenden van het programma van zowel de ‘ Technisch team en zakelijk team ’ , waaronder de eigenaar van het product, productmanagers, bedrijfsanalisten, architecten, testers en klantvertegenwoordigers.

Er zouden brainstormsessies met deze belanghebbenden worden georganiseerd om de discussie uit te voeren om het belang van elk kenmerk van een product te identificeren en deze te prioriteren op basis van het risico van mislukking en de impact ervan op de eindgebruikers in de productie.

Verschillende ‘Projectdocumenten’, zoals Requirements Document, Technical Specification Documents, Architecture and Design Documents, Business Process Document, Use Case Document, etc., zullen de input worden voor de brainstormsessie.

De kennis van belanghebbenden over het product en het bestaande product op de markt zal ook een inputfactor zijn voor de discussie.

Er zijn maar weinig andere bronnen van invoer die ook kunnen zijn:

• Om input te verzamelen over de meest gebruikte functionaliteit.
• Input van het raadplegen van een domeinexpert.
• Gegevens van de vorige versie van het product of een vergelijkbaar product op de markt.

Tijdens de brainstormen sessie worden de risico's met betrekking tot elk van deze functies geïdentificeerd. De soorten risico's kunnen een operatie zijn, technisch of zakelijk. De tests en scenario's die daarop betrekking hebben, worden gewogen en risicowaarden worden beoordeeld op basis van de waarschijnlijkheid dat het risico zich voordoet en de impact van het risico.

De ‘waarschijnlijkheid dat het risico zich voordoet’ kan het gevolg zijn van:

• Slecht begrip van de functie door het productontwikkelingsteam.
• Onjuiste architectuur en ontwerp.
• Onvoldoende tijd om te ontwerpen.
• Incompetentie van het team.
• Ontoereikende middelen - mensen, tools en technologie.

De ‘impact van het risico’ is het effect van een mislukking voor de gebruikers en het bedrijf als het zich voordoet. De impact zou kunnen zijn,

• Kostenimpact, resulterend in verlies.
• Zakelijke impact resulterend in verlies van zaken of verlies van marktaandeel, juridische procedures, verlies van licentie.
• Kwaliteitsimpact, resulterend in de ondermaatse of incompetente productvrijgave.
• Slechte gebruikerservaring, resulterend in ontevredenheid en verlies van een klant.

Het aandachtsgebied van het beoordelen van het risico van een functie of product kan zijn,

• Gebied van bedrijfskritiek van de functionaliteit.
• Meest gebruikte features en belangrijke functionaliteit.
• Gebreken die vatbaar zijn voor gebieden
• Functionaliteit die de impact op veiligheid en beveiliging draagt.
• Gebied van complex ontwerp en architectuur.
• Wijzigingen ten opzichte van eerdere versies.

Methodologie voor risicoanalyse

Laten we de ‘Risicogebaseerde testmethodologie’ nu in detail begrijpen.

De op risico gebaseerde testbenadering gebruikt RISK als criterium in alle testfasen van de testcyclus, d.w.z. testplanning , testontwerp, testimplementatie, test uitvoering , en testrapportage. Idealiter kan men een groot aantal mogelijke combinaties van testscenario's ontwerpen.

Daarom omvat de RBT-benadering een rangschikking van de tests op basis van de ernst van de risico's om het meest defecte of risicovolle gebied van mislukking te achterhalen, wat een grote impact op het bedrijf heeft.

Het belangrijkste doel van risicoanalyse is om onderscheid te maken tussen de 'Hoge waarde' items zoals producteigenschappen, functionaliteiten, vereisten, gebruikersverhalen , en testcases, en ‘ Lage waarde' ones en dus later om meer te focussen op ‘Hoge waarde’ testcases, door minder te focussen op ‘Lage waarde’ testcases. Dit is de eerste stap van Risicoanalyse voordat de risicogebaseerde test wordt gestart.

De hoofdtaak van categorisering of groepering van testcases in hoge en lage waarde en het toewijzen van de prioriteitswaarde aan elk van deze testcases omvat de volgende stappen:

Stap # 1) Met behulp van een 3X3-raster

Risicoanalyse wordt uitgevoerd met behulp van een 3X3-raster, waarbij elke functionaliteit, niet-functionaliteit en de bijbehorende testcases worden beoordeeld door een team van belanghebbenden op hun ‘Waarschijnlijkheidvan mislukking ’en‘ Gevolgen van mislukking ’.

De waarschijnlijkheid van mislukking van elke functionaliteit in de productie wordt over het algemeen benaderd door een groep ‘technische experts’ en worden gecategoriseerd als ‘waarschijnlijk mislukken, vrij waarschijnlijk en onwaarschijnlijk’ langs de verticale as van het raster.

het verschil tussen c en c ++

Evenzo wordt de ‘impact van het falen’ van deze kenmerken en functionaliteiten in de productie ervaren door de eindklant, indien niet getest, wordt deze beoordeeld door een groep van ​ Bedrijfsspecialisten ”en zijn gecategoriseerd onder de categorieën‘ Kleine, zichtbare en onderbreking ’langs de horizontale as van het raster.

Stap 2) Waarschijnlijkheid en impact van een mislukking

Alle testgevallen zijn gepositioneerd in de kwadranten van het 3 x 3-raster op basis van de geïdentificeerde waarden van de waarschijnlijkheid van falen en de impact van falen, die als stippen in de onderstaande afbeelding worden weergegeven.

Uiteraard zijn de hoge faalkans en de hoge impact van falen (onderbreking) gegroepeerd in de rechterbovenhoek van het net, wat van groot belang is en daarom wordt vastgesteld dat 'High Value'-tests en' Low Value'-tests zijn gegroepeerd in de linkerbenedenhoek die voor de klant het minst of niet van belang is, waar minder aandacht kan worden besteed aan deze features of testcases.

Stap 3) Prioriteitsraster testen

Op basis van de bovenstaande positionering van de testgevallen in het raster, worden de tests geprioriteerd en gelabeld met prioriteiten 1,2,3,4 en 5 en worden ze tegen elk ervan gemarkeerd. De belangrijkste tests zijn geplaatst in een 1^strasters die zijn toegewezen met prioriteit 1 en evenzo minder belangrijke worden gerangschikt als 2, 3, 4 en 5.

Ten slotte worden alle testcases gesorteerd op basis van hun prioriteitsnummers en worden ze opgehaald voor uitvoering in de volgorde van prioriteit. De degenen met hoge prioriteit worden als eerste opgepikt voor uitvoering en degenen met lage prioriteit worden ofwel later uitgevoerd of gedeactiveerd.

Stap # 4) Details van testen

De volgende stap is om te beslissen over het detailniveau van testen voor de gedefinieerde testomvang. De diepte van de reikwijdte van de tests kan worden bepaald op basis van de bovenstaande rangschikking volgens het onderstaande raster.

Tests met hoge prioriteit met ranglijst 1 worden ‘grondiger’ getest en dienovereenkomstig worden experts ingezet om deze functies met hoge kriticiteit en de bijbehorende testcases te testen. Evenzo testcases met prioriteit 2, 3 en 4. Er kan een beslissing worden genomen om de functies en tests van prioriteit 5 buiten beschouwing te laten op basis van de beschikbare tijd en middelen.

Daarom helpt de Level of Detail of Testing-benadering van het prioriteren van de functies en de testcases de testers niet alleen om de 'High-Value Tests' te identificeren, maar begeleidt ze hen ook om te beslissen over hun 'detailniveau van testen' op basis van deze prioriteitsclassificaties en helpt hen om beter te testen en verlaagt de testkosten door een optimalisatieproces.

Hoe is RBT relevant voor Agile en DevOps?

Nu, na het begrijpen van de risicogebaseerde testbenadering van het uitvoeren van testen op basis van de prioriteitstelling van tests afhankelijk van het 'risico op mislukking' van een bepaald kenmerk en de 'impact op de klant' in live, zou men natuurlijk de vraag kunnen stellen van de relevantie van op risico gebaseerde testaanpak in Agile en DevOps-praktijken.

‘Alles automatiseren’, ‘Alles testen’, ‘Continu testen’, ‘Herhaaldelijk testen’ zijn de belangrijkste concepten van deze praktijken.

Elke keer dat er een wijziging in de code is of er een release is, worden alle ontworpen tests automatisch doorlopen Continue integratie (CI) ​ Continue levering (cd) pijplijn snel en herhaaldelijk, ongeacht hun prioriteit.

Wat is dan de relatie tussen RBT en DevOps? Waar zou RBT passen en relevant worden in Agile en DevOps ???

# 1) Ja, zoals ik al eerder zei, het is niet zo dat elke branche en elk product 100% automatiseringsdekking heeft voor hun testuitvoeringen. Dus als het team überhaupt de prioriteitskeuze voor testuitvoering moet maken uit de keuze van handmatige testcases en de energie en inspanning van de testmiddelen wil sparen voor andere activiteiten, dan is RBT de beste keuze.

De op risico gebaseerde benadering is ook een betere gok voor het uitvoeren van geautomatiseerde tests met hoge prioriteit en testen op zijn vroegst.

#twee) Q Een team kan de RBT-benadering effectiever toepassen tijdens de behoefteanalyse bij het analyseren van de vereisten en het verstrekken van een voorafgaand rapport van de waarschijnlijke risico's van de producten en de kenmerken, zodat het programmateam proactief passende maatregelen kan nemen om deze te verminderen.

# 3) De RBT-benadering kan effectief worden gebruikt bij het ontwerpen van de testcases en scenario's op basis van hoog risico, zodat er meer aandacht kan worden besteed aan kenmerken en functionaliteiten met een hoog risico.

# 4) Door de ‘Hoog risico’ gebieden te identificeren, kan het QA-team hun testinspanningen richten op die gebieden om ‘grondiger’ te testen met ‘hooggeschoolde testers’.

# 5) 'Fail Fast', zoals we allemaal weten, is het concept van 'Agile' en 'DevOps', waarvoor de RBT-aanpak helpt om de 'hoogrisico'-gebieden in de software te identificeren, de defecten vroegtijdig te identificeren en ze snel te laten falen en falen eerst en laat het team het repareren.

# 6) Het uiteindelijke doel van Agile / DevOps is ‘Klantgerichtheid’ en daarom stelt de RBT-benadering de QA in staat zich te concentreren op de klantervaring dan alleen het vinden van defecten.

Voordelen van op risico gebaseerde testaanpak

We begrepen al het doel en het gebruik van de RBT-benadering om de vereisten te analyseren, de testscenario's te ontwerpen en uit te voeren. Er zijn verschillende voordelen van RBT.

We kunnen de voordelen van risicogebaseerd testen consolideren en vermelden als:

• Helpt bij een efficiënter en geoptimaliseerd gebruik van testmiddelen.
• Helpt bij het vergemakkelijken van het QA-werk, testen, testontwerp en -ontwikkeling en testvoorbereidingsactiviteiten door prioriteiten te stellen.
• Helpt bij het beter beheren van de QA-bronnen door de belangrijkste middelen toe te wijzen aan gebieden met een hoge focus.
• Het helpt bij het effectieve gebruik van middelen en besteedt hun tijd en energie aan betere dingen in het project.
• Helpt het QA-team bij het plannen van de testinspanningen op basis van de risicobeoordeling en identificatie van vluchtige en risicovolle gebieden.
• Het helpt het team om de uit te voeren tests te optimaliseren, afhankelijk van het belang en dus de-scope van tests met een lage waarde in overleg met de belanghebbenden.
• Over het algemeen helpt het bij kostenreductie door geoptimaliseerde en verminderde testactiviteiten.
• De RBT-benadering stelt het QA-team in staat om eerst de gebieden met een hoog risico te testen en stelt het product in staat 'snel te falen' en snel te repareren.
• De RBT-aanpak helpt om duidelijkheid te scheppen in de ‘ Testdekking ’ en de ‘Test Scope’ voor de hele groep belanghebbenden.
• Het team kan hun focus op gebieden met een hoog risico vergroten en minder aandacht houden op het gebied met een laag risico.
• RBT stelt het team in staat om ruim van tevoren te beslissen over de implementatie van de meest effectieve manier om de productrisico's te mitigeren.
• RBT helpt bij het vermijden van het effect van de ongepaste implementatie van mitigerende maatregelen.
• Met risicogebaseerde tests kan het team passende maatregelen nemen om onvoorziene gebeurtenissen te beperken of te plannen of om een ​​tijdelijke oplossing te vinden om de storing te verhelpen of de impact ervan te verminderen als het risico zich voordoet in Live.
• RBT helpt bij het minimaliseren van het restrisico bij de introductie.
• Het helpt bij het bereiken van de ‘Verbeterde kwaliteit’ door minder dure defecten in de productie.
• Helpt uiteindelijk bij ‘Verbeterde klantervaring’ en ‘Tevreden klant’.

Vervolgens leren we hoe we risico's kunnen beheersen tijdens de testplanning- en testuitvoeringfasen van de softwaretestlevenscyclus.

Risicobeheer tijdens testplanning

Risico's beheren tijdens de testplanningsfase:

Het leven is vol risico's, net als een softwareproject. Er kan altijd iets misgaan. We zijn altijd op onze hoede om dingen goed te maken - maar hoe zit het met ervoor zorgen dat er niets misgaat en dat wanneer het weet, we precies weten wat we moeten doen? Voer risicobeheer in - dit is een onderdeel van een softwaretestproject dat ons voorbereidt om risico's te voorkomen, te begrijpen, te vinden en te overwinnen.

Een risico is gewoon een probleem dat zich waarschijnlijk zal voordoen en wanneer het zich voordoet, zal het verlies veroorzaken.

Het verlies kan van alles zijn: geld, tijd, moeite of een compromis in kwaliteit. Het verlies is nooit goed. Het maakt niet uit hoeveel spin we eraan geven, het is niet positief - en zal het ook nooit worden. Daarom Risicomanagement is een integraal onderdeel van softwareprojecten om ervoor te zorgen dat we met risico's omgaan en verliezen voorkomen / verminderen.

Risicogebaseerd testen ​ Omdat we een QA-gemeenschap zijn, laten we ons uitsluitend in onze QA-wereld specifiek houden voor risico's en het proces dat ermee verband houdt. Risico's worden grofweg in 2 fasen ingeschat en beheerd Software Test levenscyclus ​STLC kan worden onderverdeeld in 3 fasen: testplanning, testontwerp en testuitvoering.

Het risicobeheerproces vindt twee keer plaats, tijdens:

1. Testplanning
2. Test Case Design (einde) of soms in de Test Execution fase

Het is verplicht in geval 1, maar in geval 2 is het meer een 'behoeftebasis'-situatie.

Tweedelige artikelreeks:

Ook al is het onderliggende proces hetzelfde, de soorten risico's die op beide gebieden worden aangepakt, zijn totaal verschillend. Om ze individueel recht te doen, gaan we ze als tweedelige serie anders behandelen.

Dit gedeelte gaat over 'Risicobeheer tijdens testplanning​

Risicobeheerproces

Het generieke proces voor risicobeheer omvat 3 belangrijke fasen:

1. Risico-identificatie
2. Risico-impactanalyse
3. Risicobeperking

Voorbeelden van risico's en risicobeperking testen:

# 1) Risico-identificatie

Zoals gezegd, is de eerste stap om een ​​probleem op te lossen het identificeren ervan. Deze fase omvat het maken van een lijst van alles dat mogelijk naar boven zou kunnen komen en de normale stroom van gebeurtenissen zou kunnen verstoren.

Het belangrijkste resultaat van deze stap is een lijst met risico's.

Deze risicogebaseerde teststap wordt gewoonlijk geleid door de QA-lead / manager / vertegenwoordiger. De hoofdleider alleen zal echter niet in staat zijn om de volledige lijst te maken - de input van het hele QA-team heeft een enorme impact. We kunnen zeggen dat dit een collectieve activiteit is die wordt geleid door de QA-leider.

Ook zijn de risico's die worden geïdentificeerd tijdens de testplanningsfase meer 'bestuurlijk' van oriëntatie, wat betekent dat we gaan kijken naar alles dat van invloed kan zijn op de planning, de inspanning, het budget, de infrastructuurveranderingen enz. Van het QA-project. niet de AUT, maar de manier waarop de QA-fase verloopt.

Risico's tijdens het plannen van tests: voorbeelden van op risico gebaseerde tests

Het volgende is een voorbeeldlijst van risico's die tijdens de testplanningsfase kunnen worden vermeld. Houd er rekening mee dat de AUT en zijn functionaliteit hier niet de focus is.

1. Het testschema is strak. Als de start van het testen wordt vertraagd vanwege ontwerptaken, kan de test niet worden verlengd tot na de geplande startdatum van de UAT.
2. Onvoldoende middelen, middelen te laat aan boord (het proces duurt ongeveer 15 dagen).
3. Gebreken worden ontdekt in een laat stadium van de cyclus of in een laat stadium; defecten die te laat worden ontdekt, zijn hoogstwaarschijnlijk te wijten aan onduidelijke specificaties en zijn tijdrovend om op te lossen.
4. Scope niet volledig gedefinieerd
5. Natuurrampen
6. Niet-beschikbaarheid van Independent Test omgeving en toegankelijkheid
7. Vertraagd testen vanwege nieuwe problemen

Op dit punt kunt u ervoor kiezen om zo grondig te zijn als u zou willen, afhankelijk van de hoeveelheid beschikbare tijd.

Zodra alle risico's zijn opgesomd, gaan we over naar Risicobeoordeling / Risico-impactanalyse.

# 2) Risicobeoordeling / risico-impactanalyse

Is uw risicoanalyse zoiets als dit? ​

Risicoanalyse bij softwaretests : Alle risico's worden in deze stap gekwantificeerd en geprioriteerd. De waarschijnlijkheid van elk risico (de kans van optreden) en de impact (de hoeveelheid verlies die het zou veroorzaken als dit risico zich voordoet) worden systematisch bepaald.

Hoog gemiddeld laag worden waarden toegekend aan zowel de waarschijnlijkheid als de impact van elk risico. De risico's met “hoge” waarschijnlijkheid en “Hoge” impact worden eerst aangepakt en daarna volgt de volgorde.

Risico-impact analyse tabel:

Als u deze stappen volgt, ziet de tabel met risico-impactanalyse voor de bovengenoemde risico's er ongeveer zo uit (alle waarden zijn hypothetisch en alleen bedoeld om inzicht te krijgen):

# 3) Risicobeperking

De laatste stap in dit Risk Based Testing (RBT) -proces is het vinden van oplossingen om te plannen hoe met elk van deze situaties om te gaan. Deze plannen kunnen verschillen van bedrijf tot bedrijf, project tot project en zelfs van persoon tot persoon.

Risicobeperkende technieken:

Hier is een voorbeeld van waar de Risicotabel in verandert wanneer deze fase is voltooid:

Enkele aandachtspunten:

1. Hoe eerder risicomanagement begint in een QA-projectplanningsfase, hoe beter.
2. Van alle 3 de stappen, Risico-identificatie is het belangrijkste ​Als iets niet wordt vermeld en overwogen wordt voor verdere stappen, wordt het risico niet afgehandeld.
3. Probeer een ideaal tijdsbestek te vinden voor deze activiteit. Bedenk dat te veel planning te weinig tijd laat om te doen.
4. Als zich na het risicobeheerproces een nieuwe situatie voordoet, kan het risicobeheerplan worden gewijzigd of bijgewerkt om de meest actuele situatie weer te geven.
5. Historische gegevens kan erg nuttig zijn voor het succes van dit proces.

Gevolgtrekking

Hiermee komen we aan het einde van Risicomanagement in de Testplanningsfase. Hoewel de onderliggende stappen en principes vergelijkbaar zijn, is het risicomanagementproces meer geconcentreerd op de AUT wanneer het plaatsvindt in de testontwerp- / uitvoeringsfase.

In onze volgende sectie behandelen we - Risicomanagement in de testuitvoeringsfase.

Risicobeheer tijdens de testuitvoeringsfase (met voorbeeld)

Tijdens onze reis om het risicobeheerproces te begrijpen, hebben we gesproken over hoe het uitsluitend verloopt in de Testplanningsfase van risicogebaseerd testen ​We begrepen ook het generieke proces dat daarbij hoort: risico-identificatie, risicobeoordeling en risicobeperkingsplan.

Risico's beheren tijdens het ontwerpen van tests of de uitvoeringsfase van tests:

Er is nog een andere vorm van Risicomanagement (ook wel aangeduid als, Risicogebaseerd testen ) die plaatsvindt tijdens de testontwerp- of testuitvoeringsfase, afhankelijk van de situatie. Nu, over welke situatie hebben we het? Laten we dat eerst proberen te begrijpen.

We weten allemaal dat ons testwerk reactief is. Geen vereisten (of scope gedefinieerd), we kunnen geen haalbaarheidsanalyse uitvoeren en testscenario's schrijven of testactiviteiten plannen.

Evenzo, als de code niet klaar is, hoeven we niets te testen, ongeacht hoeveel voorbereidend werk we klaar zouden kunnen hebben gehad in termen van testcases, testgegevens, enz. Ook is testen de enige stap die overblijft voordat het product gaat leven.

Risicobeheer - met een focus op de AUT

Laten we dit beter begrijpen met een voorbeeld:

Als het testen op die datum zou beginnen, 1 januari^sten moest doorgaan tot 14 januari^th- wanneer het testen is voltooid, wordt de Go-live-datum van het product meestal onmiddellijk vastgesteld. Laten we zeggen - 15 januari^thvoor de eenvoud. Nu, in een perfecte wereld zouden de dingen precies gaan zoals gepland. Maar we kennen allemaal de realiteit.

Laten we in dit geval aannemen dat het testen om de een of andere reden pas op 7 januari begon^th, wat betekent dat we de helft van onze testtijd verloren. Maar we hebben wel 14 dagen nodig om het product grondig te testen. We zouden de go-live-datum echter 7 dagen kunnen verschuiven; dit is meestal geen optie. Omdat het product wordt beloofd om op een bepaalde datum op de markt te komen en eventuele vertragingen niet goed zijn voor het bedrijf.

Meestal moeten wij, testteams, de vertragingen opvangen, op de een of andere manier compenseren, met de beschikbare tijd werken en ervoor zorgen dat het product goed wordt getest. Een zware klus, nietwaar?

Hier wordt opnieuw het proces Risicomanagement ingezet.

• Nu als vertragingen worden van tevoren verwacht voordat zelfs het testen begint, vindt het proces plaats in de testontwerpfase.
• Als vertragingen gebeuren tijdens een Test Uitvoeringsfase dat normaal begon - het proces wordt gevolgd tijdens de testuitvoeringsfase.
• De stappen en de methode zijn hetzelfde, ongeacht in welk stadium het gebeurt.

Wat is het proces?

Risicomanagement vindt plaats om te bepalen op welke gebieden van de AUT (Application Under Test) maximale focus nodig is. Dit zijn typisch de functionele gebieden (modules of componenten) die cruciaal zijn voor het succes van het eindproduct en die het meest vatbaar zijn voor storingen.

Lees ook​ Failure Mode and Effects Analysis (FMEA) is een techniek voor risicobeheer

Wie voert het uit?

Omdat het de AUT betreft, is de kennis erover niet alleen bij de QA maar ook bij alle andere teams - Dev, BA, Klant, Projectmanagementteams, enz. Daarom is het een collectieve inspanning, aangestuurd door het testteam.

Hoe vindt testen op risicobasis plaats?

Stap 1​ Risico-identificatie

Identificeer alle functionele gebieden van de AUT. Dit omvat simpelweg het maken van een lijst.

Stap 2) Risicobeoordeling

In deze stap worden alle risico's gekwantificeerd en geprioriteerd. Kwantificeren is simpelweg het toekennen van een nummer aan elk risico in de lijst dat een indicatie geeft van de prioriteit waarmee het moet worden aangepakt.

De waarschijnlijkheid van elk risico (de kans dat het zich voordoet) en de impact (de hoeveelheid verlies die het zou veroorzaken wanneer dit risico zich voordoet) worden beslist.

De typische methode is om de beoordelingen toe te wijzen. Bijvoorbeeld​ De kans kan waarden 1 tot 5 aannemen. 1 is de kans dat het voorkomen laag is (zal waarschijnlijk helemaal niet gebeuren) en 5 is hoog (zal zeer zeker gebeuren).

Evenzo kan Impact ook een cijfer van 1-5 krijgen. 1 met een lage impact (zelfs als dit risico zich voordoet, is het verlies minimaal) en 5 met een grote impact (enorme verliezen als er zich voordoet).

Stap 3​

Maak een tabelindeling en verspreid deze naar alle teamvertegenwoordigers - Dev, BA, Client, PM, QA en alle andere relevante personen.

Stap 4​

websites om youtube-video's naar mp3 te converteren

Geef elk team de opdracht om de waarden in te vullen op basis van hun beoordeling voor waarschijnlijkheid en impact.

Aangezien de waarschijnlijkheids- en impactwaarden numeriek zijn, wordt de berekening van de ‘Risicofactor’ gemakkelijk gemaakt.

Risicofactor = Waarschijnlijkheid X Impact. Hoe hoger de risicofactor, hoe ernstig het probleem is.

Een voorbeeld​

Houd er rekening mee dat dit op dit moment gewoon de uitkomst is van de beoordeling van een team. Voor een project waarbij 5 verschillende teams betrokken zijn, zou het QA-team eindigen met 5 verschillende tafels.

Stap # 5​

Neem een ​​gemiddelde van de risicofactorwaarden. Bijvoorbeeld​ Als er 5 teams zijn, tel dan voor elke module alle risicofactorwaarden op en deel deze door 5. Dit zijn de uiteindelijke waarden waar we het over gaan hebben. Stel dat dit de gemiddelde risicofactoren zijn:

Hoe meer de risicofactor, hoe meer die module moet worden getest.

Module 5 en 2 zijn dus het meest cruciaal voor het succes van het bedrijf. Deel de resultaten met alle teams.

Stap # 6​

Risicobeperkingsplan : Dit is de stap die verandert van Project naar Project. We hebben vastgesteld dat de modules 5 en 2 degene zijn waarop we ons het meest moeten concentreren.

Voorbeeldenvan het plan zou kunnen zijn:

1. Modules 5 en 2 zullen grondig worden getest door ervoor te zorgen dat alle bijbehorende testcases worden getest. De overige modules worden verkennend getoetst.
2. Modules 5 en 2 worden eerst getest en afhankelijk van de beschikbare tijd wordt er voor de andere gezorgd.

Zodra een plan is gemaakt, bereiken alle teams een overeenkomst en volgen die om het product te testen, rekening houdend met de risicofactor.

Dat is het!

Enkele belangrijke punten om op te merken:

• Omdat dit een collectieve activiteit is die nodig is rekening houden met ieders mening ​de kans dat het accuraat en effectief is, is groter.
• Dit is geen formele methode en hoeft geen onderdeel te zijn van elk QA-project.
• Soms, zelfs als het team ervoor kiest om geen tabellen te tekenen en waarden toe te kennen, a eenvoudige brainstormsessie met alle aanwezigen kan het QA-team goede aanwijzingen geven over hoe verder te gaan.
• De input van het ontwikkelteam is erg belangrijk omdat zij degenen zijn die het product maken, zodat ze weten wat mogelijk werkt en wat mogelijk extra moet worden gecontroleerd. Wees daar zeker naar op zoek.
• Ook al zijn er meerdere stappen in het proces, het kost niet veel tijd om ze uit te voeren ​Vooral als alle teams bij elkaar kunnen zitten en tegelijkertijd kunnen werken.
• Onthoud dit proces en het resultaat is alleen het alternatief ​Zoveel tijd krijgen als gepland voor het testen is de beste manier om de QA-activiteit uit te voeren.

Gevolgtrekking

De benadering van risicogebaseerd testen geeft duidelijk aan dat de focus van de tester niet alleen is om de defecten te blijven onderzoeken, ongeacht de ernst en prioriteit. Nu zijn de dingen veranderd en moeten testers slim werken en de duidelijke ‘behoefte van de klant en wensen van de gebruiker’ begrijpen.

Ze moeten het product grondig bestuderen en begrijpen wat de meest gebruikte functie in de productie is, wat het meest kritieke pad is voor het genereren van inkomsten en hoe ze de klanten kunnen beschermen en beschermen tegen productieproblemen en zakelijke bedreigingen.

De RBT-aanpak leert de testers dus duidelijk dat alleen alles testen of uitgebreid testen niet betekent dat het testen voltooid is of dat er geen defecten in het product zitten. Effectief testen binnen een bepaalde tijd en ervoor zorgen dat kritische en grote zakelijke gevolgen teniet worden gedaan en dat is best belangrijk voor de tester.

Risicogebaseerd testen is dus het meest efficiënte hulpmiddel voor het QA-team om de belanghebbenden van het project te begeleiden op basis van de projectrisico's. De RBT-benadering helpt het QA-team bij de continue identificatie van risico's en de oplossing ervan die het behalen van de algemene projectdoelen en objectieven in gevaar kunnen brengen en helpt bij het bereiken van het uiteindelijke doel van de QA Group.

P.S. De woorden QA en Testen zijn in het hele document door elkaar gebruikt.

Over de auteur: Dit artikel is geschreven door meerdere STH-teamleden - Gayathri Subrahmanyam en Swati S.

Gayathri is een softwaretest-KMO met meer dan 2 decennia ervaring in softwaretests en heeft de ‘Risk-Based Testing’ -benadering uitgebreid toegepast als onderdeel van Test Industrialisatie in verschillende opdrachten en heeft het voordeel gerealiseerd van optimalisatie van testbronnen en kwaliteitstests.

Was op risico gebaseerd testen een uitdaging voor u? Heb je nog interessante feiten om aan onze tutorial toe te voegen? Voel je vrij om je mening te geven in de comments hieronder !!

​ Bezoek hier voor een complete serie testplannen

Aanbevolen literatuur

• Continu integratieproces: hoe u de softwarekwaliteit kunt verbeteren en risico's kunt verminderen
• Failure Mode and Effects Analysis (FMEA) - Hoe risico's te analyseren voor betere softwarekwaliteit en tevreden klanten!
• De ultieme gids voor risicogebaseerd testen: risicobeheer bij softwaretests
• Top 10 risicobeoordeling en managementtools en -technieken
• Soorten risico's in softwareprojecten
• Enkele interessante sollicitatievragen voor het testen van software
• Softwaretests kiezen als uw carrière
• Feedback en recensies over softwaretestcursussen