Automatitzar les proves

L’Automatització de proves requereix els següents passos:

1. Avaluar el retorn d’inversió en l’automatització, per determinar si convé o no automatitzar les proves (depèn del nombre d’execucions, l’inversió i el seu retorn, …)

   Un dels majors errors en l’automatització de les nostres proves és no escollir correctament les proves a automatitzar. Cal fer una anàlisi inicial del seu retorn d’inversió, comparant els costos de fer l’execució de les proves de forma manual respecte l’automatització de les proves.

2. Projecte d’automatització. Una vegada acordat si es farà automatització o no, i quins casos de prova s’automatitzaran, s’ha de realizar la seva automatització.

Avaluació retorn inversió automatització

No tot es pot automatitzar i no tot s’ha d’automatitzar. Cal fer una anàlisi prèvia de que convé automatitzar en base a una relació de cost/benefici.

Per realitzar l’exercici s’ha d’usar la plantilla Calculadora del ROI d’automatització de proves d’un projecte tenint en compte els següents apartats.

Identificar abast i nombre d’execucions

Identificar casos de prova candidats per la seva automatització

El primer pas és identificar quins són els casos de prova que té sentit automatitzar, en base als següents criteris:

• Verifiquen una funcionalitat de criticitat alta (formen part habitualment del que anomenem proves de regressió). Cal en aquests casos ser molt curosos. Es recomanar fer-ho de forma manual si no s’està segur de que l’automatització és completa, efectiva i no té errors.
• Estabilitat de la funcionalitat. Si la funcionalitat no és estable NO automatitzar (cal tenir en compte que si canvia la interfície s’haurian de reprogramar les proves automatitzades)
• Diferents jocs de dades o un volum important de dades. Si volem executar les proves amb un nombre diferents de jocs de dades, és recomanable automatitzar.
• Diferents configuracions d’entorn. Si volem executar les proves en diferents entorns, navegadors Web, versions, és totalment recomanable automatitzar-les.
• Dificultat tècnica. No automatitzar casos de prova que tècnicament són molt i molt complexos i/o no arribarem a tenir certesa del seu resultat. Per exemple, si dins el procés s’obre un PDF i s’ha de visualitzar un resultat dins d’ell, el procés automàtic pot ser no beneficiós.
• Proven funcionalitats reutilitzables o transversals per altres aplicacions

Una vegada haguem desglossat els casos de prova i identificat quins són automatitzables i quins no, farem un recompte total, i ficarem aquest valor en la cel·la “Quants casos de prova es preveu automatitzar”.

Identificar freqüència d’execució de les proves

En aquest pas hem d’identificar al camp “Quantes vegades s’executen les proves a l’any”, el nombre de cops que executem a l’any el conjunt de proves determinat en el pas anterior.

Calcular el cost de les proves manuals

Identificar a l’apartat Cost proves manuals:

• Quin és el temps total en hores per executar les proves manuals que es preveu automatitzar?. És a dir, del nombre total de proves que s’ha considerat automatitzar, quant tardem en executar-les manualment?

• Cost hora tester manual. Cost sense IVA d’una hora d’un tester que fa les proves manuals.

Calcular el cost de les proves automàtiques

1. Revisar els esforços mitjos per complexitat de cas de prova (taula Esforços mitjos segons complexitat (h)). L’automatització d’un cas de prova depèn de la seva complexitat, tenint en compte:

   • Accions. El nombre d’accions que realitza l’usuari sobre l’aplicació en la prova
   • Verificacions. El nombre de verificacions o checkpoints que s’ha de realitzar (per verificar que el resultat real és l’esperat, p.ex. comprovant per pantalla que surt un text)
   • Jocs de dades. Si es parametritzaran les dades d’entrada de les proves (amb una graella de dades).

   Els valors específics per complexitat depenen de l'experiència de l'equip, la tecnologia, o el tipus de projecte, però s'han establert els següents valors mitjos de referència en els projectes per a la Generalitat de Catalunya:

   • Simple. 2 hores
   • Complexitat mitja. 4 hores
   • Complexitat alta. 8 hores

   S'ha establert un estàndard d'hores mitges per complexitat que NO s'ha de tocar.

2. Determinar del total de casos de prova identificats al primer pas quin percentatge hi ha de cada tipus de complexitat

   Per exemple, es pot usar com a guia:

   • Simple. Menys de 5 accions i/o 5 verificacions, sense joc de dades
   • Mitja. Entre 5 i 15 accions i/o entre 5 i 10 verificacions i/o amb joc de dades de prova
   • Complexa. Més de 15 accions i/o més de 10 verificacions i/o amb joc de dades de prova amb un volum important de dades extret d’un sistema extern
   • Molt complexa. Un cas de prova que requereix quelcom més difícil que Complexa

   

   Per exemple: 25% de Simple, 50% de Mitja, 15% de Complexa i 10% de Molt complexa

3. Determinar el cost per hora d’un tester d’automatització

Una vegada introduïdes aquestes dades ja podrem disposar de l’import total que implica la tasca d’automatització de totes les proves identificades a la cel·la COST TOTAL DESENVOLUPAMENT AUTOMATITZACIÓ

