how effectively prepare test bed
Testbed / testomgeving instellen Uitdagingen en best practices:
Bij verschillende gelegenheden merken de testers dat hun defecten worden afgewezen vanwege milieukwesties of ze merken dat ze de defecten om vergelijkbare redenen constant repliceren. Hoewel het openen van het grootste aantal defecten zeker een van de persoonlijke benchmarks voor elke tester moet zijn, moeten de meeste testers ook benadrukken dat ze het meeste aantal geldige defecten hebben.
Hoe wordt dit bereikt?
Afgezien van de andere aspecten, zoals het plannen van een verscheidenheid aan testscenario's en het grondig begrijpen van het regelitem, is een er moet veel tijd worden geïnvesteerd in het opzetten van de testbed of testomgeving Ten tweede, ondanks dat ze een geschat bedrag hebben voor het plannen van testgevallen, moeten testers dat ook doen richten hun energie op het creëren van effectieve testgegevens
Persoonlijk, als onderdeel van het auditproces, heb ik geconstateerd dat het meeste aantal geldige defecten wordt gevonden wanneer er veel moeite is gestoken in het op een correcte manier creëren van de testbed of testomgeving en wanneer de tester een gedegen begrip van het soort omgeving dat nodig is.
Ook kan het soort testgegevens dat aan de testomgeving wordt geleverd, enkele zeer ernstige tekortkomingen in de te testen code / functie aan het licht brengen die de kwaliteit van het product ernstig kunnen beïnvloeden.
In dit artikel wordt uitgelegd wat het testbed precies inhoudt: het is een proces in twee stappen van het instellen van de testomgeving en het instellen van testgegevens:
Deel 1) In het eerdere deel van het artikel wordt het algemeen proces voor het instellen van de testomgeving , de meest voorkomende installatieproblemen waarmee tests en tips in gedachten moeten worden gehouden bij het maken van een testbed in plaats van deze uitdagingen.
Deel 2) Na zoveel te hebben gezegd met betrekking tot het testbed in dit artikel, was het de moeite waard om wat licht te werpen op de Onderhoud van de testomgeving aspecten ook. Het laatste deel van het artikel bespreekt het tweede deel van de testbedopstelling, die de testgegevens, de aanpak om het op te zetten en enkele effectieve Test datamanagementtechnieken
Met een constante 'big bang' in softwareontwikkeling en -testen, is er een steeds grotere focus op het toepassen van verschillende methodologieën om het algehele kwaliteitsborgingsproces transparant, efficiënt en adequaat te maken.
Er worden verschillende kwaliteitsaudits uitgevoerd in organisaties om ervoor te zorgen dat de prestaties van het testteam op passende wijze kunnen worden geëvalueerd en meetbare resultaten opleveren met de metrische gegevens die zijn geïdentificeerd bij de initialisatie van de testcyclus. Deze resultaten maken het mogelijk om te bepalen waar een bepaald team staat in termen van optimale kwaliteit van de software die ze testen.
Deze rapporten helpen het team ook om de mogelijkheden voor verbetering te begrijpen op basis van de observaties die tijdens de audit zijn gedaan.
Onnodig te vermelden dat een zeer voor de hand liggende metriek voor elk testteam zou zijn met betrekking tot het totale aantal geopende defecten versus het aantal geldige defecten Daarom is een van de vragen die duidelijk opduiken: wat is de basis van het proberen om een defect te ontdekken? Anders gezegd, wat is de basis waarop een defect kan worden gevonden?
Het antwoord is unaniem: opstelling van testbed en / of testomgeving. Binnen teams zijn er kwaliteitsbenchmarks vastgesteld verminder de defecten die worden afgewezen als een testconfiguratiefout / gebruikersfout, ongeldige configuraties of in sommige gevallen de defecten die ontstaan als ontsnappingen van een bepaald team vanwege niet-beschikbare configuraties, niet-geteste configuraties.
Laten we beginnen door nader te bekijken wat een testbed of testomgeving is.
Wat je leert:
Wat is een testbed en testomgeving?
In zeer algemene zin zou een testbed kunnen worden gedefinieerd als een soort ontwikkelomgeving waarbij de implementeerders van code of modules de vrijheid hebben om hun modules te testen zonder enige verstoring van het testteam, in absolute opsluiting.
Een testbed is echter niet alleen specifiek voor een ontwikkelteam. Vanuit het perspectief van een testteam of een tester, aangezien het testbed niets anders is dan een platform dat is geïdentificeerd voor het testen van software / producten, wordt het ook door elkaar een testomgeving genoemd.
Elke testbed of testomgeving moet worden geconfigureerd in overeenstemming met het geïdentificeerde testdoel voor de applicatie / product / software die wordt getest. In bepaalde situaties is een testbed de verzameling van de testomgeving en de testgegevens waarmee het werkt.
Onderdelen van een testomgeving
Elke test zou zijn specifieke testomgevingvereisten hebben, maar in zeer brede zin zal elke testbed / testomgeving bestaan uit de hardware, software en de netwerkonderdelen om de vereiste configuratie minimaal te ondersteunen om de specifieke test te besturen en uit te voeren .
Het is een bekend feit dat een redelijke hoeveelheid tijd van een tester wordt verbruikt door milieuproblemen, die op hun beurt de productiviteit en testschema's beïnvloeden. Hoewel het soort uitdagingen voor elk testteam verschilt, kunnen sommige ervan vaak voorkomen.
Enkele belangrijke uitdagingen waarmee we vaak worden geconfronteerd, zijn:
# 1) Externe omgeving
De testmiddelen of -omgevingen worden meestal geografisch geplaatst op locaties die ver verwijderd zijn van de teams. Dit is een van de meest voorkomende uitdagingen voor testteams, zoals in het geval van problemen die zich kunnen voordoen met betrekking tot hardware, firmware, software, netwerken, enz.
De teams die de activa verbruiken, zouden sterk moeten vertrouwen op de ondersteuningsteams op de locatie waar de activa aanwezig zijn.
In dezelfde zin, als een asset een firmware-upgrade of een build-upgrade nodig heeft, kan het testteam opnieuw de ondersteuning nodig hebben van de ondersteuningsteams die de omgeving bezitten door ondersteuningstickets te openen. Dit kan ook aanzienlijke testtijd- en vertragingsschema's in beslag nemen, vooral in gevallen van tijdzoneverschillen.
# 2) Gecombineerd gebruik tussen teams
Meestal gebruiken ontwikkel- en testteams dezelfde omgevingsactiva. Hoewel de algemene norm bepaalt dat ontwikkel-, test- en productieomgevingen gescheiden moeten zijn, wordt dit ideale scenario in werkelijkheid zeer zelden bereikt. Het wordt voor organisaties buitengewoon kostenonvriendelijk om voor elk team afzonderlijke middelen aan te schaffen.
Daarom verplichten de meeste organisaties het gemeenschappelijk gebruik van de omgeving tussen ontwikkeling en test. Bovendien leidt het tot chaos en meningsverschillen binnen de leden als de ontwikkel- en testmiddelen strijden om het gebruik van dezelfde middelen.
# 3) Ineffectieve planning voor het gebruik van middelen voor integratie
In sommige gevallen voor scenario's waarvoor een end-to-end testen waarbij er een integratie is van twee of meer componenten om samen te functioneren, kan er opnieuw een vereiste zijn om het gemeenschappelijk gebruik van middelen tussen testteams te hebben. Ineffectieve planning met betrekking tot gebruik draagt er in hoge mate toe bij dat de omgeving instabiel wordt, naast conflicten tussen teams.
Het meest voor de hand liggende effect hiervan is dat een probleem dat een of twee keer voor een bepaald probleem wordt opgemerkt, totaal ander gedrag kan veroorzaken in de volgende runs voor hetzelfde scenario. Als hiervoor al een defect is geopend, is de kans groot dat het door de ontwikkeling niet wordt geaccepteerd als een geldige kandidaat voor een fix.
# 4) Complexe testconfiguratie
De configuratie van de testbed of testomgeving is soms te complex. Dit brengt verschillende uitdagingen met zich mee, aangezien het testteam de vereiste vaardigheden nodig heeft om de benodigde configuraties te begrijpen. Soms is er een gebrek aan kennisbasis voor de tester om de gewenste configuratie te kunnen bedenken.
In dergelijke gevallen kunnen de testers zelf een fout in de testbank veroorzaken door deze onjuist te configureren. Dit zou een grote invloed hebben op de testcase en de resultaten die het oplevert.
# 5) Uitgebreide installatietijd
Op andere momenten kan de testopstelling voor elk testgeval veel te uitgebreid zijn voor elk geïdentificeerd testgeval. Dit kan te wijten zijn aan een grote verscheidenheid aan naast elkaar bestaande technologieën die aan elkaar moeten worden gekoppeld of aan meerdere componenten om samen te werken in gevallen van integratietests.
In deze gevallen moet elk van de componenten perfect werken om consistente resultaten te garanderen, aangezien de ene component een input kan vormen voor de volgende.
Best practices voor het opzetten van een testomgeving
We hebben de grote lijnen van uitdagingen bekeken waarmee een tester wordt geconfronteerd voordat of tijdens het begin van de testuitvoering. De meesten van ons hebben wel eens met een of meer van deze problemen te maken gehad tijdens de mijlpalen van ons project. Deze uitdagingen hebben bestaan en zullen mogelijk in verschillende mate blijven bestaan, omdat er geen idealistische situatie bestaat.
Gezien het feit dat setup-uitdagingen een essentieel onderdeel zijn van het werk van een tester en onvermijdelijk zijn, volgen hier enkele suggesties voor het effectief voorbereiden van de setup voor testen. Dit zou kunnen helpen om de defecten te minimaliseren die kunnen voortkomen uit setup-problemen.
Tip # 1) Begrijp de Testvereisten grondig en leer jezelf
qa tester interviewvragen en antwoorden pdf
Begin altijd met de basis en met de meest voor de hand liggende! Wanneer een specificatiedocument of een use case-document wordt uitgerold door het ontwikkelteam, is de onveranderlijke stap voor het testteam om de regelitemvereisten te begrijpen en vervolgens een testcase-document op te stellen waarin de testcases worden beschreven.
Terwijl de testplanning wordt uitgevoerd, is dat zo het beste oefen om ook de gedetailleerde testomgeving-informatie op te nemen in het testcase-document. Geen gok dat de tester dan enige tijd zal besteden aan het analyseren van welke testomgeving mogelijk vereist is en dienovereenkomstig de benodigde configuraties.
Dit kan worden bereikt door met het ontwikkelteam / architecten te praten om een goede kennisbasis op te bouwen. Dit bespaart niet alleen wat tijd in de uitvoeringscyclus, maar helpt een tester ook om zijn uitvoeringstijd effectief te verdelen over eenvoudige en complexe tests.
Persoonlijk is een goede uitkomst hiervan dat velen van ons setup-problemen ontdekten (die inherent een consistente testuitvoering zouden verhinderen) in het allereerste begin van de cyclus, wat ons tijd gaf om te kanaliseren en de vereiste hulp te verwerven om die problemen op te lossen - dus de testcyclus niet langer dan onaanvaardbare perioden verlengen.
Een ander positief effect dat dit zou hebben, is dat dit de kennis van het testteam aanzienlijk zou verbeteren en onnodige defecten zou voorkomen. Hoewel deze praktijk bijna alle praktijken samenvat die inherent nodig zijn om het hoofd te bieden aan de hierboven genoemde uitdagingen bij het instellen van tests, is het toch de moeite waard om de andere tips te vermelden.
Tip # 2) De connectiviteit controleren
Een ander zeer belangrijk ijkpunt is om ervoor te zorgen dat de bronnen of middelen die u voor het testen wilt gebruiken, bereikbaar zijn. Als het systeem geïntegreerd moet worden uitgevoerd met andere machines, controleer dan hun connectiviteit met elkaar door ping of telnet te gebruiken.
Als de systemen met elkaar moeten communiceren en zich achter firewalls bevinden, zorg er dan voor dat ze zich kunnen authenticeren via deze firewalls met behulp van basisbeveiligingsopties (BSO) en controleer ook of er proxy's zijn. Als u merkt dat sommige machines niet bereikbaar zijn of BSO-authenticatie nodig hebben, kunnen passende serviceverzoeken worden ingediend om aan de vereisten van het ondersteuningsteam te voldoen.
Dit is vooral handig als de omgeving zich op afgelegen locaties bevindt en voorkomt ook escalaties met betrekking tot de machines en systemen. In het geval dat het testteam toegang nodig heeft tot een bron of repository, zou dit helpen bij het proactief bepalen van hetzelfde.
Tip # 3)Het netwerk en / of opslag controleren
Dit is bijna een uitbreiding op de vorige tip en zou nog een andere controle met meer technische diepgang nodig hebben. Zorg ervoor dat het testen dat u nodig heeft over de benodigde bandbreedte beschikt en of voor het testen een internetverbinding nodig is. Zorg er ook voor dat u een manier vindt om te controleren of de netwerktopologie tussen systemen en bronnen correct is.
Ten tweede, als uw testdoel inhoudt dat er opslag nodig is, zorg er dan voor dat er opslag- en netwerkconnectiviteit is. Meestal is het de verantwoordelijkheid van een beheerder om dit voor elkaar te hebben, maar het is ook een grote meerwaarde om enige functionele en functionele kennis hiervan te hebben.
Tip # 4) Controleer de vereiste hardware en software, licenties
Het komt vaak voor dat testers met de uitvoering op de systemen beginnen zonder de benodigde hardware en software te controleren die mogelijk nodig is. Als gevolg hiervan realiseert een tester zich vaak bijna tijdens de testcyclus dat bepaalde functionaliteit alleen beschikbaar is op een hoger niveau van hardware of software / firmware.
Op dat moment zal de tester in zijn testinspanning een blocker markeren die veel testtijd opslokt. Daarom is het een onschatbare gewoonte om een ijkpunt te hebben om vooraf een notitie te maken van de hardware en software die nodig is.
Vaak kan er downtime optreden bij het upgraden van de hardware / software, wat allemaal neerkomt op Tip 1 waarbij een tester zich moet bezighouden met proactieve planning van de hardware. Voor een deel van de software zijn mogelijk licenties vereist die mogelijk goedkeuring en acties van het juridische team vereisen. Omdat dit een procesgestuurde actie is, kan het opnieuw een aantal dagen duren voordat het is vervuld, wat moet worden gepland.
Tip # 5)Browsers en versies
Het testen dat u doet, moet spiegelen wat een eindgebruiker zal presteren Hij zou in een bepaalde browser kunnen testen met de nieuwste versies van alle browsers. Daarom is het verplicht om de verschillende soorten browsers te identificeren die zouden worden gebruikt voor het testen en deze in uw eigen lokale testopstelling te installeren.
Ten tweede, identificeer ook welke versies van browsers moeten worden gebruikt om te testen. Een goede gewoonte zou zijn om te beginnen met een browser van de lagere versie, waardoor achterwaartse compatibiliteit wordt gegarandeerd en vervolgens te upgraden naar de nieuwste versie.
Tip # 6)Plannen van het gebruik van de testomgeving.
Gezien het feit dat het testteam nooit de situatie zal hebben met eigen testresources, -systemen en -middelen, is het een van de belangrijkste mijlpalen in de testplanning om effectief gebruik te maken van testresources.
wat kan ik maken met c ++
Dit is met name vereist wanneer meer dan één team toegang moet hebben tot dezelfde set bronnen, hetzij vanwege een end-to-end-scenario dat bestaat uit twee of meer samenwerkende componenten, of een situatie waarin de testopstelling te uitgebreid of te complex is om te worden gerepliceerd. heel gemakkelijk en er kunnen meerdere leden binnen hetzelfde team zijn die hun eigen testdoelen hebben met dezelfde opzet.
Een goede gewoonte zou zijn om een time-sharing-benadering uit te werken waarbij een bepaald team of een bepaalde persoon het gebruikt voor de eerste helft en de overige mensen voor de tweede helft. Er kan ergens tussenin zitten dat normaal zal zijn, waarbij elk van hen onafhankelijke tests kan uitvoeren die de ander niet zullen hinderen.
Dit zal niet alleen de chaos en conflicten binnen de leden verminderen, maar ook de gedragsstabiliteit van de omgeving voor een langere duur verzekeren.
Tip # 7)Automatiseringstools en hun configuraties
Zoals we weten, zal elk regelitem dat wordt getest een paar herhaalde tests ondergaan die deel uitmaken van de regressiecyclus die moet worden geautomatiseerd. Het testteam moet bepalen wat voor soort automatisering ze willen doen en welke tools daarvoor nodig zijn.
Hoewel dit noodzakelijke geen onderdeel hoeft te zijn van de voorbereiding van de omgeving, zou ik dit toch als een best practice willen noemen om de automatiseringstools te identificeren en dienovereenkomstig te configureren. Dit zou volledig afhangen van de discretie van de tester wanneer hij deze activiteit wil uitvoeren, aangezien dit geen verplichte factor is om de testgereedheid te garanderen.
Gevolgtrekking
Deze tips en trucs kunnen een goede maatstaf en voetafdruk vormen om ervoor te zorgen dat de testomgeving gereed is voor testen. Elk team wordt ongetwijfeld geconfronteerd met zijn eigen unieke reeks uitdagingen en de bovenstaande tips kunnen worden aangepast en aangepast aan hun eigen respectieve behoeften.
In feite is de bron voor het opschrijven van dit hele skelet van tips afkomstig van een van mijn opdrachten waarbij ik te maken kreeg met zeer complexe installatieproblemen en het me bijna een jaar kostte om zelfs maar te beginnen met testen!
Hoewel ik geen controle had over de beperkingen in de testomgeving, had ik het gevoel dat veel van deze problemen eerder hadden kunnen worden gemeld als ik deze tips had toegepast. Ik heb het toegepast voor elke opdracht die sindsdien op mijn pad komt en dit skelet heeft me veel geholpen bij het proactief vinden van setup-problemen en het kanaliseren van mijn inspanningen om ze op te lossen.
Over de auteur: Dit artikel is geschreven door Sneha Nadig. Ze werkt als een testleider met meer dan 7 jaar ervaring in handmatige en automatiseringstestprojecten.
In deel 2 van dit artikel zullen we het installatie- en onderhoudsproces van de testomgeving en de voorbereiding van testgegevens en beheertips zien. Ondertussen kunt u uw vragen over het voorbereiden van testbedden in opmerkingen plaatsen.
Aanbevolen literatuur
- Effectief testen na de release en de impact van de release op live clients minimaliseren
- Hoe bepaalt u welke defecten aanvaardbaar zijn om de software live te laten gaan?
- Hoe u een uitstekende QA-testpresentatie voorbereidt en aan het team geeft
- Defectbeheerproces: hoe u een defect effectief kunt beheren
- 9 beste ideeën voor testers om hun bench-tijd effectief te gebruiken
- Leiderschap bij het testen - Verantwoordelijkheden van testleiders en hoe u het testteam effectief kunt beheren
- Testprojecten effectief plannen en beheren (tips)
- Defect Triage Process en Manieren om Defect Triage Meeting aan te pakken