Problemes amb l'automatització de proves i el control de qualitat modern

Quins són alguns problemes habituals amb l'automatització de proves en Agile i DevOps?

El desenvolupament modern de programari i el control de qualitat se centren massa en l'automatització de proves i no en les proves exploratòries.

Estem llançant programari de millor qualitat amb proves més automatitzades? Jo crec que no!


Fa poc em vaig trobar amb una publicació en una xarxa de xarxes socials que deia

El que veig a la majoria d’esdeveniments de proves i de control de qualitat actual és principalment DevOps, integració contínua i automatització de proves.


Tot i que és molt bonic, veig que s’estan automatitzant molts casos de proves de merda.

Veig pocs errors reportats durant les proves d’integració i proves funcionals, tot i que tots estan automatitzats.

A UAT els usuaris troben cada vegada més errors perquè els equips de prova no els identifiquen en fases anteriors.

Si no ensenyem a la gent a escriure bons casos de prova, acabarem amb un procés completament automatitzat ...


I la meva interpretació de ... és 'merda'. :-)

De totes maneres, a veure què es realment succeeix al món de la QA moderna i l'automatització de proves.



Problemes amb la QA moderna

La major part de l ''automatització de proves' dins del desenvolupament àgil es troba en un estat pèssim. La indústria del programari inverteix grans quantitats de diners per contractar 'experts en automatització de proves', sobretot per obtenir la sensació de confiança que el programari que estan construint és d'alta qualitat. Tot i això, es troben errors notables i / o altres problemes durant la UAT o passen als entorns de producció. Què passa, doncs?

Nota:Amb Test Automation, em refereixo sobretot Ceba Automatització de proves.

Les proves automatitzades són ara el centre de qualsevol procés modern de desenvolupament de programari. El seu propòsit és ajuda oferir programari d'alta qualitat de manera repetible, però, de debò?


Els provadors encara fan proves?

La veritat és que en la majoria d’equips àgils, els provadors ja no fan proves.

Les proves manuals han perdut la seva virtut, gràcies a pràctiques de desenvolupament i cultures com l'àgil i DevOps , que han creat una divisió a l’espai QA: aquells que poden codificar i els que no.

Sovint escoltareu coses com ara: 'Sóc un enginyer 100% automatitzat', o 'un 80% automatització 20% manual', o encara pitjor, 'Odio les proves manuals'. Xocant!

A DevOps, se’ns fa creure que tot s’hauria d’automatitzar. No hi ha lloc per a la intervenció manual, p. proves manuals.


Actualment, la majoria dels provadors d’un equip àgil lluiten per mantenir-se al dia amb la demanda de “Test Automation”. Hi ha pressió per automatitzar totes les històries del sprint i no hi ha prou temps per fer proves exploratòries exhaustives.

El problema, especialment en el desenvolupament Agile, és que els control de qualitat prenen una història d’usuari i automatitzen els seus criteris d’acceptació. Mentre ho fan, el seu principal i únic enfocament és lluitar amb les seves habilitats de codificació limitades només per superar la prova.

Naturalment, això crea un focus estret quan només us interessa automatitzar la prova i veure-la passar a la canonada de construcció. Això només demostra que el que hi havia als criteris d’acceptació (correcte o incorrecte) funciona i tendeix a oblidar-se del panorama general.

La disminució de les proves manuals

Cada vegada hi ha més 'provadors tradicionals' que passen a 'proves àgils' prenent algunes lliçons de codificació i esdevenint més tècnics.


No m’equivoqueu; tot això és bo. Crec que, com a provadors, sempre hem d’esforçar-nos per aprendre tecnologies noves i emergents per mantenir-nos enginyosos. Hauríem d’entendre la pila de tecnologia si volem provar un sistema amb un alt grau de qualitat.

Tanmateix, la veritable raó per la qual la majoria dels verificadors manuals prenen aquestes iniciatives és que hi ha una creença comuna que les 'proves automatitzades' són superiors a les proves manuals i vaja, la codificació és divertida, oi?

Nota:Per proves manuals, ho estic NO referint-se a la manera de vella escola de seguir un script i executar els passos. Em refereixo als anomenats 'verificadors exploratoris': aquells que fan les proves reals i tenen curiositat per examinar el comportament del sistema exercint escenaris interessants i reflexius.

Malauradament, sembla que hi ha un gran descens en el mercat dels provadors exploratoris. Això és força evident. Només cal que feu un parell de consultes de cerca per a 'verificador manual' i 'verificador d'automatització' en qualsevol lloc de treball de TI i veureu el resultat per vosaltres mateixos.



Problemes amb l'automatització de proves

Ara, vegem per què la major part de l’esforç d’automatització de les proves no aporta cap valor.

Errors comuns que veig que passen reiteradament:

  • Tenir una expectativa errònia de proves automatitzades
  • Automatitzar les proves en la capa equivocada, en el moment equivocat i amb eines equivocades
  • Automatització de proves inútils
  • Descuidar àrees importants
  • Falten escenaris clau

Expectatives equivocades

