Agile: QA senza risorsa di test dedicata

3

Attualmente sto lavorando in un piccolo team di sviluppo software interno di quattro persone. Avendo avuto molto successo con Agile in passato (che nessuno dei miei colleghi ha mai usato prima), sono desideroso di provare a passare a un processo più agile.

Il problema è che non abbiamo risorse di QA dedicate. Non è così pericoloso come sembra: il 90% del lavoro che facciamo è su progetti interni e il "team di test" finisce per essere gli utenti che fanno UAT. Ovviamente non è l'ideale: non sono così veloci o completi quanto il QA dedicato, ma in sostanza funziona.

Al momento eseguiamo versioni e demo incrementali, dopo di che gli utenti eseguono alcuni test e contrassegnano le cose come completate. Tuttavia, sto cercando di capire come integrare questo processo nel tradizionale framework Agile.

Comprendo l'importanza di terminare un'attività in uno sprint e di non contrassegnare una funzionalità come completa finché non è stata testata. Apprezzo anche che possiamo eseguire molti test automatizzati, ma, secondo la mia esperienza, ci sono spesso molti requisiti che non sono adatti per un test automatico e richiedono una sorta di controllo qualità.

Allo stato attuale, non possiamo fare test fino a dopo il rilascio. E non possiamo avere alcun controllo su quando questo test viene eseguito (gli utenti hanno altri compiti da fare). E non possiamo avere una risorsa di QA dedicata (ho chiesto, ma sono in una situazione di uova e galline di dover dimostrare che funziona prima di ottenere il budget).

Che cosa posso fare? E 'abbastanza buono solo per fare i nostri magri test interni / automatizzati e contrassegnare le cose come "fatte" per ora, con UAT che è una fase separata? O esiste un modo per integrare meglio l'UAT nei cicli di sprint?

Ci sono altre domande

Sembrano simili al problema centrale di questo, tuttavia, tutte le risposte presumono un team di controllo qualità esistente, solo uno che non funziona in sincronia con gli sviluppatori. In questa situazione non c'è alcun QA. In effetti, il solito livello intermedio di test è del tutto assente.

    
posta Matt Thrower 05.03.2015 - 11:25
fonte

1 risposta

2

Raccomando che il tuo team di sviluppo tenti di assumere il ruolo di test di accettazione degli utenti, almeno nella misura del possibile. Potrebbe non essere efficace quanto gli utenti effettivi, almeno fino a quando gli sviluppatori non avranno una buona conoscenza del dominio e di come gli utenti svolgono il loro lavoro nel software, ma aiuterà a cogliere le grandi cose prima di coinvolgere gli utenti e contribuirà a guidare la comprensione del dominio.

Quando una storia è completa, qualcuno nel team di sviluppo può assumere il ruolo di testare quella storia. A seconda del processo di sviluppo, forse anche qualcuno che non era precedentemente coinvolto nella storia in precedenza potrebbe essere responsabile per l'UAT finale. Ciò consentirebbe al team di sviluppo di ottenere alcune informazioni su come gli utenti stanno effettivamente utilizzando il software e guideranno le decisioni di progettazione.

Ci sono alcuni aspetti negativi, però. La velocità verrà ridotta in quanto sarà necessario allocare gli sviluppatori per svolgere questo ruolo UAT. Tuttavia, penso che l'aumento della comprensione dei ruoli e dei bisogni degli utenti e la capacità di fornire software di qualità superiore supereranno la velocità ridotta.

    
risposta data 05.03.2015 - 15:50
fonte

Leggi altre domande sui tag