Menu

20 selectieve QA-interviewvragen om het interview in 2021 te wissen

  • Hoofd
  • Andere
  • 20 selectieve QA-interviewvragen om het interview in 2021 te wissen

20 selective qa interview questions clear interview 2021

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Meest gestelde vragen en antwoorden voor QA-interview over kwaliteitsborging om u te helpen bij de voorbereiding op het interview:

Hier zijn enkele van de vragen die ik zou stellen als ik een Quality Assurance Engineer interview.

De vragen zullen meer de nadruk leggen op de kwaliteitsprocessen en de strategie en deze vragen zullen niet worden gesteld voor testen.

Quality Assurance QA Interview Vragen

De QA-ingenieurs zijn meestal mensen die enige tijd in de testindustrie hebben doorgebracht, want als u routekaarten en strategieën maakt, is het altijd gunstig om enige bekendheid in de sector te hebben.

Laten we beginnen!!

Veelgestelde vragen over QA-sollicitatiegesprekken

Laten we beginnen!!

V # 1) Wat is het verschil tussen kwaliteitsborging, kwaliteitscontrole en testen?

Antwoord: Kwaliteitszorg is het proces van het plannen en definiëren van de manier waarop de kwaliteits- (test) processen binnen een team en organisatie worden bewaakt en geïmplementeerd. Deze methode definieert en stelt de kwaliteitsnormen van de projecten vast.

Kwaliteitscontrole is het proces waarbij defecten worden opgespoord en suggesties worden gedaan om de kwaliteit van de software te verbeteren. De methoden die door kwaliteitscontrole worden gebruikt, worden meestal bepaald door kwaliteitsborging. Het is de primaire verantwoordelijkheid van het testteam om kwaliteitscontrole uit te voeren.

Testen is het proces van het vinden van defecten / bugs. Het valideert of de door het ontwikkelteam gebouwde software voldoet aan de eisen die de gebruiker stelt en aan de normen die de organisatie stelt.

Hier ligt de focus vooral op het vinden van bugs en werken de testteams als kwaliteitspoortwachter.

V # 2) Wanneer denk je dat QA-activiteiten moeten beginnen?

Antwoord: Q Een activiteit moet beginnen bij het begin van het project. Hoe eerder het begint, hoe voordeliger het is om de norm te stellen voor het bereiken van de kwaliteit.

De kosten, tijd en inspanningen zijn zeer uitdagend voor het geval de QA-activiteiten vertraging oplopen.

Q # 3) Wat is het verschil tussen het testplan en de teststrategie ​

Antwoord: Teststrategie is op een hoger niveau, meestal gemaakt door de projectmanager, die de algemene aanpak van het testen voor het hele project laat zien, terwijl het testplan beschrijft hoe het testen moet worden uitgevoerd voor een bepaalde toepassing, die onder een project valt.

Vraag 4) Kunt u de levenscyclus van software testen uitleggen?

Antwoord: Levenscyclus van software testen verwijst naar een testproces met specifieke stappen die in een bepaalde volgorde moeten worden uitgevoerd om ervoor te zorgen dat de kwaliteitsdoelstellingen zijn bereikt.

V # 5) Hoe definieer je een formaat voor het schrijven van een goede testcase ​

char to int c ++

Antwoord: Het formaat van Testcase omvat:

  • Testcase-ID
  • Test case beschrijving
  • Ernst
  • Prioriteit
  • Milieu
  • Build-versie
  • Uit te voeren stappen
  • Verwachte resultaten
  • Daadwerkelijke resultaten

V # 6) Wat is een goede testcase?

Antwoord: In eenvoudige bewoordingen is een goede testcase er een waarin een defect wordt gevonden. Maar niet alle testgevallen zullen defecten vinden, dus een goede testcase kan er ook een zijn die alle voorgeschreven details en dekking heeft.

V # 7) Wat zou u doen als u een grote suite heeft die in zeer korte tijd moet worden uitgevoerd?

Antwoord: In het geval dat we minder tijd hebben en het grotere aantal testcases moeten uitvoeren, moeten we prioriteit geven aan de testcase en eerst de testcases met hoge prioriteit uitvoeren en vervolgens doorgaan naar de lagere prioriteitsgevallen.

Op deze manier kunnen we ervoor zorgen dat de belangrijke aspecten van de software worden getest.

Als alternatief kunnen we ook de voorkeur van de klant zoeken naar dat wat volgens hen de belangrijkste functie van de software is, en we moeten beginnen met testen vanuit die gebieden en dan geleidelijk overgaan naar die gebieden die van minder belang zijn.

V # 8) Denk je dat QA's ook kunnen deelnemen om productieproblemen op te lossen?

Antwoord: Vast en zeker!! Het zou een goede leercurve zijn voor QA's om deel te nemen aan het oplossen van productieproblemen. Veel tijdproductieproblemen kunnen worden opgelost door de logboeken te wissen, enkele registerinstellingen te maken of door de services opnieuw te starten.

