Avantatges i desavantatges de l'automatització de proves

L’automatització de proves, quan es fa correctament, pot tenir molts avantatges i ser molt beneficiós per al projecte i l’organització. Tanmateix, hi ha algunes trampes o desavantatges de l'automatització de proves que hem de tenir en compte.



Avantatges de l'automatització de proves

Quins avantatges té l'automatització de proves?

Confirmació del conegut

Els controls automàtics són una manera excel·lent de confirmar que l’aplicació encara funciona correctament després dels canvis que s’hi han fet.


És possible que quan s’afegeix una nova característica a una aplicació o es corregeixi un error, afecti la funcionalitat del programari de treball, és a dir, s’introdueixi un error de regressió.

Executant un conjunt de comprovacions de regressió automàtiques quan s’actualitza l’aplicació, podem identificar qualsevol error nou introduït com a resultat dels canvis.


La informació clau aquí és executar comprovacions automatitzades tan sovint com s’actualitzi l’aplicació.

No cal executar el conjunt complet de comprovacions automàtiques. Un paquet de regressió ràpida de fum hauria de ser suficient per detectar qualsevol problema important.

Comentaris ràpids

Un altre gran avantatge dels controls automàtics és la ràpida retroalimentació que rebem quan s’actualitza l’aplicació. L’ideal seria que l’equip de desenvolupament solucioni qualsevol fallada tan aviat com aparegui, abans de passar a altres tasques.

Tingueu en compte que aquest feedback ràpid només es pot aconseguir amb proves unitàries i proves API. Si provem la funcionalitat des de la IU o a nivell de sistema, les proves poden trigar molt a completar-se.


Ràpida execució de xecs

Les comprovacions automàtiques poden trigar una estona a escriure. Tanmateix, quan els executem, generalment són ràpids i poden fer diversos passos molt més ràpidament que els humans. Per tant, ajuden a proporcionar una retroalimentació ràpida a l’equip de desenvolupament.

Això és especialment cert en el cas d’escenaris basats en dades.

Allibera el temps dels provadors

El millor ús dels controls automàtics són les proves de regressió.

Automatitzar les proves de regressió ens allibera el temps dels verificadors, de manera que poden centrar-se més en les proves exploratòries de noves funcions.


De la mateixa manera, quan s’implementen correctament, les verificacions automatitzades es poden executar automàticament amb una supervisió o intervenció manual mínima o nul·la.

L’equip de desenvolupament pot contribuir

Els xecs automatitzats solen escriure’s en el mateix idioma que l’aplicació que es prova. Per aquest motiu, la responsabilitat d'escriure, mantenir i executar les proves es converteix en una responsabilitat compartida.

Tothom de l’equip de desenvolupament pot contribuir, no només els provadors.



Inconvenients de l'automatització de proves

Quins són els desavantatges de l'automatització de proves?


Fals sentit de la qualitat

Compte amb la superació de proves. Això és específicament important per verificar la funcionalitat a nivell d’interfície o sistema.

Una comprovació automàtica només comprova allò que s’ha programat per comprovar.

Totes les comprovacions automàtiques d'un conjunt de proves poden passar satisfactòriament, però hi pot haver defectes importants que no es detectin. La raó d'això és perquè la comprovació automàtica no es va codificar per 'buscar' aquests errors.

Solució: assegureu-vos de dissenyar bons escenaris de prova abans d’automatitzar-los. Un control automàtic només és tan bo com el disseny de la prova. Complementeu també les comprovacions automatitzades amb proves manuals / exploratòries.


No és fiable

Les comprovacions automatitzades poden fallar a causa de molts factors. Si les comprovacions automatitzades continuen fallant a causa de problemes que no siguin errors reals, poden provocar alarmes falses.

Per exemple, les comprovacions automàtiques es poden interrompre a causa d'un canvi de la interfície d'usuari, d'un servei inactiu o de problemes amb la xarxa.

Aquests problemes no provenen directament de l'aplicació sotmesa a prova, però poden afectar el resultat de les comprovacions automàtiques.

Solució: Quan sigui possible / aplicable, utilitzeu talons. Els esbossos superen problemes relacionats amb la connectivitat o canvis en els sistemes de tercers. Per tant, les comprovacions automatitzades serien independents de qualsevol fallada posterior.

