Automatització de proves

Podem realitzar les proves sempre de forma manual, sense usar l’automatització, però això pot arribar a ser molt costós en el llarg termini, especialment si participa un equip gran. Automatitzant les proves, podem cobrir tasques repetitives, comunes i reduir l’equip de proves o fer per exemple que participin per trobar més defectes mitjançant proves negatives (provar com “trencar” l’aplicació, enlloc de reproduir el que s’espera).

Avantatges i desavantatges de l’automatització

Els avantatges de l’automatització versus l’execució de proves manual són principalment:

• Eficàcia. Són més ràpides d’executar que de forma manual, i en menor temps podem fer més proves (cobertura)
• Repetibilitat. Poder provar sempre sota les mateixes condicions les mateixes proves (no es depén de la interpretació humana)
• Reutilització. Poder provar amb diferents escenaris d’entorns.
• Confiança. S’evita l’error humà.
• L’esforç de re-prova durant el cicle de correctius/evolutius és molt més petit que les proves manuals

Però cal considerar que té alguns desavantatges:

• El cost d’automatització inicial és alt. Es tracta d’una inversió, i com a tal ha de comparar-se el seu cost amb el retorn en el temps.
• S’ha de preveure el seu manteniment (en definitiva és codi que necessita ser mantingut en cas que canvïi l’aplicació o la seva interfície)

Estratègia d’automatització

Durant l’estratègia d’automatització s’ha de planificar quin serà l’abast de l’automatització i identificar els candidats que s’automatitzaran i en quin ordre es realitzaran.

Té sentit automatitzar?

El primer pas en l’automatització ès avaluar si té o no sentit automatitzar les proves. Cal prendre en consideració:

1. No automatitzar mai els processos complets de proves. Les proves exploratòries sempre trobaran més defectes dels que podem trobar mitjançant l’automatització.
2. L’automatització és una eina, no una solució. Si no s’aplica amb bones habilitats, el resultat pot ser totalment inefectiu.

3. L’automatització ha de donar almenys un retorn de 4:1 respecte a les proves manuals. Avaluar:

   • Nombre total de casos de prova. Nombre de casos de prova a executar (manuals i automatitzats)
   • Nombre d’execucions per cicle. Mitja de vegades que repetim les proves en cada cicle/build/versió
   • Nombre de cicles anuals.
   • Temps total d’execució manual. El temps mig per executar manualment els casos de prova i analitzar els seus resultats.
   • Costos de llicenciament de l’eina d’automatització.

     En general, a partir del 6è cicle de prova (repetició) el cost global de proves automàtiques és menys costós que el de proves manuals.

4. L’aplicació està “estàtica”, en el sentit que el que volem provar no té ja modificacions

Identificar candidats automatització

Com no s’ha d’automatitzar tota l’aplicació, és important identificar els escenaris de negoci més crítics que són ideals per la seva automatització. Hem de determinar el percentatge de casos de prova que automatitzarem per determinar quant de temps necessitarem durant el projecte.

Escollirem els casos de prova amb:

• Casos amb criticitat alta. NOTA: 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.
• Casos de prova que s’han d’executar repetidament (vàries vegades l’any)
• Casos de prova que són força tediosos o difícils de realitzar manualment
• Casos de prova amb diferents jocs de dades o un volum important de dades
• Casos de prova que s’executen en diferents navegadors

Identificar la complexitat de les proves a automatitzar

El cost d’una automatització d’una prova depén de la seva complexitat, que es pot mesurar segons:

• 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)
• Jocs de dades. Podem incorporar un factor addicional si es parametritzaran les dades d’entrada de les proves (amb una graella de dades).

Podem classificar la complexitat dels diferents casos de prova segons:

• 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

Segons la seva complexitat també podem determinar si són o no bons candidats depenent del nombre de vegades que s’executaran a l’any:

• Simple. 15 execucions anuals
• Mitja. Entre 8 i 10 execucions anuals
• Complexa. Més de 5-8 execucions anuals

Estimar el cost d’automatització

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

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

Fora d’aquests marges es poden determinar casos de prova especialment complexos i per sobre de la complexitat alta, cas en el que s’han de justificar.

Conceptes previs

Àmbits d’automatització

En quins casos podem aplicar l’automatització?

1. Per executar tasques repetitives (en proves de regressió o fum, per exemple)
2. Per executar tasques que es realitzen amb diferents jocs de dades
3. Per executar proves entre diferents tipus d’entorns (com per exemple en varis navegadors Web)
4. Per preparar o generar jocs de dades de prova (podem per exemple automatitzar amb una navegació la creació dels usuaris necessaris per una prova posterior, …)
5. Per executar proves de funcionalitats que són reutilitzables o transversals per altres aplicacions

Enfocs d’automatització

Podem establir 3 tipus d’enfocs d’automatització:

• 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.

Es poden combinar tots els mètodes entre sí per generar un script adaptable, mantenible i executable per diferents escenaris.

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, …

Manteniment de l’automatització

Després de creades, les proves poden ser modificades o adaptades per a cada versió. En promig, considerem que per cada nova prova, el 25% de les proves requereixen manteniment i el 75% resten sense canvis.

---