Meer dan 40 populaire vragen en antwoorden voor interviews met QA-analisten (2021 LIST)

40 popular test qa analyst interview questions

Meest gestelde vragen en antwoorden voor test- / kwaliteitsborgingsanalisten:

Bij het bepalen van de carrière waarin je wilt zijn, is de doorslaggevende factor niet alleen degene waarvan je denkt dat die met plezier kan werken.

Maar om in die categorie te vallen, vereist veel vaardigheden, inzicht in de verantwoordelijkheden en de noodzakelijke functietaken voor de carrière die u kiest. Hetzelfde geldt voor het kiezen van een carrière als QA-analist. Je moet niet alleen een goede tester, een snelle leerling, een buitengewone denker zijn, maar ook een complexe probleemoplosser zijn.

Hoewel de bovengenoemde kwaliteiten niet onmiddellijk worden bereikt, vereist het uiteraard ook ervaring en dagen hard werken.

Dit artikel behandelt elk aspect waarvan de kennis verplicht is om een ​​QA-analist te zijn. De meest gestelde interviewvragen en antwoorden voor QA Test Analyst die hier zijn opgenomen, geven u een duidelijk beeld van uw interviewvoorbereiding.

Populaire QA Test Analyst sollicitatievragen

V # 1) Wat zijn de verantwoordelijkheden van een QA-analist?

Antwoord: QA Analyst is degene die ervoor zorgt dat alle mogelijke maatregelen zijn genomen om elke functie van de softwareoplossing zowel functioneel als technisch te testen.

De belangrijkste verantwoordelijkheden van QA Analyst kunnen als volgt worden ingeroepen:

• Voer alle activiteiten uit en beheer ze om aan de doelstellingen van het testplan te voldoen.
• Kies de processen van hoge kwaliteit om het product te ontwikkelen.
• Moet de vereisten kunnen analyseren en procedures kunnen documenteren.
• Documenteer en verifieer alle defecten opnieuw. Stel de prioriteit en ernst van defecten in.
• Ze moeten testcases kunnen maken, documenteren en onderhouden.
• Analyse van testresultaten.

V # 2) Wat is uw begrip over een testplan?

Antwoord: Als je een duidelijk idee hebt van wat, wanneer, hoe en wie, dan wordt het gemakkelijker. Hetzelfde is het geval met softwaretests, waarbij het testplan een document is dat bestaat uit de scope, aanpak, middelen en een overzicht van het testproject, evenals de activiteiten voor het volgen van de voortgang van het project.

Het testplan is een verslag van processen, waaronder:

• Taken testen
• Testomgeving
• Ontwerptechnieken
• In- en uitstapcriteria
• Eventuele risico's, etc.

V # 3) Maak gebruik van de prioriteit van de testtaken die zijn gedefinieerd door het QA-team bij productontwikkeling.

Antwoord: De prioriteit van de testtaken wordt als volgt gedefinieerd:

• Er wordt een testplan opgesteld bestaande uit de opzet en scope van het testproject.
• Testcases worden voorbereid om alle grote en kleine functionaliteiten te dekken met de gegevens die nodig zijn voor het testen.
• Uitvoering van de testcases volgens de functionaliteiten die zijn geïmplementeerd met de komende builds van het testproject in de testcyclus.
• Defectrapportage met herverificatie en het volgen van de voortgang.
• Opstellen van de samenvatting van het testuitvoeringsrapport.

V # 4) Noem enkele van de belangrijkste uitdagingen waarmee u wordt geconfronteerd tijdens het uitvoeren van softwaretests.

Antwoord: Omdat we zeggen dat volledige tests nooit kunnen worden bereikt, zijn er verschillende uitdagingen aan verbonden. Of het nu een kleine of een gecompliceerde is, er zijn enkele uitdagingen waarmee u wordt geconfronteerd bij het uitvoeren van softwaretests van elk project.

Hieronder staan ​​een paar belangrijke uitdagingen:

• Gebrek aan bekwame tester die gewoonlijk wordt geconfronteerd met het probleem van het bewustzijn van het onderwerp, evenals een gebrek aan goede kennis van de zaken van de klant.
• Tijd wordt ook als de factor beschouwd, aangezien testers zich meestal voornamelijk richten op taakdekking in plaats van testdekking met kwaliteitstesten wanneer er een enorme lijst met taken moet worden voltooid.
• Om te beslissen welke testcase als eerste en met prioriteit moet worden uitgevoerd. Dit wordt meestal bereikt door de ervaring van werk.
• Een goed begrip van de vereisten die ertoe kunnen leiden dat al uw testinspanningen op nul komen te staan, als de vereiste verkeerd wordt begrepen.
• Onbeschikbaarheid van de beste tools die nodig zijn om het testen te voltooien met minder tijd en meer effectiviteit.
• Omgaan met de relatie tussen testers en developers met goede communicatieve en analytische vaardigheden.

