Menú

Com preparar-se per escriure casos de proves (Consells sobre productivitat)

how prepare yourself

Proveu El Nostre Instrument Per Eliminar Problemes

Com preparar-se per escriure casos de proves i millorar la seva productivitat:

Quan un provador decideix escriure casos de prova d’alta qualitat i vol millorar la seva eficiència i la productivitat de l’escriptura de casos de prova, hi ha pocs punts clau que ajudin els verificadors a assolir aquests objectius.

En primer lloc, han de preparar-se professionalment i psicològicament amb alguns dels punts clau necessaris per a tots els provadors de programari amb èxit de la indústria de TI. Això es tractarà com ' Entrades ”Per a un provador abans de començar a escriure casos de prova.

redacció de casos de prova

A continuació, han d’entendre les mètriques de qualitat implicades en el projecte, que s’utilitza com a eina per avaluar el rendiment del comprovador en diverses fases del cicle de vida de les proves. Això es tractarà com ' Sortides ”Per a un provador després de completar-lo redacció de casos de prova .

Finalment, el comprovador ha de saber com s’informa l’error, s’incrementen els problemes i com es preparen els informes de proves en línia amb el procediment estàndard i poden ser comprensibles per les parts interessades del projecte.

Què aprendreu:

la millor eina de gestió de casos de prova per a jira

Prepareu-vos per escriure casos de proves

1) L’escriptura de casos de prova és un art i no és només una feina. Es pot dissenyar i desenvolupar una peça o un segment de programari, però fins que no es provi completament per a tots els escenaris amb un enfocament de prova eficient, serà inútil i no podrà ser publicat i utilitzat per ningú. Tan, tractar-se com una persona important en el projecte i tractar la seva activitat de proves com una tasca important en el projecte .

2) El passió amb actitud positiva , que és la màxima personalitat haurien de tenir els provadors de qualitat al llarg del cicle de vida del projecte. La passió motiva les capacitats de formació d’equips i l’actitud aporta una gran productivitat a l’hora d’escriure casos de proves de qualitat. És a dir, l’activitat d’escriptura de proves és una barreja de qualitats professionals i personals per a un objectiu comú d’aconseguir grans resultats com a resultat final del projecte.

3) Positiu i casos de proves negatius formen part d’escriure casos de proves, però els verificadors haurien de tenir un semipositiu mentalitat per trencar l'aplicació que es prova provant errors . Aquesta no és una mentalitat negativa, sinó evitar la situació d’identificar un error per algú després del llançament o evitar la situació en què alguns usuaris del sistema trenquin el sistema.

4) Eficiència del provador no s’ha d’estimar en funció del nombre d’errors identificats al sistema que s’està provant, sinó de la capacitat d’escriure casos de prova amb èxit que resulten del descobriment dels defectes. Per tant, els casos de prova s’han d’escriure de manera que la cobertura i traçabilitat ha de ser màxim segons el límit i l'abast del sistema.

5) Conegui bé el domini de l’aplicació .Per exemple, provar un lloc web és més fàcil que provar un programari financer desenvolupat per a la borsa que utilitzen milers de persones alhora. Qualsevol provador pot comprendre la funcionalitat de llocs web senzills, mentre que els termes i les funcionalitats financeres no poden ser comprensibles per a tots els verificadors fins que no tinguin la formació o la formació pertinents o tinguin experiència de domini .

Per tant, quan s’assigna un provador a un nou projecte, hauria de fer una autoavaluació, tant si són elegibles com si poden realitzar la seva feina segons les expectatives o no. Si els requisits funcionals són difícils d’entendre, s’haurien de comunicar a l’equip del projecte amb molta antelació per evitar futures idees errònies sobre l’eficiència i el rendiment del comprovador. Serà gestionat pel cap de projecte o el cap de proves mitjançant plans i formació adequats.

