Pianificazione del test per uno sprint Agile

Penso che dipenda davvero dal tipo di progetto e dal tipo di decisioni che devi prendere. Ad esempio, qual è lo scopo del piano di test per te.

Qui condividerò alcune esperienze riguardanti il nostro progetto.

Nel nostro progetto e test del nostro team si intende:

• preparazione degli ambienti di test, richiesta per i test di sistema
• preparazione dei dati di test: acquisizione di dati reali dalla produzione o simulazione
• automatizzazione dei test a livello di unità, integrazione, sistema, integrazione di sistema.
• scrivere mock, driver di test, simulatori di dati, framework di test
• dimostrazione dell'output di sviluppo

Quindi i test di pianificazione riguardano decisioni di alto livello da chiarire in precedenza. Ad esempio, decidiamo se il QA deve testare end-to-end una determinata storia, o è meglio se aumenta la copertura del test a livello di unità, estendendo in questo modo i test scritti dagli sviluppatori. Ottenere dati di test spesso significa entrare in contatto con clienti, analisi di business e altre parti interessate per ottenere l'accesso ad essi. I test end-to-end spesso richiedono il know-how di più esperti tester, business analytics e delivery guys, quindi dobbiamo pianificare una formazione in anticipo. I tester spesso presentano ciò che il team ha raggiunto, quindi a volte pianifichiamo quali test preparare per la demo.

L'automazione è una storia a parte. Abbiamo stabilito la metodologia e le strutture per il test, quindi test significa implementare ed eseguire casi di test. Dall'altro lato, stiamo sviluppando un nuovo framework di test, ovvero un progetto di sviluppo separato parallelo a quello principale. Anche questo deve essere pianificato, non può essere fatto ad hoc, ma impariamo ancora dagli altri team come pianificare in modo efficace.

Di solito sappiamo cosa faremo nella versione attuale o in uscita, quindi i test di pianificazione vengono eseguiti in anticipo per diverse iterazioni.

Di solito pianifichiamo i test con il resto del team, quando inizia l'iterazione. Non scriviamo sempre tutte le decisioni sui test, ma pianifichiamo ancora il processo di test.

A volte, come tester, dobbiamo supportare sia l'iterazione corrente che i test di regressione. Quindi dobbiamo pianificare quanto la nostra capacità può essere dedicata all'attuale iterazione e se gli sviluppatori possono coprire i nostri test, se siamo troppo occupati con altre responsabilità. Questo è agile, quindi gli sviluppatori possono fare alcuni test, ma dobbiamo ancora programmarlo in qualche modo.

Can anyone offer any tips or experience on developing a test plan for an Agile sprint?

Per prima cosa, pensa a dove i piani di test rientrano nella tua definizione di una storia che viene "fatta"? È sufficiente scriverli ad alto livello? Li implementa? Implementare e passarli? Ci sono vari pezzi qui che vale la pena notare che possono essere discussi all'interno di una squadra che dovrebbe essere un consenso per determinare lo standard per il tempo.

Is it common to just write high-level testing tasks without making the actual test cases transparent to the development team?

Potrebbe essere. In vari luoghi in cui ho lavorato, non sono stati effettuati test come parte dello sviluppo per analizzare più di una manciata di compiti come parte dei test, in quanto ci sarebbero stati test unitari, test di integrazione, QA con test propri e cancellati da gli utenti finali che potrebbero far parte del nostro processo in un unico posto.

What sort of methodologies have you used when developing a test plan and what does it look like both at the beginning of a sprint and at the end?

TDD sarebbe un'idea che potresti usare qui. Ci sono molte altre possibilità in cui la domanda è: cosa stai cercando di ottenere da questa metodologia: ridurre il debito tecnico, migliorare la qualità o qualcos'altro?

Le demo sprint possono essere un utile punto per mostrare la funzionalità agli utenti e raccogliere feedback su ciò che potrebbe essere stato perso. Anche se questo non è tecnicamente in un "piano di test", direi che ciò rientra nella garanzia della qualità, che è parte del punto di test.

Any advice or tips on what comprises an effective and transparent test plan as well as a means of developing the test plan would be much appreciated.

In primo luogo, documenta quali sono i problemi con la strategia corrente che stai utilizzando. Dove non riesce a fornire valore? Secondo, quali sono i fattori che vorresti in una strategia di test rivista? Una parte di Agile riguarda il cambiamento delle cose e l'essere pronti a continuare ad adattarsi. Se si conosce un modo strutturato per eseguire i test, comunicarlo e vedere cosa pensano gli altri membri del team di un simile approccio. Forse lo ameranno e vorranno provarlo? Forse avranno domande che non hai meditato inizialmente?

Dove ho lavorato dove abbiamo avuto una serie di test potrebbero esserci problemi con la fragilità dei test nel codice a causa di tutti i dati fittizi che dovevamo generare per eseguire i test e poi se qualcuno cambia qualcosa, alcuni test si rompono e non sempre vengono ripuliti correttamente.

Ho scoperto che i test basati su sessioni e l'automazione dei test sono davvero brillanti in questi casi. Normalmente inizierò con alcuni scenari di alto livello che gli stakeholder trovano importanti. Da lì, inizio a scrivere schede di sessione per le cose che voglio testare, con un po 'più di dettagli. Quando eseguo la sessione, è quando i dettagli iniziano a entrare, registrati nelle note di sessione.

Anche l'automazione dei test può essere d'aiuto. Ancora di più quando si usa qualcosa come il cetriolo. Io, usando SpecFlow, sono in grado di creare il test in modo che i miei stakeholder possano capire cosa sta facendo il test e hanno un riepilogo di alto livello di ciò che effettivamente ha passato / fallito.

Anche se non sono un fan dei piani di test giganti, capisco che sia necessario occasionalmente. Invece di inserire i casi di test nel piano di test, inserire invece le schede di sessione e l'automazione del test. Ricorda, è un documento vivente, e cambierà e si evolverà man mano che i test continueranno. Allo stesso tempo, tuttavia, il piano di test dovrebbe essere probabilmente per la tua applicazione / progetto, e non necessariamente per ogni singolo sprint.