V # 5) Use Case Testing definiëren.

Antwoord: Use Case-testen kunnen worden gedefinieerd als de functionele black-box-testtechniek die de reeks interacties vastlegt die hebben plaatsgevonden tussen ‘actoren’ en ‘systeem’. Hier worden ‘Acteurs’ vertegenwoordigd door de gebruikers en hun interacties.

Kenmerken van de use case-tests worden hieronder opgesomd:

• De functionele eisen van het project zijn georganiseerd.
• Registreert het pad of de scenario's van begin tot eind.
• Kan integratiedefecten dekken, d.w.z. de defecten die zijn opgetreden als gevolg van interactie tussen verschillende componenten.
• Het beschrijft zowel de belangrijkste stromen als de uitzonderlijke stroom van de evenementen.
• Eventuele randvoorwaarden die nodig zijn om de use case te laten werken, moeten eerder worden gespecificeerd.

Vraag 6) Bepaal de teststrategie.

Antwoord: Een reeks richtlijnen of de testbenaderingen die gewoonlijk door de projectmanager worden uitgevoerd om het testontwerp en de algemene testaanpak te bepalen, wordt gedefinieerd als Teststrategie. Het wordt gevonden als een klein deel van het testplan en wordt gebruikt door meerdere projecten.

Er worden verschillende testbenaderingen gevolgd op basis van factoren zoals de aard en het domein van het product, het risico van productfalen, expertise in het werken met voorgestelde tools, enz.

Deze benaderingen worden als volgt verder gecategoriseerd:

• Proactieve aanpak , waar de benadering van testontwerpen begint voordat de build wordt gemaakt. Het helpt dus bij het vinden en oplossen van de bugs voordat de build.
• Reactieve benadering , waar de testaanpak wordt gestart na de voltooiing van het testontwerp en de codering.

V # 7) Leg het verschil uit tussen kwaliteitscontrole en kwaliteitsborging.

Antwoord: 'Kwaliteitscontrole' en 'Kwaliteitsverzekering' zijn de twee belangrijkste termen die worden gebruikt met betrekking tot elk testproject of product. Meestal begrijpen testers, die nieuw zijn in dit vakgebied, het werkelijke verschil tussen de twee niet.

Laten we het verschil begrijpen met behulp van de onderstaande tabel.

V # 8) Wanneer is volgens u het goede moment om QA in een project te starten?

Antwoord: Volgens de Software Development Life Cycle (SDLC) wordt de testfase uitgevoerd na voltooiing van de ‘Implementatie en codering’ fase. Maar in het huidige scenario is het, om de beste resultaten te bereiken, vereist om de QA van het project of product aan het begin van het project te starten.

Het volgen van deze aanpak zal leiden tot de volgende grote voordelen:

• Vroege procesplanning om aan de kwaliteitsverwachtingen van de klant te voldoen.
• Goede en gezonde communicatie tussen de teams.
• Geeft voldoende tijd die nodig is voor het opzetten van de testomgeving.
• Maakt een vroege beoordeling en goedkeuring van testplannen mogelijk.

V # 9) Differentiëren van verificatie- en validatieprocessen.

Antwoord: Verificatie- en validatieprocessen worden meestal bepaald door twee bekende vragen, namelijk ' Zijn we het systeem goed aan het bouwen? ' en 'Zijn we het juiste systeem aan het bouwen?' ​

Laten we het andere verschil tussen deze twee processen in de onderstaande tabel bekijken:

Vraag 10) Leg de voordelen van destructief onderzoek uit.

Antwoord: Destructief testen wordt gedefinieerd als de vorm van testen die wordt uitgevoerd door het testteam om het punt van falen van het product onder verschillende belastingen te bepalen, d.w.z. om de structurele prestaties van de toepassing te evalueren om de sterkte, taaiheid, hardheid of zeg maar robuustheid te bepalen.

Hieronder worden de voordelen van destructief testen vermeld:

• De zwakte van het applicatieontwerp wordt bepaald.
• Bepaal de levensduur van de applicatie.
• Het helpt om kosten en uitval te verminderen.

V # 11) Wat is het verschil tussen hertesten en regressietesten?

Antwoord: Er zijn verschillende verschillen tussen hertesten en regressietesten.

Dit is gemakkelijk te begrijpen uit de onderstaande tabel:

Vraag 12) Wat weet u over datagestuurd testen?

Antwoord: Het is voor elke automatiseringstester heel duidelijk dat automatiseringstestscripts alleen het gebied van de te testen applicatie bestrijken met een geregistreerde reeks gebruikersacties. Normaal gesproken leveren deze acties geen fouten op, aangezien alleen die invoergegevens worden uitgevoerd onder omstandigheden die we tijdens het opnemen hebben ingevoerd.

