test scenario vs test case
Verschil tussen testscenario en testcase.
6 jaar geleden Toen ik met een middelgrote MNC werkte, toen ik voorstelde om testscenario's te documenteren in plaats van tijd te verspillen aan het voorbereiden van het volledige bewijsdocument, testgevallen genaamd, wendden alle hoofden zich geërgerd naar mij.
De blik op de gezichten maakte duidelijk dat ik een grote fout had gemaakt door het te suggereren. Hoewel niemand het idee ontkende, accepteerde niemand het zelfs. Iedereen was van mening dat het volgen van de traditie, d.w.z. het schrijven van testcase-documenten, veiliger zou zijn. Ik kon niet tegenspreken.
Na 4 jaar ontving het bedrijf een testproject, waarbij de enige beperking de tijd was en de enige verwachting volledig bewijs was testen.
We waren weer in de vergadering en bespraken ideeën om de kritische deadline te halen. De applicatie ging vooral over het zoeken en genereren van verschillende rapporten via verschillende menu-items. Het documenteren van testcases moest het grootste deel van de tijd rukken en we wisten niet zeker hoeveel het document voor de klant zou gebruiken.
Ik stelde voor om testscenario's te documenteren en op de een of andere manier was iedereen het met enige aarzeling eens. We hoeven niet te vermelden dat we kostbare documentatietijd kunnen besparen en deze kunnen gebruiken voor testen.
Wat je leert:
- Worden testcases snel vervangen door testscenario's?
- Wanneer is documentatie van testcases belangrijk?
- Verschillen tussen testscenario en testcase in tabelvorm
- Gevolgtrekking
- Aanbevolen literatuur
Worden testcases snel vervangen door testscenario's?
Met de tijd, terwijl alles aan het veranderen is, zijn de software-industrie en -processen ook veel veranderd.
c # technische interviewvragen en antwoorden
Traditioneel Waterval en V-modellen worden vervangen door agile en iteratieve modellen. Documentatie is noodzakelijk maar om deadlines te halen en het proces eenvoudig en transparant te maken, kan de manier van documenteren worden gewijzigd.
Wanneer is documentatie van testcases belangrijk?
- De opdrachtgever heeft hetzelfde gevraagd als onderdeel van het project.
- Er is geen tijdsdruk (ik denk niet dat het mogelijk is).
- Testers zijn frisser of onbekend voor het product.
- Bedrijfsbeleid (ik ben er sterk van overtuigd dat het kan worden gewijzigd).
Laat me een ervaring met je delen:
Ik en mijn team waren betrokken bij het testen van een project van een Fortune 500-bedrijf met flexibele tijdlijnen. We hebben testcases gedocumenteerd met de best beschikbare sjabloon en deze laten goedkeuren door de klant.
Toen de build eenmaal begon vrij te geven aan het QA-team, was het onze taak gedurende het grootste deel van de dag om 100 testcases per dag mechanisch te volgen, het document bij te werken met het resultaat geslaagd / mislukt en het aan het einde van de dag naar de klant te sturen. Meeste van de teamleden begonnen te klagen eentonig werk maar het bedrijf genereerde inkomsten.
Daarna was er een pauze van een dag tussendoor zonder nieuwbouw om te testen. We zaten aan het begin van de dag samen en bespraken wat we die dag gingen doen. Toen ik voorstelde om meer ideeën te genereren om het testcase-document te verbeteren, ontkenden alle teamleden hun inspanningen.
Volgens hen was er niets meer om over na te denken, aangezien we alle scenario's hadden behandeld. En hen ervan te overtuigen denk out of a box en genereer meer ideeën was echt moeilijk.
Meestal, wanneer we testgevallen documenteren en ook dat eenmaal goedgekeurd door de klant, denkt die menselijke geest dat we ons werk hebben gedaan en onze geest stopt automatisch met het overwegen van elke poging om na te denken over andere manieren om het product te testen.
En geloof me, wanneer het testcases-document wordt opgesteld, willen we het gewoon mechanisch volgen. Vertel me hoe vaak je in je carrière hebt meegemaakt dat jij of de teamgenoot aanvullende testcases aanbood bij het goedgekeurde testcases-document?
Nog een ervaring:
youtube naar mp3 converter met tag-editor
Tijdens de wekelijkse teamuitdagingsactiviteit hebben we de applicatie aangekondigd en de teamleden gevraagd om testscenario's in te gieten.
Alle teamleden, inclusief de late responders of non-responders, hebben ideeën ingebracht. Waarom? Er was geen formele documentatie waarin ze het verwachte resultaat moesten invullen voor elke reeks functionaliteit en randvoorwaarden voor elke testcase. We verzamelden 40 testscenario's op een dag en dat was een geweldige ervaring.
Om mijn ervaring te bevorderen, Ik zou graag een voorbeeld willen geven.
Neem een voorbeeldtoepassing, bijvoorbeeld inlogpagina met gebruikersnaam, wachtwoord, login en annuleerknoppen. Als we gevraagd worden om testcases voor hetzelfde te schrijven, zullen we uiteindelijk meer dan 50 testcases schrijven door verschillende opties en details te combineren.
Maar als testscenario's moeten worden geschreven, is het een kwestie van 10 regels, zoals hieronder:
Scenario op hoog niveau: Login-functionaliteit
Scenario's op laag niveau
1. Om te controleren of de toepassing wordt gestart
2. Om de tekstinhoud op de aanmeldingspagina te controleren
3. Om het veld Gebruikersnaam te controleren
4. Om het veld Wachtwoord te controleren
5. Om de login-knop en de knopfunctionaliteit te annuleren
Zie ook 180+ voorbeeldtestscenario's voor het testen van web- en desktoptoepassingen.
Omdat we allemaal weinig tijd hebben, werken testscenario's als pijnstillers in plaats van die oude IODEX. En toch is het effect hetzelfde.
Verschillen tussen testscenario en testcase in tabelvorm
Ten slotte wil ik het verschil tussen testscenario en testgeval samenvatten:
| Testgevallen | Testscenario's | |
|---|---|---|
| Wat het is => | Een concept dat gedetailleerde informatie geeft over wat er moet worden getest, de te nemen stappen en het verwachte resultaat daarvan | Een concept dat in één regel informatie geeft over wat u moet testen. |
| Het gaat over => | Het gaat meer over het documenteren van details. | Het gaat meer over het nadenken en bespreken van details. |
| Belang => | Het is belangrijk wanneer het testen offshored is en de ontwikkeling op locatie plaatsvindt. Het schrijven van testcases met details helpt zowel het ontwikkel- als het QA-team te synchroniseren. | Het is belangrijk wanneer de tijd minder is en de meeste teamleden de details van het oneliner-scenario eens kunnen worden / begrijpen. |
| Voordeel => | Eenmalige documentatie van alle testgevallen is nuttig om in de toekomst duizenden ronden van regressietesten te volgen. Meestal is het handig tijdens het rapporteren van bugs. De tester hoeft alleen maar een referentie van de testcase-ID op te geven en hoeft niet elk detail te vermelden. | Een tijdbesparende activiteit en het genereren van ideeën, waaraan de voorkeur wordt gegeven door de nieuwe generatie softwaretestgemeenschap. Wijziging en toevoeging is eenvoudig en niet specifiek voor een persoon. Voor een enorm project, waarbij een groep mensen alleen specifieke modules kent, geeft deze activiteit iedereen de kans om naar andere modules en brainstorm te kijken en te discussiëren |
| Gunstig voor => | Een volledig proof testcase-document is een levenslijn voor een nieuwe tester. | Een goede testdekking kan worden bereikt door de applicatie in testscenario's te verdelen en het vermindert de herhaalbaarheid en complexiteit van het product |
| Nadeel => | Tijd- en geldverslindend omdat er meer middelen nodig zijn om alles uit te leggen over wat u moet testen en hoe u moet testen | Indien gemaakt door een specifieke persoon, synchroniseert de recensent of de andere gebruiker mogelijk niet het exacte idee erachter. Meer discussies en teaminspanningen nodig. |
Gevolgtrekking
Testcases zijn het belangrijkste onderdeel van de levenscyclus van softwareontwikkeling en zonder deze is het moeilijk om iets op te sporen, te begrijpen, te volgen en te beredeneren. Maar in het tijdperk van Agile worden testcases snel vervangen door testscenario's.
Een gewone test checklist voor elk type testen (databasetests, GUI-tests, functionaliteitstests, enz.) In combinatie met testscenario's is de moderne artillerie voor softwaretesters. Discussies, training, vragen en oefenen kunnen de uiteindelijke grafiek van zeker veranderen uw productiviteit evenals een bugrapportmatrix.
Zoals gewoonlijk verwelkomen we uw mening en vragen. Stem af.
PREV-zelfstudie VOLGENDE zelfstudie
Aanbevolen literatuur
- Verschil tussen testplan, teststrategie, testcase, testscript, testscenario en testconditie
- Soorten softwaretests: verschillende testtypen met details
- Testcases schrijven: de ultieme gids met voorbeelden
- SRS-document bekijken en testscenario's maken - Training voor softwaretests voor een live project - Dag 2
- Hoe positieve en negatieve testscenario's te classificeren - een cheatsheet voor testers
- Prestatietests versus belastingtests versus stresstests (verschil)
- Statisch testen en dynamisch testen - Verschil tussen deze twee belangrijke testtechnieken
- 101 Verschillen tussen de basisprincipes van softwaretests