6) Els requisits del projecte i els tipus de proves a realitzar varien d'un projecte a un altre. Un provador hauria d’estar preparat per fer qualsevol tipus de prova. No limiteu les vostres capacitats a les teves habilitats i especialitats. Estigueu preparats per assumir responsabilitats i reptes per escriure i executar casos de prova per a qualsevol tipus de prova.

Molts provadors intenten adaptar-se o projectar-se només com a provadors manuals o d'automatització. Quan arriben a proves de rendiment, proves de càrrega o proves d’estrès, són pocs els verificadors que prenen els rols i es preparen formant o recopilant els coneixements necessaris. Tan, ser un aprenent ràpid i estigueu preparats per assumir responsabilitats i créixer a la vostra carrera.

7) Identifiqueu els tipus de proves a realitzar i les habilitats necessàries per provar el AUT. Per exemple, alguns projectes només requereixen proves de caixa negra i d’altres requereixen habilitats per provar caixes blanques. El coneixement de “ guions 'O experiència a' SQL 'O treballar amb' marca el llenguatge ”, Com ara HTML / XML, etc., o fins i tot un coneixement del sistema sobre com instal·lar / solucionar problemes d’instal·lació del programari, etc. són alguns requisits específics del projecte que heu d’aprendre vosaltres mateixos o formar-vos per al mateix.

8) Assegureu-vos que els casos de prova cobreixen el Tipus de proves de rendiment, proves de seguretat i proves de regressió. Per exemple, per iniciar sessió a l'aplicació mitjançant la pantalla d'inici de sessió següent:

Eficiència del cas de prova 2

  • És possible que calgui fer proves de rendiment per comprovar si l’aplicació és estable quan milers d’usuaris inicien sessió al sistema alhora i els casos de prova s’han d’escriure per cobrir aquest escenari.
  • És possible que calgui fer proves de seguretat per comprovar si l'aplicació només permet que els usuaris que tinguin els drets i permisos adequats puguin utilitzar el sistema i els casos de prova s'han d'escriure per cobrir aquests escenaris.
  • És possible que calgui fer proves de regressió per comprovar si la funcionalitat bàsica i les funcions crítiques funcionen correctament en cada versió.

9) Revisió de casos de prova : Una de les fases més importants i més ignorades de qualsevol desenvolupament de programari i del cicle de vida de les proves és ' REVISIÓ ”. Quan un pla de projecte inclou prou assignació de temps per a un procés de revisió en totes i cadascuna de les etapes del desenvolupament del projecte, es poden esperar els resultats i els resultats de més qualitat.

Per exemple, abans de començar a escriure casos de prova, els verificadors haurien de comprovar si es revisa el document 'especificació de requisits' i es consideren i actualitzen tots els punts de revisió al document. Si l'organització segueix un procés adequat i madur, totes les plantilles de documents haurien de tenir aquesta informació de canvi a la primera pàgina del document.

Els documents de casos de prova s’han de revisar almenys 3 vegades mitjançant:

i) Auto-revisió
ii) Revisió per parells
iii) Revisió per part de tercers de la integritat, la cobertura de la prova, la traçabilitat i si el cas de la prova es pot comprovar o no.

10) Finalment, entendre com estimar i planifiqueu les tasques de proves . Planifiqueu treballar només durant l'hora prevista prevista en un dia. Això es pot aconseguir iniciant i completant les tasques a temps i sortint al dia amb els plans per a les tasques del dia següent.

Eviteu quedar-vos a la nit i passar els caps de setmana a l’oficina. Avui en dia, hi ha disponibles enfocaments de gestió de projectes eficients i els projectes s’executen en un entorn àgil. Si els equips del projecte no aconsegueixen fites, es tractarà com una gestió del projecte ineficient en lloc de la ineficiència dels equips del projecte.

Nota : Tingueu en compte, fins i tot per proves automatitzades , els casos de prova s’han d’escriure i revisar clarament almenys una vegada, cobrint completament el flux funcional de l’aplicació sotmesa a prova. Qualsevol eina de proves d'automatització només pot registrar i executar casos de prova quan els casos de prova manuals estan definits i escrits clarament.

