Més de 40 preguntes i respostes d'entrevistes d'analistes de control de qualitat populars [LLISTA 2021]

40 popular test qa analyst interview questions

Preguntes i respostes més freqüents de les entrevistes dels analistes de proves / assegurament de la qualitat:

Tot i decidir la carrera en què voleu estar, el factor decisiu no només és el que creieu que pot gaudir treballant.

Però estar en aquesta categoria requereix moltes habilitats, entendre les responsabilitats i els deures laborals necessaris per a la carrera que heu escollit. El mateix passa quan es tria una carrera com a analista de control de qualitat. No només requereix que sigueu un bon provador, un estudiant ràpid, un pensador extraordinari, sinó que també necessiteu ser un solucionador de problemes complex.

Tot i que les qualitats esmentades no s’aconsegueixen a l’instant, òbviament també requereix experiència i dies de treball dur.

Aquest article tractarà tots els aspectes els coneixements dels quals són obligatoris per ser analista de control de qualitat. Les preguntes i respostes de l'entrevista QA Test Analyst més freqüents que s'inclouen aquí us donaran una idea clara de la preparació de l'entrevista.

Preguntes populars d'entrevistes d'analistes de proves de control de qualitat

P # 1) Quines són les responsabilitats d'un analista de control de qualitat?

Resposta: QA Analyst és qui s'assegura que s'han pres totes les mesures possibles per provar cada funció de la solució de programari, tant a nivell funcional com tècnic.

Les principals responsabilitats de QA Analyst es poden incloure de la següent manera:

• Executeu i gestioneu totes les activitats per assolir els objectius del pla de proves.
• Trieu els processos d'alta qualitat per desenvolupar el producte.
• Hauria de poder analitzar els requisits i documentar els procediments.
• Documenta i torna a verificar tots els defectes. Definiu la prioritat i la gravetat dels defectes.
• Haurien de ser capaços de crear, documentar i mantenir casos de prova.
• Anàlisi dels resultats de les proves.

Q # 2) Què enteneu pel que fa a un pla de proves?

Resposta: Quan teniu una idea clara de què, quan, com i qui, les coses es tornen més fàcils. El mateix passa amb les proves de programari, on el pla de prova és un document que consta de l'abast, l'enfocament, els recursos i l'esquema del projecte de proves, així com les activitats per fer un seguiment del progrés del projecte.

El pla de prova és un registre de processos que inclouen:

• Tasques de proves
• Entorn de proves
• Tècniques de disseny
• Criteris d’entrada i sortida
• Qualsevol risc, etc.

P # 3) Indiqueu la prioritat de les tasques de prova definides per l'equip de control de qualitat en el desenvolupament de productes.

Resposta: La prioritat de les tasques de prova es defineix de la manera següent:

• Es prepara un pla de proves que consisteix en l'esquema i l'abast del projecte de proves.
• Els casos de prova es preparen per cobrir totes les funcions principals i menors amb les dades necessàries per a la prova.
• Execució dels casos de prova segons les funcionalitats implementades amb les properes versions del projecte de proves en el cicle de proves.
• Informe de defectes amb una nova verificació, així com un seguiment del seu progrés.
• Preparació del resum de l'informe d'execució de la prova.

Q # 4) Enumereu alguns dels principals reptes que cal afrontar durant la realització de proves de programari.

Resposta: Com diem que mai es poden aconseguir proves completes, hi ha diversos desafiaments. Ja sigui petit o complicat, hi ha alguns reptes als quals s’enfronta la realització de proves de programari de qualsevol projecte.

A continuació es detallen alguns dels principals reptes:

• La manca de verificadors qualificats que solen enfrontar-se al problema de la consciència del tema, així com a la manca d’un bon coneixement del negoci del client.
• El temps també es considera el factor, ja que normalment els verificadors se centren principalment en la cobertura de tasques en lloc de cobrir-les amb proves de qualitat quan hi ha una enorme llista de tasques per completar.
• Per decidir quin cas de prova s’ha d’executar primer i amb prioritat. Això normalment s’aconsegueix amb l’experiència laboral.
• Una comprensió adequada dels requisits que poden portar a zero tots els esforços de prova, si s’entén malament.
• Indisponibilitat de les millors eines necessàries per completar les proves amb menys temps i més efectivitat.
• Manejar la relació entre provadors i desenvolupadors amb una bona comunicació i habilitats d’anàlisi.

