Menú

Com implementar una automatització de proves eficient al món àgil

how implement efficient test automation agile world

Proveu El Nostre Instrument Per Eliminar Problemes

L’automatització a Agile és molt crítica.

Penseu en les moltes funcions que s’afegeixen i es lliuren a cada Sprint. Hi ha d’haver una manera de garantir que la nova funció afegida no afecti la funcionalitat existent.

A causa de la baixa durada del Sprint, és pràcticament impossible executar tot el vestit cada vegada que s’incrementa el producte al final del Sprint. Tenir un vestit de prova automatitzat tindria un paper més important aquí.

Tanmateix, introduir i madurar a l’automatització definitivament trigaria una mica. Fer una inversió inicial en la planificació i el disseny de l’activitat d’automatització resultaria definitivament fructífer a la llarga.

En aquesta tercera part de la sèrie avançada de proves àgils, intento citar alguns consells que cal tenir en compte segons la meva experiència, ja que aporteu automatització al vostre projecte.

A més, llegiu part 1 i part 2 primer per tenir una millor comprensió del tema.

Què aprendreu:

Què cal automatitzar en Agile?

Sempre que tenim previst introduir l’automatització en els nostres projectes, la majoria de nosaltres votem immediatament perquè el “vestit de proves de fum” o el “vestit de prova de regressió” sigui el millor candidat a l’automatització . Per descomptat, ho són, però quan pensem en la piràmide de proves d’automatització, podem concloure que només parlem de la capa superior de la piràmide.

A part de la capa superior, encara en tenim capa de servei i la capa d’unitat que són més importants.

sql plsql preguntes i respostes de l'entrevista

Llavors, quines proves, a part de les proves de fum i les proves de regressió, poden ser bons candidats a l'automatització?

# 1) Compilacions i desplegaments

En entorns tradicionals, tenim versions predefinides que poden ser setmanals, quinzenals o, de vegades, fins i tot mensuals. Un dels motius és que aquests desplegaments requereixen temps. El problema d’aquest enfocament és que hem d’esperar a les dates predefinides per solucionar els errors o per implementar les noves funcions, de manera que hi ha un retard.

La segona raó va ser: quan els provadors acaben la prova i presenten errors i defectes, els programadors han passat a diferents parts d’implementació i tenen menys interès a resoldre els errors de l’antiga aplicació. Aquest enfocament també retarda el temps perquè la funció estigui disponible a la producció.

La construcció i els desplegaments són les entitats que són repetitives i, de vegades, avorrides. També pot trigar hores a desplegar una compilació, cosa que retarda les proves i, finalment, els comentaris. En ser una tasca repetitiva, els desplegaments es converteixen en un bon candidat per a l'automatització.

Llegiu també=> El procés de gestió de llançaments i desplegaments

Alguns dels avantatges de tenir un desplegament de compilació automatitzat són:

  • No hi ha possibilitat de cometre errors de desplegament (es poden evitar errors humans com copiar el fitxer incorrecte o copiar el fitxer a la ubicació incorrecta)
  • Els errors / funcions estan disponibles per provar-los tan aviat com es solucionin
  • Els provadors tenen més temps per provar
  • La funció està preparada per passar a la producció en menys temps
  • Comentaris ràpids

# 2) Proves unitàries / Proves de components

Ja he parlat de la importància d’automatitzar la capa d’unitat mitjançant el fitxer Enfocament TDD al meu últim tutorial .

Aquesta forma la capa més baixa de la piràmide, per tant, la base i qualsevol fonament han de ser sòlids. L’equip de desenvolupament hauria de col·laborar i treballar junts per adaptar la major part de la prova a aquesta capa.

# 3) Prova d'API / servei web

Els serveis web són el mitjà en què dues aplicacions intercanvien dades o informació en termes de sol·licitud i resposta, sense molestar-se amb l’arquitectura o la tecnologia subjacents. En termes més senzills: fer una sol·licitud i validar la resposta és el que normalment fem a les proves de serveis web.

