Menu

Software Manual Testing Interviewvragen voor ervaren professionals

software manual testing interview questions

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Meest gestelde, op scenario's gebaseerde interviewvragen voor handmatige tests voor ervaren professionals met gedetailleerde antwoorden:

Ik had onlangs deze unieke ervaring van QA coaching (10 jaar ervaring) voor het bijwonen van een sollicitatiegesprek voor een softwaretest van een klant met een toonaangevend entertainmentbedrijf in Los Angeles. De te testen site was een eenvoudige klantgerichte website (een soort van online tv-kanaal) met zowel web- als mobiele componenten.

Software Manual Testing Interview Vragen

Een adviesbureau projecteerde profielen naar deze klant voor een onsite tester + coördinatorpositie maar geen van hen haalde het testinterviewproces. Dus besloten ze het QA interviewvragen van de vorige aanwezigen en ze gaven me een vragenlijst.

converteer youtube-video naar wav-bestand

Ze wilden dat ik de antwoorden aan de volgende kandidaat zou geven en die zou coachen persoon om succesvol te zijn in het test QA-interview.

Handmatig testen van interviewvragen voor ervaren

Toen ik de lijst met vragen kreeg, was ik verrast en tegelijkertijd ‘niet verrast’. Verbaasd, want de vragen waren erg basic en een ervaren QA van 10 jaar had ze gemakkelijk moeten kunnen beantwoorden. Niet zo verbaasd, want QA is het gebied van IT dat naar mijn mening het meeste onkruid heeft, maar laten we er niet op ingaan.

Nadat ik klaar was met de oefening, dacht ik dat het leuk zou zijn om deze ervaring met de STH-lezers te delen. Voor beginners is dit een goede live-belichting. Voor anderen zal het een vriendelijke herinnering zijn aan hoe belangrijk het is grondbeginselen maakt niet uit hoe ervaren we zijn.

Aanbevolen literatuur​ 101+ vragen en antwoorden over het testen van software.

Hier gaat…..

Handmatig testen van interviewvragen voor ervaren

9 meest voorkomende interviewvragen voor QA Software Testing voor zowel beginners als ervaren kandidaten:

#Q 1) Wat is het proces voor het maken van een testscript?

Antwoord:

Stap 1: is om een ​​grondig begrip te krijgen van de AUT:

  • Dit kan zijn door de vereiste documenten grondig te lezen.
  • Bij gebrek aan documenten kunnen we proberen elk referentiepunt dat we hebben te begrijpen: een eerdere versie van de applicatie of draadframes of schermafbeeldingen

Stap 2: Nadat we de vereisten hebben begrepen, maken we een lijst van de gebieden in deze applicatie die moeten worden getest. Met andere woorden, we identificeren de testvereisten. De focus in deze stap is om te identificeren 'Wat' moet worden getest. Het resultaat van deze stap is een lijst met Testscenario's ​

Stap 3: Zodra we de testscenario's hebben, concentreren we ons vervolgens op 'hoe' we ze kunnen testen. Deze fase omvat het schrijven van gedetailleerde stappen over het testen van een bepaalde functie, welke gegevens moeten worden ingevoerd ( Testgegevens ) en wat is het verwachte resultaat.

Zodra deze 3 stappen zijn voltooid, zijn we klaar om te testen.

#Q 2) Wat zijn de velden in een bugrapport?

Antwoord: De volgende belangrijke velden moeten worden opgenomen in een goed bugrapport ​

  1. Een uniek ID
  2. Defectbeschrijving: een korte beschrijving van wat de bug is.
  3. Stappen om te reproduceren: details over hoe tot de fout te komen, exacte testgegevens, het tijdstip waarop het defect werd gevonden (indien van toepassing) omgeving: alle informatie die kan helpen het probleem opnieuw op te lossen
  4. Module / sectie van de applicatie (indien van toepassing)
  5. Ernst
  6. Screenshot
  7. Verantwoordelijke QA: in geval van eventuele vervolgvragen over dit probleem