Q # 5) Definiu la prova de casos d'ús.

Resposta: La prova de casos d’ús es pot definir com la tècnica de proves de caixes negres funcionals que capturen la sèrie d’interaccions que s’han produït entre ‘actors’ i ‘sistema’. Aquí, els 'actors' estan representats pels usuaris i les seves interaccions.

A continuació es detallen les característiques de la prova de casos d’ús:

• S’organitzen els requisits funcionals del projecte.
• Enregistra el camí o els escenaris de principi a fi.
• Pot cobrir defectes d’integració, és a dir, els defectes que es van produir com a resultat de la interacció entre diferents components.
• Descriu els fluxos principals, així com el flux excepcional dels esdeveniments.
• Les precondicions necessàries perquè el cas d’ús funcioni s’han d’especificar abans.

Q # 6) Definiu l'estratègia de prova.

Resposta: Es defineix com a Estratègia de prova un conjunt de directrius o enfocaments de proves que sol dur a terme el gerent del projecte per determinar el disseny de les proves i l'enfocament general de les proves. Es troba com una petita secció del pla de proves i és utilitzat per diversos projectes.

Es segueixen diferents mètodes de prova basats en factors com la naturalesa i el domini del producte, el risc de fallada del producte, l'experiència en treballar amb les eines proposades, etc.

Aquests enfocaments es classifiquen de la següent manera:

• Enfocament proactiu , on l'enfocament dels dissenys de prova comença abans de crear la compilació. Per tant, ajuda a trobar i corregir els errors abans de la compilació.
• Enfocament reactiu , on s'inicia l'enfocament de les proves després de finalitzar el disseny i la codificació de les proves.

Q # 7) Expliqueu la diferència entre control de qualitat i garantia de qualitat.

Resposta: 'Control de qualitat' i 'Garantia de qualitat' són els dos termes principals que s’utilitzen per a qualsevol producte o projecte de prova. Normalment, els verificadors, que són nous en aquest camp, no entenen la diferència real entre els dos.

Comprenem la diferència amb l’ajuda de la taula següent.

Q # 8) Segons vosaltres, quan és el bon moment per iniciar el control de qualitat en un projecte?

Resposta: Segons el cicle de vida de desenvolupament de programari (SDLC), la fase de proves s’executa després de completar la fase ‘Implementació i codificació’. Però, en l’escenari actual, per aconseguir els millors resultats, cal iniciar el control de qualitat del projecte o producte a l’inici del projecte.

Seguir aquest enfocament comportarà els principals avantatges que es donen a continuació:

• Planificació inicial del procés per satisfer les expectatives de qualitat del client.
• Bona i sana comunicació entre els equips.
• Dóna un temps suficient per configurar l'entorn de proves.
• Permet revisar i aprovar amb anticipació els plans de prova.

Q # 9) Diferenciar els processos de verificació i validació.

Resposta: Els processos de verificació i validació solen estar determinats per dues preguntes famoses, és a dir, ' Estem construint el sistema, oi? ” i 'Construïm el sistema adequat?' .

Vegem l’altra diferència entre aquests dos processos a la taula següent:

Q # 10) Expliqueu els avantatges de les proves destructives.

Resposta: Les proves destructives es defineixen com la forma de proves que realitza l’equip de proves per determinar el punt de fallada del producte sota diferents càrregues, és a dir, per avaluar el rendiment estructural de l’aplicació per determinar la seva resistència, duresa, duresa o, per exemple, la seva robustesa.

A continuació es detallen els avantatges de les proves destructives:

• Es determina la debilitat del disseny de l'aplicació.
• Determineu la vida útil de l'aplicació.
• Ajuda a reduir els costos i el fracàs.

Q # 11) En què es diferencien les proves de regressió de les proves de regressió?

Resposta: Hi ha diverses diferències entre la prova de repetició i la prova de regressió.

Això es pot entendre fàcilment a la taula següent:

P # 12) Què en sabeu de les proves basades en dades?

Resposta: Per a tots els provadors d'automatització és molt clar que els scripts de proves d'automatització només cobreixen l'àrea de l'aplicació a provar amb una seqüència enregistrada d'accions de l'usuari. Normalment, aquestes accions no produeixen cap error, ja que només es prenen les dades d’entrada en les condicions que hem introduït durant la gravació.