Prova dels serveis web implica escriure programes per trucar a aquests mètodes de servei web i validar el / s valor / s que retorna. Fins i tot podem provar els serveis de diverses permutacions i combinacions. Teniu totes les dades de prova al full Excel i el vostre programa pot llegir-les i trucar al servei que es pot provar passant les dades de prova com a paràmetre i validant els resultats.

Aquesta prova particular forma part de la capa mitjana de la piràmide. La majoria de les proves funcionals es poden introduir en aquesta capa. Resoldre els defectes que sorgeixen en aquesta capa es fa fàcil de solucionar i no s’ajornen fins que la IU estigui disponible.

ajuda a les preguntes i respostes de l’entrevista

# 4) Proves darrere de la GUI

Automatitzar les proves darrere de la GUI és relativament més senzill que automatitzar la GUI real. Un altre avantatge és que, independentment dels canvis de la IU, la funcionalitat roman intacta. Fins i tot si es modifica algun element de la IU, la funcionalitat de la funció no canvia. Aquesta tècnica se centra principalment en la lògica i les regles del negoci.

Els casos de prova s’escriuen majoritàriament en un format tabular o en un full de càlcul i s’escriuen accessoris / fragments de codi que accepten l’entrada d’aquestes taules i en retornen els resultats. Els resultats es generen immediatament i proporcionen una gran plataforma perquè els grups d'interès no tècnics executin aquestes proves i obtinguin els resultats esperats. Una de les eines que s’utilitzen per aconseguir aquesta tècnica és Aptitud .

# 5) Proves no funcionals

Això tècnica de proves no funcionals bàsicament implica la prova de càrrega, rendiment i estrès. Hi ha diverses eines fàcilment disponibles al mercat que es poden utilitzar per automatitzar aquestes proves.

# 6) Comparacions de dades

Moltes de les nostres proves requereixen que comparem fitxers de dades, inclosos fitxers de text, fitxers CSV o Excel

  • Aquests fitxers es poden comparar amb línies de base per fer la validació de dades
  • Les comparacions poden ser de les mateixes dades, però d’un format diferent. Això passa bàsicament quan tenim dos dels mateixos fitxers generats a partir de dues fonts diferents

Aquestes comparacions poden ser repetitives, per tant automatitzades.

# 7) Cerca

Cercar una entitat específica a partir d’un gran nombre de fitxers també pot ser tediós i Déu ens ajuda si és una tasca repetitiva. Un exemple és la cerca a través de fitxers de registre. Si aquesta és també una tasca tediosa i repetitiva, hauríem de pensar en automatitzar-la.

# 8) Tasques repetitives

Qualsevol tasca que comenci relacionant-se amb els usuaris finals o escrivint històries per desenvolupar-la, si és repetitiva, s’ha de considerar en automatització. Hem d’entendre que fer automatització no vol dir que hi hagi d’haver una eina / tecnologia sofisticada. Pot ser una macro VB simple o un programa Java amb Javascript per resoldre el propòsit.

Per on començar?

No hi ha punts vius ni una guia pas a pas que indiqui per on començar l'automatització. Per iniciar l’automatització de l’equip, cal que feu una pluja d’idees i apliqueu reflexions profundes sobre quins aspectes voleu automatitzar o quin és l’objectiu final de l’automatització?

Podeu començar per:

  • Identificar les tasques repetitives,
  • Identificar les zones de dolor de l'aplicació
  • Identificar els reptes de les proves

Si no teniu cap automatització al projecte o equip turístic, probablement podeu optar per un enfocament de diverses capes on les proves unitàries es puguin orientar primer per automatitzar-les. Això us proporcionaria el ROI més alt.

Simultàniament, els provadors poden començar a treballar amb el vestit de prova de fum i després la regressió. Un cop l’equip hagi adquirit les habilitats i se senti còmode, aneu progressivament cap a l’automatització de les altres tasques repetitives.

