Deze tutorial introduceert de zeven basissoftwaretestprincipes die elke softwaretester en QA-professional zou moeten kennen.
7 principes van softwaretests
- Testen toont de aanwezigheid van defecten aan
- Uitputtend testen is niet mogelijk
- Vroege testen
- Defecte clustering
- Paradox van pesticiden
- Testen is contextafhankelijk
- Afwezigheid van dwalingen
Laten we de testprincipes leren met het volgende videovoorbeeld-
Klik hier als de video niet toegankelijk is
Achtergrond
Het is belangrijk dat u tijdens het uitvoeren van softwaretests optimale testresultaten behaalt zonder van het doel af te wijken. Maar hoe bepaal je dat je de juiste teststrategie volgt? Daarvoor moet u zich houden aan enkele basisprincipes van testen. Hier zijn de zeven algemene testprincipes die op grote schaal worden toegepast in de software-industrie.
Om dit te begrijpen, moet u een scenario overwegen waarin u een bestand van map A naar map B verplaatst.
Bedenk alle mogelijke manieren waarop u dit kunt testen.
Naast de gebruikelijke scenario's kunt u ook de volgende condities testen
- Probeer het bestand te verplaatsen wanneer het is geopend
- 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, in feite is de lijst eindeloos
- Of stel dat u 15 invoervelden heeft om te testen, elk met 5 mogelijke waarden, dan is het aantal te testen combinaties 5 15
Als je alle mogelijke combinaties zou testen, zou het project UITVOERINGSTIJD & KOSTEN exponentieel stijgen. We hebben bepaalde principes en strategieën nodig om de testinspanning te optimaliseren
Hier zijn de 7 principes:
1) Uitputtend testen is niet mogelijk
Ja! Uitputtend testen is niet mogelijk. In plaats daarvan hebben we de optimale hoeveelheid testen nodig op basis van de risicobeoordeling van de applicatie.
En de vraag van een miljoen dollar is: hoe bepaal je dit risico?
Laten we om dit te beantwoorden een oefening doen
Welke bewerking zal er naar uw mening waarschijnlijk het falen van uw besturingssysteem veroorzaken?
Ik weet zeker dat de meesten van jullie zouden hebben geraden, het openen van 10 verschillende applicaties tegelijkertijd.
Dus als u dit besturingssysteem zou testen, zou u zich realiseren dat defecten waarschijnlijk worden gevonden in multi-tasking-activiteiten en grondig moeten worden getest, wat ons bij ons volgende principe van Defect Clustering brengt
2) Clustering van defecten
Defect Clustering waarin staat dat een klein aantal modules de meeste van de gedetecteerde defecten bevat. Dit is de toepassing van het Pareto-principe op het testen van software: ongeveer 80% van de problemen komt voor in 20% van de modules.
Door ervaring kunt u dergelijke risicovolle modules identificeren. Maar deze benadering heeft zijn eigen problemen
Als dezelfde tests keer op keer worden herhaald, zullen uiteindelijk dezelfde testgevallen geen nieuwe bugs meer vinden.
3) Pesticidenparadox
Herhaaldelijk gebruik van hetzelfde pesticidenmengsel om insecten tijdens de landbouw uit te roeien, 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, is de methode onbruikbaar om nieuwe defecten te ontdekken.
Om dit te verhelpen, moeten de testcases regelmatig worden beoordeeld en herzien, waarbij nieuwe en verschillende testcases moeten worden toegevoegd om meer defecten te helpen vinden.
Testers kunnen niet simpelweg afhangen van bestaande testtechnieken. Hij moet voortdurend op zoek zijn naar verbetering van de bestaande methoden om het testen effectiever te maken. Maar zelfs na al dit zweet en harde werk tijdens het testen, kunt u nooit beweren dat uw product geen fouten bevat. Laten we, om op dit punt naar huis te rijden, deze video bekijken van de openbare lancering van Windows 98
U denkt dat een bedrijf als MICROSOFT zijn besturingssysteem niet grondig zou hebben getest en zijn reputatie zou riskeren als zijn besturingssysteem crashte tijdens de openbare lancering!
4) Testen toont de aanwezigheid van defecten aan
Daarom stelt het testprincipe dat - Testen spreekt over de aanwezigheid van defecten en niet over de afwezigheid van defecten. Dat wil zeggen dat softwaretests de kans verkleinen dat er nog niet ontdekte defecten in de software achterblijven, maar zelfs als er geen defecten worden gevonden, is het geen bewijs van juistheid.
Maar wat als u extra hard werkt, alle voorzorgsmaatregelen neemt en uw softwareproduct 99% foutvrij maakt? En de software voldoet niet aan de wensen en eisen van de klanten.
Dit leidt ons naar ons volgende principe, dat stelt dat: afwezigheid van dwaling
5) Afwezigheid van fouten - denkfout
Het is mogelijk dat software die 99% bugvrij is, nog steeds onbruikbaar is. Dit kan het geval zijn als het systeem grondig wordt getest op de verkeerde eis. Softwaretests zijn niet alleen het vinden van defecten, maar ook om te controleren of de software aansluit op de zakelijke behoeften. De afwezigheid van een fout is een misvatting, dwz het vinden en repareren van defecten helpt niet als de systeembouw onbruikbaar is en niet voldoet aan de behoeften en vereisten van de gebruiker.
Om dit probleem op te lossen, stelt het volgende testprincipe dat Early Testing
6) Vroege testen
Vroege testen - Het testen moet zo vroeg mogelijk in de levenscyclus van softwareontwikkeling beginnen. Zodat eventuele defecten in de eisen of ontwerpfase in een vroeg stadium worden opgevangen. Het is veel goedkoper om een defect in de vroege teststadia op te lossen. Maar hoe vroeg moet men beginnen met testen? Het wordt aanbevolen dat u begint met het vinden van de bug op het moment dat de vereisten zijn gedefinieerd. Meer over dit principe in een latere trainingshandleiding.
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 commerciële standaardtoepassing test. Alle ontwikkelde software is niet identiek. U kunt een andere benadering, methodologieën, technieken en soorten testen gebruiken, afhankelijk van het type toepassing. Bijvoorbeeld, elk kassasysteem in een winkel zal anders zijn dan het testen van een geldautomaat.
Mythe: "Principes zijn alleen ter referentie. Ik zal ze in de praktijk niet gebruiken."
Dit is zo erg niet waar. Test Principles helpen u bij het creëren van een effectieve teststrategie en het opstellen van testcases om fouten op te sporen.
Maar het leren van testprincipes is net als voor het eerst leren autorijden.
In eerste instantie, terwijl je leert rijden, let je op alles, zoals schakelen, snelheid, koppeling, enz. Maar met ervaring concentreer je je gewoon 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. Vandaar dat de mythe dat de principes in de praktijk niet worden gebruikt, simpelweg niet waar is.