Les proves basades en dades apareixen aquí, on volem que l’aplicació funcioni com s’esperava per a qualsevol tipus de valors d’entrada. Amb aquest propòsit, les dades necessàries per a les proves basades en dades no es codifiquen, però els scripts de prova prenen les seves dades de fonts de dades com fitxers CSV, fonts ODBC, etc.

Per resumir, les proves basades en dades realitzen les accions següents al bucle:

millor netejador de PC per a Windows 7

• Presa les dades de prova d’entrada de l’emmagatzematge.
• Dades introduïdes a l'aplicació per realitzar accions.
• Verifiqueu els resultats reals amb els esperats.
• Repetiu de nou els mateixos passos amb les noves dades de prova d'entrada.

P # 13) Què és la matriu de traçabilitat? És necessari per a cada projecte?

Resposta: La matriu de traçabilitat en qualsevol projecte és el mitjà per fer un seguiment del progrés del projecte quant a la implementació de noves funcionalitats, la millora de les funcionalitats existents, etc. Mitjançant una matriu de traçabilitat, sempre podeu vigilar el progrés del projecte amb tots els aspectes mantinguts segons la data.

La matriu de traçabilitat de requisits consisteix en els paràmetres esmentats a continuació, que són realment segons el document d'especificació de requisits.

Els paràmetres de la matriu de traçabilitat del requisit inclouen:

• Cada secció del document de requisits és un punt que s’ha de tractar a RTM (Requirement Traceability Matrix).
• El títol de cada punt és el títol de cada secció de l'especificació de requisits.
• Corresponent a cada punt, s'esmenten els identificadors de casos de prova que s'escriuen per a aquesta secció en particular.
• A cada secció també s’esmenta BUG / New Feature ID.
• El punt més important és que també es manté el seguiment de la característica en què s’ha implementat la construcció del projecte i la seva característica.
• Un altre paràmetre inclou si la secció està completament provada o encara està en estat de prova.

Q # 14) Descriviu els avantatges de les proves àgils.

Resposta: En ser un provador, l’enfocament es converteix en oferir el producte de qualitat en menys temps comprenent el requisit de l’usuari final i, el més important, que no hi hagi defectes per part de l’usuari final. Aquí es mostren les proves Agile que segueixen el principi del desenvolupament de programari àgil i valida ràpidament els requisits del client.

A continuació, esmenten els avantatges de les proves Agile:

• A les proves s’inclou un equip àgil multifuncional, que al seu torn proporciona els resultats a intervals freqüents.
• Estalvia molt de temps i diners.
• Inclou menys documentació i comentaris puntuals de l'usuari final.
• No només el comprovador, sinó tot l’equip, inclòs el gerent, el client i el desenvolupador, participen en la comunicació cara a cara.
• Com a resultat de les reunions diàries, es poden determinar amb antelació els problemes.
• Increment de la productivitat de l’equip i una millor comprensió dels aspectes tècnics del projecte.

P # 15) Què són les proves negatives?

Resposta: Les proves negatives són el mètode per garantir que es manté l'estabilitat d'un producte o aplicació o dir que no fallen quan es dóna una entrada inesperada. L'objectiu principal d'aquesta forma de prova valida l'aplicació contra qualsevol possible entrada d'entrada no vàlida.

Aquesta forma de prova també es coneix com 'Proves de fallades' o 'proves de camí d'error' i el seu propòsit principal és comprovar la fiabilitat de la funció de l'aplicació en escenaris negatius. També exposa la debilitat del programari, detecta els errors i dóna una idea clara de la corrupció de les dades.

P # 16) Diferenciar les proves ad-hoc i les proves exploratòries?

Resposta: Hi ha diverses diferències entre les proves ad-hoc i les proves exploratòries.

Vegem les diferències a la taula següent:

P # 17) Per què es prefereixen les proves d'automatització sobre les proves manuals?

Resposta: Bé, tant les proves d'automatització com les proves manuals tenen la seva importància i existència en el món de les proves.

A continuació es detallen alguns aspectes importants a causa dels quals es prefereixen les proves d'automatització en lloc de les proves manuals:

• Es pot utilitzar el mateix script de prova cada vegada que s’executa la prova, de manera que les proves d’automatització es consideren les més fiables i eficients.
• Molt preferit en cas de proves de regressió i execució repetida.
• Es considera que les proves d'automatització són rendibles en cas d'execució a llarg termini i, per tant, garanteixen una millor qualitat del programari.
• Els scripts de prova es poden reutilitzar, són ràpids i tothom pot veure els resultats.
• Les eines que s’utilitzen per a les proves d’automatització són més ràpides i fiables en comparació amb l’enfocament manual.

