Inleiding tot het testen van softwaretesters
Wat is het eerste waar u aan denkt als u denkt aan een softwaretest? Een niet-coderend werk? Of een beroep dat heel gemakkelijk is omdat het je kansen biedt om fouten in anderen te vinden (fouten vinden terwijl in anderen de gemakkelijkste taak voor ons allemaal is)? Of beschouw je het als het beroep dat zich bezighoudt met het controleren van de juistheid van het product? Al deze gedachten zijn correct en zijn de dagelijkse activiteiten voor een softwaretester. Het testen van software is echter niet alleen beperkt tot deze activiteiten.
Inzicht in de toepassing
De applicatie kan van elk domein zijn - Healthcare, Insurance, Finance, enz. Het leren van het applicatiedomein is erg belangrijk voor softwarewerk om deuren te openen vanuit verschillende invalshoeken en vanuit verschillende gebruikersperspectieven tijdens het testen van de applicatie. Het is altijd de primaire verwachting om de voor de hand liggende en niet zo voor de hand liggende toepassingspaden te ontdekken en te valideren. Met een diepgaande kennis van de applicatie helpt het om het product effectief te valideren, terwijl de tester een aanwinst kan worden voor een project waar hij / zij wordt beschouwd als een van de primaire kennisbronnen met betrekking tot productgedrag.
Hoewel het leerdomein en de functionaliteit een doorlopend proces is voor elke andere belangrijke factor, is kennis over het testproces.
Testproces
Het testproces kan variëren van dit bedrijf tot bedrijf of zelfs van project tot project. Tegenwoordig hebben we verschillende modellen voor softwareontwikkeling, zoals het V-model, het Prototyping-model of een heel andere methode, zoals de Agile-benadering van softwareontwikkeling. Met de verandering in het ontwikkelingsmodel varieert ook de te volgen testaanpak. Werken in een V-model zal goed gedefinieerde processen hebben, terwijl dit werken in agile methodologie naar verwachting zal testen in steeds veranderende omstandigheden.
De taak is nog niet soepel met het hebben van acceptabele domeinkennis en begrip van het testproces, de volgende uitdaging die met het leven komt, is het leren van verschillende hulpmiddelen.
Gereedschap
Hulpmiddelen impliceren hulpmiddelen voor testbeheer, hulpmiddelen voor het registreren van fouten, hulpmiddelen voor databasebeheer, enzovoort.
Met verschillende defect-logging software, kwaliteiten en tools, sommige open source en sommige met licentie, is het altijd een voordeel om kennis te hebben van meer dan één tool. Het helpt het om gemakkelijk projecten of teams over te zetten met behulp van verschillende tools. Met voldoende kennis van het domein, proces en tools is er meer in het leven van Software Tester werk dat zijn / haar werkdagen uitdagend en spannend maakt. Samenwerking binnen teams is een van de belangrijke factoren in het succes van elk project en voor effectieve samenwerking speelt communicatie een zeer belangrijke rol.
Aanbevolen cursussen
- Voltooi J2EE uitgebreide cursus
- Online R-programmeertraining
- Ga de cursus programmeren
- Online certificeringstraining in Haskell-programma
Communicatie
Communicatie speelt een zeer belangrijke rol voor software it-kwaliteiten, vanaf de eerste fasen van softwareontwikkeling worden testteamleden (als een beste praktijk) betrokken bij de bespreking van vereisten, waarbij bedrijfsanalisten worden ondervraagd in geval van vragen of lacunes in de vereiste. Een tster met effectieve communicatievaardigheden kan de risico's effectief communiceren, kan effectief communiceren met het ontwikkelteam en kan effectief de testresultaten en testrapporten communiceren.
Planning van software tester werkt
Zoals de naam al doet vermoeden, is testplanning de fase waarin de voorbereiding op het testen plaatsvindt. Voorbereiding voor een tster omvat verschillende soorten activiteiten die een tster doet om de toepassing effectief te kunnen uitvoeren. Dit zal helpen bij het valideren van de applicatie en het effectief blootleggen van de defecten in de applicatie. Om met de planning te beginnen, doorloopt een teste de vereisten om de verwachtingen te begrijpen.
1. Vereisten
Aan het testteam kunnen eisen worden gesteld in de vorm van wireframes, storyboards, excel sheets. Het doel van al deze documenten is om de vereisten van de klant op een efficiënte en gemakkelijk te begrijpen manier te presenteren. Wireframe-document is niets anders dan een document in de vorm van een PowerPoint-presentatie die de vereisten van de klant weergeeft. Op dezelfde lijnen geven storyboards meestal het vereiste uiterlijk / ontwerp van de schermen weer. Tegenwoordig zijn er verschillende tools op de markt beschikbaar die kunnen worden gebruikt om de vereiste documenten voor te bereiden. Het maken van vereiste documenten is de primaire verantwoordelijkheid van een bedrijfsanalist. Van een smaak wordt verwacht dat hij de vereisten grondig begrijpt. Om ervoor te zorgen dat zowel de teste als de ontwikkelaars de vereisten correct begrijpen, houden bedrijfsanalisten het forum open voor iedereen om vragen te stellen en antwoord te krijgen op een van de vereisten. Het platform om de open vragen en vragen te bespreken en te communiceren varieert van project tot project. Het kan de keten van e-mails zijn of een telefonische vergadering of zelfs een gedeelde schijfrepository die wordt onderhouden om alle open vragen en hun antwoorden bij te houden zoals verstrekt door de bedrijfsanalist.
Duidelijke communicatie en record van communicatie speelt een zeer belangrijke rol voor een bewijs. Een kleine veronderstelling in de eis kan soms leiden tot een groot defect in het product. In elke fase wordt het aanbevolen om de eigenschappen van een softwaretester te gebruiken om de communicatie schoon te houden. Software Tester Werkcommunicatie kan zijn met Business analisten of zelfs binnen een team. Duidelijke communicatie helpt om aannames bij de planning en uitvoering weg te houden. Tegelijkertijd wordt aanbevolen om een communicatierecord te hebben (bij voorkeur e-mailcommunicatie). Het hebben van een schriftelijke communicatie over vragen in vereisten helpt in de latere fasen van de testuitvoering, waar de functionaliteit mogelijk niet is ontwikkeld zoals bevestigd in de opgenomen communicatie.
2. Scenario
Zodra de vereisten zijn begrepen, begint tester de scenario's te documenteren in het document Testscenario. Een scenario zoals de naam suggereert, is een stroom van functies die de gebruiker volgt om een taak te volbrengen.
Voorbeelden van scenario's -
- De gebruiker moet zich succesvol kunnen aanmelden.
- De gebruiker moet in het systeem tickets kunnen boeken.
- De gebruiker moet tickets in het systeem kunnen annuleren.
- De gebruiker moet de profieldetails kunnen bekijken / bijwerken.
Dit zijn de logische taken die een gebruiker in het systeem uitvoert. Wanneer deze gegroepeerde taken worden gegroepeerd, helpt het spreekwoord alle mogelijke scenario's te noteren die van een gebruiker worden verwacht. Deze scenario's worden meestal gedocumenteerd in de Excel-bladen of soms met behulp van enkele hulpmiddelen. Een spreekwoord gedijt om al dergelijke scenario's uit de vereiste documenten te halen. Een document met dergelijke scenario's wordt Testscenario-document genoemd (of ergens als scenario-document op hoog niveau). Dit document dient als invoerdocument voor het opstellen van testgevallen.
3. Geval
In dit geval is de meer gedetailleerde versie van het werkscenario van Software Tester waarin het scenario wordt opgesplitst in meer gedetailleerde stappen die de gebruiker daadwerkelijk zal uitvoeren tijdens het gebruik van de applicatie. Een eenvoudig voorbeeld op basis van de bovengenoemde scenario's is:
Scenario - Gebruiker moet zich kunnen aanmelden.
Testgevallen:
- Controleer of de gebruiker de juiste gebruikersnaam kan invoeren.
- Controleer of de gebruiker het wachtwoord kan invoeren.
- Controleer of de gebruiker met succes kan inloggen wanneer hij op de knop Inloggen klikt na het invoeren van de juiste gebruikersnaam en wachtwoord.
Zo'n lijst van deze gevallen kan verder een validatiecontrole op elk veld bevatten, waarbij negatieve scenario's worden gecontroleerd, enzovoort.
Hieronder vindt u enkele voorbeelden van deze gevallen -
- Controleer of die gebruikersnaam niet is ingevoerd, het systeem geeft een juiste foutmelding.
- Controleer dat wachtwoord wanneer niet ingevoerd, het systeem geeft een juiste foutmelding.
- Controleer of die gebruikersnaam en wachtwoord niet zijn ingevoerd, het systeem geeft een juiste foutmelding.
- Controleer of bij het invoeren van een onjuist wachtwoord het systeem een foutbericht geeft.
- Controleer of bij het invoeren van een onjuiste gebruikersnaam het systeem een foutbericht geeft.
4. Eis traceerbaarheidsmatrix (RTM)
De traceerbaarheidsmatrix voor vereisten, zoals de naam al doet vermoeden, helpt om de dekking van de vereisten zoals die door Business wordt geleverd, te controleren en op te nemen in de testdocumenten zoals scenario's en testcases.
Als best practice is dit een afzonderlijk document dat de toewijzing van het vereiste nummer toont aan dat van scenario's / gevallen waarin die eis is opgenomen.
Dit document kan niet door alle soorten projecten worden gebruikt, maar wanneer het wordt gebruikt, helpt het op een krachtige manier om de scenario's op hoog niveau te traceren naar de vereisten. Het geeft de dekking aan en kan worden gebruikt om de aanwezigheid van ten minste één in deze zaak te controleren voor elke vereiste. Het maken en onderhouden van het RTM-document wordt als de beste praktijk beschouwd, maar niet alle soorten projecten (zoals Agile) gebruiken Software als bewijs van het werkdocument. Wanneer de vereisten zeer vaak veranderen, kan onderhoud van dit document worden afgeluisterd. Om deze overhead te voorkomen en tegelijkertijd een manier te hebben om vereisten te traceren, nemen sommige projecten het traceerbaarheidsgedeelte op in de werkcase van Software Tester of het scenariodocument zelf.
Het belangrijke aspect is om een manier te hebben om scenario's / cases naar vereisten te traceren en vice versa. Goed gedocumenteerde vereisten maken het voor Prover eenvoudiger om deze documenten te maken en te onderhouden. Dubbelzinnige vereisten, steeds veranderende vereisten maken het leven van Prover uitdagender en kunnen leiden tot inconsistente afleverbare documenten die resulteren in het missen van enige validatie en dus een defect in het eindproduct.
De reis tot nu toe voor een tester was bezig met het plannen en voorbereiden van testen. Aangezien de voorbereiding op de oorlog deel uitmaakt van de oorlog, geldt hier hetzelfde. Hoe beknopter deze documenten zijn gemaakt, des te gemakkelijker is het voor de spreker om de functionaliteit te valideren en bijna alle defecten aan het licht te brengen. De volgende fase van de reis van de tester is Execution.
Uitvoering van Software tester werkt
Dit is de fase waarin alle bovengenoemde documenten in gebruik worden genomen. Vereisten werden gebruikt om een Scenario te maken, Scenario werd gebruikt om het Cases te maken. dit casusdocument is hier het zelfvoorzienende document om de aanvraag te valideren. Prover begint de toepassing te valideren door stappen uit dit casusdocument uit te voeren. Meerdere van deze gevallen kunnen worden gebruikt om een enkel scenario te valideren of zelfs een enkele testcase kan overeenkomen met een enkel testscenario. Het hangt allemaal af van de complexiteit van de scenario's of soms van de standaard die in het testteam wordt gevolgd. Daarom kan een enkel testcase-document 20-50 testgevallen bevatten of 100-120 testgevallen. Deze cijfers zijn alleen voor uitleg, het kan enorm verschillen van project tot project. Het resultaat van deze fase is testfouten. Het aantal geldige defecten dat in deze fase is opgetreden, geeft een goed idee van de stabiliteit van de toepassing, de testkwaliteit, de bouwkwaliteit en veel van dergelijke factoren die rechtstreeks van invloed zijn op het product. Deze fase is de belangrijkste fase, aangezien tester alle testcases bestrijkt (bijna alle vereiste gebruikerspaden valideert) en tegelijkertijd zoveel mogelijk geldige defecten genereren. Alle voorbereidingen, communicatieve vaardigheden, vragen die aan het bedrijf worden gesteld, komen binnen om in deze testfase te handelen.
Defecten van software tester werkt
Tijdens het uitvoeren van deze casus wordt elk gedrag dat niet gelijk is aan het verwachte resultaat als Defect aangekaart. Elke testcase heeft een Beschrijving, Verwacht resultaat en een kolom voor Werkelijk resultaat. Hoewel deze planning Software Tester Work-document een beschrijving en verwachte resultaten heeft en een lege kolom voor werkelijke resultaten. Tijdens het uitvoeren van de testgevallen wordt de tester verondersteld de werkelijke resultaatkolom in te vullen. Tegelijkertijd wordt het defect vastgelegd als het werkelijke resultaat niet gelijk is aan het verwachte resultaat. Het registreren van een defect betekent niet alleen dat de ontwikkelaar over het probleem wordt geïnformeerd. Het is weer een formeel proces dat meestal met behulp van een tool wordt uitgevoerd. Momenteel zijn er verschillende tools op de markt, sommige open source en sommige met licentie. Elk logboekprogramma voor defecten heeft de volgende velden:
- Naam project / release
- Samenvatting defect
- Detailbeschrijving defect
- Defect Ernst
- Prioriteit defect
- Fase waarin het defect is gevonden
- Toegewezen aan
- Bijlagen
Zoals we kunnen zien, is het doel van al deze velden om een formele procesmatige details van het gevonden probleem te hebben. Dit helpt ontwikkelaars om het defect in hun omgeving te reproduceren en op te lossen. Hieronder vindt u de korte beschrijving van al deze velden -
- Project- / releasenaam - Naam van de release waar het defect is gevonden, meestal heeft het project meerdere releases en hetzelfde project kan meerdere subprojecten hebben. Dit veld helpt om een probleem voor een specifieke release aan de orde te stellen.
- Samenvatting defect - Een korte beschrijving van één defect van het gevonden defect.
- Detailbeschrijving defect - Dit is de gedetailleerde beschrijving van het defect, het moet details bevatten zoals de omgeving waar het defect is gevonden, en gebruikte testgegevens, werkelijke resultaten verwachtten het resultaat en eventuele aanvullende informatie die meer waardevolle informatie toevoegt voor de belanghebbenden om de defect.
- Defect Ernst - Het geeft aan hoe ernstig het defect is. Meestal heeft het waarden vergelijkbaar met kritieke, hoge, gemiddelde, lage of numerieke waarden zoals 4, 3, 2, 1.
- Prioriteit defect - Het geeft aan hoe dringend het is om het defect te verhelpen.
- Fase waarin het defect is gevonden - Omdat er veel fasen zijn waarin een defect kan worden vastgelegd, de fase voor het testen van eenheden, SIT (testen van systeemintegratie), UAT (testen van gebruikersacceptatie) of zelfs de productiefase.
- Toegewezen aan - Naam van de ontwikkelaar of ontwikkelingsleider.
- Bijlagen - Dit gaf de tester een optie om de momentopname van het scherm waar het probleem zich voordeed bij te voegen.
Testuitvoering en defectregistratie is de fase waarin er veel uitdagingen zijn waarmee een tester geconfronteerd kan worden. Sommigen van hen communiceren effectief met de ontwikkelaars. Zouden we kunnen beweren dat het registreren van een defect met alle benodigde informatie niet voldoende is voor de ontwikkelaars om het defect te begrijpen?
Dat is het en in sommige gevallen vereist het extra uitleg / discussie met de ontwikkelaars. Er zijn gevallen waarin een tester een onverwacht gedrag tegenkomt waarvan hij / zij misschien niet zeker weet of het een defect is. Deze omstandigheden worden meestal geconfronteerd met een spreekwoord die nieuw is in het team, die beperkte domeinkennis heeft of onduidelijk is over de vereisten. Nou, de tester kan hier niet de schuld krijgen als er strakke deadlines zijn en er steeds veranderende vereisten zijn en in de meeste gevallen leert de spreker over het domein terwijl hij testcases daadwerkelijk plant en uitvoert. Zoals we kunnen zien, is het pad van een tester niet zo eenvoudig als het wordt waargenomen. Het vereist een altijd leerhouding, goede communicatievaardigheden, goede samenwerkingsvaardigheden en gretigheid om zich aan te passen aan omstandigheden waarin er veranderingen zijn in domeinen, tools, processen die worden gebruikt. Terwijl we het hadden over de reis van handmatige testers, is het algemene proces ook van toepassing op automatiseringstesters. Aan de andere kant hebben automatisering aanzienlijke veranderingen in het proces, omdat de reikwijdte van testen en plannen, uitvoering aanzienlijk varieert.
Gezien de reis van de spreker zoals hierboven besproken, kunnen we nog steeds zeggen dat de taak van softwaretesterkwaliteiten eenvoudiger is dan die van een ontwikkelaar?
Er kan worden gezegd dat het meer dan het vergelijken van de ontwikkelaarrollen van tester v / s nuttiger is om een discussie te hebben over hoe de samenwerking van twee kan leiden tot een groot succes van het product als geheel. We vergeten soms dat het de taak van de tester is om problemen in de applicatie te vinden en niet om fouten van de ontwikkelaars aan te wijzen. Wanneer we het idee van ons werk vergeten, leidt dit soms tot onnodige discussie. Er is echter geconstateerd dat er even goede test-, ontwikkelingsteams zijn waarvan iedereen begrijpt dat het uiteindelijke doel is om de applicatie naar verwachting te laten werken. Laten we hopen dat iedereen de positieve kant van het testwerk ziet als een rol die helpt bij het reinigen van het product en niet als degene die alleen fouten vindt!
Aanbevolen artikelen
Dit is een gids geweest om de voor de hand liggende en niet zo voor de hand liggende toepassingspaden te ontdekken en te valideren, is altijd de primaire verwachting van een softwaretester. Dit zijn de volgende externe koppelingen met betrekking tot het werken met softwaretesters.
- Defecte levenscyclus bij het testen van software
- 6 meest geweldige sollicitatievragen voor het testen van software
- Carrières in het testen van software