40 popular test qa analyst interview questions
Ofte stilte spørsmål / svar om test / kvalitetssikring analytiker:
Mens du bestemmer deg for karrieren du vil være i, er den avgjørende faktoren ikke bare den du tror kan like å jobbe med.
Men å være i den kategorien krever mange ferdigheter, å forstå ansvaret samt de nødvendige jobboppgavene for karrieren du valgte. Det samme gjelder mens du velger en karriere som QA-analytiker. Det krever ikke bare at du er en god tester, rask lærer, ekstraordinær tenker, men det krever også å være en kompleks problemløser.
Selv om de ovennevnte egenskapene ikke oppnås umiddelbart, krever det selvsagt erfaring og dager med hardt arbeid.
Denne artikkelen vil dekke alle aspekter hvis kunnskap er obligatorisk for å være kvalitetsanalytiker. De ofte stilte spørsmålene og svarene på QA Test Analyst intervjuene som er inkludert her, vil gi deg en klar ide om intervjuforberedelsen.
Populære spørsmål om QA-testanalytiker
Q # 1) Hva er ansvaret til en QA-analytiker?
Svar: QA Analyst er den som sørger for at alle mulige tiltak er tatt for å teste hver funksjon av programvareløsning både funksjonelt og teknisk.
De viktigste ansvarsoppgavene til QA Analyst kan verves som følger:
- Utfør og administrer alle aktivitetene for å oppfylle målene i testplanen.
- Velg prosesser av høy kvalitet for å utvikle produktet.
- Bør kunne analysere krav og dokumentprosedyrer.
- Dokumenter og bekreft alle feil. Angi prioritet og alvorlighetsgrad for feil.
- De skal kunne lage, dokumentere og vedlikeholde testsaker.
- Analyse av testresultater.
Spørsmål 2) Hva er din forståelse av en testplan?
Svar: Når du har en klar ide om hva, når, hvordan og hvem, så blir ting lettere. Det samme er tilfellet også med programvaretesting, hvor testplanen er et dokument som består av omfang, tilnærming, ressurser og oversikt over testprosjektet, samt aktivitetene for å spore fremdriften i prosjektet.
Testplanen er en oversikt over prosesser som inkluderer:
- Testing av oppgaver
- Testmiljø
- Designteknikker
- Inngangs- og utgangskriterier
- Eventuelle risikoer osv.
Q # 3) Oppgi prioriteten til testoppgavene som er definert av QA-teamet i produktutvikling.
Svar: Prioriteten til testoppgavene er definert som følger:
- Det utarbeides en testplan som består av oversikten og omfanget av testprosjektet.
- Testtilfeller er forberedt på å dekke alle hoved- og mindre funksjonaliteter med dataene som kreves for testing.
- Gjennomføring av testtilfellene i henhold til funksjonalitetene som er implementert med de kommende byggene av testprosjektet i testsyklusen.
- Feilrapportering med ny bekreftelse, samt sporing av fremdriften.
- Forbereder sammendraget av testutførelsesrapporten.
Q # 4) Bruk noen av de viktigste utfordringene som står overfor når du utfører programvaretesting.
Svar: Som vi sier at fullstendig testing aldri kan oppnås, er det flere utfordringer involvert i det. Det være seg lite eller komplisert, det er noen utfordringer når du utfører programvaretesting av ethvert prosjekt.
Nedenfor er noen viktige utfordringer:
- Mangel på dyktige tester som vanligvis står overfor problemet med emnebevissthet, samt mangel på god kunnskap om kundens virksomhet.
- Tid blir også sett på som faktoren, da testere vanligvis fokuserer hovedsakelig på oppgavedekning i stedet for testdekning med kvalitetstesting når det er en enorm liste over oppgaver som skal fullføres.
- Å avgjøre hvilken testsak som må utføres først og med prioritet. Dette oppnås vanligvis med erfaring fra arbeid.
- En riktig forståelse av kravene som kan føre til at testingen din blir null, hvis kravet misforstås.
- Utilgjengelighet av de beste verktøyene som kreves for å fullføre testingen med mindre tid og mer effektivitet.
- Håndtere forholdet mellom testere og utviklere med god kommunikasjons- og analyseferdigheter.
Q # 5) Definer bruksteststesting.
Svar: Use Case testing kan defineres som den funksjonelle black-box testteknikken som fanger opp serien av interaksjoner som har skjedd mellom 'skuespillere' og 'system'. Her er ‘Actors’ representert av brukerne og deres interaksjoner.
Kjennetegn ved brukstesten er oppført nedenfor:
- Prosjektets funksjonelle krav er organisert.
- Registrerer banen eller scenariene fra start til slutt.
- Kan dekke integrasjonsfeil, dvs. feilene som oppstod som et resultat av interaksjon mellom forskjellige komponenter.
- Den beskriver hovedstrømmene så vel som den eksepsjonelle flyten av hendelsene.
- Eventuelle forutsetninger som kreves for at brukstilfellet skal fungere, bør spesifiseres tidligere.
Q # 6) Definer teststrategi.
Svar: Et sett med retningslinjer eller testtilnærminger som vanligvis utføres av prosjektlederen for å bestemme testdesign og generell testtilnærming, er definert som teststrategi. Den finnes som en liten del av testplanen og brukes av flere prosjekter.
Forskjellige testtilnærminger følges basert på faktorer som produktets natur og domene, risikoen for produktsvikt, ekspertise i arbeidet med foreslåtte verktøy osv.
Disse tilnærmingene er videre kategorisert som følger:
- Proaktiv tilnærming , der testdesigntilnærmingen starter før bygningen blir opprettet. Dermed hjelper det å finne og fikse feilene før bygningen.
- Reaktiv tilnærming , der testtilnærmingen startes etter fullføring av testdesign og koding.
Q # 7) Forklar forskjellen mellom kvalitetskontroll og kvalitetssikring.
Svar: 'Kvalitetskontroll' og 'Kvalitetssikring' er de to viktigste begrepene som brukes om ethvert testprosjekt eller produkt. Vanligvis forstår ikke testere, som er nye i dette feltet, den faktiske forskjellen mellom de to.
La oss forstå forskjellen ved hjelp av tabellen nedenfor.
Kvalitetssikring | Kvalitetskontroll |
---|---|
Det kommer inn under kategorien Statistisk prosesskontroll. | Det kommer inn under kategorien statistisk kvalitetskontroll. |
Det er en teknikk som brukes for å håndtere kvalitet der alle teammedlemmer er ansvarlige for prosessplanlegging. | Det er en teknikk som brukes for å verifisere kvaliteten der testteamet er ansvarlig for å gjennomføre den planlagte prosessen. |
Programutførelse er ikke involvert i denne prosessen. | Denne prosessen innebærer programutførelse. |
Det er en verifiseringsprosess for å sikre at riktige ting blir gjort. | Det er en valideringsprosess for å sikre forekomsten av forventede resultater. |
Det er en prosessorientert øvelse der problemer / mangler forekomst i applikasjonen ikke blir oppdaget. | Det er en produktorientert øvelse der problemer / mangler forekomst i applikasjonen blir identifisert og rapportert |
Leveranser opprettes i denne kvalitetssikringsprosessen. | Leveranser blir bekreftet i denne kvalitetskontrollprosessen. |
Ikke en tidkrevende aktivitet. | Betraktet som den tidkrevende aktiviteten. |
Spørsmål 8) Ifølge deg, når er det bra å starte QA i et prosjekt?
Svar: I henhold til programvareutviklingens livssyklus (SDLC) blir testfasen utført etter at ”Implementation and Coding” -fasen er fullført. Men i dagens scenario, for å oppnå de beste resultatene, er det nødvendig å starte QA for prosjektet eller produktet ved starten av prosjektet.
Å følge denne tilnærmingen vil føre til de største fordelene nedenfor:
- Tidlig prosessplanlegging for å møte kundens kvalitetsforventninger.
- God og sunn kommunikasjon mellom lagene.
- Gir god tid som kreves for å sette opp testmiljøet.
- Tillater tidlig gjennomgang og godkjenning av testplaner.
Q # 9) Differensier verifiserings- og valideringsprosesser.
Svar: Verifiserings- og valideringsprosesser bestemmes vanligvis av to kjente spørsmål, dvs. Bygger vi systemet riktig? ” og 'Bygger vi riktig system?' .
La oss se den andre forskjellen mellom disse to prosessene i tabellen nedenfor:
Bekreftelse | Validering |
---|---|
F.eks. Inspeksjon, gjennomgang, anmeldelser osv | F.eks. Røykprøving, regresjonstesting, funksjonstesting osv. |
Verifisering er definert som prosessen med å evaluere produktet for å bestemme om det oppfyller kravet og designspesifikasjonene. | Validering er prosessen for å avgjøre om programvaren tilfredsstiller forretningsbehovet eller er egnet til bruk. |
Det regnes som den statiske testteknikken som ikke involverer og utfører programvaren. | Det regnes som den dynamiske testteknikken der kjøring av programvaren gjøres. |
Dette er en menneskelig basert praksis for verifisering av dokumenter, filer, utforming, koding av programmer osv. | Dette er en datamaskibasert praksis for å validere og teste det faktiske produktet. |
Omfatter ikke utførelse av kode. | Involverer utførelse av kode. |
Vanligvis gjort av QA-teamet for å sikre at programvaren er i samsvar med kravspesifikasjonene. | Vanligvis utført av testteamet. |
Utført før valideringsprosessen. | Utført etter bekreftelsesprosessen. |
Q # 10) Forklar fordelene med destruktiv testing.
Svar: Destruktiv testing er definert som testformen som utføres av testteamet for å bestemme feilpunktet for produktet under forskjellige belastninger, dvs. for å evaluere applikasjonens strukturelle ytelse for å bestemme dets styrke, seighet, hardhet eller si robusthet.
Nedenfor er fordelene med destruktiv testing:
- Svakheten ved applikasjonsdesignet bestemmes.
- Bestem levetiden til applikasjonen.
- Det bidrar til å redusere kostnader og svikt.
Spørsmål nr. 11) Hvordan er retesting forskjellig fra regresjonstesting?
Svar: Det er flere forskjeller mellom omprøving og regresjonstesting.
Dette kan lett forstås fra nedenstående tabell:
Regresjonstesting | Test på nytt |
---|---|
Bekreftelse av feilen er ikke inkludert. | Bekreftelse av feilen er delen av omprøving. |
Regresjonstesting er prosessen med å bestemme eller si å finne problemer som kan ha blitt introdusert til den eksisterende funksjonaliteten med kodeendringen. | Retesting er prosessen med å re-verifisere den mislykkede testsaken etter at mangelen er løst. |
Regresjonstesting kan utføres gjennom automatisering. | Kan ikke automatisere testsakene for ny testing. |
Denne testingen utføres vanligvis når det er endring i eksisterende kode eller si noe nytt. | Omprøving gjøres til samme feil med samme miljø, men med rettelsene i nybygget. |
Dette er generisk testing som vanligvis utføres for beståtte testtilfeller. | Dette er planlagt testing som vanligvis utføres for mislykkede testsaker. |
Kan utføres parallelt med omprøving. | Gjøres før regresjonstesting. |
Til og med pass-test-sakene utføres i løpet av denne prosessen. | Bare de mislykkede testsakene blir testet på nytt. |
Spørsmål nr. 12) Hva vet du om datadrevet testing?
Svar: Det er veldig klart for alle automatiseringstester at automatiseringstestskripter bare dekker området av applikasjonen som skal testes med en registrert sekvens av brukerhandlinger. Normalt gir disse handlingene ingen feil, da bare inngangsdata tas under forhold som vi har angitt under opptak.
Datadrevet testing kommer inn i bildet her, der vi vil at applikasjonen skal fungere som forventet for alle typer inngangsverdier. For dette formålet er ikke data som kreves for datadrevet testing ikke hardkodet, men testskripter tar dataene fra datakilder som CSV-filer, ODBC-kilder, etc.
For å oppsummere utfører datadrevet testing følgende handlinger i løkken:
hovedforskjellene mellom c og c ++
- Tar input testdata fra lagringen.
- Data som er angitt i applikasjonen for å utføre handlinger.
- Bekreft de faktiske resultatene med de forventede.
- Gjenta igjen de samme trinnene med nye inngangstestdata.
Spørsmål nr. 13) Hva er sporbarhetsmatrisen? Kreves det for hvert prosjekt?
Svar: Sporbarhetsmatrise i ethvert prosjekt er et middel til å spore fremdriften i prosjektet angående implementering av nye funksjoner, forbedring av eksisterende funksjoner osv. Gjennom en sporbarhetsmatrise kan du alltid holde et øye med prosjektfremdriften med alle aspekter vedlikeholdt iht. dato.
Krav Sporbarhetsmatrise består av de nevnte parametrene som faktisk er i samsvar med kravspesifikasjonsdokumentet.
Parametere for kravsporbarhetsmatrise inkluderer:
- Hver del av kravdokumentet er et punkt som skal dekkes i RTM (Requirement Traceability Matrix).
- Overskriften på hvert punkt er overskriften til hvert avsnitt i kravspesifikasjonen.
- Tilsvarende hvert punkt, er test case ID-er nevnt som er skrevet for den aktuelle delen.
- BUG / New Feature ID er også nevnt i hver seksjon.
- Det viktigste poenget er at sporing av funksjonen opprettholdes der prosjektet og dets funksjon er implementert.
- En annen parameter inkluderer om seksjonen er fullstendig testet eller fortsatt er under teststatus.
Sp # 14) Beskriv fordelene med smidig testing.
Svar: Å være en tester, blir fokuset å levere kvalitetsproduktet på kortere tid ved å forstå sluttbrukerkravet og viktigst, ingen mangler fra sluttbrukerens side. Her kommer Agile testing på bildet som følger prinsippet om smidig programvareutvikling og raskt validerer klientens krav.
Nedenfor er fordelene med smidig testing:
- Et tverrfunksjonelt smidig team er inkludert i testingen, som igjen leverer resultatene med hyppige intervaller.
- Sparer mye tid og penger.
- Inkluderer mindre dokumentasjon og tid til annen tilbakemelding fra sluttbrukeren.
- Ikke bare testeren, men hele teamet, inkludert leder, kunde og utvikler, er involvert i kommunikasjon ansikt til ansikt.
- Som et resultat av daglige møter, kan spørsmål bestemmes på forhånd.
- Økning i teamets produktivitet og bedre forståelse av de tekniske aspektene ved prosjektet.
Sp # 15) Hva er negativ testing?
Svar: Negativ testing er metoden for å sikre at stabiliteten til et produkt eller applikasjon opprettholdes eller si ikke mislykkes når uventede innspill er gitt. Hovedformålet med denne testformen validerer applikasjonen mot eventuelle ugyldige inndata.
Denne formen for testing er også kjent som 'Feiltesting' eller 'feiltest testing' og hovedformålet er å kontrollere påliteligheten av applikasjonsfunksjonen under negative scenarier. Det avslører også programvaresvakhet, oppdager feilene og gir en klar ide om datakorrupsjon.
Spørsmål nr. 16) Skille ad-hoc-testing og utforskende testing?
Svar: Det er flere forskjeller mellom ad-hoc-testing og utforskende testing.
La oss se forskjellene i tabellen nedenfor:
Adhoc-testing | Utforskende testing |
---|---|
Denne formen for testing inkluderer å lære applikasjonen først og deretter fortsette med testprosessen. | Som navnet antyder, inkluderer denne formen for testing å lære applikasjonen mens du tester. |
Noen spesifikke sett med dokumenter for å utføre testing er ikke tilgjengelig. | Testing av søknaden gjøres med det detaljerte settet med dokumenter. |
Det kreves å ha gode hender på erfaring og kunnskap om programvaren før testing. | Kunnskap om programvaren tilegnes mens du utfører utforskende testing. |
Det er en uformell testing som i utgangspunktet følger negativ testing. | Det regnes som formell testing som følger positiv testing. |
Fungerer ikke med arbeidsflyten. | Fungerer med arbeidsflyten. |
Sp # 17) Hvorfor foretrekkes automatiseringstesting fremfor manuell testing?
Svar: Vel, både automatiseringstesting og manuell testing har sin betydning og eksistens i testverdenen.
Nedenfor er noen viktige aspekter som skyldes at automatiseringstesting foretrekkes fremfor manuell testing:
- Det samme testskriptet kan brukes hver gang for å kjøre testen, og dermed anses automatiseringstesting som den mest pålitelige og effektive.
- Mest foretrukket i tilfelle regresjonstesting og gjentatt utførelse.
- Automatiseringstesting anses å være en kostnadseffektiv en i tilfelle langvarig kjøring og sikrer dermed en bedre kvalitet på programvaren.
- Testskript er gjenbrukbare, raske, og alle kan se resultatene.
- Verktøy som brukes til automatiseringstesting er raskere og mer pålitelige sammenlignet med manuell tilnærming.
Selv om noen flere faktorer avgjør at automatiseringstesting foretrekkes fremfor manuell testing. Ovennevnte er de viktigste faktorene.
Sp # 18) Hva forstår du med 'Test effektivitet' og 'Test effektivitet'?
Svar: Testeffektivitet kan defineres som å beregne antall ressurser og testkode som forbrukes for å utføre eller si å utføre en bestemt funksjon. Den bestemmer også antall ressurser som brukes i programvareproduksjonen.
Dette kan bestemmes av formelen:
Testeffektivitet = (Antall mangler løst / totalt antall mangler levert) * 100
Test effektivitet kan defineres som mål for å evaluere testmiljøet og dets effekt på programvaren. Her evalueres kundesvar når søknadskravet er oppfylt.
Dette kan bestemmes av formelen:
Testeffektivitet = (Antall mangler funnet / Antall utførte testsaker)
Q # 19) Forklar prosessen med Project Tailoring.
Svar: Prosjektskreddersøm er en jevn og pågående prosess som sørger for at ytelsen til prosjektet er riktig og er i samsvar med forretningskravene. Hele prosessen inkluderer gjennomgang og endring av prosjektdataene i henhold til det nåværende operative behovet til organisasjonen.
Gjennomgangsprosessen gjøres på organisasjonsnivå, men implementeringen av skreddersyringsplanene gjøres på prosjektnivå. Hovedmålet og kravene til organisasjonen, samt kunde- og brukerforhold, er de to viktigste faktorene som bør vurderes i prosessen.
Få aspekter i henhold til organisasjonsmålene under skreddersyringsprosessen er:
- Prosjekttilnærming
- Strategier
- Kontroller og prosesser involvert
- Roller og ansvar
Spørsmål nr. 20) Hvordan skiller du mellom prioritet og alvorlighetsgrad av feilen i prosjektet?
Svar: Både 'Prioritet' og 'Alvorlighetsgrad' er tilordnet feilen for å kategorisere problemene / feilene i rekkefølgen de skal tas for å fikse. Disse er basert på ulike faktorer.
La oss forstå mer sammen med forskjellene i tabellen nedenfor:
Prioritet | Alvorlighetsgrad |
---|---|
Prioritet bestemmer rekkefølgen utviklerne tar opp manglene / problemene for å fikse. | Alvorlighetsgraden bestemmer innvirkningen av et bestemt problem / en mangel på funksjonaliteten til applikasjonen. |
Dette er knyttet til planlegging av problemene og er drevet av forretningsstandarder. | Dette er både assosiert og er drevet av funksjonalitet. |
Prioritet for emisjonen avgjøres på bakgrunn av kundenes krav. | Alvorlighetsgraden av problemet avgjøres med tanke på de tekniske aspektene ved produktet. |
Kategorisert som 'High', 'Medium' og 'Low'. | Kategorisert som 'Moderate', 'Major', 'Minor', 'Critical'. |
Når en feil har Status: Høy prioritet og lav alvorlighetsgrad Resultat: Defekt påvirker ikke applikasjonen mye, men må rettes umiddelbart. | Når en feil har Status: Høy alvorlighetsgrad og lav prioritet Resultat: Feil må løses, men krever ingen umiddelbar handling. |
Spørsmål nr. 21) Hvorfor er ytelsestesting nødvendig for alle applikasjoner?
Svar: På et enkelt språk gjøres ytelsestesting for å bestemme oppførselen og responsen til en applikasjon under forskjellige situasjoner. Dette hjelper til med å samle informasjon om applikasjonsstabilitet, skalerbarhet, hastighet osv.
Årsakene til å gjøre ytelsestesting kan forstås fra punktene nedenfor:
- Den bestemmer responstiden og ytelsen til en applikasjonskomponent under arbeidsmengden.
- Svartiden for brukerens aktivitet beregnes.
- Krever erfarne programmerere med omfattende teknisk språk.
- Bestemmer oppførselen til applikasjonen under belastning, dvs. når antall brukere øker øyeblikkelig.
Spørsmål nr. 22) Hva er spesifikasjonsstyrt testing?
Svar: Som selve navnet definerer, gjøres spesifikasjonsdrevet testing basert på kravspesifikasjon for applikasjonen der funksjonelle spesifikasjoner ligger til grunn for utførte tester.
Denne formen for testing er den samme som ‘Black box testing’ der brukeren legger inn flere data og deretter observeres utdataene. Det er passende på alle nivåer av testing med spesifikasjon og testplan.
Q # 23) Forklar CMMI.
Svar: CMMI står for Capability Maturity Model Integration. Denne modellen ble utviklet av Software Engineering Institute (SEI). Det er basert på prinsippet om at prosessene involvert i styring og utvikling av et produkt eller system bestemmer kvaliteten.
Det gir også retningslinjer for prosessforbedring for produktet eller til og med hele organisasjonen.
CMMI er delt inn i 5 nivåer som vervet nedenfor:
- Nivå 1: Første
- Nivå 2: Fikk til
- Nivå 3: Definert
- Nivå 4: Kvantitativt administrert
- Nivå 5: Optimalisert
Q # 24) Forklar fordelene ved å implementere CMMI.
Svar: Det er flere fordeler med å implementere CMMI.
De er oppført som følger:
- Det gir detaljert dekning og rapportering av produktets livssyklus og hjelper dermed til prosessforbedringer.
- De eksisterende standardene i organisasjonen, deres prosesser og prosedyrer forbedres som en del av CMMI-implementeringen.
- Som et resultat av CMMI-implementering er det en økning i levering i tillegg til kundetilfredshet.
- Det fører også til effektiv styring og økte kostnadsbesparelser ettersom det er tidlig oppdagelse av feil.
Q # 25) Bruk noen verktøy for automatiseringstesting.
Svar: Noen av verktøyene for automatiseringstesting er vervet nedenfor:
- Selen
- vann
- Vindmølle
- SÅPE
- Tellurium
Q # 26) Kan vi gjøre regresjonstesting i Unit Testing?
Svar: Helt sikkert. Regresjonstesting er å teste den uønskede feilen som kan ha blitt introdusert i koden som en bivirkning ved å fikse andre feil. Enhetstesting er testutførelsen av å kjøre en liten uavhengig og individuell del av koden.
Regresjonstesting kan gjøres på alle nivåer, rett fra enhetstesting til integrasjonstesting til endelig godkjenningstesting. Regresjonstesting er testing basert på perspektiv, mens enhetstesting er tilnærmingen til nivå (Bottom Up, Top-down).
Q # 27) Hva er forskjellen mellom røykprøving og sunnhetstesting?
Svar:
- Røykprøving er testing av de gamle fremtredende funksjonene eller eksisterende funksjoner i bygningen, mens Sanity-testing er validering av nylig tilføyde moduler, faste feil i bygningen.
- Røykprøving skjer først, og deretter blir sunnhetstesting fulgt.
- Røykprøving dekker testing av kritiske funksjoner som programvaren sørger for, slik at den strekker seg gjennom programvaren. Sanity testing, derimot, er innsnevret bare til de nylig tilføyde modulene og er testet i dybden.
Q # 28) Hva er dine daglige aktiviteter som manuell tester på kontoret ditt?
Håndbok: Det første jeg sjekker i systemet mitt er å oppdatere dashbordet for status for krav / forbedringer eller feil i gjeldende iterasjon. Det blir fulgt av daglige scrum-samtaler og rapportering, diskusjon og idédugnad for å definere med testscenarier og testsaker.
Disse sakene blir deretter utført etter omformulering i henhold til gjennomgangen. Forbindelser med kunder for ikke-funksjonelle krav er også en av de viktigste aktivitetene på min plate.
Sp # 29) Hva er dine daglige aktiviteter som medlem av automatiseringstesteren på kontoret ditt?
Automasjon: Dagen min begynner med en daglig statusmøte som diskuterer gårsdagens automatiseringsresultater, i tilfelle jeg har avfyrt en rekke testsaker på nybygget.
Utførelsessyklusen kan kalles en helsekontroll for å se hvor sunn byggingen er.
Det blir fulgt av rapportering av feil basert på skriptfeil, designendringer i funksjonaliteten; vedlikeholde skriptene / bibliotekene eller funksjonene, automatisere og sjekke inn i et nytt skript for de nye kravene og om nødvendig en ny funksjon i funksjonsbiblioteket.
Noen ganger må testskriptene kjøres på nytt individuelt for å finne regresjonsfeil via automatisering og legge dem til i testserien også.
Spørsmål nr. 30) Hvordan skiller du mellom et krav og en mangel og en forbedring?
Svar : TIL krav er en brukerhistorie som er viktig for å implementeres, testes og leveres.
An Forbedring er en ekstra eller improvisert funksjon til den eksisterende.
TIL defekt er heller et fullstendig avvik fra de forventede brukerhistoriene.
Også, hvis en mangel avdekker et bestemt område av et krav som ikke er oppgitt med mindre annet er angitt i spesifikasjonen, kan det også kalles som et krav eller en del av det.
Q # 31) Hva gjør du når utvikleren din nekter å fikse en feil som du arkiverte?
Svar : En viktig faktor som avgjør å fikse en mangel er “Prioritet” som er tildelt den. Hvis feilen er av høy prioritet, en utstillingsstopper som blokkerer en hovedfunksjonalitet og gjengis konsekvent, er det nødvendig å fikse det i bygningen.
Det samme må formidles effektivt til utviklere siden testere og utviklere sammen bidrar til kvaliteten på produktet som skal sendes.
Andre aspekter som kan bidra til å overbevise utvikleren om å fikse en feil i løpet av en kort periode, er kvalitetsrapportering av feilen og å få utviklerne til å forstå det faktum at å fikse feil er av største betydning i utgivelsen.
Q # 32) Hva gjør du når utvikleren din benekter at det du sendte inn ER EN BUG?
Svar : En viktigste fase av mangelens livssyklus er ‘Avvist’, noe som betyr at den loggede hendelsesrapporten ikke er gyldig. Forretningskravdokumentet som angir krav kan bidra til å forstå programvaren og dermed arten av den rapporterte hendelsen.
Analyser feilen og avslør funnene dine om feilen for utvikleren og teamet. Hvis det er en feil, må du aldri logge den. Noen ganger må testere gi en Gap-analyse og presentere det samme for utviklere. Hvis det ikke løser konfliktene, burde seniorfolk i laget slå inn.
Sp # 33) Hva kommer først Re-testing eller Regression testing?
Svar : Omprøving kommer først siden den kjører koden på nytt, i enklere termer er det en gjentatt kjøring av forhåndsdefinerte trinn. Det trenger ikke å være nødvendig etter å ha løst en kode. Men en regresjonstest er å vurdere bivirkningene av en løst feil.
Å løse en feil og legge til en annen i koden er absolutt ikke hensikten med testprosessen. De beste funnene og de beste fangstene av testere er vanligvis regresjonsfeil. En bygning skal aldri slippes uten regresjonstest.
Q # 34) Hva er et alternativ til betatesting?
Svar : Betatesting holdes på klientens nettsted med minst involvering av utviklere, og registrerer feilene i det virkelige produksjonsmiljøet. Hvis en slik praksis ikke utføres av et firma, kan en tryggere idé være å sende produktet først til kundene de som ikke står i køen for å få den siste versjonen.
I et par dager kan visse servicekonsulenter hos klienter bruke programvaren, registrere og overvåke aktivitetene som sikrer stabiliteten i utgivelsen i deres miljø, slik at selv om en stor feil blir utelatt for å bli løst, kan den testes før levere den til den målrettede klienten. En annen tilnærming er byttet testing av kravene i et team for upartisk testing.
Q # 35) Hva er ulempene med Agile implementering / metodikk som du møtte?
Svar : Ulempene er som følger:
- Sprints er vanligvis svært begrenset.
- Dokumentasjon er ikke prioritert
- Det kan være hyppig å bytte mellom PBI-er (Product Backlog Items).
Q # 36) Hvorfor er konsekvensanalyse viktig?
Svar : For å øve risikobasert må konsekvensanalyse gjøres. Ved å gjøre dette kan testtilfeller utformes slik at alle de alvorlige feilene, kritiske fra kundens syn, kan løses før tiden. En god studie av virksomheten, kundens behov og deres bruk av programvaren skal ivaretas.
For eksempel, den viktigste risikoen forbundet med programvare i banksektoren er sikkerhet. Ethvert nytt skjema som legges til den allerede eksisterende programvaren, kan være sårbart. Det anbefales å ta en god del sikkerhetstesting ved å legge til riktige lenker, omdirigering og navigering til riktig side, ved å installere proxy om nødvendig.
Q # 37) Ved hjelp av et eksempel hver ytelsestesting, stresstesting og belastningstesting?
Svar : Det beste tilfellet her som kan tas er et live nettsted.
Ytelsestesting er gjort for å verifisere feilene i systemet når det gjennomføres i en tilstand som ligner på et sanntidsscenario. Det er ikke nødvendig å utføres under stressede forhold. Resultatene av ytelsestesting hjelper til med å fastslå om systemet er klart til å gå i produksjon.
For en enkel flybillettbestilling kan et ytelsesproblem ha forårsaket treghet. For eksempel er noen spørsmål ved bruk av sammenføyninger litt langsommere som har implementert unødvendig klausul eller lagring av data upassende i databasen.
Stresstesting er en type ytelsestesting som utføres ved å sette programvaren under ekstreme forhold (tunge og ikke-distribuerte belastninger, begrensede beregningsressurser, høy samtidighet).
Hvis et system viser en viss oppførsel som data som går tapt eller er ødelagt, ressursene brukes selv etter at stress er fjernet, uansvarlighet eller ubehandlede unntak, betyr det at det mislykkes i stresstesting. Noen ganger kan disksvikt, en unødvendig økning i GDI-antall også være resultatet.
For eksempel, Hvis nettstedet er vert på en maskin som allerede bruker enormt minne eller bombarderer det med gjentatte forespørsler, bør du ikke henge eller logge deg av.
Lastetesting observerer systematferden mens den stadig øker belastningen på systemet til en terskel er nådd. Arbeidsbelastningsmodeller, beregninger og lastnivåer er vanligvis inngangen til lastetesting.
For eksempel, tiden for å hente setetilgjengelighet for et tog øker gradvis når tidspunktet for bestilling av Tatkal-kvoten nærmer seg siden antall brukere som deretter er logget inn i systemet øker med Tatkal-bestillingstiden nær 10.00 eller 11.00.
Q # 38) Hva har vært en av dine største utfordringer mens du gjorde regresjonstesting?
Svar : Det kan være forskjellige utfordringer når du utfører regresjonstesting.
- Å utføre tester gjentatte ganger blir kanskje ikke så spennende for testere.
- Tidkrevende, siden slike tester noen ganger trenger å tenke ut av boksen.
- Kompromittert forretningsverdi.
- Feil valg av tilfeller med regresjonstest kan hoppe over en større regresjonsfeil.
- Å reprodusere mangelen ved produksjon blir dermed inkonsekvent.
- Stor suite å utføre.
Q # 39) Hvis du blir bedt om å dokumentere testscenarier, testtilfeller, testplaner, teststrategi hva vil du begynne med og i hvilken rekkefølge vil resten følge?
Svar : Sekvensen vil være teststrategi, testplan, testscenarier og til slutt testsaker.
Q # 40) Hva om jeg savner å dokumentere noe av det ovennevnte? Si at jeg savner å dokumentere testplanen, hva blir konsekvensene?
Svar : Hvis vi går glipp av å dokumentere testplanen, vil det være tomt for omfanget av å teste dens objektive tilnærming og vektlegging av testing. Det vil da være vanskelig å bestemme funksjonene som skal testes, teknikker for å teste, bestå eller ikke bestå kriterier og til slutt en stor risiko forbundet med testingen.
Q # 41) Hvordan vil du begynne å teste utbyggingen du nylig fikk: Er det noen tilnærming du følger f.eks. begynner først røykprøving, deretter sunnhetsprøving?
Svar : Røykprøving> Sanity testing> Exploratory Testing> Functionality Testing> Regression testing and Final Product Validation.
Q # 42) Forklar formatet på feilrapporten du fulgte?
Svar :
En feilrapport skal inneholde følgende informasjon:
- Feil-ID
- Kartlegging til Krav / Forbedring / Eksisterende feil
- Feilsammendrag / tittel
- En versjon av produktet
- Prioritet
- Konfigurasjon (systemspesifikasjoner)
- Forutsetninger
- Fremgangsmåte
- Forventet resultat
- Faktisk utfall
- Tømmerstokker. Øyeblikksbilder, videoklipp
- Status
- Andre merknader
Q # 43) Hvordan velger du regresjonstesttilfeller eller danner regresjonstestpakken?
Svar : Ja. Dette er et resultat av konsekvensanalyse. Det er en enkel kartlegging av funksjonene som brukes eller er tilgjengelige i forskjellige områder du tester, integrasjonen med andre funksjoner og gjennomgående som systemets slutt til slutt eller flytest.
Du kan også plukke opp feil som tidligere er arkivert for den samme funksjonaliteten i tidligere bygg. Ideelt sett bør en defekt regresjonstestes ved hjelp av minst fem forskjellige testtilfeller som bruker funksjonaliteten.
Sp # 44) Kan du komme med et eksempel på følgende feil
- Lav prioritet Høy alvorlighetsfeil
- Høy prioritet og lav alvorlighetsfeil
Svar : En feil som krasjer applikasjonen når den bare reproduseres til et gitt tidsstempel på et bestemt operativsystem, kan være en høy alvorlighetsgrad og en lav prioritetsfeil.
En mangel som er arkivert mot et syn som ikke åpnes fra dobbeltklikk, men åpnes med et høyreklikk, kan være høy prioritet og lav alvorlighetsfeil.
Sp # 45) Skriv en effektiv testtilfelle for å teste om et gitt papir er et hvitt papir?
Svar: Hvis fargen på kildeblekket du skriver på hvitt papir, forblir den samme, er papiret hvitt. For eksempel, hvis du skriver på et hvitt papir med rødt blekk, forblir fargen på blekket rødt i pennen og vises også rødt på papiret.
Merk: Det er mange andre svar på dette spørsmålet. Du kan tenke på et slikt gyldig svar med underliggende logikk.
Q # 46) Hva er Charter testing?
Svar: En økttesting utført basert på målene og agendaene som er oppført under et charter før du begynner å teste, er kjent som Charter testing.
Testingen her gjøres i et fast tidsrom med mindre fokus på dokumentasjon og mer fokus på bare testing. Det er en annen variant av utforskende testing der testingeniørene verifiserer programvaren i en tidsramme ( For eksempel, bare 2 timer) basert på noen heuristikker utviklet.
Q # 47) Hva er din tilnærming når du har en høyt prioritert utgivelse som skal leveres på veldig kort tid?
Svar: I slike tilfeller kan en gjennomtenkt plan være gunstig.
Følgende kan gjøres for å hjelpe til med testing i et tidsmangel scenario: -
- Bruke eksisterende oppdaterte automatiseringsskript for å utføre regresjonstesting.
- Testing av strømningsbaserte scenarier helt til slutt.
- Gjennomføring av testprøver med høy prioritet, og hvis tiden tillater det, bytt til sakene med lavere prioritet.
- Test på nytt de høyt prioriterte feilene som er arkivert i tidligere versjoner.
- Rask programvaretesting
- Utviklere kan bli bedt om å kjøre enhetstester for å få mer dekning i testing.
Q # 48) Skriv testtilfeller på en hvilken som helst enhet / gjenstand som finnes rundt (Eksempel: en stol)?
Svar: Et råd her vil være: Begynn alltid med å samle krav. Det viser modenheten mot livssyklusen for programvareutvikling. Still gjerne spørsmål etter at du har valgt objektet.
I dette tilfellet:-
- Hvilken type stol er det? Kontorstol, studiebordstol, sofastol, spisebordstol, komfortstol?
- Hvilket materiale brukes til å lage stolen tre, stål, plast, møbeltrekk?
- Be om dimensjonene (høyde, vekt basert på stolstype).
- Be om tilgjengelighet. Og basert på det begynner du å utarbeide sakene dine.
Test tilfeller vil variere for hver stolstype, noe som er bedre igjen for din tenkeevne ( For eksempel, formålet med stolen, dimensjoner i henhold til stolstypen, bærbar-ikke-drikke, lettvekt, kjøpsalternativer).
For hver stol, a ytelsestest tilfelle kan være: for å utlede strekkfastheten eller den maksimale vektbærende kapasiteten.
Q # 49) Kan alt automatiseres?
Svar: - Til en viss grad ja. Men automatiseringsverktøy, som annen programvare, har sine begrensninger. Også programvare under test eller Applikasjon under test vil fortsette å bli oppgradert.
Så det er ingen garanti for at programvaretesting kan kjøres uten manuell inngrep. Tross alt er et verktøy så smart som testeren er. Det er bare programvaretesting av enda en programvare. Det er koden / skriptene / bibliotekene som må være intelligente nok til å teste og finne feil.
Konklusjon
Håper denne øvelsen hjelper deg med å varme deg opp med noen spørsmål og gir deg en god start på intervjuene dine og forfiner selvtilliten din mens du svarer på spørsmålene. Det kan også være andre scenariobaserte spørsmål som kan komme ut av CV / profil.
Derfor er det alltid tilrådelig å øve på et hånlig intervju med selvhånd, slik at intervjuet viser seg å være en vinn-vinn-situasjon for både intervjueren og kandidaten. Husk at en kvalitetsanalytiker er mer enn en testingeniør, hvis tilbakemelding er viktig for ikke bare produktets kvalitet, men også prosessen som følges for testing av programvaren.
Takk og lykke til med intervjuene!
Anbefalt lesing
- Intervju Spørsmål og svar
- 25+ mest populære ADO.NET intervjuspørsmål og svar
- 25 Beste Agile Testing Intervju Spørsmål og svar
- Spock Intervjuespørsmål med svar (mest populære)
- ETL Testing Intervju Spørsmål og svar
- 20 mest populære TestNG intervju spørsmål og svar
- Topp 30+ populære agurkintervju spørsmål og svar
- Topp 50 mest populære CCNA-intervjuspørsmål og svar