Dit soort milieuproblemen kunnen heel goed worden opgelost door het QA-team.

Ook als QA inzicht heeft in het oplossen van de productieproblemen, kunnen ze deze meenemen tijdens het schrijven van de testcases, en op deze manier kunnen ze bijdragen aan het verbeteren van de kwaliteit en proberen ze de productiefouten te minimaliseren.

V # 9) Stel dat u een bug in de productie aantreft, hoe zou u er dan voor zorgen dat dezelfde bug niet opnieuw wordt geïntroduceerd?

Antwoord: De beste manier is om direct een testcase voor het productiefout te schrijven en deze op te nemen in de regressiesuite. Zo zorgen we ervoor dat de bug niet opnieuw geïntroduceerd wordt.

Ook kunnen we alternatieve testcases of vergelijkbare soorten testcases bedenken en deze opnemen in onze geplande uitvoering.

V # 10) Wat is het verschil tussen functionele en niet-functionele tests?

Antwoord:

Functioneel testen behandelt het functionele aspect van de applicatie. Deze techniek test of het systeem zich gedraagt ​​volgens de vereisten en specificaties. Deze zijn direct gekoppeld aan de wensen van de klant. We valideren de testcases aan de hand van de gespecificeerde vereisten en zorgen ervoor dat de testresultaten goed of niet slagen.

Voorbeelden omvatten regressie, integratie, systeem, rook, enz

Niet-functioneel testen ​ test anderzijds het niet-functionele aspect van de applicatie. Het richt zich niet op de eis, maar op omgevingsfactoren zoals prestatie, belasting en stress. Deze worden niet expliciet gespecificeerd in de eis maar worden voorgeschreven in de kwaliteitsnormen. Als QA moeten we er dus voor zorgen dat ook deze testen voldoende tijd en prioriteit krijgen.

V # 11) Wat is negatief testen? Waarin verschilt het van positief testen?

Antwoord: Negatief testen is een techniek die valideert dat het systeem zich netjes gedraagt ​​in het geval van ongeldige invoer. Bijvoorbeeld, in het geval dat de gebruiker ongeldige gegevens in een tekstvak invoert, moet het systeem een ​​correct bericht weergeven in plaats van het technische bericht dat de gebruiker niet begrijpt.

Negatief testen verschilt van positieve testen op een manier dat positieve testen valideren dat ons systeem werkt zoals verwacht en de testresultaten vergelijkt met de verwachte resultaten.

De meeste tijdscenario's voor negatief testen worden niet genoemd in de functionele behoeftedocumenten. Als QA moeten we de negatieve scenario's identificeren en voorzieningen hebben om deze te testen.

V # 12) Hoe zou u ervoor zorgen dat uw testen voltooid zijn en een goede dekking hebben?

Antwoord: Vereiste traceerbaarheidsmatrix en testdekkingsmatrices zullen ons helpen te bepalen of onze testcases een goede dekking hebben.

salesforce admin interviewvragen en antwoorden

De matrix voor traceerbaarheid van vereisten helpt ons te bepalen of de testomstandigheden voldoende zijn om aan alle vereisten te voldoen. Dekkingsmatrices helpen ons te bepalen of de testgevallen voldoende zijn om aan alle geïdentificeerde testcondities in RTM te voldoen.

Een RTM ziet er ongeveer zo uit:

RTM

Evenzo Testdekkingsmatrices zien er als volgt uit:

Testdekkingsmatrices

V # 13) Wat zijn de verschillende artefacten waarnaar u verwijst als u de testcases schrijft?

Antwoord: De belangrijkste gebruikte artefacten zijn:

  • Functionele eis specificatie
  • Vereiste begrip van document
  • Gebruik cases
  • Wireframes
  • Gebruikersverhalen
  • Acceptatiecriteria
  • Vaak UAT-testgevallen

V # 14) Ben je er ooit in geslaagd om de testcases te schrijven zonder documenten te hebben?

Antwoord: Ja, er zijn gevallen waarin we een situatie hebben waarin we testcases moeten schrijven zonder over concrete documenten te beschikken.

In dat geval, de beste manier is om:

  • Werk samen met het BA en ontwikkelingsteam.
  • Duik in mails die wat informatie bevatten.
  • Duik in oudere testgevallen / regressiesuite
  • Als de functie nieuw is, probeer dan de wikipagina's of de hulp van de applicatie te lezen om een ​​idee te krijgen
  • Ga bij de ontwikkelaar zitten en probeer de wijzigingen die worden aangebracht te begrijpen.
  • Stel op basis van uw begrip de testconditie vast en stuur deze naar BA of belanghebbenden om ze te beoordelen.

V # 15) Wat wordt bedoeld met Verificatie en validatie ​

Antwoord:

Validatie is het proces waarbij het eindproduct wordt geëvalueerd om te controleren of de software voldoet aan de zakelijke behoeften. De testuitvoering die we in ons dagelijks leven uitvoeren, is de validatieactiviteit die rooktesten, functionele testen, regressietesten, systeemtesten, enz. Omvat.

Verificatie is een proces waarbij de tussenliggende werkproducten van een softwareontwikkelingscyclus worden geëvalueerd om te controleren of we op het juiste spoor zitten om het eindproduct te maken.

V # 16) Wat zijn de verschillende verificatietechnieken die u kent?

Antwoord: Verificatietechnieken zijn statisch. Er zijn 3 verificatietechnieken.

Deze worden als volgt uitgelegd:

(i) Herziening - Dit is een methode waarmee de code / testcases worden onderzocht door het individu anders dan de auteur die het heeft geproduceerd. Het is een van de gemakkelijke en beste manieren om dekking en kwaliteit te garanderen.

(ii) Inspectie - Dit is een technische en gedisciplineerde manier om de defecten in het testartefact of de code te onderzoeken en te corrigeren. Omdat het gedisciplineerd is, heeft het verschillende rollen:

  • Moderator - Vergemakkelijkt de gehele inspectievergadering.
  • Blokfluit - Registreert de notulen van de vergadering, opgetreden defecten en andere besproken punten.
  • Lezer - Lees het document / de code voor. De leider leidt ook naar de volledige inspectievergadering.
  • Producent - De auteur. Ze zijn uiteindelijk verantwoordelijk om hun document / code bij te werken volgens de opmerkingen.
  • Recensent - Alle teamleden kunnen als reviewer worden beschouwd. Deze rol kan ook worden gespeeld door een groep experts, zo stelt het project.

(iii) Doorloop - Dit is een proces waarbij de auteur van het document / code de inhoud leest en de feedback krijgt. Dit is meestal een soort FYI (For Your Information) -sessie in plaats van correcties te zoeken.

Q # 17) Wat is het verschil tussen Laad- en stresstests ​

Antwoord:

Stress testen is een techniek die het gedrag van het systeem valideert wanneer het onder stress wordt uitgevoerd. Om dit uit te leggen, verminderen we de bronnen en controleren we het gedrag van het systeem. We begrijpen eerst de bovengrens van het systeem en verminderen geleidelijk de bronnen en controleren het systeemgedrag.

In Load testen, we valideren het systeemgedrag onder de verwachte belasting. De belasting kan bestaan ​​uit gelijktijdige gebruikers of bronnen die tegelijkertijd toegang hebben tot het systeem.

V # 18) Als u twijfels heeft over uw project, hoe benadert u dit dan?

Antwoord: In geval van twijfel, probeer het eerst op te lossen door de beschikbare artefacten / toepassingshulp te lezen. Vraag bij aanhoudende twijfel een directe leidinggevende of het senior lid van uw team.

Bedrijfsanalisten kunnen ook een goede keuze zijn om twijfels te stellen. We kunnen onze vragen ook doorgeven aan het ontwikkelingsteam in geval van andere twijfels. De laatste optie is om contact op te nemen met de manager en uiteindelijk met de belanghebbenden.

V # 19) Heeft u automatiseringstools gebruikt?

Antwoord: Het antwoord op deze vraag is in hoge mate exclusief voor het individu. Beantwoord alle tools en automatiseringsstrategieën die u in uw project hebt gebruikt.

V # 20) Hoe bepaal je welk stukje software hoeveel testen vereist is?

Antwoord: We kunnen deze factor kennen door de Cyclomatische complexiteit ​

T De techniek helpt om de onderstaande 3 vragen voor de programma's / features te identificeren

  • Is de functie / het programma testbaar?
  • Wordt de functie / het programma door iedereen begrepen?
  • Is het kenmerk / programma betrouwbaar genoeg?

Als QA kunnen we deze techniek gebruiken om het 'niveau' van onze tests te identificeren.

beste software voor het kopiëren van dvd naar harde schijf

Het is een praktijk dat als het resultaat van cyclomatische complexiteit meer of een groter aantal is, we dat stuk functionaliteit als complex van aard beschouwen en daarom concluderen we als tester; dat het stuk code / functionaliteit diepgaande tests vereist.

Aan de andere kant, als het resultaat van de cyclomatische complexiteit een kleiner aantal is, concluderen we als QA dat de functionaliteit minder complex is en beslissen we de reikwijdte dienovereenkomstig.

Het is erg belangrijk om de volledige testlevenscyclus te begrijpen en indien nodig wijzigingen in ons proces te kunnen voorstellen. Het doel is om software van hoge kwaliteit te leveren en op die manier moet een QA alle nodige maatregelen nemen om het proces en de manier waarop het testteam de tests uitvoert te verbeteren.

Ik hoop dat deze QA-interviewvragen en -antwoorden zullen helpen bij het voorbereiden van een kwaliteitsgarantiegesprek.

Aanbevolen literatuur

^