Come si integrano i test di sistema in un processo agile?[Chiuso]

Question

Le descrizioni classiche dello sviluppo agile hanno codice rilasciabile alla fine di un'iterazione.Se sono necessari ulteriori test e convalide per creare un prodotto rilasciabile, come integrarli nel processo?

Answer 1

Cosa ti impedisce di realizzare il tuo processo?Se trovi qualcosa può essere migliore...fallo e basta.Se funziona, persevera..altrimenti prova qualcos'altro.Non esiste un processo scolpito nella pietra se desideri l’agilità.
Il termine che viene usato più frequentemente è "spedibile' codice alla fine di ogni iterazione.Ciò significa che puoi darlo all'utente finale (come un mucchio di DLL per copiare una condivisione o consegnare personalmente un CD/DVD) e lui otterrà valore dall'utilizzo.Tale codice ha superato tutti i test unitari (sviluppatori) e i test di accettazione (clienti/QA/analisti) che erano considerati necessari per "fare!" I test di accettazione sono simulazioni di scenari dei clienti end-to-end.

Non sono sicuro di cosa intendi con "ulteriori test e convalida".Mi vengono in mente altre attività "pre-rilascio".

• alcune attività come "Convegni di formazione" e relativa creazione di contenuti.
• Demo o distribuzione su siti beta per un mese prima del rilascio se le distribuzioni dei clienti sono rare o impossibile da eseguire frequentemente.
• Potenziali clienti/esperti/servizi danno una sbirciatina pratica al nuovo prodotto di cui hanno sentito parlare.

Lo impili semplicemente alla fine del punto finale dell'ultima iterazione (se sei particolarmente pessimista come me...prendi le medie storiche..se rilasci presto.Sì!) Quindi, se l'azienda ha deciso che l'iterazione n. 14 delimita un buon insieme di funzionalità che possono essere un rilascio..È solo "Aggiungi n settimane" dopo la fine dell'iterazione n. 14..nessun calcolo complesso o incertezza a quel punto.Il punto chiave è questo se hai coinvolto regolarmente le parti interessate/clienti, incorporando feedback e mantenendo un livello di qualità accettabile, non dovrebbero esserci sorprese dell'ultimo minuto.

Se necessario, puoi anche farlo fai una partenza lanciata..cioè.il team di formazione inizia a lavorare non appena il team di sviluppo entra nell'Iterazione#13.Ciò dà loro un mese presupponendo un'iterazione di 2 settimane..e spero che non avrai un sacco di funzionalità inserite nell'ultima iterazione..Quindi, al massimo 2 settimane dopo l'Iterazione n. 14 e soggetti a tutti gli allineamenti celesti/organizzativi, dovresti avere un rilascio e una meritata pausa.

Answer 2

Per prima cosa riconosci l'ampiezza/ampiezza del test di cui parli aumenta man mano che il progetto procede e il software acquisisce portata e/o complessità.Per questo motivo, provare a inserire questo sforzo in un'iterazione non funziona dopo una o due iterazioni.La regola del benessere per le iterazioni è un livello di lavoro costante in ciascuna, come determinato dalla velocità del progetto.

Le soluzioni a questo quindi possono prendere una delle due strade:con o senza automazione.L'automazione ai livelli di test più elevati ridurrebbe lo sforzo di eseguire i test, adattando nuovamente il lavoro all'interno dell'iterazione poiché ciascuna iterazione si concentrerebbe solo sugli aumenti incrementali di ambito/complessità.Ciò non è sempre realizzabile in tutti i contesti progettuali, anche se è ciò che desideriamo.Sopravvalutare l'automazione dei test di alto livello è una trappola che dovresti prendere sul serio, in altre parole, evitare di sottovalutare ciò che un tester esplorativo con ragionevole esperienza porta sul tavolo.

Senza automazione, il problema si sposta su quello basato sulla gestione dei test.Le iterazioni di test parallele e spostate nel tempo rappresentano una soluzione candidata.Ad esempio, potresti scegliere di stabilire un backlog di test per le attività di test del sistema gestito con la stessa cadenza delle iterazioni di sviluppo ma ritardato o spostato nel tempo fino alla durata di un'intera iterazione.Ciò consente ai tester di lavorare in modo olistico sulle nuove versioni nella propria sandbox e in base alle proprie priorità.

Sosterrei che i backlog di iterazione dei test siano creati in collaborazione con gli sviluppatori, così come vorrei che i backlog di iterazioni degli sviluppatori fossero creati in collaborazione con i tester.Vorrei anche sostenere un team di test con esperienza nell'automazione in modo che possano automatizzare la noia e lavorare in modo più esplorativo.Il loro portafoglio di test automatizzati dovrebbe aumentare ad ogni iterazione.Dovrebbero anche avere accesso agli unit test degli sviluppatori ed essere in grado di eseguirli sulle versioni nella sandbox di test.

Lavorare fuori fase in questo modo non elimina il crescente problema dell'ambito/complessità dei test, ma fornisce un meccanismo per gestire tale complessità poiché il team sta creando elementi di backlog, modificando le priorità, automatizzandone alcuni, creando liste di controllo, ecc.in base a ciò che pensano collettivamente che dovrebbero fare dopo.È probabile che colpiranno gli oggetti più grandi.

Sembra che valga la pena lottare per preservare la capacità dei tester di lavorare in modo olistico, di evolvere la loro comprensione e di condividere la loro conoscenza sul sistema attraverso test automatizzati.

Answer 3

I test automatizzati dopo ogni build automatizzata ti aiutano almeno in parte.

Answer 4

Aggiungi test di sistema al tuo sprint backlog (in Scrum) o equivalente.

Idem la documentazione per l'utente.

Answer 5

L'esecuzione dei test di sistema è solitamente troppo lenta per integrarsi strettamente nello sviluppo agile.(Ci sono eccezioni a questo, ad es.un test del browser ben progettato non può essere eseguito molto più lentamente dei tipici test unitari.)

Un modo di integrazione è quello di avere una build notturna o una build continua, che viene eseguita continuamente e può richiedere diverse ore per creare ed eseguire tutti i test.Se una build supera tutti i test (test unitario + test di sistema), diventa rilasciabile, puoi fornire quel binario o lo snapshot del codice sorgente.L'idea è quella di avere x versioni dei tuoi file binari/istantanee del codice, verificarli in modo asincrono e fornire le build ecologiche.Questo dovrebbe funzionare sia con i test di sistema automatizzati che con quelli manuali.