Fa un temps vaig escriure una publicació al bloc per què voleu automatitzar una prova? ? Si no l’heu llegit, val la pena llegir-lo.

El resum d’aquest article és que automatitzeu les proves que vulgueu fer regularment. Per definició, aquestes són les proves de regressió que confirmen que el sistema encara funciona.

Tot i això, si els controls automàtics troben molts problemes de regressió, qüestionaria les habilitats dels desenvolupadors i el procés de desenvolupament. Les proves automatitzades de la interfície d’usuari no s’han de mantenir [a costa de] ni [compensar] per una mala codificació.

Capa incorrecta, eines incorrectes i temps incorrecte

La majoria de 'Test Automation Engineers' en equips àgils, analitzen la història de l'usuari i automatitzen els seus criteris d'acceptació. La majoria de les vegades es fa mitjançant una combinació de seleni i cogombre.

Les aplicacions web modernes ara es divideixen clarament entre el backend i el frontend. El dorsal es compon principalment de diversos serveis web o API REST amb punts finals fàcilment accessibles.

La lògica de l’aplicació es pot provar a la capa API. Tot i això, la majoria dels enginyers d’automatització de proves recorren a la validació de la funcionalitat a la capa d’interfície d’usuari, que en el millor dels casos és molesta.

Hi ha eines de proves, com ara Karate i Rest-Assured, que simplifiquen les proves de l'API. Hauríem d’utilitzar aquestes eines durant el desenvolupament. Malauradament, alguns enginyers d’automatització de proves ni tan sols en saben conceptes bàsics d’HTTP , i encara menys poder escriure escenaris de prova de l'API.

Quant a l’automatització de les proves d’interfície d’usuari, Xiprer és una gran eina. És més com una eina TDD per a desenvolupadors front-end. Els desenvolupadors reben comentaris molt ràpids sobre el comportament dels nous components de la IU.

Tant Karate com Cypress serveixen com a 'eines de prova de desenvolupament', és a dir, eines que guien i donen suport al desenvolupament. Tots dos són lleugers, fàcils d’integrar i poden proporcionar confiança en el desenvolupament .

A continuació, podem utilitzar Selenium o Cypress per dissenyar només un grapat d’escenaris que exerceixen el sistema de punta a punta. Aquests escenaris formen el nostre paquet de regressió lleuger i proporcionen confiança en la continuïtat del negoci .

Molt sovint sento coses com ara: 'esperem fins que la funció estigui completament desenvolupada i estable, abans d'automatitzar les proves'. Qualsevol provador conscient sap que els errors de les noves funcions superen els errors de regressió. Hi ha més possibilitats de trobar problemes amb la característica de desenvolupament actual que una característica estable.

Si passareu temps automatitzant proves, feu-les en paral·lel amb el desenvolupament quan puguin aportar més valor.

Automatització de proves inútils

No automatitzeu totes les 'proves' només per això. Introduïu una mica de procés de reflexió al joc. Estudieu els diagrames arquitectònics d’alt i baix nivell. Pregunteu què pot sortir malament. Examineu els punts d’integració i cerqueu possibles punts d’error.

Adopteu un enfocament basat en el risc en automatització, tal com faríeu (amb sort) amb el vostre enfocament de proves generals. Quina probabilitat hi ha de fallar i quin impacte té l’error? Si la resposta és alta, aquests escenaris haurien de ser automatitzats i executats en cada versió.

En cada sprint, sovint acabem escrivint proves automatitzades sobre les històries dels usuaris per a aquest sprint i ens oblidem de la integració amb altres funcions. Hi ha proves d'integració febles o no existeixen.

Recordeu que automatitzar les 'proves' requereix temps. Tingueu també en compte que, automatitzant una prova, no realitzeu proves, només comproveu que la funció en qüestió compleixi alguns criteris d’acceptació.

Vostè no pot automatitzar les proves, però podeu automatitzar la comprovació de fets coneguts.

Per tant, cada vegada que dediqueu a automatitzar una 'prova', penseu en el temps que perdeu sense provar.

Descuidar les àrees importants

Cada cop veig més aquesta negligència des del naixement de la cultura DevOps.

A DevOps, la canonada de lliurament, juntament amb els scripts de desplegament, són la columna vertebral del desenvolupament i lliurament de programari, tot i que gairebé mai es posen a prova.

En els darrers anys, podria dir fàcilment que he vist molts més 'problemes ambientals' que no pas errors funcionals. Problemes d'entorn com ara problemes amb el servidor CI, els scripts de desplegament, els entorns de prova, etc.

Els problemes mediambientals tenen un impacte greu en l’esforç de desenvolupament i proves. Consumeixen molt de temps per a desenvolupadors i DevOps i ralentitzen massivament el procés de desplegament, tot i que no es té en compte la possibilitat de provar i evitar així aquests problemes.

Només els acceptem com a part del lliurament de programari modern.

Invertim molts esforços en automatitzar el comportament funcional i ignorem completament les 'coses' que més importen. Encara pitjor és haver de confiar en les proves de seleni per indicar si els desplegaments funcionen o no.