Mètriques de qualitat

Aquesta és una activitat important en les fases de proves de programari. L’equip de proves hauria de ser completament conscient de les diverses mètriques de prova que s’utilitzen per assolir l’objectiu del projecte. El rendiment del comprovador no s’avalua basant-se només en la fase d’execució de la prova, sinó en totes les mètriques de prova recollides de l’anàlisi de requisits, l’escriptura de casos de prova, l’execució, l’informe de defectes i, finalment, la fase d’informe de proves.

A continuació trobareu algunes mètriques de prova importants seguit de la majoria de les organitzacions per millorar la productivitat dels verificadors i l'eficiència de les fases de proves.

A més, vegeualtres mètriques de prova útils utilitzades en les fases de prova:

=> Mètriques i mesures de prova de programari importants i Seguiment d'errors del projecte en viu, mètriques de prova i procés de tancament de prova.

1) Eficiència mitjana de les proves

  • Errors per mes d'home de l'esforç de prova.
  • Calculat com a mitjana (Total d'errors durant l'esforç de prova en mesos-home).
  • Es calcula després de cada versió interna i després de la finalització de la prova.
  • Límit d’acceptació: ha de ser inferior a 50

2) Densitat mitjana de defectes del client

  • Els errors reportats pel client després del lliurament van suposar un esforç total de proves en mesos laborals.
  • Calculat com a Mitjana (Total d'errors després del lliurament / prova d'esforços en mesos-home).
  • Es calcularà després de la versió externa i la finalització del projecte.
  • Límit d’acceptació: ha de ser inferior a 1

3) Fracassos de la prova funcional

  • Nombre de casos de proves funcionals fallides / Nombre total de casos de proves funcionals executats.
  • A calcular mensualment o quinzenalment.

4) Errors amb nivell de gravetat 1

eines de proves d'automatització per a aplicacions mòbils
  • El nombre total d'errors identificats amb el nivell de gravetat 1 (bloquejador).
  • No es poden continuar les proves del programari a causa dels problemes de bloqueig.
  • A calcular setmanalment.

5) Errors amb nivell de gravetat 2

  • El nombre total d'errors identificats amb el nivell de gravetat 2 (errors principals).
  • No es pot continuar la prova de la funció a causa dels errors principals, però es pot continuar amb altres parts del sistema.
  • A calcular setmanalment.

6) Errors amb nivell de gravetat 3

  • El nombre total d'errors identificats amb el nivell de gravetat 3 (errors menors).
  • Les proves es poden continuar ja que els errors identificats són menors i no atura la prova.
  • A calcular setmanalment.

7) Errors amb nivell de gravetat 4

  • El nombre total d'errors identificats amb un nivell de gravetat 4 (problemes cosmètics).
  • Les proves es poden completar sense problemes, ja que els errors identificats estan relacionats amb la cosmètica i s’arreglaran per a la propera versió.
  • A calcular setmanalment.

Informes d'errors

El mecanisme d’informació d’errors s’ha de controlar mitjançant un procés de prova madurat per mantenir la qualitat de l’aplicació. Hauria d’haver un procés d’escalada adequat per a les persones autoritzades adequades per conèixer l’estat, la gravetat i la prioritat de l’error. N’hi ha Hi ha moltes eines gratuïtes i comercials per informar d'errors com Bugzilla, Mantis, etc., que són molt eficaços en el mecanisme de seguiment de problemes i es poden integrar fàcilment amb qualsevol eina de gestió de proves utilitzada al projecte.

En tots i cadascun dels projectes de proves, cal seguir els procediments estàndard per a un mecanisme d'informes d'estat en línia diàriament. Tots els errors / problemes registrats i informats en aquests sistemes de seguiment d'errors haurien d'enviar immediatament un correu electrònic a les autoritats respectives que els ajudaran a planificar i prendre mesures en conseqüència.