Datagedreven testen komt hier in beeld, waarbij we willen dat de applicatie werkt zoals verwacht voor elk type invoerwaarden. Voor dit doel worden gegevens die nodig zijn voor datagestuurd testen niet hard gecodeerd, maar testscripts halen hun gegevens uit gegevensbronnen zoals CSV-bestanden, ODBC-bronnen, enz.

Samenvattend voert datagestuurd testen de volgende acties uit:

it helpdesk interviewvragen en antwoorden pdf

• Neemt input testgegevens uit de opslag.
• Gegevens ingevoerd in de applicatie om acties uit te voeren.
• Controleer de daadwerkelijke resultaten met de verwachte resultaten.
• Herhaal dezelfde stappen opnieuw met nieuwe invoertestgegevens.

V # 13) Wat is de traceerbaarheidsmatrix? Is het vereist voor elk project?

Antwoord: Traceerbaarheidsmatrix in elk project is het middel om de voortgang van het project te volgen met betrekking tot de implementatie van nieuwe functionaliteiten, verbetering van bestaande functionaliteiten, enz. Via een traceerbaarheidsmatrix kunt u altijd de voortgang van het project in de gaten houden, waarbij elk aspect volgens de datum.

Vereiste traceerbaarheidsmatrix bestaat uit de onderstaande parameters die feitelijk overeenkomen met het specificatiedocument van de vereisten.

Parameters van de matrix voor de traceerbaarheid van vereisten omvatten:

• Elk onderdeel van het vereiste document is een punt dat moet worden behandeld in RTM (Requirement Traceability Matrix).
• De kop van elk punt is de kop van elke sectie in de vereiste specificatie.
• Overeenkomstig elk punt worden testcase-id's genoemd die voor die specifieke sectie zijn geschreven.
• BUG / New Feature ID wordt ook in elke sectie vermeld.
• Het belangrijkste punt is dat het volgen van de functie ook wordt bijgehouden waarin de build van het project en de functie ervan is geïmplementeerd.
• Een andere parameter omvat of de sectie volledig is getest of nog in de teststatus verkeert.

Vraag 14) Beschrijf de voordelen van Agile Testing.

Antwoord: Als tester ligt de focus op het leveren van het kwaliteitsproduct in minder tijd door inzicht te krijgen in de eisen van de eindgebruiker en vooral: geen gebreken van de kant van de eindgebruiker. Hier komt Agile testen in beeld, dat het principe van agile softwareontwikkeling volgt en snel de eisen van de klant valideert.

Hieronder worden de voordelen van Agile testen genoemd:

• Een multifunctioneel agile team wordt bij het testen betrokken, dat op zijn beurt de resultaten met regelmatige tussenpozen levert.
• Bespaart veel tijd en geld.
• Bevat minder documentatie en tijd tot tijd feedback van de eindgebruiker.
• Niet alleen de tester, maar het hele team, inclusief de manager, klant en ontwikkelaar, is betrokken bij persoonlijke communicatie.
• Door dagelijkse bijeenkomsten kunnen issues vooraf goed worden bepaald.
• Verhoging van de teamproductiviteit en een beter begrip van de technische aspecten van het project.

V # 15) Wat is negatief testen?

Antwoord: Negatief testen is de methode om ervoor te zorgen dat de stabiliteit van een product of applicatie behouden blijft of zeg maar niet faalt wanneer er onverwachte input wordt gegeven. Het belangrijkste doel van deze vorm van testen is om de applicatie te valideren tegen mogelijke ongeldige invoergegevens.

Deze vorm van testen wordt ook wel ‘Testen op fouten’ of ‘testen van fouten in het pad’ en het belangrijkste doel is om de betrouwbaarheid van de applicatiefunctie onder negatieve scenario's te controleren. Het legt ook zwakke plekken in de software bloot, ontdekt de fouten en geeft een duidelijk beeld van datacorruptie.

V # 16) Onderscheid maken tussen ad-hoc testen en verkennende tests?

Antwoord: Er zijn verschillende verschillen tussen ad-hoc testen en verkennende testen.

Laten we eens kijken naar de verschillen in de onderstaande tabel:

V # 17) Waarom heeft automatiseringstests de voorkeur boven handmatige tests?

Antwoord: Welnu, zowel automatiseringstests als handmatige tests hebben hun belang en bestaan ​​in de wereld van testen.

Hieronder worden enkele belangrijke aspecten gegeven waardoor automatiseringstesten de voorkeur hebben boven handmatig testen:

• Hetzelfde testscript kan elke keer worden gebruikt om de test uit te voeren, dus automatiseringstests worden als de meest betrouwbare en efficiënte beschouwd.
• Vooral bij regressietesten en herhaalde uitvoering de voorkeur.
• Automatiseringstesten worden bij langdurige uitvoering als kosteneffectief beschouwd en zorgen zo voor een betere kwaliteit van software.
• Testscripts zijn herbruikbaar, snel en iedereen kan de resultaten zien.
• Tools die worden gebruikt voor automatiseringstests zijn sneller en betrouwbaarder in vergelijking met de handmatige aanpak.

