Menú

Preguntes d'entrevistes de proves manuals de programari per a professionals experimentats

software manual testing interview questions

Proveu El Nostre Instrument Per Eliminar Problemes

Preguntes més freqüents sobre les entrevistes de proves manuals basades en escenaris per a professionals experimentats amb respostes detallades:

Fa poc vaig viure aquesta experiència única coaching a QA (10 anys d’experiència) per assistir a una entrevista de proves de programari amb una empresa líder d’entreteniment a Los Angeles. El lloc que es va provar era un lloc web senzill orientat al client (com un canal de televisió en línia) que tenia components web i mòbils.

Preguntes d

Una empresa de consultoria projectava perfils a aquest client per a un provador in situ + posició de coordinador però cap d’ells va aconseguir el procés d’entrevista de proves. Així que van decidir recollir el Preguntes sobre l'entrevista QA dels assistents anteriors i em van donar un qüestionari.

com fer una còpia profunda d'una matriu java

Volien que donés les respostes al següent candidat i entrenador persona que tingui èxit a l’entrevista de control de qualitat.

Preguntes d

Quan vaig obtenir la llista de preguntes, em vaig sorprendre i «no sorprendre» alhora. Sorprès, perquè les preguntes eren realment bàsiques i un QA amb experiència de deu anys hauria d’haver estat capaç de respondre-les fàcilment. No em sorprèn tant, segons la meva opinió, el QA és el camp de les TI que té més males herbes, però no hi entrem.

Després de fer l’exercici, vaig pensar que seria bo compartir aquesta experiència amb els lectors de STH. Per als principiants, aquesta serà una bona exposició en directe. Per a d’altres, serà un amable recordatori de la importància fonaments tinguem per experiència que tinguem.

Lectura recomanada=> 101+ Preguntes i respostes d’entrevistes de proves de programari.

Aquí va…..

Preguntes d'entrevistes de proves manuals per a persones experimentades

9 preguntes més freqüents sobre les entrevistes de proves de programari de control de qualitat per a principiants i candidats experimentats:

#Q 1) Quin és el procés per crear un script de prova?

Resposta:

Pas 1: és obtenir una comprensió completa de l’automòbil:

  • Això podria ser llegint a fons els documents de requisits.
  • En absència de documents, podríem intentar comprendre qualsevol punt de referència que tinguéssim, una versió anterior de l’aplicació, marcs de filferro o captures de pantalla.

Pas 2: Després d’entendre els requisits, fem una llista de quins són els àmbits d’aquesta aplicació que s’hauran de provar. En altres paraules, identifiquem els requisits de la prova. El focus en aquest pas és identificar 'Què' provar. El resultat d'aquest pas és una llista de Escenaris de prova .

Pas 3: Un cop tenim els escenaris de prova, ens concentrem a continuació en 'Com' provar-los. Aquesta fase consisteix a escriure passos detallats sobre com provar una característica concreta, quines dades cal introduir ( Dades de prova ) i quin és el resultat esperat.

Un cop fets aquests 3 passos, ja estem a punt per provar-los.

#Q 2) Quins són els camps d'un informe d'errors?

Resposta: S'han d'incloure els següents camps importants a bon informe d'errors :

  1. Una identificació única
  2. Descripció del defecte: breu que descriu què és l’error.
  3. Passos per reproduir: detalls sobre com arribar a l'error, dades exactes de la prova, hora en què es va trobar el defecte (si escau) entorn: qualsevol informació que ajudi a tornar a trobar el problema
  4. Mòdul / secció de l'aplicació (si escau)
  5. Gravetat
  6. Captura de pantalla
  7. QA responsable: en cas de qualsevol pregunta de seguiment sobre aquest problema

#Q 3) Com provar un programari orientat al client?

Resposta: Amb qualsevol aplicació que provem, intentem veure si l'aplicació compleix o no un determinat conjunt de requisits. Però quan es tracta d’un lloc orientat a l’usuari, a part de concentrar-nos en la funcionalitat, també hem d’examinar algunes funcions d’usabilitat, potser fins a cert punt també aspectes de rendiment i seguretat.

El primer nivell de proves és : El lloc compleix els seus requisits funcionals.

Per exemple, si es tracta d’un lloc de gestió de préstecs, hem de tenir en compte: el nou client pot sol·licitar un préstec, el client existent pot accedir a la informació del préstec, és el percentatge d’interès aplicat a l’import del préstec, etc.

El següent nivell de proves és :Què tan fàcil és utilitzar el lloc, les opcions tenen un sentit lògic i compleixen o no les expectatives de l’usuari?

Per exemple, si l'usuari ha de passar 3-4 pantalles per enviar la informació bàsica, li molestarà, de manera que s'hauran de solucionar aquests problemes.

algorisme d’ordenació de shell c ++

Un altre exemple, després d’introduir el nom d’usuari i la contrasenya, l’usuari pot fer clic a la pestanya; això vol dir que el control hauria d’anar al botó “Inicia la sessió”; en canvi, si es cancel·la, l’usuari estarà realment molest i l’experiència d’utilitzar el lloc és estarà compromesa. Aquests problemes s’han de detectar.

Proves de rendiment en la seva mesura completa, potser no estigués dins l'abast, però situacions simples com, quant de temps triguen a mostrar-se els resultats de cerca i quant de temps triga el sistema a recuperar la informació del client a l'hora punta: aquests són alguns exemples de tipus de coses que voldríem vigilar.