Per conèixer en detall el procés d’informació d’errorsllegiu els articles següents:

=> Com escriure un bon informe d'errors? Consells i trucs
=> Exemple d'informe d'errors
=> Per què la notificació d'errors és un art que tots els provadors haurien d'aprendre?
=> Cicle de vida dels errors
=> Exemples d'informes d'errors per a aplicacions web i de productes

Informes de proves

A part dels informes d'errors generats, registrats i escalats al sistema d'informes d'errors, un informe de prova és un dels documents més importants per conèixer l'estat de la prova i altres mètriques importants identificades i calculades durant el període de temps de presentació d'informes.

A continuació es mostra un informe tan senzill:

Llegiu també els següents tutorials útils per ainformes de proves efectius:

=> Guia per redactar un informe de resum eficaç de la prova
=> Com informar de manera intel·ligent de l'execució de la prova (baixar la plantilla d'informe d'estat)

què és la prova de regressió a la prova de programari

victoriosa

jaya1

Conclusió

El procés de preparació per escriure casos de prova no només és l’assignació de recursos al projecte, sinó que hi ha pocs requisits clau com preparar-nos com a provadors elegibles i entendre les mètriques de qualitat que es controlen durant tot el cicle de vida de les proves i fins i tot després de la publicació.

Per tant, seguir el procés, els estàndards, els procediments i complir estrictament les mètriques de qualitat amb passió, us pot aportar automàticament una gran eficiència de proves, productivitat i un test de qualitat, que esdevindrà un hàbit a la vostra vida professional.

Aquests factors de qualitat es poden autoanalitzar o analitzar en grup fent algunes preguntes que ens dirà si anem pel bon camí de la millora de nosaltres mateixos i de processos amb l'objectiu d'aconseguir un enfocament eficient en l'escriptura i l'execució de casos de prova:

  • Heu passat pels requisits funcionals / requisits de l'usuari / documents de casos d'ús empresarial?
  • S'ha revisat i actualitzat correctament el document de requisits funcionals amb comentaris de revisió?
  • Heu rebut els prototips de pantalla de totes les funcions a provar?
  • Esteu còmode escrivint casos de prova que es poden comprovar i rastrejar durant tot el cicle de vida de les proves?
  • Teniu els coneixements de domini i coneixements necessaris per provar l'aplicació que es prova?
  • Necessiteu formació o coneixements tècnics necessaris per executar els casos de prova?
  • Té el calendari per escriure, revisar i executar casos de proves, que cobreixi el temps per preparar documents de qualitat?
  • Teniu els companys per revisar els vostres casos de prova i un expert autoritzat en matèria per verificar la exhaustivitat i la cobertura de les funcions i funcionalitats a provar?
  • Té suficients casos de prova per a tots els requisits funcionals?
  • Té prou casos de proves per al rendiment, les proves de càrrega i les proves de seguretat?
  • Té suficients casos de prova per a la instal·lació i la prova de regressió?
  • Teniu el punt de contacte per augmentar els problemes o informar d'errors?
  • L'eina de seguiment d'errors està configurada correctament amb tots els permisos necessaris?
  • Esteu còmodes seguint tots els processos definits al pla de proves?
  • Esteu participant en totes les reunions de revisió i teniu l'oportunitat de parlar amb l'equip de desenvolupament o de gestió?
  • Es millora la vostra productivitat i eficiència o heu de prendre alguna mesura per això?

Lectura recomanada = >> Els millors cursos d’escriptura creativa en línia

Hi ha moltes preguntes similars que es poden fer els avaluadors per fer anàlisis de millora personal, en funció del tipus de projecte o de l’organització amb què treballin. El més important és que totes aquestes activitats no s’han de seguir només per seguir els processos, sinó que s’han de fer com els seus hàbits diaris que es poden fer a través de PASSIÓ PER LES PROVES només.

PREV Tutorial | NEXT Tutorial

Lectura recomanada

^