Er zijn echter nog een aantal factoren die bepalen dat automatiseringstests de voorkeur hebben boven handmatige tests. Het bovenstaande zijn de belangrijkste factoren.

Vraag 18) Wat verstaat u onder ‘Testeffectiviteit’ en ‘Testefficiëntie’?

Antwoord: Test efficiëntie kan worden gedefinieerd als het berekenen van het aantal bronnen en testcode dat wordt gebruikt om een ​​bepaalde functie uit te voeren of, bijvoorbeeld, uit te voeren. Het bepaalt ook het aantal bronnen dat wordt gebruikt bij het maken van softwareproducten.

Dit kan worden bepaald door de formule:

Test efficiëntie = (Aantal opgeloste defecten / totaal aantal ingediende defecten) * 100

Test de effectiviteit kan worden gedefinieerd als de maatstaf voor het evalueren van de testomgeving en het effect ervan op de softwareapplicatie. Hier wordt de reactie van de klant geëvalueerd wanneer aan de toepassingsvereiste is voldaan.

Dit kan worden bepaald door de formule:

Testeffectiviteit = (Aantal gevonden defecten / aantal uitgevoerde testcases)

V # 19) Leg het proces van Project Tailoring uit.

Antwoord: Projectafstemming is een consistent en continu proces dat ervoor zorgt dat de prestaties van het project correct zijn en voldoen aan de zakelijke vereisten. Het hele proces omvat het herzien en aanpassen van de projectgegevens volgens de huidige operationele behoefte van de organisatie.

Het beoordelingsproces vindt plaats op organisatieniveau, maar de implementatie van de op maat gemaakte plannen gebeurt op projectniveau. Het belangrijkste doel en de vereisten van de organisatie, evenals de relaties met klanten en gebruikers, zijn de twee belangrijkste factoren waarmee tijdens het proces rekening moet worden gehouden.

Enkele aspecten volgens de organisatiedoelen onder het maatwerkproces zijn:

• Projectbenadering
• Strategieën
• Betrokken controles en processen
• Rollen en verantwoordelijkheden

V # 20) Hoe maakt u onderscheid tussen prioriteit en ernst van het defect binnen het project?

Antwoord: Zowel ‘Prioriteit’ als ‘Ernst’ wordt toegewezen aan de bug voor het categoriseren van de problemen / bugs voor de volgorde waarin ze moeten worden genomen voor het oplossen. Deze zijn gebaseerd op verschillende factoren.

Laten we meer begrijpen, samen met hun verschillen in de onderstaande tabel:

V # 21) Waarom moeten prestatietests worden uitgevoerd voor elke toepassing?

Antwoord: In eenvoudige taal worden prestatietests uitgevoerd om het gedrag en de reactie van een applicatie onder verschillende situaties te bepalen. Dit helpt om informatie te verzamelen over applicatiestabiliteit, schaalbaarheid, snelheid, etc.

De redenen voor het uitvoeren van prestatietests kunnen worden afgeleid uit de onderstaande punten:

• Het bepaalt de reactietijd en prestaties van een applicatiecomponent onder de werkdruk.
• De reactietijd van de activiteit van de gebruiker wordt berekend.
• Vereist ervaren programmeurs met uitgebreide technische taal.
• Bepaalt het gedrag van de applicatie onder belasting, d.w.z. wanneer het aantal gebruikers onmiddellijk toeneemt.

V # 22) Wat is specificatiegestuurd testen?

Antwoord: Zoals de naam zelf definieert, wordt specificatiegestuurd testen gedaan op basis van de specificatie van de vereisten van de applicatie, waarbij functionele specificaties dienen als basis voor de uitgevoerde tests.

Deze vorm van testen is hetzelfde als ‘Black box testing’ waarbij de gebruiker meerdere gegevens invoert en vervolgens wordt de output geobserveerd. Het is geschikt voor alle testniveaus met specificatie en testplan.

Q # 23) CMMI uitleggen.

Antwoord: CMMI staat voor Capability Maturity Model Integration. Dit model is ontwikkeld door het Software Engineering Institute (SEI). Het is gebaseerd op het principe dat de processen die betrokken zijn bij het beheren en ontwikkelen van een product of systeem de kwaliteit bepalen.

Het geeft ook richtlijnen voor procesverbetering voor het product of zelfs voor de hele organisatie.

CMMI is onderverdeeld in 5 niveaus, zoals hieronder vermeld:

• Niveau 1: Eerste
• Level 2: Beheerd
• Niveau 3: Bepaald
• Niveau 4: Kwantitatief beheerd
• Niveau 5: Geoptimaliseerd

Vraag 24) Leg de voordelen uit van het implementeren van CMMI.

Antwoord: Er zijn verschillende voordelen aan het implementeren van CMMI.

Ze zijn als volgt opgesomd:

• Het biedt een gedetailleerde dekking en rapportage van de productlevenscyclus en helpt zo bij procesverbeteringen.
• De bestaande standaarden van de organisatie, hun processen en procedures worden verbeterd als onderdeel van de CMMI-implementatie.
• Als gevolg van de implementatie van CMMI is er een toename in tijdige levering en klanttevredenheid.
• Het leidt ook tot effectief beheer en hogere kostenbesparingen doordat fouten vroegtijdig worden ontdekt.

Vraag 25) Schakel enkele automatiseringstesthulpmiddelen in.

Antwoord: Enkele van de automatiseringstesttools worden hieronder vermeld:

• Selenium
• water
• Windmolen
• ZEEP
• Tellurium

V # 26) Kunnen we regressietesten uitvoeren in unit-testen?

Antwoord: Vast en zeker. Regressietesten zijn het testen van het ongewenste defect dat mogelijk in de code is geïntroduceerd als bijwerking van het verhelpen van andere defecten. Unit testing is de testuitvoering van het uitvoeren van een klein, onafhankelijk en individueel deel van de code.

Regressietesten kunnen op elk niveau worden uitgevoerd, van unit-testen tot integratietesten en uiteindelijk acceptatietesten. Regressietesten is testen op basis van perspectief, terwijl Unit-testen de benadering van niveau is (Bottom Up, Top-down).

Q # 27) Wat is het verschil tussen rooktesten en gezondheidstesten?

Antwoord:

• Rooktesten is het testen van de oude prominente kenmerken of bestaande kenmerken van de build, terwijl Sanity-testen de validatie is van nieuw toegevoegde modules, vaste defecten in de build.
• Rooktesten vinden eerst plaats en worden daarna gevolgd door Sanity-testen.
• Rooktesten omvatten het testen van kritieke functionaliteiten die door de software worden verzorgd, zodat deze zich door de hele software uitstrekt. Sanity-testen, aan de andere kant, zijn beperkt tot alleen de recent toegevoegde modules en worden diepgaand getest.

Q # 28) Wat zijn uw dagelijkse werkzaamheden als handmatige tester op kantoor?

Handboek: Het eerste dat ik in mijn systeem controleer, is het dashboard vernieuwen voor de status van vereisten / verbeteringen of bugs in de huidige iteratie. Het wordt gevolgd door dagelijkse scrum-oproepen en rapportage-, discussie- en brainstormsessies om te definiëren met testscenario's en testcases.

Deze gevallen worden vervolgens uitgevoerd nadat ze opnieuw zijn opgesteld volgens de beoordeling. Het contact met klanten voor niet-functionele vereisten is ook een van de belangrijkste activiteiten op mijn bord.

Q # 29) Wat zijn uw dagelijkse werkzaamheden als lid van de automatiseringstester op kantoor?

Automatisering: Mijn dag begint met een dagelijkse statusbijeenkomst waarin de automatiseringsresultaten van gisteren worden besproken, voor het geval ik een reeks testcases heb afgevuurd op de nieuwe build.

De uitvoeringscyclus kan een Health Check worden genoemd, om te zien hoe gezond de build is.

Het wordt gevolgd door het melden van defecten op basis van de scriptfouten, ontwerpwijzigingen in de functionaliteit; onderhoud de scripts / bibliotheken of functies, automatiseer en check in in een nieuw script voor de nieuwe vereisten en indien nodig een nieuwe functie in de functiebibliotheek.

Soms moeten de testscripts afzonderlijk opnieuw worden uitgevoerd om regressiedefecten via automatisering te vinden en deze ook aan de testsuite toe te voegen.

V # 30) Hoe maakt u onderscheid tussen een vereiste en een defect en een verbetering?

Antwoord : NAAR vereiste is een user story die essentieel is om geïmplementeerd, getest en opgeleverd te worden.
Een verbetering is een toegevoegde of geïmproviseerde functie aan de bestaande.
NAAR defect is eerder een volledige afwijking van de verwachte gebruikersverhalen.

Als een defect een bepaald gebied van een vereiste aan het licht brengt dat niet is vermeld, tenzij anders in de specificatie is vermeld, kan het ook worden genoemd als een vereiste of een onderdeel ervan.

Vraag 31​ Wat doe je als je ontwikkelaar ontkent dat je een bug hebt opgelost die je hebt ingediend?

Antwoord : Een belangrijke factor die het verhelpen van een defect bepaalt, is de 'Prioriteit' die eraan wordt toegekend. Als het defect een hoge prioriteit heeft, een showstopper, die een belangrijke functionaliteit blokkeert en consistent wordt gereproduceerd, moet dit in de build worden opgelost.

Hetzelfde moet effectief worden overgebracht op ontwikkelaars, aangezien testers en ontwikkelaars samen bijdragen aan de kwaliteit van het te verzenden product.