No us dediqueu directament a comprar una nova eina sense avaluar les vostres necessitats. Com he dit anteriorment, un programa simple o una macro poden resoldre el vostre propòsit d’automatitzar algunes de les tasques repetitives. Per tant, abans de decidir comprar una eina, do a POC i avaluar si aquesta eina seria eficaç d’utilitzar.

Consulteu aquests documents on he proporcionat més detalls sobre com seleccionar casos de prova correctes per a l'automatització i algunes idees sobre l'estimació dels esforços d'automatització als articles següents. manual per als desafiaments del procés de proves d'automatització i estimació de proves del projecte d'automatització de seleni.

Un cop finalitzat l’abast de l’automatització i de l’eina, el següent és dissenyar el marc.

Recordeu, a Agile, el marc ha evolucionat. NO voleu dissenyar primer tot el marc i després implementeu-lo. Dissenyeu i implementeu el MVP (producte mínim viable) i, a continuació, milloreu el marc existent per incloure més funcions. També heu d’aplicar bones pràctiques de codificació i desenvolupament si voleu que el vostre paquet d’automatització sigui robust.

Algunes pràctiques recomanades

  • No us apunteu a automatitzar el 100% alhora. Comenceu poc. Recordeu que és un procés en evolució
  • Seguiu les mateixes pràctiques Agile que seguiu per a qualsevol desenvolupament de programari. L’automatització també requereix una planificació i un disseny adequats. No voldríeu augmentar els vostres deutes tècnics quan esteu automatitzant
  • Creeu el vostre backlog d'automatització de proves. Aquest retard pot anar des de la implementació d'una nova característica fins a millorar una característica existent. Doneu punts de la història als vostres elements identificats i assigneu-los en conseqüència. Porteu aquests elements pendents al Sprint i feu-ne un seguiment mitjançant un tauler Kanban
  • Escriviu els criteris d’acceptació de les vostres històries d’automatització. Aquests criteris d'acceptació poden incloure:
    • Integració del conjunt de proves amb CI
    • Portar el vestit a una ubicació centralitzada
    • Envieu els resultats per correu electrònic
    • Disposició d'enviament de fitxers de registre d'errors quan la prova falla
    • Qualsevol altre criteri ...
  • No dediqueu massa temps a avaluar una nova eina. Podeu crear una llista de comprovació amb prioritat de tot el que vulgueu de la nova eina i decidir una cronologia per avaluar-la. Si no veieu els vostres resultats en el temps estipulat, aneu al següent
  • Preneu una decisió prudent sobre què voleu automatitzar. No totes les automatitzacions són efectives i generen un ROI positiu. No automatitzeu només per automatitzar
  • Fer ús de l’entorn de desenvolupament adequat. No guardeu el codi al vostre local. Teniu un dipòsit per conservar el vostre codi i hàbiteu de comprovar-lo al final del dia
  • De manera similar, proveu d'executar les proves automàtiques des d'una ubicació centralitzada. Feu que sigui persona independent. Hauria de ser que qualsevol de l’equip pugui activar els scripts des de la seva màquina i els resultats s’obtinguin per correu electrònic

Quins són els principis Agile que es poden aplicar a l'automatització?

