20 selective qa interview questions clear interview 2021
Preguntes i respostes més freqüents sobre l'entrevista de garantia de qualitat per ajudar-vos a preparar l'entrevista:
A continuació, es detallen algunes de les preguntes que faria si entrevistés un enginyer de garantia de qualitat.
Les preguntes posaran més èmfasi en els processos de qualitat i l’estratègia i aquestes preguntes no es faran per fer proves.
Els enginyers de control de qualitat són majoritàriament persones que han passat algun temps a la indústria de les proves, perquè quan creeu fulls de ruta i estratègies, sempre és beneficiós tenir una certa exposició del sector.
Comencem!!
Preguntes freqüents sobre l'entrevista de control de qualitat
Comencem!!
P # 1) Quina diferència hi ha entre la garantia de qualitat, el control de qualitat i les proves?
Resposta: L’assegurament de la qualitat és el procés de planificació i definició de la manera de controlar i implementar els processos de qualitat (test) dins d’un equip i una organització. Aquest mètode defineix i estableix els estàndards de qualitat dels projectes.
El control de qualitat és el procés de trobar defectes i proporcionar suggeriments per millorar la qualitat del programari. Els mètodes utilitzats pel control de qualitat solen establir-se mitjançant la garantia de qualitat. És responsabilitat principal de l’equip de proves implementar el control de qualitat.
La prova és el procés de trobar defectes / errors. Valida si el programari creat per l'equip de desenvolupament compleix els requisits establerts per l'usuari i els estàndards establerts per l'organització.
Aquí, el focus principal és trobar errors i els equips de proves funcionen com un porter de qualitat.
Q # 2) Quan creieu que haurien de començar les activitats de control de qualitat?
Resposta: L’activitat de control de qualitat hauria de començar al principi del projecte. Com més aviat comença, més beneficiós és establir la norma per assolir la qualitat.
El cost, el temps i els esforços són molt difícils en cas que les activitats de control de qualitat es retardin.
Q # 3) Què és el diferència entre el pla de prova i l'estratègia de prova ?
Resposta: L’estratègia de proves es troba a un nivell superior, creat principalment pel gestor de projectes, que demostra l’enfocament general de les proves per a tot el projecte, mentre que el pla de proves mostra com s’haurien de realitzar les proves per a una aplicació concreta, que pertany a un projecte.
Q # 4) Podeu explicar el cicle de vida de les proves de programari?
Resposta: Cicle de vida de proves de programari fa referència a un procés de proves que té passos específics a executar en una seqüència definida per assegurar que s’han assolit els objectius de qualitat.
Q # 5) Com es defineix un format d’escriptura d’un bon cas de prova ?
quin és el propòsit de les proves de regressió
Resposta: El format de Test Case inclou:
- Identificador del cas de prova
- Descripció del cas de prova
- Gravetat
- Prioritat
- Medi ambient
- Versió de compilació
- Passos a executar
- Resultats esperats
- Resultats reals
P # 6) Què és un bon cas de prova?
Resposta: En paraules simples, un bon cas de prova és aquell que troba un defecte. Però tots els casos de prova no trobaran defectes, de manera que un bon cas de prova també pot ser aquell que tingui tots els detalls i cobertura prescrits.
P # 7) Què faríeu si teniu una gran suite per executar en molt menys temps?
Resposta: En cas que tinguem menys temps i haguem d'executar el volum més gran de casos de prova, hauríem de prioritzar el cas de prova i executar primer els casos de prova d'alta prioritat i després passar als casos de prioritat inferior.
D'aquesta manera, podem assegurar-nos que es provin els aspectes importants del programari.
Com a alternativa, també podem buscar la preferència del client per la funció més important del programari segons ells, i hauríem de començar a provar-les des d'aquestes àrees i després passar gradualment a aquelles zones amb menys importància.
millor servidor privat wow per a pvp
Q # 8) Creieu que els assistents de qualitat també poden participar per resoldre problemes de producció?
Resposta: Definitivament !! Seria una bona corba d’aprenentatge que els QA participessin en la resolució de problemes de producció. Molts problemes de producció de temps es podrien resoldre esborrant els registres o fent algunes configuracions del registre o reiniciant els serveis.
Aquest tipus de problemes ambientals podrien ser molt ben solucionats per l’equip de control de qualitat.
A més, si QA té una idea de com resoldre els problemes de producció, poden incloure'ls mentre escriuen els casos de prova, i d'aquesta manera poden contribuir a millorar la qualitat i intentar minimitzar els defectes de producció.
P # 9) Suposem que trobeu un error en producció, com us asseguraríeu que el mateix error no es tornés a introduir?
Resposta: La millor manera és escriure immediatament un cas de prova del defecte de producció i incloure’l a la suite de regressió. D’aquesta manera ens assegurem que l’error no es torni a introduir.
A més, podem pensar en casos de proves alternatius o tipus similars de casos de prova i incloure'ls a la nostra execució prevista.
Q # 10) Quina diferència hi ha entre les proves funcionals i no funcionals?
Resposta:
Proves funcionals tracta de l’aspecte funcional de l’aplicació. Aquesta tècnica prova que el sistema es comporta segons els requisits i les especificacions. Aquests estan directament relacionats amb els requisits del client. Validem els casos de prova en funció del requisit especificat i fem que els resultats de la prova passin o no en conseqüència.
Exemples inclouen regressió, integració, sistema, fum, etc.
Proves no funcionals , d'altra banda, prova l'aspecte no funcional de l'aplicació. No se centra en el requisit, sinó en factors ambientals com el rendiment, la càrrega i l'estrès. No s’especifiquen explícitament al requisit, sinó que es prescriuen a les normes de qualitat. Per tant, com a control de qualitat, hem d’assegurar-nos que a aquestes proves també se’ls doni temps i prioritat suficients.
Q # 11) Què són les proves negatives? En què es diferencia de les proves positives?
Resposta: Les proves negatives són una tècnica que valida que el sistema es comporti amb gràcia en cas d’entrada no vàlida. Per exemple, en cas que l'usuari introdueixi dades no vàlides en un quadre de text, el sistema hauria de mostrar un missatge adequat en lloc del missatge tècnic que l'usuari no entén.
Proves negatives és diferent de les proves positives de manera que les proves positives validen que el nostre sistema funciona com s’esperava i compara els resultats de la prova amb els resultats esperats.
La majoria dels escenaris de temps per a proves negatives no s’esmenten als documents de requisits funcionals. Com a control de qualitat, hem d’identificar els escenaris negatius i hem de disposar de disposicions per provar-los.
P # 12) Com asseguraríeu que les proves siguin completes i tinguin una bona cobertura?
Resposta: La matriu de traçabilitat de requisits i les matrius de cobertura de proves ens ajudaran a determinar que els nostres casos de prova tenen una bona cobertura.
La matriu de traçabilitat dels requisits ens ajudarà a determinar que les condicions de la prova són suficients per cobrir tots els requisits. Les matrius de cobertura ens ajudaran a determinar que els casos de prova són suficients per satisfer totes les condicions de prova identificades a RTM.
An RTM es veurà com:
De la mateixa manera, Les matrius de cobertura de prova tindran el següent aspecte:
P # 13) Quins són els diferents artefactes als quals fa referència quan escriu els casos de prova?
Resposta: Els principals artefactes utilitzats són:
- Especificació de requisits funcionals
- Document d’enteniment del requisit
- Casos d’ús
- Marcs metàl·lics
- Històries d'usuaris
- Criteris d'acceptació
- Molts casos de proves UAT
P # 14) Alguna vegada heu aconseguit escriure els casos de prova sense tenir cap document?
Resposta: Sí, hi ha casos en què hem d’escriure casos de prova sense tenir cap document concret.
En aquest cas, la millor manera és:
- Col·labora amb el BA i l’equip de desenvolupament.
- Digueu correus electrònics que tinguin alguna informació.
- Aprofiteu en casos de proves / suite de regressió més antics
- Si la característica és nova, proveu de llegir les pàgines del wiki o ajuda de l'aplicació per tenir una idea
- Seieu amb el desenvolupador i intenteu entendre els canvis que s’estan fent.
- Segons la vostra comprensió, identifiqueu la condició de la prova i envieu-la a BA o als grups d'interès perquè la revisin.
P # 15) Què s’entén per Verificació i validació ?
Resposta:
Validació és el procés d'avaluació del producte final per comprovar si el programari compleix les necessitats empresarials. L’execució de les proves que fem en el nostre dia a dia és l’activitat de validació que inclou proves de fum, proves funcionals, proves de regressió, proves de sistemes, etc.
Verificació és un procés d’avaluació dels productes de treball intermedis d’un cicle de vida de desenvolupament de programari per comprovar si estem en la pista correcta de creació del producte final.
P # 16) Quines són les diferents tècniques de verificació que coneixeu?
Resposta: Les tècniques de verificació són estàtiques. Hi ha 3 tècniques de verificació.
S’expliquen de la següent manera:
(i) Revisió - Aquest és un mètode mitjançant el qual els casos de codi / prova són examinats per l’individu que no sigui l’autor que l’ha produït. És una de les millors maneres de garantir la cobertura i la qualitat.
(ii) Inspecció - Es tracta d’una manera tècnica i disciplinada d’examinar i corregir els defectes en l’artefacte o codi de prova. Com que és disciplinat, té diversos rols:
- Moderador - Facilita tota la reunió d’inspecció.
- Gravadora - Registra les actes de la reunió, els defectes i altres punts discutits.
- Lector - Llegiu el document / codi. El líder també condueix a tota la reunió d’inspecció.
- Productor - L'autor. En última instància, són els responsables d’actualitzar el seu document / codi segons els comentaris.
- Revisor - Es pot considerar que tots els membres de l’equip són revisors. Aquest paper també el pot exercir algun grup d’experts segons el projecte exigeixi.
(iii) Tutorial - Es tracta d’un procés en què l’autor del document / codi llegeix el contingut i obté els comentaris. Es tracta principalment d’una mena de sessió FYI (per a la vostra informació) en lloc de buscar correccions.
P # 17) Quina diferència hi ha entre Proves de càrrega i estrès ?
Resposta:
Proves d’estrès és una tècnica que valida el comportament del sistema quan s’executa sota tensió. Per explicar-ho, reduïm els recursos i comprovem el comportament del sistema. Primer entenem el límit superior del sistema i reduïm gradualment els recursos i comprovem el comportament del sistema.
En Prova de càrrega, validem el comportament del sistema sota la càrrega esperada. La càrrega pot ser d’usuaris o recursos simultanis que accedeixin al sistema alhora.
P # 18) En cas que tingueu dubtes sobre el vostre projecte, com us plantegeu?
Resposta: En cas de dubtes, primer, intenteu esborrar-los llegint els ajuts disponibles sobre els artefactes / aplicacions. En cas de dubtes que persisteixen, pregunteu a un supervisor immediat o al membre sènior del vostre equip.
Els analistes de negocis també poden ser una bona opció per fer dubtes. També podem fer arribar les nostres preguntes a l’equip de desenvolupament en cas de dubtes. L'última opció seria fer un seguiment amb el gestor i, finalment, amb els grups d'interès.
P # 19) Heu utilitzat alguna eina d'automatització?
Resposta: La resposta a aquesta pregunta és molt exclusiva de l’individu. Respondre a totes les eines i estratègies d'automatització que heu utilitzat al vostre projecte.
P # 20) Com es determina quina peça de programari requereix quant de proves?
Resposta: Podem conèixer aquest factor descobrint el Complexitat ciclomàtica .
T la tècnica ajuda a identificar les 3 preguntes següents sobre els programes / funcions
- Es pot provar la funció / programa?
- Tothom entén la funció / programa?
- La funció / programa és prou fiable?
Com a control de qualitat, podem utilitzar aquesta tècnica per identificar el 'nivell' de les nostres proves.
com escriure casos de prova efectius
És una pràctica que si el resultat de la complexitat ciclomàtica és més o més gran, considerem que aquesta peça de funcionalitat és de naturalesa complexa i, per tant, conclourem com a provador; que la part de codi / funcionalitat requereix proves en profunditat.
D'altra banda, si el resultat de la complexitat ciclomàtica és un nombre menor, conclouem com a QA que la funcionalitat és de menys complexitat i decidim l'abast en conseqüència.
És molt important entendre tot el cicle de vida de les proves i, si cal, podríem suggerir canvis en el nostre procés. L'objectiu és oferir programari d'alta qualitat i, d'aquesta manera, un control de qualitat hauria de prendre totes les mesures necessàries per millorar el procés i la manera en què l'equip de proves executa les proves.
Espero que aquestes preguntes i respostes de l’entrevista de control de qualitat ajudin a preparar una entrevista de garantia de qualitat.
Lectura recomanada
- Preguntes i respostes de l’entrevista
- Algunes preguntes d’entrevistes de proves de programari interessants
- Preguntes i respostes d’entrevistes de proves ETL
- Top 20 de les preguntes i respostes de les entrevistes de proves API més importants
- Com es prepara per a l’entrevista de proves de programari
- Preguntes d'entrevistes de proves manuals de programari per a professionals experimentats
- 25 millors preguntes i respostes d’entrevista de proves àgils
- Top 200 preguntes sobre l'entrevista de proves de programari (una lectura obligada per esborrar qualsevol entrevista de prova)