Andere aspecten die de ontwikkelaar kunnen helpen overtuigen om een ​​bug binnen een korte periode te verhelpen, zijn kwaliteitsrapportage van de bug en de ontwikkelaars laten inzien dat het oplossen van een bug van het grootste belang is bij de release.

Q # 32) Wat doe je als je ontwikkelaar ontkent dat wat je hebt ingediend EEN BUG IS?

Antwoord : Een zeer belangrijke fase van de defectlevenscyclus is ‘Afgewezen’, wat betekent dat het geregistreerde incidentrapport niet geldig is. Het bedrijfsvereisten-document met daarin de vereisten kan helpen om de software en daarmee de aard van het gemelde incident te begrijpen.

Analyseer de bug en vertel uw bevindingen over de bug aan de ontwikkelaar en het team. Als het een defect is, meld het dan altijd. Soms moeten testers een Gap-analyse maken en deze aan ontwikkelaars presenteren. Als dat de conflicten niet oplost, moeten senior mensen in het team meedoen.

Q # 33) Wat komt er eerst opnieuw testen of regressietesten?

Antwoord : Opnieuw testen komt op de eerste plaats omdat het de code opnieuw uitvoert, in eenvoudiger bewoordingen is het een herhaalde uitvoering van vooraf gedefinieerde stappen. Het hoeft niet nodig te zijn na het corrigeren van een code. Maar een regressietest is om de bijwerkingen van een opgelost defect te beoordelen.

Het oplossen van een defect en het toevoegen van een ander aan de code is zeker niet het doel van het testproces. De beste vondsten en beste vangsten van testers zijn meestal regressiedefecten. Een build mag nooit worden vrijgegeven zonder te zijn getest op regressie.

Q # 34) Wat is een alternatief voor bètatests?

Antwoord : Bètatests worden gehouden op de locatie van de klant met de minste betrokkenheid van ontwikkelaars, waarbij de fouten in de echte productieomgeving worden geregistreerd. Als een dergelijke praktijk niet door een bedrijf wordt uitgevoerd, kan het veiliger zijn om het product eerst naar de klanten te verzenden die niet in de wachtrij staan ​​om de laatste build te krijgen.

Een aantal dagen lang kunnen bepaalde serviceadviseurs bij de klant de software gebruiken, de activiteiten registreren en bewaken die de stabiliteit van de release in hun omgeving verzekeren, zodat zelfs als een grote bug wordt weggelaten om te worden verholpen, eerder kan worden getest. het bezorgen aan de beoogde klant. Een andere benadering is het verwisselen van het testen van de vereisten binnen een team voor onbevooroordeeld testen.

Q # 35) Wat zijn de nadelen van de Agile implementatie / methodologie waarmee u te maken kreeg?

Antwoord ​ De nadelen zijn als volgt:

1. Sprints hebben meestal een zeer beperkte deadline.
2. Documentatie is niet de prioriteit
3. Het wisselen tussen PBI's (Product Backlog Items) kan frequent zijn.

Q # 36) Waarom is impactanalyse belangrijk?

Antwoord : Om risicogebaseerd te oefenen, moet een impactanalyse worden uitgevoerd. Door dit te doen kunnen testcases zo worden ontworpen dat alle ernstige bugs, die kritiek zijn vanuit het oogpunt van de klant, voor tijd kunnen worden opgelost. Er moet voor een goede studie van het bedrijf, de behoefte van de klant en hun gebruik van de software worden gezorgd.

Bijvoorbeeld, Het belangrijkste risico van software in het bancaire domein is beveiliging. Elk nieuw formulier dat aan de reeds bestaande software wordt toegevoegd, kan kwetsbaar zijn. Een goede hoeveelheid beveiligingstests is aan te raden door de juiste links, omleidingen en navigatie naar de juiste pagina toe te voegen en, indien nodig, proxy te installeren.

Q # 37) Met behulp van een voorbeeld elke Performance Testing, Stress Testing en Load Testing?

Antwoord : Het beste geval dat hier kan worden genomen, is een live website.

Prestatietesten wordt gedaan om de storingen in het systeem te verifiëren wanneer deze een toestand doorlopen die lijkt op een real-time scenario. Het is niet nodig om onder stressvolle omstandigheden te worden uitgevoerd. De resultaten van prestatietests helpen om vast te stellen of het systeem klaar is om in productie te gaan.

Voor een eenvoudige boekingsstroom voor tickets kan een prestatieprobleem traagheid hebben veroorzaakt. Sommige query's met joins zijn bijvoorbeeld een beetje langzamer en hebben een onnodige clausule of opslag van gegevens op onjuiste wijze in de database geïmplementeerd.

Stress testen is een type prestatietest dat wordt uitgevoerd door de software onder extreme omstandigheden te plaatsen (zware en niet-verdeelde belastingen, beperkte rekenkracht, hoge gelijktijdigheid).

