7 principes van softwaretesten met voorbeelden

Deze tutorial introduceert de zeven basisprincipes voor het testen van software die elke softwaretester en QA-professional zou moeten kennen.

Laten we de testprincipes leren met het volgende videovoorbeeld-

Klik hier als de video niet toegankelijk is

Achtergrond

Het is belangrijk dat u optimale testresultaten behaalt tijdens het uitvoeren van softwaretesten zonder af te wijken van het doel. Maar hoe bepaalt u of u de juiste strategie voor testen volgt? Daarvoor moet u zich houden aan een aantal basisprincipes voor testen. Hier zijn de zeven algemene testprincipes die veel worden toegepast in de software-industrie.

Om dit te begrijpen, kunt u een scenario overwegen waarin u een bestand van map A naar map B verplaatst.

Bedenk alle mogelijke manieren waarop je dit kunt testen.

Naast de gebruikelijke scenario's kunt u ook de volgende omstandigheden testen

• Er wordt geprobeerd het bestand te verplaatsen terwijl het geopend is
• U beschikt niet over de beveiligingsrechten om het bestand in map B te plakken
• Map B staat op een gedeelde schijf en de opslagcapaciteit is vol.
• Map B heeft al een bestand met dezelfde naam, sterker nog, de lijst is eindeloos
• Of stel dat u 15 invoervelden heeft om te testen, elk met 5 mogelijke waarden, dan zou het aantal te testen combinaties 5^15 zijn.

Als je alle mogelijke combinaties van het project zou testen, zouden de UITVOERINGSTIJD & KOSTEN exponentieel stijgen. We hebben bepaalde principes en strategieën nodig om de testinspanningen te optimaliseren

Dit zijn de 7 principes:

1) Uitputtend testen is niet mogelijk

Ja! Uitputtend testen is niet mogelijk. In plaats daarvan hebben we de optimale hoeveelheid tests nodig op basis van de risicobeoordeling van de toepassing.

En de vraag van een miljoen dollar is: hoe bepaal je dit risico?

Om dit te beantwoorden, gaan we een oefening doen

Welke operatie is volgens u het meest waarschijnlijk de oorzaak van uw Operasysteem mislukt?

Ik ben er zeker van dat de meesten van jullie het al geraden hadden: 10 verschillende applicaties tegelijkertijd openen.

Dus als je dit zou testen OperaAls je een systeem gebruikt, zou je je realiseren dat er waarschijnlijk fouten worden aangetroffen bij multitasking-activiteiten en dat deze grondig moeten worden getest, wat ons bij ons volgende principe brengt Defect ClusterING

2) Defect ClusterING

Defect Clustering waarin staat dat een klein aantal modules de meeste gedetecteerde defecten bevat. Dit is de toepassing van het Pareto-principe op het testen van software: ongeveer 80% van de problemen wordt in 20% van de modules aangetroffen.

Uit ervaring kunt u dergelijke risicovolle modules identificeren. Maar deze aanpak heeft zijn eigen problemen

Als dezelfde tests keer op keer worden herhaald, zullen dezelfde testgevallen uiteindelijk geen nieuwe bugs meer vinden.

3) Pesticidenparadox

Herhaaldelijk gebruik van hetzelfde mengsel van pesticiden om insecten uit te roeien tijdens de landbouw zal er na verloop van tijd toe leiden dat de insecten resistentie tegen het pesticide ontwikkelen. Daardoor zijn pesticiden niet effectief op insecten. Hetzelfde geldt voor het testen van software. Als dezelfde reeks herhaalde tests wordt uitgevoerd, zal de methode nutteloos zijn voor het ontdekken van nieuwe defecten.

Om dit te ondervangen, moeten de testgevallen regelmatig worden beoordeeld en herzien, waarbij nieuwe en verschillende testgevallen worden toegevoegd om meer defecten te helpen vinden.

