Menu

Come implementare un'automazione di test efficiente nel mondo Agile

how implement efficient test automation agile world

Prova Il Nostro Strumento Per Eliminare I Problemi

L'automazione in Agile è molto critica.

Pensa alle molte funzionalità che vengono aggiunte e fornite in ogni Sprint. Deve esserci un modo per assicurarsi che la nuova funzionalità aggiunta non influisca sulla funzionalità esistente.

A causa della bassa durata dello Sprint, è praticamente impossibile eseguire l'intera tuta ogni volta che il prodotto viene incrementato alla fine dello Sprint. Avere una tuta di prova automatizzata avrebbe sicuramente un ruolo più importante qui.

Tuttavia, introdurre e maturare nell'automazione richiederebbe sicuramente del tempo. Fare un investimento iniziale nella pianificazione e progettazione dell'attività di automazione sarebbe sicuramente ripagato a lungo termine.

In questa terza parte della serie avanzata di test Agile, sto cercando di citare alcuni suggerimenti da considerare in base alla mia esperienza, mentre porti l'automazione al tuo progetto.

Inoltre, leggi parte 1 e parte 2 primo per avere una migliore comprensione dell'argomento.

Cosa imparerai:

Cosa automatizzare in Agile?

Ogni volta che abbiamo in programma di introdurre l'automazione nei nostri progetti, la maggior parte di noi vota immediatamente per la 'tuta per i test di fumo' o la 'tuta per il test di regressione' come la migliore candidato per l'automazione . Certo che lo sono, ma quando pensiamo alla piramide dei test di automazione, possiamo concludere che è solo lo strato superiore della piramide di cui stiamo parlando.

A parte il livello sopra, abbiamo ancora il file livello di servizio e il strato unitario che sono più importanti.

come aprire i file bin in Android

Quindi quali test, oltre ai test di fumo e ai test di regressione, possono essere buoni candidati per l'automazione?

# 1) Build e implementazioni

Negli ambienti tradizionali, abbiamo build predefinite che possono essere settimanali, quindicinali o talvolta anche mensili. Uno dei motivi è che queste distribuzioni richiedono tempo. Il problema con questo approccio è che dobbiamo aspettare le date predefinite per correggere i bug o per ottenere le nuove funzionalità implementate, quindi c'è un ritardo.

La seconda ragione era: quando i tester terminano il test e escogitano bug e difetti, i programmatori sono passati a diversi pezzi di implementazione e hanno meno interesse a risolvere i bug della vecchia applicazione. Questo approccio ritarda anche il tempo necessario per rendere la funzionalità disponibile in produzione.

La costruzione e le distribuzioni sono entità ripetitive e talvolta noiose. Possono essere necessarie anche ore per distribuire una build, il che ritarda il test e, infine, il feedback. Essendo un'attività ripetitiva, le distribuzioni diventano un buon candidato per l'automazione.

Leggi anche=> Il processo di gestione del rilascio e della distribuzione

Alcuni dei vantaggi di avere una distribuzione di build automatizzata sono:

  • Nessuna possibilità di commettere errori di distribuzione (è possibile evitare errori umani come la copia del file errato o la copia del file nella posizione errata)
  • È possibile testare bug / funzionalità non appena vengono risolti
  • I tester hanno più tempo per testare
  • La funzionalità è pronta per essere spostata in produzione in meno tempo
  • Feedback rapido

# 2) Test unitari / Test dei componenti

Ho già parlato dell'importanza di automatizzare lo strato unitario utilizzando il Approccio TDD nel mio ultimo tutorial .

Questo forma lo strato più basso della piramide, quindi le fondamenta e qualsiasi fondazione devono essere solide come una roccia. Il team di sviluppo dovrebbe collaborare e lavorare insieme per accogliere la maggior parte del test in questo livello.

blocco pop-up gratuito per google chrome

# 3) Test API / Web Service

I servizi web sono il mezzo in cui due applicazioni scambiano i dati o le informazioni in termini di richiesta e risposta, senza preoccuparsi dell'architettura o della tecnologia sottostante. In termini più semplici: dare una richiesta e convalidare la risposta è ciò che normalmente facciamo nei test dei servizi web.

Testare i servizi web implica la scrittura di programmi per chiamare quei metodi del servizio web e convalidare il valore / i che restituisce. Possiamo anche testare i servizi per varie permutazioni e combinazioni. Avere tutti i dati del test nel foglio Excel e il programma può leggere i dati e chiamare il servizio testabile passando i dati del test come parametro e convalidare i risultati.

Questo particolare test fa parte dello strato intermedio della piramide. La maggior parte dei test funzionali può essere inserita in questo livello. La risoluzione dei difetti che si verificano in questo livello diventa facile da correggere e non vengono posticipati finché l'interfaccia utente non è disponibile.

# 4) Test dietro la GUI

Automatizzare i test dietro la GUI è relativamente più facile che automatizzare la GUI effettiva. Un altro vantaggio è che, indipendentemente dalle modifiche dell'interfaccia utente, la funzionalità rimane intatta. Anche se alcuni degli elementi dell'interfaccia utente vengono modificati, la funzionalità della funzione non cambia. Questa tecnica si concentra principalmente sulla logica e le regole aziendali.

I casi di test sono per lo più scritti in un formato tabulare o in un foglio di calcolo e vengono scritti fixtures / snippet di codice che accettano l'input da queste tabelle e restituiscono i risultati. I risultati vengono generati immediatamente e forniscono un'ottima piattaforma per gli stakeholder non tecnici per eseguire questi test e ottenere i risultati attesi. Uno degli strumenti utilizzati per ottenere questa tecnica è Fitness .

# 5) Test non funzionali

Questo tecnica di test non funzionale fondamentalmente coinvolge i test di carico, prestazioni e stress. Esistono vari strumenti prontamente disponibili sul mercato che possono essere utilizzati per automatizzare questi test.

# 6) Confronto dei dati

Molti dei nostri test ci richiedono di confrontare file di dati, inclusi file di testo, file CSV o excel

  • Questi file possono essere confrontati con le linee di base per la convalida dei dati
  • I confronti possono essere degli stessi dati ma di un formato diverso. Fondamentalmente questo accade quando abbiamo due degli stessi file generati da due fonti diverse

Questi confronti possono essere ripetitivi, quindi automatizzati.

# 7) Ricerca

Anche la ricerca di un'entità specifica da una grande quantità di file può essere noiosa e Dio ci aiuta se questo è un compito ripetitivo. Un esempio è la ricerca nei file di registro. Se anche questo è un compito noioso e ripetitivo, dovremmo pensare di automatizzarlo.

# 8) Attività ripetitive

Qualsiasi attività che inizi con l'interazione con gli utenti finali o la scrittura di storie per svilupparla, se è ripetitiva, dovrebbe essere considerata nell'automazione. Dobbiamo capire che fare automazione non significa che ci deve essere uno strumento / tecnologia sofisticata coinvolti in essa. Può essere una semplice macro VB o un programma Java con un Javascript per risolvere lo scopo.

Dove iniziare?

Non ci sono elenchi puntati o una guida passo passo che indichi da dove iniziare l'automazione. Per dare il via all'automazione per il team, devi fare un brainstorming e applicare pensieri profondi su quali aspetti stai cercando di automatizzare o qual è l'obiettivo finale dell'automazione?

Puoi iniziare da:

  • Identificare i compiti ripetitivi,
  • Identificazione delle aree dolorose dell'applicazione
  • Identificare le sfide del test

Se non si dispone di automazione nel progetto / team del tour, è probabile che si possa optare per un approccio a più livelli in cui gli unit test possono essere prima mirati ad automatizzare. Questo ti darebbe il ROI più alto.

Allo stesso tempo, i tester possono iniziare a lavorare sulla tuta da fumo e quindi sulla regressione. Una volta che il team ha acquisito le capacità e si sente a proprio agio, passa gradualmente all'automazione delle altre attività ripetitive.

Non saltare direttamente all'acquisto di un nuovo strumento senza valutare le tue esigenze. Come ho detto prima, un semplice programma o una macro può risolvere il tuo scopo di automatizzare alcune delle attività ripetitive. Quindi, prima di decidere di acquistare uno strumento, fare il POC e valutare se tale strumento sarebbe efficace da utilizzare.

Consulta questi documenti in cui ho fornito maggiori dettagli su come selezionare casi di test corretti per l'automazione e alcuni approfondimenti sulla stima degli sforzi di automazione nei seguenti articoli manuale alle sfide del processo di test di automazione e stima del test del progetto di automazione del selenio.

Una volta finalizzato lo scopo dell'automazione e dello strumento, si passa alla progettazione del framework.

Ricorda, in Agile, il framework si è evoluto. NON indirizzare prima la progettazione dell'intero framework e poi l'implementazione. Progettare e implementare per l'MVP (Minimum Viable Product) e quindi migliorare il framework esistente per includere più funzionalità. È inoltre necessario applicare una buona pratica di codifica e sviluppo se si desidera che la propria suite di automazione sia solida.

Alcune best practice

  • Non mirare ad automatizzare al 100% in una volta sola. Inizia in piccolo. Ricorda che è un processo in evoluzione
  • Segui le stesse pratiche Agile che segui per qualsiasi sviluppo software. L'automazione richiede anche un'adeguata pianificazione e progettazione. Non vorresti aumentare i tuoi debiti tecnici quando stai automatizzando
  • Crea il tuo backlog dell'automazione dei test. Questo backlog può variare dall'implementazione di una nuova funzionalità al miglioramento di una funzionalità esistente. Assegna punti della storia agli elementi identificati e assegnali di conseguenza. Porta questi elementi del backlog nel tuo Sprint e monitorali utilizzando una lavagna Kanban
  • Scrivi i criteri di accettazione per le tue storie di automazione. Questi criteri di accettazione possono includere:
    • Integrazione della suite di test con CI
    • Trasferimento della tuta in una posizione centralizzata
    • Invia i risultati tramite e-mail
    • Fornitura di invio dei file di registro degli errori quando il test fallisce
    • Qualsiasi altro criterio….
  • Non perdere tempo a valutare un nuovo strumento. Puoi creare un elenco di controllo prioritario di ciò che desideri dal nuovo strumento e decidere una sequenza temporale per valutarlo. Se non visualizzi i risultati entro il tempo stabilito, passa a quello successivo
  • Prendi una decisione oculata su cosa automatizzare. Non tutti i componenti dell'automazione sono efficaci e producono un ROI positivo. Non automatizzare solo per motivi di automazione
  • Utilizzare l'ambiente di sviluppo appropriato. Non conservare il codice nel tuo locale. Avere un repository per conservare il codice e prendere l'abitudine di controllare il codice alla fine della giornata
  • In modo simile, prova a eseguire i tuoi test automatizzati da una posizione centralizzata. Rendilo indipendente dalla persona. Dovrebbe essere che chiunque dal team possa attivare gli script dalla propria macchina e ottenere i risultati via e-mail

Quali sono i principi Agile che possono essere applicati all'automazione?

Alcuni suggerimenti molto semplici:

  • Mantieni le cose semplici. Fai ciò che è necessario. Ho visto molti casi in cui forniamo un'implementazione rivestita di zucchero che rende l'automazione inutilmente complicata. Evitiamo le cose che non sono necessarie
  • Fare cose semplici non significa fare le cose più facili. Ciò significa fare piccoli passi per raggiungere i tuoi obiettivi di automazione. Puoi utilizzare una semplice funzionalità per automatizzare, ma può accadere che l'implementazione dell'automazione risulti complessa
  • Applica l'approccio dell'intero team . Credo che tutti siano tester in un team agile. Non limitiamo il lavoro di automazione solo con i tester o solo con gli sviluppatori. Ciascuna delle discipline deve mettersi nei panni l'una dell'altra per ottenere l'automazione del progetto. Questo approccio sarebbe inoltre efficace per risolvere qualsiasi problema tecnico derivante dall'implementazione
  • Il framework si è evoluto in Agile . Non cercare di fornire troppe funzionalità che potrebbero rendere inutilmente complessa la parte di automazione
  • Prenditi il ​​tempo per farlo bene. Prenditi del tempo per progettarlo correttamente per evitare i debiti tecnici
  • Ricevi feedback frequenti
  • Applicare standard e pratiche di codifica adeguati. Il design dovrebbe essere semplice, applicare i concetti OOPS e cercare di mantenere i test indipendenti l'uno dall'altro. Considera fattori come la 'manutenibilità' della tuta di prova

Vedo difficoltà durante l'automazione in Agile?

L'automazione nel mondo Agile viene fornita con le proprie sfide :

  • Dobbiamo pianificare molto bene. Per decidere la suite di test, lo strumento, il framework e l'approccio appropriati, è necessaria una strategia adeguata. Tuttavia, dovremmo ricordarci di NON pianificare troppo. Tieni a mente l'MVP (Minimal Viable Product)
  • Compromettere la qualità del codice perché vogliamo consegnare velocemente: dobbiamo ricordare che i debiti tecnici reggono bene anche nell'automazione
  • I team la maggior parte delle volte i team non seguono l'approccio 'Whole-Team-Approach' e lasciano l'intera responsabilità della codifica e del mantenimento della suite automatizzata per i tester che si aggiunge alla responsabilità dei tester
  • L'automazione dei test funzionali è più difficile dell'automazione dell'interfaccia utente

Tra tutte queste sfide, la sfida più critica è aggiornare le abilità dei tester.

Fare e mantenere l'automazione per un team è quasi come un'attività di programmazione (sviluppo) svolta dai programmatori (sviluppatori). Non solo l'implementazione, ma anche l'integrazione della tuta automatizzata in CI è importante e richiede che i tester apprendano e adottino nuove competenze e apprendano nuovi strumenti e tecnologie.

Alcuni strumenti open source che si adattano ad Agile

  • Selenium WebDriver - Per l'interfaccia utente
  • Griglia di selenio - Per l'esecuzione parallela
  • Cetriolo - Per BDD
  • JMeter - Per test delle prestazioni
  • SAPONE - Per i servizi web
  • WireMock: test del servizio Web quando il servizio Web non è disponibile.
  • Epochs - for Mobile

Vorrei concludere con i famosi quadranti di test Agile:

Quadranti di test agili

Quadrante 1 è il test dell'Unità e dei componenti che può essere automatizzato con l'approccio TDD.

Quadrante 2 parla del test di funzionalità, dove possiamo applicare l'approccio BDD.

Quadrante 3 è l'unico quadrante che ha un ambito di verifica manuale.

Quadrante 4 fondamentalmente parla dei test che possono essere ottenuti da alcuni strumenti. Questo si occupa dei test di carico, stress test, test di volume e test di sicurezza.

qual è la subnet mask appropriata per una rete tra due host

Conclusione

C'è molto spazio per l'automazione a parte i test di fumo e i test di regressione. Pertanto, dobbiamo liberarci dal concetto di limitare l'automazione solo a questi tipi di test, il che a sua volta significa che il set di abilità di un tester in Agile richiede più della semplice ricerca di bug e difetti.

I tester devono essere più collaborativi e affinare le proprie capacità di programmazione / automazione. Se sempre più test fossero automatizzati, darebbe ai tester più tempo per impegnarsi in attività più sofisticate e impegnative.

Circa l'autore: Questo articolo è del membro del team STH Shilpa. Negli ultimi 10 anni lavora nel campo del test del software in domini come la pubblicità su Internet, gli investimenti bancari e le telecomunicazioni.

Per favore condividi i tuoi commenti e pensieri qui sotto.

Lettura consigliata

^