Als een systeem bepaald gedrag vertoont, zoals verloren of beschadigde gegevens, middelen die zelfs worden gebruikt nadat stress is verwijderd, onverantwoordelijkheid of onverwerkte uitzonderingen, betekent dit dat het niet is geslaagd voor stresstests. Soms kan een schijfstoring, een onnodige toename van het aantal GDI's, ook het resultaat zijn.

Bijvoorbeeld, Als de website gehost wordt op een computer die al enorm veel geheugen verbruikt of deze bombardeert met herhaalde verzoeken, zou je niet moeten blijven hangen of je uitloggen.

Laadtesten observeert het systeemgedrag terwijl de belasting van het systeem constant wordt verhoogd totdat een drempel is bereikt. Werkbelastingsmodellen, meetgegevens en belastingsniveaus zijn meestal de input voor de belastingtests.

Bijvoorbeeld, de tijd om de beschikbaarheid van stoelen voor een trein op te halen, neemt geleidelijk toe wanneer het tijdstip van het boeken van Tatkal-quota dichterbij komt, aangezien het aantal gebruikers dat vervolgens op het systeem is ingelogd toeneemt naarmate de Tatkal-boekingstijd bijna 10 uur of 11 uur nadert.

Q # 38) Wat was een van uw grootste uitdagingen tijdens het uitvoeren van regressietests?

Antwoord : Er kunnen verschillende uitdagingen zijn tijdens het uitvoeren van regressietests.

• Het herhaaldelijk opnieuw uitvoeren van tests kan voor testers niet zo opwindend worden.
• Tijdrovend, aangezien voor dergelijke tests soms out of the box-denken nodig is.
• Gecompromitteerde bedrijfswaarde.
• Onjuiste selectie van regressietestgevallen kan een groot regressiedefect overslaan dat wordt gevonden.
• Het reproduceren van het defect tijdens de productie wordt daarom inconsistent.
• Grote suite om uit te voeren.

Q # 39) Als u wordt gevraagd om testscenario's, testgevallen, testplannen, teststrategie te documenteren, waar begint u dan en in welke volgorde volgt de rest?

Antwoord : De volgorde is Teststrategie, Testplan, Testscenario's en tenslotte Testcases.

Q # 40) Wat moet ik doen als ik een van de bovenstaande documenten niet documenteer? Stel dat ik het testplan niet heb gedocumenteerd, wat zijn de gevolgen?

Antwoord : Als we het documenteren van het testplan missen, zal er een leegte zijn voor de reikwijdte van het testen van de objectieve aanpak en de nadruk op testen. Het zal dan moeilijk zijn om de te testen functies, de te testen technieken, de criteria voor slagen of falen te bepalen en uiteindelijk een groot risico verbonden aan het testen.

Q # 41) Hoe zou je beginnen met het testen van de build die je onlangs hebt gekregen: Is er een benadering die je volgt, bijv. beginnen met het testen van rook en vervolgens het testen van gezond verstand?

Antwoord : Rook testen> Sanity testen> Exploratory Testing> Functionality Testing> Regressietesten en eindproduct validatie.

Q # 42) Verklaar het formaat van het bugrapport dat u heeft gevolgd.

Antwoord ​

Een bugrapport moet de volgende informatie bevatten:

• Bug-id
• Toewijzing aan vereiste / verbetering / bestaande bug
• Bugsamenvatting / titel
• Een versie van het product
• Prioriteit
• Configuratie (systeemspecificaties)
• Eerste vereisten
• Stappen
• Verwachte uitkomst
• Werkelijk resultaat
• Logboeken. Momentopnamen, videoclips
• Toestand
• Andere opmerkingen

Q # 43) Hoe selecteer je regressietestgevallen of hoe vorm je de regressietestreeks?

Antwoord : Ja. Dit is een uitkomst van impactanalyse. Het is een eenvoudige mapping van de functies die worden gebruikt of geopend in verschillende gebieden die u test, de integratie ervan met andere functies en doorlopend als end-to-end- of stroomtests van een systeem.

U kunt ook defecten ophalen die eerder voor dezelfde functionaliteit in eerdere builds zijn ingediend. Idealiter zou één defect regressietest moeten worden met behulp van ten minste vijf verschillende testcases die de functionaliteit gebruiken.

Q # 44) Kunt u een voorbeeld geven van de volgende defecten

• Lage prioriteit Hoog Ernstig defect
• Hoge prioriteit en lage ernst defect

Antwoord : Een defect dat de toepassing laat crashen wanneer het alleen op een bepaald tijdstempel op een bepaald besturingssysteem wordt gereproduceerd, kan een defect met een hoge ernst en een lage prioriteit zijn.

Een defect dat wordt ingediend tegen een weergave die niet opent door te dubbelklikken, maar opent met een rechterklik, kan een defect met hoge prioriteit en weinig ernst zijn.

Q # 45) Schrijf een effectieve testcase om te testen of een bepaald artikel een wit papier is?