Tot i que hi ha alguns factors més que determinen que es prefereixen les proves d'automatització en lloc de les proves manuals. Els factors esmentats anteriorment són els principals.

P # 18) Què enteneu per 'Eficiència de prova' i 'Eficiència de prova'?

Resposta: Eficàcia de la prova es pot definir com a càlcul del nombre de recursos i codi de prova consumits per realitzar o dir executar una funció concreta. També determina el nombre de recursos utilitzats en la creació de productes de programari.

Això es pot determinar mitjançant la fórmula:

Eficiència de la prova = (Nombre de defectes resolts / nombre total de defectes presentats) * 100

Eficàcia de la prova es pot definir com la mesura d’avaluació de l’entorn de prova i el seu efecte sobre l’aplicació de programari. Aquí s’avalua la resposta del client quan es compleix el requisit de la sol·licitud.

Això es pot determinar mitjançant la fórmula:

Eficàcia de la prova = (Nombre de defectes trobats / Nombre de casos de prova executats)

P # 19) Expliqueu el procés de sastreria de projectes.

Resposta: La personalització del projecte és un procés constant i continu que garanteix que el rendiment del projecte sigui correcte i sigui d’acord amb els requisits empresarials. Tot el procés inclou revisar i modificar les dades del projecte segons la necessitat operativa actual de l'organització.

El procés de revisió es fa a nivell organitzatiu, però la implementació dels plans d’adaptació es fa a nivell de projecte. L’objectiu principal i els requisits de l’organització, així com les relacions amb els clients i els usuaris, són els dos principals factors que s’han de tenir en compte en el procés.

Pocs aspectes segons els objectius organitzatius del procés de sastreria són:

• Enfocament del projecte
• Estratègies
• Controls i processos implicats
• Rols i responsabilitats

P # 20) Com diferencieu entre la prioritat i la gravetat del defecte dins del projecte?

Resposta: Tant 'Prioritat' com 'Gravetat' s'assignen a l'error per classificar els problemes / errors per l'ordre en què s'han de corregir. Aquests es basen en diversos factors.

Entenguem més informació sobre les seves diferències a la taula següent:

P # 21) Per què cal fer proves de rendiment per a qualsevol aplicació?

Resposta: En un llenguatge senzill, les proves de rendiment es fan per determinar el comportament i la resposta d'una aplicació en diverses situacions. Això ajuda a recopilar informació sobre l'estabilitat, escalabilitat, velocitat de l'aplicació, etc.

Els motius per fer proves de rendiment es poden entendre a partir dels punts següents:

• Determina el temps de resposta i el rendiment d'un component d'aplicació sota la càrrega de treball.
• Es calcula el temps de resposta de l’activitat de l’usuari.
• Requereix programadors experimentats amb un llenguatge tècnic extens.
• Determina el comportament de l'aplicació sota càrrega, és a dir, quan el nombre d'usuaris augmenta a l'instant.

P # 22) Què són les proves basades en les especificacions?

Resposta: Tal com el seu propi nom defineix, les proves basades en les especificacions es fan basant-se en l'especificació de requisits de l'aplicació, on les especificacions funcionals serveixen de base per a les proves realitzades.

Aquesta forma de prova és la mateixa que la 'prova de caixa negra' en què l'usuari introdueix diverses dades i després s'observa la sortida. És adequat a tots els nivells de proves amb especificació i pla de proves.

Q # 23) Expliqueu CMMI.

Resposta: CMMI significa Integració de models de maduresa de capacitats. Aquest model va ser desenvolupat pel Software Engineering Institute (SEI). Es basa en el principi que els processos implicats en la gestió i el desenvolupament d’un producte o sistema determinen la qualitat.

També proporciona pautes per millorar el procés del producte o fins i tot de tota l’organització.

CMMI es divideix en 5 nivells, tal com s'indica a continuació:

• Nivell 1: Inicial
• Nivell 2: Gestionat
• Nivell 3: Definit
• Nivell 4: Gestionat quantitativament
• Nivell 5: Optimitzat

Q # 24) Expliqueu els avantatges d’implementar CMMI.

Resposta: Hi ha diversos avantatges en implementar CMMI.

Es detallen de la següent manera:

• Proporciona una cobertura i informes detallats del cicle de vida del producte i, per tant, ajuda a millorar els processos.
• Els estàndards existents de l’organització, els seus processos i procediments es milloren com a part de la implementació de CMMI.
• Com a resultat de la implementació de CMMI, hi ha un augment del lliurament puntual i de la satisfacció del client.
• També comporta una gestió eficaç i un major estalvi de costos, ja que hi ha una detecció precoç d’errors.

P # 25) Demaneu algunes eines de proves d'automatització.

Resposta: A continuació es detallen algunes de les eines de proves d’automatització:

• Seleni
• aigua
• Molí de vent
• SABÓ
• Tel·luri

P # 26) Podem fer proves de regressió a la prova unitària?

Resposta: Definitivament. Les proves de regressió consisteixen a provar el defecte no desitjat que podria haver estat introduït al codi com a efecte secundari de solucionar altres defectes. La prova d’unitat és l’execució de la prova d’executar una petita part independent i independent del codi.

Les proves de regressió es poden fer a qualsevol nivell, des de les proves de la unitat fins a les proves d’integració i fins i tot les proves d’acceptació. Les proves de regressió són proves basades en la perspectiva, mentre que les proves d’unitat són l’enfocament del nivell (de baix a dalt, de dalt a baix).

Q # 27) Quina diferència hi ha entre les proves de fum i les proves de seny?

Resposta:

• La prova de fum és la prova de les funcions destacades antigues o de les característiques existents de la versió, mentre que la prova de seny és la validació de mòduls acabats d’afegir, defectes solucionats a la construcció.
• Primer es produeixen les proves de fum i després les de Sanity.
• Les proves de fum cobreixen les proves de funcionalitats crítiques ateses pel programari, de manera que s’estén per tot el programari. Les proves de seny, en canvi, es redueixen només als mòduls afegits recentment i es proven en profunditat.

Q # 28) Quines són les vostres activitats diàries com a provador manual a la vostra oficina?

manual: El primer que comprovo al meu sistema és actualitzar el tauler de control per veure l'estat dels requisits / millores o errors a la iteració actual. El segueixen trucades diàries i informes, sessions de discussió i pluja d'idees per definir amb escenaris de prova i casos de prova.

Aquests casos s’executen després de tornar-los a redactar segons la revisió. Mantenir contactes amb clients per a requisits no funcionals també és una de les activitats principals del meu plat.

Q # 29) Quines són les vostres activitats diàries com a membre del verificador d'automatismes a la vostra oficina?

Automatització: El meu dia comença amb una reunió d’estat diària que analitza els resultats d’automatització d’ahir, per si he llançat un lot de casos de prova a la nova versió.

El cicle d’execució es pot anomenar Comprovació de salut, per veure la salut de la construcció.

Tot seguit, s’informen de defectes basats en els errors de seqüència d’ordres, canvis de disseny en la funcionalitat; mantenir els scripts / biblioteques o funcions, automatitzar i registrar un script nou per als nous requisits i, si cal, una nova funció a la biblioteca de funcions.

De vegades, els scripts de prova han de tornar-se a executar individualment per trobar defectes de regressió mitjançant automatització i afegir-los a la suite de proves.

P # 30) Com diferencieu entre un requisit i un defecte i una millora?

Resposta : A requisit és una història d'usuari que és essencial per implementar, provar i lliurar.
An millora és una funció afegida o improvisada a la ja existent.
A defecte és més aviat una desviació completa de les històries d'usuaris esperades.

A més, si un defecte descobreix una determinada àrea d'un requisit que no s'indica tret que s'especifiqui el contrari, també es pot anomenar com a requisit o part del mateix.

Q # 31) Què feu quan el vostre desenvolupador nega la solució d'un error que heu presentat?

Resposta : Un factor important que decideix solucionar un defecte és la 'Prioritat' que se li assigna. Si el defecte és d’alta prioritat, un tap d’espectacle, que bloqueja una funcionalitat important i es reprodueix constantment, és necessari que es solucioni a la construcció.

El mateix s'ha de transmetre als desenvolupadors de manera eficaç, ja que junts els provadors i desenvolupadors contribueixen a la qualitat del producte que s'envia.

Altres aspectes que poden ajudar a convèncer el desenvolupador per corregir un error en un curt període de temps són l'informe de qualitat de l'error i fer entendre als desenvolupadors el fet que la solució de l'error és de primera importància en la versió.

Q # 32) Què feu quan el vostre desenvolupador nega que el que heu presentat sigui una ERA?

Resposta : Una fase més important del cicle de vida dels defectes és 'Rebutjat', el que significa que l'informe d'incidents registrats no és vàlid. El document de requisits empresarials que estableix els requisits pot ajudar a entendre el programari i, per tant, la naturalesa de l’incident reportat.

Analitzeu l’error i exposeu els desenvolupaments i l’equip als vostres resultats. Si es tracta d'un defecte, no deixeu mai de registrar-lo. De vegades, els provadors han de proporcionar una anàlisi de Gap i presentar-los als desenvolupadors. Si això no resol els conflictes, la gent gran de l'equip hauria de presentar-se.

Q # 33) Què passa amb la primera prova o regressió?

Resposta : La prova nova és la primera, ja que torna a executar el codi, en termes més senzills, és una execució repetida de passos predefinits. No ha de ser necessari després de corregir un codi. Però una prova de regressió consisteix a avaluar els efectes secundaris d’un defecte resolt.

Certament, no és el propòsit del procés de resoldre un defecte i afegir-ne un altre al codi. Les millors troballes i millors captures dels provadors solen ser defectes de regressió. Una compilació no s'hauria de llançar mai sense provar la regressió.

Q # 34) Quina és una alternativa a les proves beta?

Resposta : Les proves beta es realitzen al lloc del client amb la menor participació dels desenvolupadors, registrant els errors en l'entorn de producció real. Si una empresa no la duu a terme, una idea més segura pot ser enviar el producte primer als clients que no estan a la cua per obtenir la versió més recent.

Durant un parell de dies, certs consultors de serveis de la premissa dels clients poden utilitzar el programari, enregistrar i supervisar les activitats que asseguren l’estabilitat de la versió al seu entorn, de manera que fins i tot si es deixa un error important per solucionar es pot provar abans lliurant-lo al client objectiu. Un altre enfocament és la permuta de proves dels requisits dins d’un equip per a proves imparcials.

Q # 35) Quins són els inconvenients de la implementació / metodologia Agile que heu tingut?

Resposta : Els inconvenients són els següents:

1. Els sprints solen estar molt limitats.
2. La documentació no és la prioritat
3. El canvi entre PBIs (Product Backlog Items) pot ser freqüent.

Q # 36) Per què és important l’anàlisi d’impacte?

Resposta : Per practicar els anàlisis d’impacte basats en el risc, s’ha de fer. En fer-ho, es poden dissenyar casos de prova de manera que tots els errors greus, crítics des del punt de vista del client, es puguin resoldre abans de temps. Cal tenir en compte un bon estudi de l’empresa, la necessitat del client i l’ús del programari.

Per exemple, el risc més important associat al programari del domini bancari és la seguretat. Qualsevol nou formulari afegit al programari ja existent pot ser vulnerable. Es recomana una bona quantitat de proves de seguretat afegint enllaços, redirecció i navegació adequats a la pàgina adequada, instal·lant el servidor intermediari si cal.

Q # 37) Amb l'ajut d'un exemple, cada prova de rendiment, prova d'esforç i prova de càrrega?

Resposta : El millor cas que es pot fer aquí és un lloc web en directe.

Proves de rendiment es fa per verificar els problemes del sistema quan es passen per una condició similar a un escenari en temps real. No cal realitzar-lo en condicions estressades. Els resultats de les proves de rendiment ajuden a determinar si el sistema està preparat per entrar en producció.

Per a un flux senzill de reserva de bitllets, un problema de rendiment pot haver causat lentitud. Per exemple, algunes consultes que fan servir combinacions són una mica més lentes que han implementat una clàusula o emmagatzematge de dades innecessaris a la base de dades de manera inadequada.

Proves d’estrès és un tipus de prova de rendiment que es realitza posant el programari en condicions extremes (càrregues pesades i no distribuïdes, recursos computacionals limitats, alta concurrència).

Si un sistema presenta cert comportament, com ara dades perdudes o danyades, recursos utilitzats fins i tot després d’eliminar l’estrès, de la irresponsabilitat o d’excepcions no gestionades, vol dir que fallen a les proves d’estrès. De vegades, la fallada del disc, un augment innecessari del recompte de GDI també pot ser el resultat.

