Qual è / il tuo processo di QA più efficace? [chiuso]

Gli utenti cambiano idea costantemente, il che è naturale e salutare. Significa che hanno imparato di più su ciò che vogliono.

Oggi i requisiti know saranno errati domani, quindi non ha senso cercare di ottenere una risposta definitiva. Comunque sono solo speculazioni. Non saranno soddisfatti anche se fornisci esattamente in base alle specifiche, perché ciò che volevano non è ciò che vogliono ora.

Quindi, devi cambiare il tuo processo di sviluppo per lavorare con questo invece di contro esso. Ecco cosa suggerisco per i requisiti:

Trova alcuni "requisiti" iniziali con i tuoi utenti. Li implementa. Invita i tuoi utenti a provarlo e poi ascolta il loro prezioso feedback. Ripeti fino a quando soddisfatto.

I grandi strumenti per questo sono user story e un ottimo processo che implementa ciò che ho appena detto Scrum. Davvero, funziona.

Non penso che questo sia un problema di garanzia della qualità. Questo è più di un problema di raccolta dei requisiti. Suggerirei che la vostra direzione redigesse un documento sui requisiti, lo desse al cliente per la sua approvazione e solo allora dovrebbe iniziare il lavoro di implementazione dei requisiti.

Ricorda che le persone possono cambiare idea, è la natura umana. Modifiche minori dovrebbero essere accettabili. Tuttavia, i drastici cambiamenti da parte del cliente non dovrebbero essere consentiti e dovrebbero essere penalizzati di conseguenza.

Sarei d'accordo con gli altri sul fatto che questo non è sicuramente un processo di garanzia della qualità. Se si tenta di legarlo a qualcosa, sarebbe sicuramente la fase dei requisiti, in genere gestita dal proprietario del prodotto o dall'analista aziendale. Invece di fare sviluppo subito, se possibile, siediti con il cliente per ciascuno dei requisiti per scoprire cosa vogliono realmente. Un'incontro di un'ora può spesso salvare una settimana o più in lavori ripetuti, in realtà non è diverso dal rilevare bug in dev o QA piuttosto che in produzione.

In passato, se l'intero processo è nuovo, ho visto che funziona molto bene quando un rappresentante di ciascuna parte del gruppo di sviluppo (ad esempio: BA, QA, DEV) si incontra in queste discussioni mentre tutti iniziano a ottenere una sensazione per ciò che è effettivamente richiesto. Dopo un po ', arriva al punto in cui l'analista di business, o chiunque, può comodamente sedersi con il cliente e discutere i requisiti per ottenere qualcosa che il cliente vuole realmente.

Personalmente ritengo che il passo più importante in un processo di QA venga dopo che le specifiche sono state in qualche modo confermate (anche se tendono ad essere piuttosto dinamiche) e il tester inizia a lavorare su un piano di test.

I piani di test sono fondamentali per assicurare che il processo di controllo qualità sia organizzato. Poiché le tue esigenze cambiano spesso, prova a rendere più generici i piani di test e prenota piani di test specifici per i requisiti essenziali che non cambieranno radicalmente.

Il piano di test dovrebbe essere sottoposto a peer review e cerco sempre di rivedere i miei piani di test dagli stessi sviluppatori.

Oltre ai piani di test, è spesso consigliabile creare script di test per supportare il piano di test. È prassi comune posizionare questi script nel database del piano di test del QA (presumo che ne esista uno in quanto è piuttosto essenziale per la maggior parte delle società). Il project manager (supponendo che abbia delle conoscenze tecniche) può ora guardare gli script tramite il database e osservare anche il piano di test per assicurarsi che il test / la pianificazione del QA avvenga in modo fluido ed efficiente !!

Vorrei echo @Bernard, @rrazd e @Lyndon: il piano di test è un co-prodotto del processo di definizione dei requisiti. Se un requisito non è verificabile, probabilmente manca di specificità.

Per dirla in altro modo: se i tuoi utenti firmano (almeno provvisoriamente) su un piano di test sei sulla stessa pagina, almeno per il momento.

Nota:

1. questo sarebbe un piano di test accettazione (non affronta nessun altro tipo di test);
2. come per @Martin, aspettati che i requisiti cambino man mano che gli utenti (e tu) arrivano a comprendere meglio il dominio del problema.