Il QA o il test di un sovraccarico o non vengono utilizzati correttamente?

Sì, l'agilità è in parte "orientata alla riduzione di questo" spreco ": i test vengono coinvolti all'inizio dello sviluppo in modo che i problemi vengano eliminati all'inizio?"

Il ruolo del controllo qualità dovrebbe essere quello in cui sono uguali collaboratori con gli sviluppatori e il lato commerciale dello sviluppo del software. Sono i sostenitori del cliente, quello che guarda il software dal punto di vista dell'utente per assicurarsi che corrisponda alla definizione di qualità.

Quando fai affidamento sulle attività di controllo qualità alla fine di un ciclo di sviluppo, è troppo tardi per avere un impatto significativo sul prodotto. Alla fine del ciclo, il meglio che possono fare è identificare i bug esistenti. Quando li sposti all'inizio del ciclo, possono essere utili per prevenire bug. Quel è il vero valore che il QA può apportare alla tabella, perché un bug trovato in fase di progettazione o in fase di sviluppo è notevolmente più economico da correggere rispetto a quello trovato alla fine del ciclo di sviluppo.

La differenza tra il ruolo del QA quando sono inclusi solo alla fine di un ciclo cascata vs agile o qualsiasi altra metodologia che coinvolge il QA all'inizio del ciclo è uno dei difetti rilevamento rispetto al rilevamento prevenzione .

I test sono per il controllo della qualità e dell'ambulanza per l'assistenza sanitaria. L'idea è di concentrarsi su ciò che può essere fatto all'interno di quest'ultimo in modo che il primo non sia necessario. Il QA dovrebbe essere tanto impegnato all'inizio del processo quanto chiunque, se non più occupato. Quanto prima saranno coinvolti nello stabilire come e quanta qualità verrà raggiunta, saranno necessari meno test e le poche questioni verranno dai test.

Agile non è un proiettile d'argento per uccidere quei piccoli e problematici e problematici tester. Impara a mostrare rispetto, o qualsiasi cosa tu faccia è destinata a fallire. Probabilmente l'unica ragione per cui il test ti dà fastidio è che non hai fatto il tuo lavoro. Non facendoti lavoro, hai fatto molto più lavoro per loro. Se ritieni di avere motivi per lamentarti dei tester che trovano difetti, pensa a lungo e duramente quale parte hai giocato in quel piccolo problema e quanto lavoro hai creato per loro. (Rant Over)

Quindi, come risolverlo? Agile, Cascata, qualsiasi cosa non abbia importanza, parla solo tra loro. Se non sei chiaro sui requisiti, assicurati di chiedere alla BA e ai tester. Chiedi ai tester come si aspettano di testare ciascuna caratteristica. Chiedi ai tester di accedere ai loro piani di test e assicurati che il tuo software passi i piani. Non gettare il prodotto su una recinzione, consegnarlo in un pacchetto ben avvolto. Se qualcuno non è chiaro su tutto ciò, torna al BA finché non sai cosa è necessario e in che modo ciascuna squadra raggiungerà il risultato.