Falta escenaris clau

Els escenaris són el rei! Al cap i a la fi, són els escenaris els que revelen errors.

Molt sovint, es produeix un problema greu a la producció perquè ningú no pensava en aquest escenari en concret. El nombre de proves automatitzades executades no té importància. Si no es va pensar ni es va provar un escenari, la llei de sod ens indica que hi ha un error.

Malauradament, en els entorns de desenvolupament més àgils, no es dóna prou dedicació a aquesta important activitat del 'Taller d'escenaris'.



Problemes amb el procés

Vegem com els problemes anteriors es manifesten en un escenari de desenvolupament típic:

  • El propietari del producte escriu històries d’usuaris sense cap criteri d’acceptació o mínim.
  • No hi ha prou temps dedicat a les sessions de perfeccionament de la història per discutir diversos escenaris per a una història de l'usuari.
  • Els criteris d’acceptació s’interpreten com a proves d’acceptació - Sí, hi ha una diferència entre tots dos !
  • Els verificadors només automatitzen els criteris d’acceptació a les històries d’usuaris, principalment amb seleni i / o cogombre.
  • Les proves automatitzades quasi sempre són responsabilitat dels 'verificadors d'automatització'.
  • Els desenvolupadors no tenen ni idea del que es recull als paquets de proves o ni tan sols saben com executar les proves automàtiques.
  • Les proves automatitzades s’afegeixen a un “paquet de regressió” cada vegada més en expansió, per tant, cada vegada s’executa més temps.
  • Les proves funcionals automatitzades de la interfície d’usuari s’integren a la canonada de construcció, cosa que és bona, però ...

Un desenvolupador fa un canvi senzill i ha d’esperar 30 minuts perquè les proves automatitzades es posin de color verd abans que la nova funció o correcció d’errors es pugui implementar a la producció. L’espera de 30 minuts només és si les proves passen la primera vegada. Si fallen a causa d'alguns problemes de prova o d'entorn, pot trigar més.

Com que les proves automatitzades s’estan executant i el control de qualitat està investigant fallades aleatòries, el desenvolupador i / o el propietari del producte han verificat la nova implementació i estaran encantats de publicar-les, però no poden fer-ho perquè la versió no és verda.

Al cap d’un temps, la compilació es torna verda o la direcció es frustra amb les proves fallides i decideix alliberar-la de totes maneres. Després, BOOM, després d’uns minuts de producció, hi ha un augment de 500 errors de servidor.

Fracassos d’infraestructura

Les falles semblen mostrar un patró similar

  • Fracàs en els punts d’integració.
  • Error en la comunicació amb aplicacions de tercers.
  • Els serveis web no estan 'activats' i fallen les sol·licituds als punts finals de l'API.
  • Una configuració incorrecta en una de les màquines virtuals o nodes, cosa que provoca problemes intermitents.

Tot i això, no hi ha cap procés per verificar aquests problemes com a part del procés de desenvolupament o lliurament.

El focus dels enginyers d'automatització de proves és automatitzar proves funcionals. No hi ha cap enfocament en el rendiment, la seguretat ni la resistència. I, certament, no hi ha proves de la infraestructura.



Resum

Ha arribat el moment de canviar el nostre focus d’automatització de proves funcionals que tenen poques possibilitats de detectar problemes funcionals a problemes ambientals més greus i comuns que afecten el desenvolupament.

Automatització de proves, si es fa malament o sense cap procés de pensament , és una pèrdua de temps i no aporta cap valor a ningú. Les proves automatitzades de merda poden suposar grans costos de manteniment i impedir el desenvolupament. Al final, l’única solució és binar les proves.

En el desenvolupament de programari modern, la major part dels esforços dels 'Test Automation Engineers' es dediquen a lluitar amb el codi d'automatització i aconseguir que les 'proves' funcionin en lloc de centrar-se en proves adequades i explorar el sistema.

Literalment, no hi ha prou temps per escriure codi d'automatització i realitzar proves exploratòries. Automatitzem història rere història i ens oblidem de les proves d’integració, ens oblidem del panorama general.

Sovint acabem executant tones de proves automàtiques, tot i que les proves exploratòries troben la majoria dels errors. Després, retrospectivament, escrivim una prova automatitzada dels errors que es van trobar mitjançant proves exploratòries, per detectar errors de regressió.

Hauríem de ser selectius sobre què hem d’automatitzar i jutjar la nostra decisió en funció del risc. Què pot sortir malament, quina és la probabilitat que vagi malament i quina incidència tindrà sobre l'usuari o l'empresa si va sortir malament?

Si us dediqueu a 'Test Automation', no utilitzeu Selenium per provar la funcionalitat de les API o components de la interfície d'usuari. En lloc d'això, utilitzeu Selenium per automatitzar només un grapat d'escenaris útils i crítics per al negoci per proporcionar confiança en la continuïtat del negoci abans de cada llançament.

I, finalment, cada vegada que dediqueu a automatitzar una “prova”, penseu en el temps que perdeu sense provar.

Per llegir més: