Menú

Quan optar per fer proves d'automatització?

when opt automation testing

Proveu El Nostre Instrument Per Eliminar Problemes

Hauríem de considerar les proves d'automatització d'un projecte? Quan hem d’anar a les proves d’automatització?

Les proves es realitzen per proporcionar productes de bona qualitat a l'usuari final. Fase de proves és un dels principals aspectes de STLC .

Qualsevol empresa se centra més en les proves de programari, ja que la seva qualitat aporta una satisfacció òptima del client, però moltes d’elles encara tenen dificultats per triar quin tipus de proves es realitzaran, ja sigui amb proves automatitzades o manuals.

Quan optar per les proves d

Aquest article ajuda el lector a entendre què és la prova d’automatització, quan cal buscar-lo i, sobretot, quan no cal fer-ho. Apreneu també la utilització òptima de Eines d'automatització per a proves .

Qualsevol que es faci la feina, s’ha de dur a terme amb eficàcia i també ha de ser rendible. A més, hauria de tenir sentit perquè el client se senti satisfet pels lliuraments.

Què aprendreu:

Proves de programari i avantatges de costos

Les proves de programari normalment les realitza un provador de programari. La diferència entre un usuari de prova i un usuari real és que aquest últim només coneixerà un ús parcial del programari que s’utilitza per al seu negoci o per a les seves tasques i no el coneixerà completament. D'altra banda, un provador serà conscient de tots els requisits tècnics i funcionals del programari. Basant-se en els requisits proporcionats pel client, caldrà preparar els plans de prova i els casos de prova.

Un pla de prova no és res més que un pla detallat de la manera com s’ha de dur a terme el procés de prova. Això tindrà detalls complets sobre el nombre de recursos i fonts implicats en les proves, què fer i quan fer-ho, què no es farà, i l’entorn on es durà a terme, etc.

Els casos de prova s’han de preparar després d’una comprensió clara de l’aspecte funcional i tècnic del programari. El comprovador ha de tenir una gran capacitat d’observació i un coneixement complet sobre el programari.

Prova del cicle de vida

A més, el cost té un paper eficaç aquí. Els clients prefereixen acceptar programari amb la màxima qualitat a un cost mínim. Quan anem a fer proves manuals, el procés és més tediós i consumeix més temps, ja que el provador ho fa manualment.

Per exemple , quan necessitem 'n' nombre de verificadors executeu la prova de regressió , pot trigar gairebé 50 hores a executar tots els casos de prova. I en funció de la disponibilitat de recursos, s’executaran els casos de prova. Però amb menys temps per a les proves automatitzades, es realitza una utilització òptima dels recursos juntament amb la màxima cobertura dels casos de prova en comparació amb les proves manuals.

Procés de proves manuals

Intel·ligència darrere de les proves de programari

És molt important que qualsevol organització sàpiga quan ha de començar el procés de proves i quan ha de sortir-ne. Se suposa que hem de saber quan s’inicien les proves perquè no serveix de res començar les proves quan s’acaba la fase de desenvolupament i quan no es compleixen els criteris exigits. Sempre és una bona pràctica començar amb la fase de disseny de proves mentre el desenvolupament està en curs.

Intel·ligència de proves de programari

A continuació es detallen els criteris per a l’entrada i sortida de les proves de programari:

Criteris d’entrada

Un cop signat el document de disseny, cal preparar els plans de prova en la fase de planificació. Un pla de proves té un paper vital. El maquinari necessari s’ha d’instal·lar i configurar correctament i s’ha de comprovar la funcionalitat del maquinari. Els requisits funcionals han de ser clars i aprovats. El codi desenvolupat ha de ser provat per unitats i signat pels desenvolupadors.

Els casos de prova i les dades de prova s’han de preparar i aprovar. Les dades i l'aplicació de les proves haurien d'estar disponibles. El comprovador ha de tenir un coneixement significatiu i suficient sobre l’aplicació. Els recursos han d’estar ben entrenats sobre les eines i s’han d’aclarir amb totes les funcionalitats necessàries.

El provador ha d’estar disponible. Quan no s’assoleix cap dels criteris, es retenen els criteris d’entrada de les proves.

(Nota: Feu clic a qualsevol imatge per obtenir una vista ampliada)

Automatització de criteris d’entrada

Criteris de sortida

Només quan almenys el 95% dels casos de prova obligatoris estiguin bloquejats amb un resultat 'aprovat', podem sortir de la fase de prova del producte. Tot i això, no és tan fàcil determinar quan es pot aturar la prova de programari o si encara s’ha d’executar. I sovint també es presenta aquest tipus de situacions.

Automatització de Criteris de sortida

A continuació es detallen els principals criteris:

  • Quan es solucionin tots els errors.
  • Quan s’acabi el termini.
  • Quan el pressupost s’esgota o s’esgota.
  • Quan es passin tots els casos de prova.
  • Quan es signi l'acord.
  • Quan es fa un percentatge determinat de proves.
  • Quan el Alfa i les proves beta acaben.

Els criteris de sortida es poden derivar exclusivament en funció de factors com el risc, el cost, etc. Quan s’assoleix la prova del requisit funcional principal, la prova s’aturarà normalment i mai no busquen errors menors, cosa que crearà problemes al períodes posteriors.

Automatització de criteris de sortida d’entrada

Exemple: El programari ABC es troba en una fase de disseny. El desenvolupament i la construcció de proves es produeixen generalment al mateix temps. Després de congelar el disseny, comença el desenvolupament del programari. La finalització del desenvolupament del programari, tal com s’ha acordat, indica els criteris d’entrada. Els lliuraments aquí són de l’equip de desenvolupament. Inclou notes de llançament i problemes coneguts.

Després d’unes poques iteracions de proves, quan no hi ha cap tap important / bloquejador / espectacle pendent de resolució i el 95% de les proves han donat lloc a una aprovació, s’anomena criteri de sortida.

Automatització: és realment essencial?

Quan hem de decidir si ho necessitem Tècnica de proves automatitzades o no, aquí es planteja la qüestió dels recursos disponibles. Els motius que hem d’automatitzar consisteixen en comprovar si el flux de dades i la funcionalitat desenvolupada funcionen segons les expectatives sense intervenció manual o no. S'utilitza principalment en llocs on el programari tindrà canvis en forma de múltiples llançaments / cicles, etc.

Enumereu i expliqueu almenys dues coses que podeu aconseguir provant el programari per detectar problemes de seguretat.

Al final del desenvolupament de cada cicle, es farà la prova de la funcionalitat afegida actualment. A més, es faran proves de la funcionalitat antiga per assegurar-se que les funcionalitats antigues no es trenquen. Aquesta és la part principal que té l’abast de l’automatització.

En verificar les lògiques basades en codi i els requisits de la GUI, es pot triar Proves automatitzades, sempre que el factor de risc sigui elevat.

L’automatització és essencial

Exemple: Per al programari ABC, hi ha actualitzacions freqüents, les actualitzacions són cercades pel client i proporcionades pels desenvolupadors. Per tant, com a part de les proves, es fa una regressió per al programari que ja està en funcionament i que està en producció. Independentment de qualsevol nombre de versions, actualitzacions i actualitzacions, la versió actual serà vàlida.

Suposem que es necessiten 10 dies d’esforços manuals per cobrir les proves de regressió i que s’ha de tenir la màxima cura per automatitzar-les. Pot estalviar almenys un 60% d’esforç i un treball manual de 10 * 8 = 80 hores.

L'automatització pot completar-se 80/24 = només 3,33 dies. Això estalvia aproximadament 6,67.

Per què l'automatització?

L'automatització només es pot triar quan:

  • L'aplicació té una àrea molt extensa amb un alt grau d'inversió en regressió.
  • L'optimització dels costos es va produir a causa d'errors manuals.
  • El programari té diverses versions i versions.
  • És rendible a llarg termini.
  • El factor de risc és més elevat per a un abast més ampli d’execució de la prova.
  • Les xifres de costos i els càlculs matemàtics s’inclouen a la funcionalitat del programari.
  • Hi ha un major augment del tempo d’execució, eficiència juntament amb la qualitat del programari.
  • Hi ha un temps d’inversió menor, fins i tot per a proves de programari d’alt risc.

Factor de risc

El factor de risc esdevé predominant a l’empresa on hi ha moltes dependències del factor temps. El programari que funcioni basat en sistemes transaccionals i que funcioni en diverses aplicacions requerirà que el programari actuï de manera ideal segons el disseny del programari. En aquest cas, hi ha molts riscos per registrar el comportament funcional correcte.

Aquí l’automatització serà molt útil per realitzar les transaccions funcionals a un millor ritme segons el mecanisme del programari.

Per exemple , en el cas d'un indicador del mercat de divises, el factor temps és molt important i crític. Els canvis en les existències i els productes bàsics es produeixen respecte al temps, de vegades menys de segons. Aquí l’automatització us pot ajudar a provar aquest tipus de programari amb un alt risc.

Factor de risc en automatització

Exemple: El programari ABC té diverses actualitzacions i actualitzacions. Per tal d’estalviar esforços manuals i reduir el temps d’inversió de la fase de proves, es pot automatitzar la versió base o les antigues funcionalitats. Això només pot ser vàlid quan les funcionalitats bàsiques es mantindran sense canvis.

L’avantatge de l’automatització és que es poden executar sense cap intervenció manual. Fins i tot això es pot realitzar en paral·lel amb la prova de noves funcionalitats. Per tant, l’automatització estalvia molt d’esforç i molt de temps.

Quan no s'ha de preferir l'automatització?

Hi ha una pregunta entre diverses organitzacions: - Per què no és possible un 100% d'automatització?

La resposta dels experts és NO perquè els usuaris qualificats han de realitzar proves automatitzades i també han d’estar ben entrenats. L’automatització no es pot dur a terme durant la fase inicial dels criteris i els requisits de les aplicacions no estaran clars.

Normalment, es prefereix Automatització a partir de la segona iteració de qualsevol versió de programari. Es pot canviar la interfície d’usuari, que és més costosa, i el manteniment dels scripts també és més costós. Quan el cost requerit per a l’eina d’automatització supera el pressupost del projecte, podem dir que no.

Exemple: El programari XYZ és un tipus de lloc de comerç electrònic on els requisits del client no es congelen i continuen canviant quan els clients ho requereixen.

Aquí, en aquest cas, l'automatització no pot ajudar a la regressió. Això es deu al fet que les antigues funcionalitats que no són vàlides no s'han de provar i, per tant, s'han de fer manualment. Per exemple, un client ha de tenir tots els quadres de llista del programari base per canviar-los com a quadres desplegables.

Cost vs ROI d'automatització

El ROI és molt baix quan es vol automatitzar inicialment perquè l’automatització és cara per primera vegada. El ROI continua augmentant a mesura que l’esforç manual en provar el programari es redueix de les iteracions de la segona versió. Hem de ser conscients del resultat esperat de qualsevol cas de prova abans de Automation.

Penseu en el disseny dels casos de prova més importants a l’hora de triar l’automatització i qualsevol eina per assegurar-vos que no augmentarà el cost.

Manual de comparació de costos versus automatització

On es pot fer que l’automatització redueixi el cost mínim a cap cost?

Fins i tot els costos d’automatització ja que s’ha de comprar l’eina necessària per a les proves. Els recursos s’han de formar amb l’eina concreta. L'eina escollida ha de ser factible per provar totes les àrees del programari.

Per tant, la selecció d'eines ha de ser feta amb cura pels experts en proves d'automatització.

Exemple: Penseu en el producte XYZ que tracta de les assegurances. Per reduir el factor de cost, l’empresa només va utilitzar proves manuals, però quan es tracta d’assegurances, el factor de risc és elevat i pot costar diners a l’empresa quan qualsevol dels càlculs de la prima s’equivoca. La pèrdua total serà per a la direcció. o a l'usuari final. L'usuari final no suportarà cap pèrdua, mentre que l'empresa ho haurà de fer.

Quan la quantitat calculada de la prima no coincideix amb la prima original (és a dir) quan hi ha una diferència en el càlcul de la prima frontal i posterior, apareix un gran problema entre el client i el venedor del producte. Pot contenir molts mòduls com ara automòbils, casa i altres.

Quan alguna cosa surt malament, és una pèrdua total. La diferència en el càlcul pot tenir sentit per al provador i pot provocar errors. En aquest projecte, el proves manuals es pot fer per a la interfície d’usuari bàsica, com ara verificar el número TIN, identificador social i altra informació relacionada amb la cartera d’usuaris i, per tant, es pot provar manualment quan el factor de risc és baix. El m com més guanyaria l’empresa, més prefereixen l’automatització per provar el seu programari.

Conclusió

Tant l'automatització com les proves manuals també tenen avantatges i desavantatges. Només quan tinguem clars els conceptes i els requisits, podrem triar quin tipus de proves realitzarem.

Cap projecte no es pot provar només amb proves manuals o automàtiques. Depèn del disseny, la plataforma i la tecnologia amb què s’ha desenvolupat el programari. Per tant, a l’hora de prendre una decisió s’ha d’anar amb compte a l’hora d’escollir el mètode de prova i recórrer als consells d’experts.

A l’article anterior, és possible que ens haguem perdut alguns factors; compartiu els factors que creieu que són importants a l’hora de triar l’automatització o fins i tot les eines d’automatització.

Mentrestant, no dubteu a compartir els vostres comentaris / suggeriments sobre aquest article.

Lectura recomanada

^