Seguretat - per als llocs on hi hagi un inici de sessió segur per accedir al lloc, s'ha de provar la funcionalitat mínima al seu voltant. Per exemple, si deixo el lloc inactiu durant més de 10 minuts, es tanca la sessió automàticament o no? Una cosa tan bàsica com aquesta s’hauria de centrar.

#Q 4) Com superar el repte de no tenir documentació d’entrada per a les proves?

Resposta: SI la documentació estàndard detallada com BRD i FSD no està disponible, el provador haurà de dependre d'algun punt de referència.

  • Captures de pantalla
  • Una versió anterior de l'aplicació
  • Marcs metàl·lics, etc.

Un altre factor que ens ajuda enormement és parlar amb els desenvolupadors o els analistes de negoci (quan estigui disponible) per obtenir una confirmació de la nostra comprensió o aclariments en cas de dubtes.

Quan cap d’aquestes situacions no funciona, només podem conceptualitzar l’aplicació basant-nos en la nostra experiència d’aplicacions de TI anteriors i crear el conjunt bàsic d’escriptures de prova. Quan arriba la fase de proves, podem configurar una part del temps del cicle de prova i fer una gestió de casos pràctics (fer que els scripts ja creats siguin perfectes), de manera que disposem del document per a les properes fases.

#Q 5) Com arribar-hi màxima productivitat d'un equip offshore?

Resposta: La clau és assegurar-se que tots els verificadors coneguin tots els mòduls i que no hi hagi concentració de coneixement en un lloc. La participació de tothom en les revisions d’equips de scripts de prova, reunions de defectes i sessions de KT assegurarà que tothom sigui conscient de l’aplicació en la millor mesura possible.

A més, fomentant el concepte de treball en equip podem fer que els membres de l’equip col·laborin, s’ajudin i s’ajudin mútuament per obtenir una millor productivitat.

el millor reproductor de DVD de Windows 10

Les reunions de seguiment periòdiques també ajuden molt el procés.

#Q 6) Quins són els rols i les responsabilitats d'un coordinador in situ? També fa proves?

Resposta: El coordinador del lloc és un punt de contacte per a l'equip offshore i per al client per obtenir informació sobre la participació de les proves.

Aquesta feina inclou:

  • KT des de i cap a fora i clients
  • Aconseguir que l’entorn provi tot a punt
  • Proves de seny, proves de fum
  • Prova: la funcionalitat clau.
  • Revisió d'errors: trobat per l'equip offshore
  • Assignació d'errors al dev
  • Presentació de mètriques
  • Proporcionant el tancament de sessió

Sí, fins i tot un coordinador del lloc ha de provar.

#Q 7) Errors incoherents: per què pot trobar-los en el lloc, però a l’estranger no i viceversa: Com gestionar aquesta situació?

Resposta: Cal assenyalar i analitzar tots els errors, tant si es produeixen en el lloc com a l’estranger, siguin repetibles o no. Un valor afegit real a la feina d’un provador és quan ens implicem en el procés d’anàlisi de la causa arrel d’un error en lloc de simplement informar-ne.

Algunes de les maneres de gestionar aquesta situació són:

  • Tots els membres de l’equip on-site i offshore haurien de seguir una pauta que hauria de fer captures de pantalla per a cada error que ens trobéssim, repetible o no.
  • Si hi ha registres, fitxers del sistema o qualsevol cosa semblant, això ens pot ajudar a trobar evidències del problema; hauríem d'intentar trobar-lo.
  • Malgrat tots aquests passos, si encara no sabem per què i quan es produeix el problema, hauríem d'informar-lo al desenvolupador de la mateixa manera, amb tota la informació que puguem.

#Q 8) Proves relacionades amb vídeo / àudio: què inclou això?

Resposta: Com provar una aplicació que tingui vídeo o àudio?

Aquests són els punts importants a tenir en compte:

  • Nivells d'accés (restringit o no: controlat per contrasenya)
  • Diferents tipus d’ambients
  • Compatibilitat amb el navegador
  • Resolucions de pantalla
  • Velocitat de connexió a Internet
  • Les opcions específiques d’un vídeo, com ara reproduir, aturar, silenciar, etc.
  • Vídeo per mida
  • Resposta als vídeos: comentaris (limitacions de la durada del comentari i del nombre de comentaris que pot prendre)
  • Respostes de vídeo als vídeos
  • Interfície amb llocs de xarxes socials: interoperabilitat
  • Velocitat de memòria intermèdia
  • Inserció del vídeo

#Q 9) ​​Prova d'aplicacions mòbils: què inclou breument?

Resposta: Prova d'aplicacions mòbils Escenaris de prova importants:

  • Comproveu si l'aplicació funciona bé amb diversos operadors i diversos dispositius.
  • Usabilitat de les funcions de la pantalla del mòbil.
  • Provant-lo en diferents plataformes mòbils, com ara Android i iOS.
  • Instal·lacions, desinstal·lació, inici de l’aplicació amb xarxa i sense xarxa, prova de la funcionalitat.
  • Connexions de xarxa –WiFi, 2G, etc.
  • Els registres de la utilitat de configuració de l'iPhone d'iOS per a Android Monitor.bat es poden utilitzar per a la depuració.

Això va ser tot. Ara bé, no era tan senzill.

Com a nota final, reitero la filosofia d’STH: coneix bé els conceptes bàsics, la resta segueix automàticament.

Conclou, esperant que aquest esforç sigui beneficiós i significatiu per als nostres lectors. Si us plau, feu-nos-ho saber a la secció de comentaris sobre com ho vam fer.

Autor: Aquest article està escrit per Swati Seela, membre del nostre equip de STH.

Lectura recomanada

^