Testers kunnen niet zomaar vertrouwen op bestaande testtechnieken. Hij moet voortdurend uitkijken naar het verbeteren van de bestaande methoden om het testen effectiever te maken. Maar zelfs na al dit zweet en harde testwerk kun je nooit beweren dat je product vrij van bugs is. Laten we, om dit punt duidelijk te maken, deze video bekijken van de publieke lancering van Windows 98

Denk je dat een bedrijf als MICROSOFT zijn besturingssysteem niet grondig heeft getest en zijn reputatie op het spel heeft gezet, alleen maar om te zien dat zijn besturingssysteem crasht tijdens de publieke lancering?

4) Testen tonen de aanwezigheid van defecten aan

Het testprincipe stelt dus dat – bij testen wordt gesproken over de aanwezigheid van defecten en niet over de afwezigheid van defecten. Software testen vermindert de kans dat onontdekte defecten in de software achterblijven, maar zelfs als er geen defecten worden gevonden, is dit geen bewijs van juistheid.

Maar wat als u extra hard werkt, alle voorzorgsmaatregelen neemt en uw softwareproduct 99% bugvrij maakt? En de software voldoet niet aan de wensen en eisen van de klanten.

Dit brengt ons bij ons volgende principe, dat luidt: afwezigheid van fouten

5) Afwezigheid van fouten – misvatting

Het is mogelijk dat software die voor 99% bugvrij is, nog steeds onbruikbaar is. Dit kan het geval zijn als het systeem grondig wordt getest op de verkeerde eis. Bij het testen van software gaat het niet alleen om het vinden van defecten, maar ook om te controleren of de software voldoet aan de bedrijfsbehoeften. De afwezigheid van fouten is een denkfout, dat wil zeggen dat het vinden en repareren van defecten niet helpt als de systeembuild onbruikbaar is en niet voldoet aan de behoeften en eisen van de gebruiker.

Om dit probleem op te lossen, luidt het volgende testprincipe: Early Testing

6) Vroeg testen

Vroeg testen – Testen moet zo vroeg mogelijk in de softwareontwikkelingslevenscyclus beginnen. Zodat eventuele defecten in de vereisten of ontwerpfase in een vroeg stadium worden vastgelegd. Het is veel goedkoper om een ​​defect in een vroeg stadium van testen te verhelpen. Maar hoe vroeg moet men beginnen met testen? Het wordt aanbevolen om de bug te vinden op het moment dat de vereisten zijn gedefinieerd. Meer over dit principe in een latere trainingstutorial.

7) Testen is contextafhankelijk

Testen is contextafhankelijk, wat in feite betekent dat de manier waarop u een e-commercesite test, anders zal zijn dan de manier waarop u een kant-en-klare commerciële toepassing test. Niet alle ontwikkelde software is identiek. Afhankelijk van het toepassingstype kunt u een andere aanpak, methodologieën, technieken en soorten testen gebruiken. Testen: elk kassasysteem in een winkel zal anders zijn dan het testen van een geldautomaat.

Mythe: “Principes dienen alleen ter referentie. In de praktijk zal ik ze niet gebruiken.”

Dit is zo ontzettend onwaar. Testprincipes helpen u bij het creëren van een effectief Teststrategie en concept-foutopsporingstestgevallen.

Maar het leren van testprincipes is net als voor de eerste keer leren autorijden.

In het begin, terwijl je leert autorijden, besteed je aandacht aan alles, zoals schakelen, snelheid, koppelingsbediening, etc. Maar met de ervaring concentreer je je alleen op het rijden, de rest komt vanzelf. Zodanig dat je zelfs gesprekken voert met andere passagiers in de auto.

Hetzelfde geldt voor testprincipes. Ervaren testers hebben deze principes zo geïnternaliseerd dat ze ze zelfs zonder na te denken toepassen. De mythe dat de principes in de praktijk niet worden toegepast, is dus eenvoudigweg niet waar.