#Q 3) Hoe test je klantgerichte software?

Antwoord: Bij elke applicatie die we testen, proberen we te zien of aan een bepaalde set vereisten wordt voldaan door de applicatie of niet. Maar als het gaat om een ​​gebruikersgerichte site, moeten we ons niet alleen concentreren op functionaliteit, maar ook kijken naar een aantal gebruiksfuncties, misschien ook tot op zekere hoogte prestatie- en beveiligingsaspecten.

Het eerste testniveau is ​ Voldoet de site aan zijn functionele eisen.

Bijvoorbeeld​ als het een site voor het beheer van leningen is, moeten we kijken - kan de nieuwe klant een lening aanvragen, kan de bestaande klant toegang krijgen tot hun leninginformatie, is het rentepercentage dat op het geleende bedrag wordt toegepast correct, enz.

Het volgende testniveau is ​hoe gemakkelijk is het om de site te gebruiken, zijn de opties logisch en voldoen ze aan de verwachtingen van de gebruiker of niet.

Bijvoorbeeld​ als de gebruiker 3-4 schermen moet passeren om de basisinformatie in te dienen, zullen ze geïrriteerd raken, dus dergelijke problemen moeten worden aangepakt.

Een ander voorbeeld, na het invoeren van de gebruikersnaam en het wachtwoord, kan de gebruiker op het tabblad klikken, wat betekent dat het besturingselement naar de knop 'Aanmelden' moet gaan, in plaats daarvan zal de gebruiker erg geïrriteerd raken als het gaat annuleren en de ervaring van het gebruik van de site is zal worden gecompromitteerd. Dergelijke problemen moeten worden aangepakt.

Prestatietests in de volledige mate misschien niet binnen het bereik vallen, maar eenvoudige situaties zoals, hoe lang duurt het voordat de zoekresultaten worden weergegeven en hoeveel tijd duurt het voordat het systeem op het piekuur klantgegevens ophaalt - dit zijn enkele voorbeelden van de soort dingen die we in de gaten willen houden.

Veiligheid - voor sites waar een beveiligde login is om toegang te krijgen tot de site, moet de minimale functionaliteit eromheen worden getest. Bijvoorbeeld​ als ik de site langer dan 10 minuten inactief laat, wordt automatisch uitgelogd of niet. Iets zo basaals als dat zou moeten worden gefocust.

#Q 4) Hoe overwin je de uitdaging om geen input-documentatie te hebben voor testen?

binaire boomimplementatie in c ++ broncode

Antwoord: ALS de gedetailleerde standaarddocumentatie zoals BRD en FSD niet beschikbaar zijn, zal de tester afhankelijk moeten zijn van een referentiepunt.

  • Schermafbeeldingen
  • Een eerdere versie van de applicatie
  • Wireframes, enz

Een andere factor die enorm helpt, is om met de ontwikkelaars of de bedrijfsanalisten (indien beschikbaar) te praten om een ​​bevestiging van ons begrip of opheldering te krijgen in geval van twijfel.

Als geen van deze situaties werkt, kunnen we de applicatie conceptualiseren op basis van onze eerdere ervaring met IT-applicaties en de basisset testscripts maken. Wanneer de testfase zich aandient, kunnen we een deel van de testcyclustijd instellen en wat testcasebeheer uitvoeren (de reeds gemaakte scripts perfect maken), zodat we het document hebben voor de volgende fasen.

#Q 5) Hoe te verkrijgen maximale productiviteit van een offshore team?

Antwoord: De sleutel is om ervoor te zorgen dat alle testers op de hoogte zijn van alle modules en dat er geen kennisconcentratie op één plek is. Door iedereen te betrekken bij peer reviews van testscripts, defect meetings en KT-sessies zal iedereen zo goed mogelijk op de hoogte zijn van de applicatie.

Door het concept van teamwerk aan te moedigen, kunnen we de teamleden ook laten samenwerken, elkaar helpen en helpen voor een betere productiviteit.

Regelmatige vervolgvergaderingen helpen ook enorm bij het proces.

#Q 6) Wat zijn de rollen en verantwoordelijkheden van een onsite coördinator? Test hij / zij ook?

Antwoord: De onsite coördinator is een aanspreekpunt voor het offshore team en voor de opdrachtgever voor alle informatie over de testopdracht.

Deze job omvat:

  • KT van en naar offshore en klanten
  • De omgeving klaar maken om te testen
  • Sanity testen, rook testen
  • Testen - de belangrijkste functionaliteit.
  • Bugbeoordeling - gevonden door het offshore-team
  • Bug die wordt toegewezen aan de respectieve dev
  • Metrische gegevens presenteren
  • Afmelden

Ja, zelfs een coördinator ter plaatse moet testen.

#Q 7) Inconsistente bugs - Waarom kan het ter plaatse worden gevonden, maar offshore niet en vice versa - Hoe om te gaan met deze situatie?

Antwoord: Elke bug moet worden opgemerkt en geanalyseerd - of deze nu op locatie of offshore wordt aangetroffen, of deze nu herhaalbaar is of niet. Een echte meerwaarde voor het werk van een tester is wanneer we onszelf betrekken bij het Root Cause Analysis-proces voor een bug in plaats van deze simpelweg te rapporteren.

Enkele van de manieren waarop we deze situatie kunnen aanpakken zijn:

hoe array in java te kopiëren
  • Alle onsite en offshore teamleden moeten een richtlijn volgen dat screenshots moesten worden gemaakt voor elke fout die we tegenkomen - herhaalbaar of niet.
  • Als er logboeken, systeembestanden of iets dergelijks zijn, kan dat ons helpen enig bewijs van het probleem te vinden - we moeten proberen het te vinden.
  • Als we ondanks al deze stappen nog steeds niet kunnen zeggen waarom en wanneer het probleem zich voordoet, moeten we het toch aan de ontwikkelaar melden, met zoveel mogelijk informatie.

#Q 8) Video- / audiogerelateerde tests - Wat houdt dit in?

Antwoord: Hoe een applicatie testen met video of audio?

Hier zijn de belangrijkste punten om te overwegen:

  • Toegangsniveaus (beperkt of niet - wachtwoord gecontroleerd)
  • Verschillende soorten omgevingen
  • Browser compatibiliteit
  • Schermresoluties
  • Internet verbindingssnelheden
  • De specifieke opties op een video - zoals afspelen, stoppen, dempen, enz.
  • Video op grootte
  • Reactie op de video's - reacties (beperkingen op de lengte van de reactie en het aantal reacties dat kan duren)
  • Videoreacties op de video's
  • Interface met sociale netwerksites - Interoperabiliteit
  • Buffersnelheid
  • De video insluiten

#Q 9) ​​Testen van mobiele applicaties - wat houdt het in het kort in?

Antwoord: Mobiele app testen belangrijke testscenario's:

  • Controleer of de app goed werkt met meerdere providers en meerdere apparaten.
  • Bruikbaarheid van de functies op een mobiel scherm.
  • Het testen op verschillende mobiele platforms, zoals Android en iOS.
  • Installaties, verwijderen, app starten met netwerk en zonder netwerk, functionaliteit testen.
  • Netwerkverbindingen - WiFi, 2G, etc.
  • Logboeken op het iOS iPhone-configuratieprogramma voor Android Monitor.bat kunnen worden gebruikt voor foutopsporing.

Dat was het. Nu was het niet zo eenvoudig.

Als laatste opmerking herhaal ik de filosofie bij STH - ken de basis goed, de rest volgt automatisch.

Ik besluit, in de hoop dat deze inspanning nuttig en zinvol zal zijn voor onze lezers. Laat het ons hieronder weten in het opmerkingengedeelte over hoe we het hebben gedaan.

Auteur: Dit bericht is geschreven door ons STH-teamlid Swati Seela.

Aanbevolen literatuur

^