Test Automation no és una prova

Malauradament, molta gent confon 'Test Automation' amb Testing.

Un cop tinguin les eines per automatitzar les proves, volen 'automatitzar totes les proves'. Volen desfer-se de tots els 'verificadors manuals'.

La veritat és que les proves són un exercici d’exploració. Les proves requereixen coneixement del domini, una ment enfocada i voluntat d’aprendre l’aplicació.

La prova no és només executar un conjunt de passos de prova predefinits i comparar els resultats reals amb els resultats esperats. Aquesta és la feina dels controls automàtics.

Per provar adequadament una aplicació, sempre es requereix una intel·ligència humana.

Solució: Comprengueu que per a l’èxit d’un lliurament d’un projecte necessiteu proves automàtiques i manuals.

Un no és un substitut de l’altre; complementar els controls automàtics amb proves manuals / exploratòries.

Temps i esforç de manteniment

Heu d’acceptar el fet que les proves automatitzades requereixen manteniment. A mesura que l’aplicació sotmesa a prova evoluciona, també ho haurien de fer les comprovacions automatitzades.

Els controls automàtics són de curta durada. Si els paquets de regressió no es mantenen actualitzats, començareu a veure tot tipus de fallades.

Potser alguns controls ja no són rellevants. O potser les comprovacions no són una representació real de les noves implementacions.

Aquests fracassos podrien contaminar els resultats de les proves.

Emprendre l’automatització de proves no és un esforç puntual. Per treure el màxim profit dels controls automàtics, s’han de mantenir actualitzats i pertinents. Això requereix molt de temps, esforç i recursos.

Solució: Com que el factor de manteniment és una activitat contínua, invertiu temps en dissenyar un bon marc. Utilitzeu mòduls reutilitzables, separeu les proves del marc i utilitzeu bons principis de disseny per alleujar l’esforç de manteniment.

Feedback lent

Quan una funcionalitat està a punt per provar-se, la majoria de les vegades és més ràpid fer una comprovació manual.

El problema és que les comprovacions automatitzades poden trigar molt a escriure en funció de la complexitat de la prova. Per tant, fer una comprovació manual proporciona comentaris més ràpids que la creació de scripts, l'execució i la comprovació dels resultats.

A més, en termes de proves d’interfície d’usuari i de sistema, les comprovacions automatitzades poden trigar molt a completar-se i informar-se. Per tant, si hi ha un error genuí, és possible que no en siguem conscients fins que no acabin totes les proves.

Solució: Proveu d’automatitzar les proves junt amb el desenvolupament, de manera que, un cop finalitzat el desenvolupament, pugueu executar-les amb la nova funcionalitat.

A més, separeu els xecs automatitzats en diferents paquets.

Un paquet de regressió de fum hauria de ser súper ràpid. Les proves només han de comprovar que es pugui iniciar i accedir a l'aplicació.

A continuació, podeu tenir un paquet de regressió funcional que comproveu les funcionalitats principals.

Un altre paquet de regressió pot incloure totes les proves de punta a punta i proves en profunditat. Aquests controls es poden executar durant la nit.

Un exemple d’execució nocturna són els controls automàtics de diversos navegadors. Normalment, triguen molt a executar-se en tots els navegadors.

No s'han trobat molts errors

La majoria dels errors semblen trobar-se per 'accident' o quan es realitzen proves exploratòries.

Probablement, perquè en cada sessió de proves exploratòries podríem provar l'aplicació de diferents maneres.

Per contra, les comprovacions de regressió automatitzades segueixen sempre un camí determinat. De vegades amb el mateix conjunt de dades de prova. Això redueix la possibilitat de trobar nous defectes a l'aplicació.

També el nombre d'errors de regressió sembla ser menor que els errors de noves funcions.

Solució: Intenteu generar aleatorietat en l'escenari i les dades. Provar diferents camins amb dades diferents cada vegada pot revelar possibles problemes.



Conclusió

En aquest post, hem analitzat alguns dels avantatges i desavantatges de les proves automatitzades. Quan participem en automatitzar proves, hauríem de tenir en compte els punts anteriors per obtenir el màxim benefici.