Alguns consells molt senzills:

  • Mantingueu les coses senzilles. Feu el que calgui. He vist molts casos en què lliurem implementació recoberta de sucre que fa que l’automatització sigui innecessàriament complicada. Evitem les coses que no són necessàries
  • Fer coses senzilles no vol dir fer les coses més fàcils. Això significa prendre mesures per aconseguir els vostres objectius d'automatització. És possible que utilitzeu una característica senzilla per automatitzar, però pot passar que la implementació de l’automatització resulti complexa
  • Apliqueu l'enfocament de tot l'equip . Crec que tothom és un provador d’un equip àgil. No restringim la feina d'automatització només amb els provadors ni només amb els desenvolupadors. Cadascuna de les disciplines ha d’entrar en la pell de l’altra per aconseguir l’automatització del projecte. Aquest enfocament també seria eficaç per resoldre qualsevol dels problemes tècnics que comporta la implementació
  • El marc s’evoluciona a Agile . No intenteu proporcionar massa funcions que puguin complicar innecessàriament la peça d'automatització
  • Preneu-vos el temps per fer-ho bé. Preneu-vos un temps per dissenyar-lo adequadament per evitar els deutes tècnics
  • Obteniu comentaris freqüents
  • Aplicar normes i pràctiques de codificació adequades. El disseny ha de ser senzill, aplicar els conceptes OOPS i intentar mantenir les proves independents entre si. Penseu en factors com la 'mantenibilitat' del vestit de prova

Veig algun repte en automatitzar a Agile?

L’automatització al món àgil sí que arriba els seus propis reptes :

  • Hem de planificar molt bé. Per decidir el conjunt de proves, l'eina, el marc i l'enfocament adequats, tots necessiten una estratègia adequada. Tot i això, hem de recordar que no s’ha de fer un pla excessiu. Tingueu present el MVP (producte mínim viable)
  • Comprometre's amb la qualitat del codi perquè volem lliurar ràpidament: hem de recordar que els deutes tècnics també es mantenen bé en automatització
  • Els equips de la majoria dels equips no segueixen el 'Full-Team-Approach' i deixen tota la responsabilitat de codificar i mantenir el paquet automatitzat per als verificadors, cosa que se suma a la responsabilitat dels verificadors.
  • Automatitzar les proves funcionals és més difícil que automatitzar la interfície d’usuari

Entre tots aquests reptes, el repte més important és millorar les habilitats dels provadors.

Fer i mantenir l'automatització d'un equip és gairebé com una activitat de programació (desenvolupament) que fan els programadors (desenvolupadors). No només la implementació, sinó també la integració del vestit automatitzat a CI és important i requereix que els avaluadors aprenguin i adoptin noves habilitats i aprenguin noves eines i tecnologies.

Algunes eines de codi obert que s’adapten a Agile

  • Selenium WebDriver - Per a la IU
  • Reixa de seleni - Per a l'execució paral·lela
  • Cogombre: per a BDD
  • JMeter - Per a proves de rendiment
  • SABÓ - Per a serveis web
  • WireMock: proves de serveis web quan el servei web no està disponible.
  • Èpoques: per a mòbils

Deixeu-me concloure amb els famosos quadrants de proves Agile:

Quadrants de prova àgils

Quadrant 1 és la prova d'unitat i components que es pot automatitzar amb l'enfocament TDD.

on veure l'anime de forma gratuïta

Quadrant 2 parla de les proves de funcionalitat, on podem aplicar l'enfocament BDD.

Quadrant 3 és l'únic quadrant que té un abast de proves manuals.

Quadrant 4 bàsicament parla de les proves que es poden aconseguir mitjançant algunes eines. Això s’encarrega de les proves de càrrega, proves d’estrès, proves de volum i proves de seguretat.

Conclusió

Hi ha molt d’abast d’automatització a part de les proves de fum i les proves de regressió. Per tant, hem d’alliberar-nos del concepte de limitar l’automatització només a aquest tipus de proves, la qual cosa al seu torn significa que el conjunt d’habilitats d’un provador d’Agile exigeix ​​més que trobar errors i defectes.

Els provadors han de ser més col·laboratius i afinar les seves habilitats de programació / automatització. Si cada vegada s’automatitzen més proves, donaria als verificadors més temps per dedicar-se a tasques més sofisticades i desafiadores.

Sobre l'autor: Aquest article és de Shilpa, membre de l'equip de STH. Ha estat treballant en el camp de proves de programari durant els darrers deu anys en dominis com ara publicitat a Internet, banca d’inversions i telecomunicacions.

Comparteix els teus comentaris i opinions a continuació.

Lectura recomanada

^