Per exemple, Si el lloc web allotjat en una màquina que ja consumeix una gran memòria o el bombarda amb sol·licituds repetides, no us hauria de penjar ni tancar la sessió.

Prova de càrrega observa el comportament del sistema mentre augmenta constantment la càrrega del sistema fins que s’arriba a un llindar. Els models de càrrega de treball, les mètriques i els nivells de càrrega solen ser l’entrada de les proves de càrrega.

Per exemple, el temps per obtenir la disponibilitat de seients per a un tren augmenta gradualment quan s’acosta el temps de reserva de la quota de Tatkal, ja que el nombre d’usuaris que han iniciat sessió al sistema augmenta amb el temps de reserva de Tatkal a les 10 del matí o a les 11 del matí.

Q # 38) Quin ha estat un dels vostres majors reptes en fer proves de regressió?

Resposta : Hi pot haver diversos reptes en realitzar proves de regressió.

• Reexecutar proves repetidament pot ser que no sigui tan emocionant per als verificadors.
• Consumeixen molt de temps, ja que de vegades aquestes proves necessiten un pensament exprés.
• Valor empresarial compromès.
• La selecció incorrecta dels casos de proves de regressió pot saltar-se un defecte de regressió important que es trobi.
• La reproducció del defecte de la producció esdevé, per tant, inconsistent.
• Gran suite per executar.

Q # 39) Si se us demana que documenteu els escenaris de prova, casos de prova, plans de prova, estratègia de prova, amb què començareu i en quina seqüència seguirà la resta?

Resposta : La seqüència serà Estratègia de prova, Pla de prova, Escenaris de prova i, finalment, Casos de prova.

Q # 40) Què passa si trobo a faltar documentar alguna de les anteriors? Suposem que trobo a faltar documentar el pla de proves, quines conseqüències tindrà?

Resposta : Si perdem la documentació del pla de proves, hi haurà un buit per a l'abast de la prova del seu enfocament objectiu i l'èmfasi en les proves. Aleshores serà difícil determinar les característiques a provar, les tècniques per provar, aprovar o suspendre els criteris i, en última instància, un risc important associat a la prova.

Q # 41) Com començaríeu a provar la compilació que heu obtingut recentment: hi ha algun enfocament que seguiu, per exemple? primer comencen les proves de fum, després les proves de seny?

Resposta : Proves de fum> Proves de seny> Proves exploratòries> Proves de funcionalitat> Proves de regressió i validació del producte final.

Q # 42) Expliqueu el format de l'informe d'errors que heu seguit?

Resposta :

Un informe d'errors ha de contenir la informació següent:

• Identificador d'error
• Assignació de requisits / millora / error existent
• Resum d'errors / títol
• Una versió del producte
• Prioritat
• Configuració (especificacions del sistema)
• Requisits previs
• Passos
• Resultat esperat
• Resultat real
• Registres. Instantànies, videoclips
• Estat
• Altres observacions

Q # 43) Com seleccioneu els casos de proves de regressió o formeu el conjunt de proves de regressió?

Resposta : Sí. Aquest és el resultat de l'anàlisi d'impacte. És un mapatge senzill de les funcions que s’utilitzen o s’accedeix a les diferents àrees que esteu provant, la seva integració amb altres funcions i, a més, com a prova final del sistema o de flux.

També podeu recollir els defectes presentats anteriorment per la mateixa funcionalitat en versions anteriors. Idealment, s’hauria de provar un defecte de regressió mitjançant almenys cinc casos de prova diferents que utilitzin la funcionalitat.

Q # 44) Podeu venir amb un exemple dels següents defectes?

• Defecte d'alta gravetat de baixa prioritat
• Prioritat alta i defecte de baixa gravetat

Resposta : Un defecte que bloqueja l'aplicació quan es reprodueix només en un segell de temps determinat en un sistema operatiu concret pot ser un defecte d'alta gravetat i una prioritat baixa.

Un defecte arxivat contra una vista que no s'obre des del doble clic, sinó que s'obre amb un clic dret, pot ser un defecte d'alta prioritat i baixa gravetat.

Q # 45) Escriviu un cas de prova eficaç per comprovar si un determinat paper és un llibre blanc?

Resposta: Si el color de la tinta font amb què escriviu sobre paper blanc continua sent el mateix, el paper serà blanc. Per exemple, si escriviu en un paper blanc amb tinta vermella, el color de la tinta es mantindrà vermell al bolígraf i també apareixerà vermell al paper.