Antwoord: Als de kleur van de broninkt waarmee u op wit papier schrijft, hetzelfde blijft, is het papier wit. Als u bijvoorbeeld met rode inkt op wit papier schrijft, blijft de kleur van de inkt rood in de pen en verschijnt ook rood op het papier.

Notitie: Er zijn veel andere antwoorden op deze vraag. Je kunt zo'n geldig antwoord met onderliggende logica bedenken.

Q # 46) Wat is chartertesten?

Antwoord: Een sessietest die wordt uitgevoerd op basis van de doelen en agenda's die onder een charter worden vermeld voordat met testen wordt begonnen, staat bekend als chartertesten.

Het testen hier wordt gedaan in een vast tijdvak met een minder focus op documentatie en meer focus op alleen testen. Het is een andere variant van verkennend testen waarbij de testingenieurs de software in een tijdsbestek verifiëren ( Bijvoorbeeld, slechts 2 uur) op basis van enkele ontwikkelde heuristieken.

Q # 47) Wat is uw aanpak als u een release met hoge prioriteit heeft die in zeer korte tijd moet worden geleverd?

Antwoord: In dergelijke gevallen kan een goed doordacht plan nuttig zijn.

Het volgende kan worden gedaan om te helpen bij het testen in een scenario met tijdgebrek: -

• Bestaande bijgewerkte automatiseringsscripts gebruiken voor het uitvoeren van regressietests.
• Op stromen gebaseerde scenario's van begin tot eind testen.
• Uitvoeren van testcases met hoge prioriteit en als de tijd het toelaat, overschakelen naar cases met lagere prioriteit.
• Het opnieuw testen van de bugs met hoge prioriteit die in eerdere versies zijn ingediend.
• Snelle softwaretests
• Ontwikkelaars kunnen worden gevraagd om unit-tests uit te voeren om meer testdekking te krijgen.

Q # 48) Schrijf testcases op elk apparaat / object dat in de buurt aanwezig is (voorbeeld: een stoel)?

Antwoord: Een advies hier zou zijn: Begin altijd met het verzamelen van vereisten. Het toont uw volwassenheid richting de levenscyclus van softwareontwikkeling. Stel gerust vragen na het selecteren van het object.

In dit geval:-

• Wat voor soort stoel is het? Bureaustoel, studeertafelstoel, fauteuil, eettafelstoel, comfortstoel?
• Van welk materiaal is de stoel gemaakt: hout, staal, plastic, bekleding?
• Vraag naar de afmetingen (hoogte, gewicht afhankelijk van het type stoel).
• Vraag naar beschikbaarheid. En op basis daarvan beginnen met het opstellen van uw cases.

Testgevallen zouden voor elk type stoel verschillen, wat beter wordt overgelaten aan uw denkvermogen ( Bijvoorbeeld, doel van de stoel, afmetingen volgens het type stoel, draagbaar - niet drinkbaar, lichtgewicht, aankoopopties).

Voor elke stoel een prestatietestgeval kan zijn: om de treksterkte of het maximale draagvermogen af ​​te leiden.

Q # 49) Kan alles worden geautomatiseerd?

Antwoord: - Tot op zekere hoogte wel. Maar automatiseringstools hebben, net als andere software, zijn beperkingen. Ook software die wordt getest of Applicatie die wordt getest, wordt steeds geüpgraded.

Er is dus geen garantie dat softwaretests kunnen worden uitgevoerd zonder handmatige tussenkomst. Een tool is immers net zo slim als de tester. Het is gewoon software die weer een andere software test. Het zijn de code / scripts / bibliotheken die intelligent genoeg moeten zijn om defecten te testen en te vinden.

Gevolgtrekking

Ik hoop dat deze oefening je helpt op te warmen met een aantal vragen en je een goede start geeft voor je interviews en je zelfvertrouwen verfijnt bij het beantwoorden van de vragen. Er kunnen ook andere scenario-gebaseerde vragen zijn die uit uw cv / profiel kunnen komen.

Daarom is het altijd aan te raden om een ​​proefgesprek met self pre-hand te oefenen, zodat het interview een win-winsituatie blijkt te zijn voor zowel de interviewer als de kandidaat. Onthoud dat een kwaliteitsanalist meer is dan een testingenieur, van wie de feedback niet alleen belangrijk is voor de kwaliteit van het product, maar ook voor het proces dat wordt gevolgd om de software te testen.

Bedankt en veel succes met de interviews!

Aanbevolen literatuur

• Interview vragen en antwoorden
• 25+ meest populaire ADO.NET interviewvragen en antwoorden
• 25 beste vragen en antwoorden voor agile-tests
• Spock-interviewvragen met antwoorden (meest populair)
• Vragen en antwoorden over ETL-tests
• 20 meest populaire TestNG interviewvragen en antwoorden
• Top 30+ populaire komkommer interviewvragen en antwoorden
• Top 50 meest populaire CCNA interviewvragen en antwoorden