Estimar el cost de manteniment de les proves automàtiques

Les proves automàtiques definides han de mantenir-se en el temps, degut a canvis del programari. En aquest punt % Cost anual modificació de l’automatització casos de prova s’estableix quin és el percentatge habitual d’esforç en manteniment requerit, respecte l’esforç inicial d’automatització.

Estimar el cost de revisió per a cada execució automàtica

Una revisió manual de l’execució d’unes proves acostuma a ser tediòs, però en una execució automàtica no és un temps zero. A la finalització cal revisar si hi hagut algun problema d’execució, s’han registrat els resultats correctament, etc.

En aquest punt Quin serà el temps previst en revisar els resultats de cada execució introduir quantes hores (o decimals d’hora) cal per revisar com ha anat l’execució automàtica.

Avaluació final del ROI

Amb totes les dades recollides podem visualitzar a la taula final:

Si recuperem o no la inversió abans de 4 anyhs, i en quin cas afirmatiu en quin any concret recuperem la inversió de l’automatització (mostrat amb un Sí a la fila Recuperació d’inversió)

Projecte d’automatització

Consideracions

Enfoc d’automatització

L’automatització dels scripts ha de considerar de forma més detallada com es portarà terme l’automatització dels casos de prova, utilitzant l’enfoc més adequat i acordat:

• Gravació i reproducció (Record and replay). Amb una eina, com HP UFT, es captura una navegació real que es pot reproduir posteriorment (es genera un script bàsic)
• Automatització per paraules clau (keyword-driven). Les proves dirigides per paraules clau permeten dissenyar les proves des d’un punt de vista de negoci, enlloc de objectes.
  

Per exemple, l’eina HP UFT pot reconéixer una sel·lecció d’una opció com varis passos: un click en un objecte de tipus botó, una operació de ratolí per moure’s en la llista mostrada i una tecla premuda per sel·leccionar un element. Podem agrupar aquestes operacions de baix nivell en una única, paraula clau de negoci. Aquesta paraula clau, també pot reutilitzada per crear nous casos de prova sense coneixement tecnològic previ (reutilitzant aquestes accions). A més, com a benefici, es millora el manteniment, ja que un canvi a la presentació només afecta al lloc on s’ha definit l’acció, no tot arreu on s’usa. En l’exemple, les diferents operacions que interactuen amb la pantalla (escollir el camp ‘fromPort’ i seleccionar el valor ‘New York’, …) estan agrupades en l’acció ‘Cercar un vol’.

• Automatització dirigida per dades (data-driven). S’usen variables per representar les dades de prova i s’usen diferents jocs de dades (des d’un fitxer extern, una graella de dades, …) per reproduir el script en diferents escenaris.
• Automatització híbrida. Combina les opcions prèvies.

Elements d’automatització

Quan es registra una automatització s’interactua amb objectes (botons, enllaços, …) mitjançant esdeveniments (prémer, passar per sobre, …).

En el cas de l’automatització de interfícies d’usuari, es poden millorar les automatitzacions amb diferents tipus d’elements:

• Checkpoints o verificacions. Verificació que compara el valor actual (en l’execució de la prova) d’una propietat o característica d’un objecte amb el valor esperat. Per exemple, podem:

  • Verificar que el text mostrat per pantalla correspon a l’esperat
  • Verificar que després de seleccionar un radio button està activat
  • Verificar que es mostra una imatge específica
  • Verificar el text d’un PDF
  • Verificar la base de dades per comprovar que s’ha emmagatzemat correctament la informació

• Valors de sortida. El cas de prova pot recuperar valors i emmagatzemar-los per ser usats com a entrada en un pas posterior de l’execució.

• Parametritzacions de valors. El cas de prova pot parametritzar els valors d’entrada o sortida per ser usats en la prova

• Accions. Divisió de la prova en accions (keyword driven testing)

Activitats d’automatització

Preparació del cas de prova i la infraestructura de proves

Durant les tasques prèvies a l’automatització d’un cas de prova cal:

1. Executar el cas de prova manualment abans de la seva automatització per verificar el seu correcte funcionament
2. Sel·leccionar les dades i/o generar les dades que seran usades en l’execució de l’automatització
3. Identificar si es poden reutilitzar accions prèvies ja existents (login, mateix punt de navegació fins fer diferents casos de prova, …)

Crear els passos de les accions

1. Registrar el cas de prova amb l’eina de gravació/reproducció
2. Estructurar els passos registrats en accions comprensibles (keywords)

Millorar el cas de prova

Incorporar:

• Punts de verificació o checkpoints, per comprovar que els resultats reals són els esperats.
• Parametrització de les dades de prova (entrada de dades mitjançant una graella per exemple), reemplaçant els valors fixos de les accions per paràmetres, per poder usar valors específics en cada iteració de la prova.
• Valors de sortida (per exemple recollits en una pantalla prèvia i que volem usar en una altra pantalla més endavant)

Executar la prova i depurar-la

1. Depurar la prova per identificar i eliminar defectes en la prova
2. Provar l’aplicació amb la prova

Analitzar resultats i informar defectes

Durant l’execució de la prova s’han de poder visualitzar els resultats amb imatges, vídeos, …