Nota: Hi ha moltes altres respostes a aquesta pregunta. Podeu pensar en qualsevol resposta vàlida amb una lògica subjacent.

Q # 46) Què són les proves Charter?

Resposta: Una prova de sessió realitzada sobre la base dels objectius i agendes que figuren en una carta abans de començar la prova es coneix com a prova de Carta.

Les proves aquí es fan en una franja horària fixa amb un enfocament menor a la documentació i més atenció només a les proves. És una variant diferent de les proves exploratòries en què els enginyers de proves verificen el programari en un període de temps ( Per exemple, només dues hores) basat en algunes heurístiques desenvolupades.

Q # 47) Quin és el vostre enfocament quan teniu una versió prioritària que es lliurarà en molt poc temps?

Resposta: En aquests casos, un pla ben pensat pot ser beneficiós.

Es pot fer el següent per ajudar a provar en un escenari d’escassetat de temps: -

• Utilitzar scripts d’automatització actualitzats existents per executar proves de regressió.
• La prova d’escenaris basats en flux de punta a punta.
• Executant casos de prova d'alta prioritat i si el temps ho permet, canvieu als casos de prioritat inferior.
• Torneu a provar els errors d'alta prioritat arxivats en versions anteriors.
• Proves ràpides de programari
• Es pot demanar als desenvolupadors que facin proves unitàries per obtenir més cobertura en les proves.

Q # 48) Escriure casos de prova en qualsevol dispositiu / objecte present al voltant (exemple: una cadira)?

Resposta: Un consell aquí seria: Comenceu sempre per reunir els requisits. Mostra la vostra maduresa cap al cicle de vida del desenvolupament de programari. No dubteu a fer preguntes després de seleccionar l'objecte.

En aquest cas:-

• Quin tipus de cadira és? Cadira d'oficina, taula d'estudi, cadira de sofà, taula de menjador, cadira confortable?
• Quin material s’utilitza per fabricar la cadira: fusta, acer, plàstic, tapisseria?
• Demaneu les dimensions (alçada, pes en funció del tipus de cadira).
• Demana disponibilitat. I a partir d’això comenceu a redactar els vostres casos.

Els casos de prova serien diferents per a cada tipus de cadira, cosa que és millor deixar-la per a la vostra capacitat de pensar ( Per exemple, finalitat de la cadira, dimensions segons el tipus de cadira, portàtil-no potable, lleuger, opcions de compra).

Per a cada cadira, a el cas de la prova de rendiment pot ser: per obtenir la resistència a la tracció o la capacitat màxima de suport.

Q # 49) Es pot automatitzar tot?

Resposta: - Fins a cert punt sí. Però les eines d’automatització, com altres programes, tenen les seves limitacions. A més, el programari en proves o l’aplicació en prova continuarà actualitzant-se.

Per tant, no hi ha garantia que les proves de programari es puguin executar sense intervenció manual. Al cap i a la fi, una eina és tan intel·ligent com ho és el provador. Simplement és provar un programari més. És el codi / scripts / biblioteques que ha de ser prou intel·ligent per provar i trobar defectes.

Conclusió

Espero que aquest exercici us ajudi a escalfar-vos amb algunes preguntes i us doni un bon començament per a les entrevistes i refineu la vostra confiança mentre responeu a les preguntes. A més, pot haver-hi altres preguntes basades en escenaris que puguin sortir del vostre currículum / perfil.

Per tant, sempre és aconsellable practicar una entrevista falsa amb autopromoció, de manera que l’entrevista resulti ser una situació guanyadora de guanys tant per a l’entrevistador com per al candidat. Recordeu que un analista de qualitat és més que un enginyer de proves, els comentaris dels quals són importants no només per a la qualitat del producte, sinó també per al procés seguit per provar el programari.

Gràcies i molta sort amb les entrevistes!

Lectura recomanada

• Preguntes i respostes de l’entrevista
• 25+ Preguntes i respostes d'entrevista ADO.NET més populars
• 25 millors preguntes i respostes d’entrevista de proves àgils
• Preguntes d'entrevistes de Spock amb respostes (més populars)
• Preguntes i respostes d’entrevistes de proves ETL
• 20 preguntes i respostes de l'entrevista TestNG més populars
• Top 30 de les preguntes i respostes més populars de l'entrevista de cogombre
• Top 50 de les preguntes i respostes de les entrevistes CCNA més populars