Defect Life Cycle - Zoals u misschien al weet, is het uitvoeren van tests de fase waarin de tester de testscripts daadwerkelijk uitvoert. Het proces van uitvoering van testscripts varieert van bedrijf tot bedrijf en kan ook verschillen in verschillende projecten binnen hetzelfde bedrijf.
Tegenwoordig zijn er tools beschikbaar voor het uitvoeren van tests, tools zoals - Quality Center, Microsoft Visual Studio enzovoort. Het daadwerkelijke uitvoeringsproces van het uitvoeren van elke stap om het werkelijke en verwachte resultaat te vergelijken, blijft hetzelfde voor de functionele tester, ongeacht de gebruikte tools.
- Wat als het werkelijke gedrag niet gelijk is aan het verwachte gedrag?
Wanneer een tester vindt dat het werkelijke testresultaat niet gelijk is aan het verwachte resultaat, wordt een defect vastgelegd.
- Hoe een defect te loggen?
Tegenwoordig zijn er veel tools beschikbaar, sommige van de defect-logging tools zijn ClearQuest van IBM, HP's Quality Center, open source tools zoals defect life cycle in JIRA enzovoort.
Er zijn enkele verplichte velden die veel voorkomen in de verschillende tools voor het registreren van defecten, deze velden zijn -
- Defect levenscyclus Beschrijving
- Defect levenscyclus Samenvatting
- Defect aangemeld door
- Defect toegewezen aan
- Defect Ernst
- Prioriteit defect
- Aanvullende snapshots
- Nummer / naam vrijgeven
Defecte levenscyclus
Defect Levenscyclus begint met het registreren van een nieuw defect. Wanneer een defect wordt vastgelegd, bevindt het zich in de status "Nieuw".
Tester - Nieuw defect
Aan wie moet een nieuw defect worden toegewezen?
Een tester kan een defect toewijzen aan een ontwikkelaar of een ontwikkelingsleider. Deze beslissing tot toewijzing van defecten varieert van project tot project. Op sommige werkplekken is er een defectlevenscyclusproces om het rechtstreeks toe te wijzen aan een respectieve ontwikkelaar en op sommige plaatsen wordt het defect eerst toegewezen aan een dev-lead en wijst de dev-lead het op zijn beurt toe aan een ontwikkelaar.
Defect Assignment (New) - Defect Life Cycle Developer
Defect Assignment (New) - Dev Leadà Developer
Defectanalyse
De ontwikkelaar analyseert het defect om te controleren of het reproduceerbaar is. Hier is de belangrijkste bijdrage van de tester het opnemen van alle noodzakelijke details in het defect. Defectoverzicht, Defect gedetailleerde beschrijving zijn de velden die de stakeholders helpen om het defect in één keer te begrijpen. Defectoverzicht mag altijd alleen de informatie op hoog niveau van het defect bevatten. Tegelijkertijd moet het voldoende informatie hebben om het overzicht van het defect in één regel te beschrijven.
Defectbeschrijving is de plaats waar van tester wordt verwacht dat het alle benodigde informatie bevat, zoals Omgeving, Scenario, Gebruikte testgegevens, Verwacht resultaat, Werkelijk resultaat, Verwijzing naar bestanden / gegevens en verwijzing naar momentopname.
Hier is het korte overzicht van verschillende elementen van Defect Gedetailleerde beschrijving -
Milieu
Testomgeving waarin het defect is gevonden. Vaak hebben projecten meerdere testomgevingen waarin het testteam tests uitvoert. Bijvoorbeeld - AT (testomgeving voor assemblage), PT (omgeving voor producttests), UAT (testomgeving voor gebruikersacceptatie), enzovoort. Het doel van verschillende omgevingen is dat het binnen het ontwikkel- en testteam flexibiliteit biedt om de code in een van de beschikbare omgevingen te implementeren om de tests op tijd te starten.
Er zijn momenten waarop de Producttest (ook wel systeemtest genoemd) en UAT-testen elkaar overlappen, dus het hebben van meerdere omgevingen is een must om parallel te kunnen blijven testen.
Er zijn gevallen waarin het ontwikkelteam een extra omgeving nodig heeft om de door het testteam gemelde problemen op te lossen. Ook heeft het ontwikkelteam een speciale omgeving voor het testen van eenheden.
Daarom moet met meerdere omgevingen in het defect een bepaalde omgeving worden vermeld waarin het probleem is gevonden.
Scenario
Scenario is de reeks door de tester uitgevoerde stappen die tot een defect hebben geleid. Hier wordt van een tester verwacht dat hij alle stappen vermeldt die de ontwikkelaar kan uitvoeren om het defect te reproduceren. Vaak zijn er momenten waarop het defect door de tester wordt gemeld, maar de ontwikkelaar niet in staat is om hetzelfde te repliceren en daarom wordt het defect afgewezen. Dit kan gebeuren vanwege onjuiste stappen / ontbrekende stappen die in de beschrijving worden vermeld. Duidelijke stappen helpen iedereen om het defect te begrijpen en te repliceren zonder afhankelijk te zijn van een tester om input te krijgen. Een goed gedocumenteerd scenario heeft eenvoudig te lezen, gemakkelijk te begrijpen en precieze stappen die moeten worden gevolgd om het defect te repliceren.
Testgegevens
Een tester zou de gegevens moeten vermelden die zijn gebruikt tijdens de teststroom die tot een probleem heeft geleid. Deze informatie geeft ontwikkelaar de kans om vergelijkbare gegevens te gebruiken om het defect te reproduceren en de oorzaak hiervan te achterhalen.
Er zijn enkele scenario's waarin een tester een defect vindt met behulp van specifieke gegevens, maar hetzelfde probleem is niet reproduceerbaar met vergelijkbare gegevens. Dit kan gebeuren als gevolg van gegevensbeschadiging, dus het invoeren van gegevens geeft een kans om de oorzaak van het defect te achterhalen. Een ontwikkelaar graaft mogelijk niet naar codeniveau als datacorruptie het geval is. Dit soort defect kan worden omgezet in datafout.
Verwacht en feitelijk resultaat
Dit is het hoogtepunt van een gedetailleerd beschrijvingsveld waarbij een tester bewijst dat de aangetroffen fout inderdaad een defect is. Door het verwachte resultaat duidelijk te vermelden, wordt het voor elke stakeholder duidelijk dat de fout als een defect wordt beschouwd. Stel je voor dat een defect is vastgelegd met alle details, maar het geeft niet de verwachte uitkomst van het scenario aan!
Gewoonlijk voert een tester alleen het verwachte resultaat in een lijn of twee in, maar het is heel belangrijk om de bron van het verwachte resultaat te vermelden. Bron hier verwijzing naar het document waar het verwachte resultaat wordt vermeld. Dit kan een document met vereisten of een storyboardreferentie zijn.
Verwijzing naar bestanden / gegevens
Soms is het defect het genereren van een bestand of invoer als een bestand. In dit soort scenario's wordt verondersteld dat tester informatie geeft over het bestand dat is gebruikt en dat het probleem in de toepassing heeft veroorzaakt. Deze bestanden kunnen worden bijgevoegd met behulp van het defectbeheertool of de referentie hiervoor kan worden verstrekt. Deze referentielocaties moeten toegankelijk zijn voor alle belanghebbenden.
Verwijzing naar momentopname
Momentopnames spelen een zeer belangrijke rol wanneer u hen het exacte foutbericht voor pagina-einde wilt laten zien zoals weergegeven op het scherm of wanneer u de details van de schermnavigatie wilt tonen. Snapshot geeft snel een idee over het aangetroffen defect, het scherm waarop het defect is gevonden, gegevens die op het scherm zijn gebruikt, enzovoort. Elke defectbeheertool heeft voorzieningen om de snapshots te koppelen. Soms voegt Tester ook de Excel-spreadsheets of Word-documenten toe.
Dit waren de verschillende componenten van defectregistratie en best practices voor elk daarvan. Terugkomend op de defectlevenscyclus, zodra het defect is toegewezen aan een ontwikkelaar, zal hij / zij het analyseren met behulp van de gegevens in het defect-item. Als volgens de analyse het geregistreerde probleem inderdaad een defect is, zal de ontwikkelaar het defect "openen" om aan de oplossing te werken.
Aanbevolen cursussen
- Webservices in Java-trainingsbundel
- Training over spelontwikkeling in C ++
- Voltooi ethische hacktraining
- Vegas Pro 13 Trainingscursussen
Nieuw - Openen
Een defect in de Open-status geeft aan dat deze zich in de ontwikkelingsplaat bevindt en dat de ontwikkelaars aan de oplossing werken. In het geval dat uit de analyse blijkt dat het gelogde probleem geen defect is, kan dit gebeuren wanneer er een gebrek aan inzicht is in het verwachte gedrag van het systeem. Als de analyse zegt dat het defect ongeldig is, zal de ontwikkelaar het defect weigeren. Terminologie is "Geweigerd" of "Terug naar testen".
Nieuw - Terug naar testen.
Hoe tester moet valideren of het defect inderdaad een ongeldig defect was?
Dit is het scenario waarin een nauwkeurig document met vereisten iedereen in het team helpt om tot de conclusie te komen of het gelogde defect ongeldig of geldig was. Verwijzen naar vereiste documenten helpt zowel tester als ontwikkelaar tot dezelfde conclusie te komen en vergemakkelijkt het discussieproces.
Er zijn scenario's waarin de juistheid van ontwerp- en vereiste documenten in twijfel wordt getrokken terwijl deze documenten worden doorverwezen in tijden van discussies over defecten. Op zulke momenten wordt teruggaan naar Business Analyst beschouwd als de beste optie om de vragen te verduidelijken.
Als best practice moeten vereisten- en ontwerpdocumenten altijd up-to-date zijn om ze zonder dubbelzinnigheid door te verwijzen.
In de status "Open" werkt het ontwikkelingsteam aan het oplossen van het defect. Zodra het defect is verholpen, verandert de status in "Gereed voor implementatie".
Open - klaar voor implementatie
Implementatie is het proces waarbij de wijzigingen worden geüpload naar de server zodat het testteam kan werken aan de vaste versie van de code. Gewoonlijk heeft elk project een afzonderlijk implementatieteam voor deze taak.
Dus op hoog niveau bestaat een softwareteam voornamelijk uit deze 3 groepen -
- Ontwikkeling
- Defecte levenscyclus bij testen
- Implementatie (of soms aangeduid als Build-team)
Nadat de build is geïmplementeerd en het defect weer beschikbaar is voor hertesting, wordt het toegewezen aan een geschikte tester voor de hertesttaak.
Defect toegewezen aan - testkabel.
Testleiding - Individueel testapparaat.
Defect toegewezen - Individueel testapparaat.
Op sommige werkplekken wordt het defect eerst toegewezen aan de testleiding en hij / zij wijst het op zijn beurt toe aan de individuele tester, maar op sommige plaatsen wordt het defect direct toegewezen aan de tester die het zou testen of degene die het defect had veroorzaakt.
De status verandert hier van Gereed voor implementatie - Ready SIT Testing.
Nu zit het defect in de plaat van de tester. Het testteam zal het defect valideren en er zijn 2 mogelijkheden, ofwel de fix zou correct werken of hetzelfde probleem wordt opnieuw aangetroffen. Afhankelijk van de uitkomst kan het defect naar de volgende statussen gaan -
Ready SIT Testing - Gesloten
Ready SIT Testing - Opnieuw openen
In beide bovenstaande scenario is tester vereist om de opmerkingen van uitgevoerde tests toe te voegen. Dit omvat het vermelden van de geteste scenario's en de gebruikte gegevens. Als het defect opnieuw wordt geopend, moet de tester de exacte stappen uitvoeren die opnieuw tot de fout hebben geleid.
De status Heropenen is hetzelfde als de status "Nieuw" defect.
Nadat het defect opnieuw is geopend, volgt het dezelfde cyclus opnieuw.
Defecte levenscyclusuitdagingen
- Beslissen over de ernst van defecten - dit is een van de meest voorkomende onderwerpen van discussie (vaak gevechten) tussen ontwikkelaars van testers en v / s.
- Defect is niet reproduceerbaar op het systeem van de ontwikkelaar.
- Gebrek aan de orde in het scenario dat niet wordt genoemd in vereisten en ontwerpdocumenten.
- Er is een defect gevonden, maar hetzelfde kan niet worden opgeworpen omdat het optreden van het scenario in de productieomgeving niet haalbaar is.
Hoe moet een tester bovenstaande uitdagingen overwinnen?
- De ernst is recht evenredig met de impact die het defect op de toepassing veroorzaakt, als de tester niet kan doorgaan vanwege het defect, is dit zeker gemarkeerd met de hoogste ernst.
- Als er een oplossing bestaat om door te gaan met testen, moet deze worden gemarkeerd als gemiddelde ernst. Naast het overwegen van de impact van verdere testen van de defectlevenscyclus, kan de ernst ook worden bepaald, rekening houdend met de situatie waarin een volledige module faalt, in dit geval hoewel het testen van een andere module kan worden uitgevoerd maar de ernst van de huidige module hoog is dus het defect moet worden gemarkeerd met de hoogste ernst.
- Als een defect niet reproduceerbaar is op het systeem van de ontwikkelaar, is er een kans dat de ontwikkel- en testomgeving niet synchroon lopen. Een op het testsysteem reproduceerbaar defect wordt altijd als een geldig defect beschouwd.
- Er zijn situaties waarin een defect wordt vastgelegd, rekening houdend met het algemene bedrijfsscenario, maar het directe scenario wordt niet vermeld in de vereisten of het ontwerpdocument. Het wordt altijd als een best practice beschouwd om de werkelijke bedrijfsscenario's te overwegen in plaats van alleen de teststappen te volgen. Communicatie met bedrijfsanalisten en andere stakeholders van producten speelt een belangrijke rol om dergelijke defecten te registreren.
- Er zijn scenario's waarin een tester een gat in de bedrijfslogica ontdekt tijdens de testfase. Het vinden van dergelijke hiaten wordt opnieuw als een groot pluspunt voor een tester beschouwd. Ontwerphiaten worden meestal afgehandeld via verbeteringen.
- Verbetering - Als een gedrag tijdens de testfase van de levenscyclus van de software moet worden gewijzigd, wordt een verbetering gemaakt die in de huidige of volgende release kan worden genomen, rekening houdend met de tijdlijnen en bandbreedte van de ontwikkelingsteams en testteams.
- Er zijn enkele scenario's die een tester zou kunnen testen tijdens ad-hoc testen, wat eigenlijk de ongeldige scenario's kunnen zijn, gezien de mogelijkheid dat ze in de productie voorkomen.
Wie is de beste vriend van tester?
Waar moet een tester naartoe gaan in geval van dubbelzinnigheid? Het antwoord hangt af van het type vraag, als een vraag betrekking heeft op de vereisten, is het raadzaam om eerst binnen het team te bespreken om te begrijpen of het systeem correct is, door senior leden te raadplegen. Het volgende aanspreekpunt moeten bedrijfsanalisten zijn.
Als de vraag betrekking heeft op het testproces, is het raadzaam contact op te nemen met de testleider of testmanager.
Als de vraag betrekking heeft op het begrijpen van de technische details van de applicatie, kan het lid van het ontwikkelteam de juiste persoon zijn om naar toe te gaan.
Aangezien testen een proces is dat een algemeen begrip van het systeem vereist, helpt communicatie een tester om snel antwoord te krijgen op de vragen, het hangt er gewoon van af om de juiste vragen te stellen aan de juiste personen. Als u niet op het juiste moment vragen stelt, kan dit leiden tot een defect in de productieomgeving.
Hoe belangrijk is de rol van een tester vandaag in het bedrijf?
Er zijn projecten waarbij het testteam even belangrijk is als het ontwikkelteam en in sommige scenario's is er meer afhankelijkheid van het testteam dan van het ontwikkelteam. Het latere scenario is zeldzaam, maar het bestaat op sommige werkplekken. Dit is in de loop van de tijd gebeurd en kan voor een specifieke periode zijn waarin het ontwikkelteam niet veel ervaring heeft in vergelijking met het testteam. Er zijn mensen die de algehele flow en functionaliteit beter begrijpen dan de meeste andere teamleden. Zo'n persoon kan deel uitmaken van een test- / ontwikkelingsteam. Dit is een van de factoren die de afhankelijkheid van een team / individu voor het specifieke project bepaalt.
Wat is het carrièrepad voor een tester?
Een individu kan enige tijd nodig hebben om het algehele testproces, domein en andere taken te begrijpen waaraan hij / zij in het dagelijks leven wordt geacht te werken. Op basis van dit inzicht is het raadzaam om een beslissing te nemen om verdere gebieden te verkennen die een tester zou kunnen oppakken. Er zijn altijd kansen in het proces om verschillende stromen te automatiseren. Het creëren van kleine hulpprogramma's kan het team ook enorm helpen. Als een tester goed is in programmeren, wordt dit als een groot pluspunt beschouwd. Dit opent kansen voor automatiseringsrollen. Prestatietesten is ook een van de carrièretracks voor testers. Bedrijfsanalist is een andere optie. Goede domeinkennis met goede communicatievaardigheden zijn de vereiste vaardigheden om een bedrijfsanalist te zijn. Testen biedt veel mogelijkheden voor de testers om te werken aan verschillende domeinen, tools, processen enzovoort. Het hangt gewoon van een persoon af om op te pakken en diep in een van de testkerngebieden te gaan. Er zijn veel certificeringen die specifiek zijn voor verschillende tools om zich te specialiseren in een van de testgebieden. Certificering van de standaardverkoper is een voordeel om de carrière te stimuleren, maar het certificaat alleen kan u op de lange termijn niet helpen als het niet wordt gecombineerd met de juiste werkervaring.
Aanbevolen artikelen
Hier zijn enkele artikelen die u zullen helpen om meer details over de Software Testing te krijgen, dus ga gewoon door de link.
- 6 meest geweldige sollicitatievragen voor het testen van software
- Carrières in het testen van software
- Hoe u een betere carrièregroei kunt bereiken bij het testen van softwaretesters