Migliora i test non validi [chiuso]

Qualsiasi metodologia è valida solo come la tua applicazione. Da qualche parte nel processo (o forse in più punti), qualcosa non viene fatto adeguatamente. Esempi ipotetici:

• Il tester X va e dice al suo amico sviluppatore Y di un bug, piuttosto che metterlo nel sistema di tracciamento dei bug. Non è stato corretto, e il bug è stato dimenticato.
• Il piano di test per la caratteristica A non è abbastanza dettagliato. Dice "l'utente può aprire correttamente il file". Ma non dice che tipo di file usare, quindi il tester lo prova solo con un piccolo file di test, piuttosto che con un file di linea da 1.000.000 che potrebbe essere utilizzato nella vita reale. Il programma supera il test, ma non funziona con i dati del mondo reale.
• Il test è rigoroso, ma dopo la procedura di test qualcuno avverte della piccola caratteristica Z mancante. Questa piccola funzionalità viene aggiunta senza ripetere il test (è comunque una caratteristica banale, cosa potrebbe rompere?) E la versione viene scaricata fuori dalla porta. Ma questo rompe la versione di rilascio.

E così via. È impossibile dire dove il tuo processo specifico stia andando male. Ma dovrebbe essere facile arrivare alla causa principale osservando le segnalazioni di bug e ponendo domande semplici:

• Il bug nella funzionalità era coperto nel piano di test?

  • Sì. L'errore specifico era coperto da un caso di test?
    • Sì. Il test è stato eseguito e approvato nella versione spedita?
      • Sì. I test stessi sono inadeguati e devono essere migliorati.
      • No. Il processo di rilascio del software è interrotto se il software che non supera i tuoi requisiti di test è stato spedito.
    • No. I casi di test non sono sufficientemente rigorosi o non sufficientemente specifici.
  • No. I test non coprono tutte le funzionalità.

Trovo che una cosa sia sospetta. Tu dici:

the testing team is involved in the design of the feature and are included in the development process as much as possible.

Che tipo di input stanno dando i tester qui?

Una caratteristica essenziale di un buon test è che i tester sono separati dal processo di creazione del software. Non stanno prendendo decisioni sul design e sulla funzionalità del programma. E certamente non dovrebbero scrivere codice. Se stanno facendo cose del genere nel tuo progetto, i tuoi tester non sono realmente dei tester e il tuo processo di test è rotto. Perché questo è un problema?

• I tester che aiutano le funzionalità di progettazione sono suscettibili di fare le stesse ipotesi fatte durante il processo di progettazione e meno probabilità di scoprire problemi a causa della rottura di questi presupposti. Inoltre, a causa della natura umana, saranno meno liberi di criticare il modo in cui funzionano le cose se hanno aiutato a progettare il modo in cui funziona.
• I tester che scrivono anche il codice sono molto meno produttivi nel trovare bug. Nessuno di noi vuole che il nostro codice si spezzi, così inconsciamente renderemo il test meno rigoroso, evitando cose che potrebbero essere un problema, razionalizzando noi stessi "che non ha davvero bisogno di essere testato, non accadrà mai, ecc. .. ". E le stesse ipotesi utilizzate nella scrittura del codice saranno usate anche nei test, impedendo di nuovo la ricerca di bug che rompano queste ipotesi.

La prima cosa che devi fare, prima che questa domanda possa essere ulteriormente risolta, è fare una analisi delle cause principali - tieni chiedendo "perché?" . Quindi spererai che sappia cosa deve essere migliorato / risolto.

I piani di test sono corretti?

Le tue esigenze cambiano molto. Il team di test ha abbastanza tempo per aggiornare i piani di test? Chi convalida che i piani di test sono corretti?

Ci sono alcuni tester le cui sezioni finiscono con più bug di altri?

Guardando in un altro modo, ci saranno sempre bug, ma è la frase "difetti semplici ed evidenti" che sporge.

Sei sicuro che la tua squadra di sviluppo abbia test di unità sufficienti? Non c'è niente che odio di più come un dev quando qualcuno trova un "difetto semplice ed evidente". Perché non l'ho capito? Certo che qualcuno riuscirà, ma se c'è molto, allora sto facendo qualcosa di sbagliato.

Solo supposizioni ... potresti soffrire di un Test Pyramid con i piedi di argilla (scarsa o nessuna unità di test unitario)?

"Difetti semplici ed evidenti" suona come qualcosa che dovrebbe essere curato fin dalle prime fasi di sviluppo.

Inoltre, potrebbe essere una buona idea (se non già esistente) includere la garanzia della qualità come parte della definizione di Fatto per le tue storie utente. Avere il team di test in prova durante lo sprint e rifiutare qualsiasi storia non conforme è molto più efficiente di test una volta per versione.

Come sviluppatore solitario, non c'è molto che tu possa fare per migliorare il numero / qualità dei difetti trovati dai tester.

Come squadra, puoi provare a incoraggiare i tester a cercare di rompere il sistema nel modo più creativo possibile. Questo è il ruolo del tester, per rompere il sistema, non per dimostrare che funzioni.

Per convincere i tester a pensare in termini di rottura del sistema, potresti provare a mettere una piccola ricompensa per il tester che, durante l'ultimo sprint, ha rotto il sistema nel modo più creativo. Non ha nemmeno bisogno di avere un valore monetario o forma fisica.

But every release of the product, they miss even the most simple and obvious defects.

La radice di ogni buon processo (non importa come appare nei dettagli - sia esso scrum o tradizionale) è sempre :

• massima garanzia di qualità costruttiva : buoni strumenti produttivi, standard di codifica, requisiti solidi ecc. - > prevenzione dei difetti
• buona garanzia di qualità analitica : come test blackbox manuale / automatizzato, revisioni del codice - > individuazione dei difetti

"massimo costruttivo" significa: prima di migliorare la ricerca di difetti, migliora che crei meno difetti.

Sei sicuro di avere un buon QA analitico mix ? Come test unitari, test manuali, ma anche recensioni di codici etc?

I tuoi tester usano tecniche diverse come i test esplorativi e non solo i test basati sul piano? La tua attrezzatura è sufficiente per i test? (Spero tu non usi gli elenchi Excel ...)

Tieni sotto controllo gli angoli di visuale diversi?

I tuoi tester hanno buoni dati di test?

Alla fine: budget? Sarebbe possibile testare tutto come desiderato? In caso contrario, imposta le priorità.

Questi sono solo alcuni punti. Probabilmente nessuna squadra o compagnia è brava in tutto e probabilmente la tua squadra non è affatto male.

Cerca di riflettere sul problema e priorizzare le cose che potrebbero aiutarti. Ma assicurati sempre di avere un equilibrio tra misure costruttive e analitiche.

E alcune verità non così belle: alcune persone non sono adatte a progetti complessi - sono sciatte e non cambieranno mai. Sbarazzati di loro.

L'abbiamo sperimentato molto.

Il problema principale, che ho sperimentato molto è che la funzionalità viene testata, sembra OK, la si spinge in produzione e poi si verificano problemi.

Il mio approccio a questo (sono un operatore di un solo uomo con 4 sviluppatori!) è un buon mix di test di regressione automatizzati combinati con test di unità della funzione corrente.

Non ho il tempo o la capacità di scrivere script (selenio nel mio caso) per tutte le varie funzionalità fornite, quindi quello che faccio è testato manualmente. Di solito è abbastanza semplice. Mi concentro su più browser, versioni e dispositivi a questo punto per vedere come stanno le cose. Cerco di inserire valori inusuali, fare clic su tutti i collegamenti, questo genere di cose.

Su una pista parallela sviluppo test automatizzati con Selenium. Questi sono buoni test di integrazione e sono davvero utili per ottenere quelle "conseguenze non volute" che accadono quando una cosa viene cambiata e influenza gli altri. Questi test rappresentano anche un vero flusso di lavoro dell'utente. Ho ogni suite ripartire da zero e costruire l'intero sistema. Quindi i dati vengono eliminati (anche attraverso l'interfaccia utente). Ho dovuto conoscere le variabili di selenio, xpath e css e javascript call-out per ottenere alcune delle cose più difficili ma ha avuto una grande ricompensa. Le suite si concentrano sulle funzionalità principali e sul flusso di lavoro del prodotto, non sulle ultime funzionalità.

Anche 'quando' il coinvolgimento del QA è importante. Ho visto due approcci a questo:

1. Quando la funzione è stata codificata e consegnata ed è considerata "pronta per il QA"
2. Durante la sessione di progettazione

È più facile da fare 1) ma questo porta a che il controllo qualità sia troppo tardi e, criticamente, non viene coinvolto nella progettazione o nel layout. Questo a sua volta porta a bassa motivazione e bassa soddisfazione lavorativa, che sono i due più grandi assassini per ottenere un lavoro di alta qualità. Secondo l'approccio 2) quando il QA è coinvolto in anticipo durante la progettazione, è più probabile che sia motivato a fare un buon QA quando sarà il momento.

Inoltre, assicurati che (e l'umorismo possa aiutarti) che il QA sa che è davvero buono quando trovano bug (s). È il loro lavoro e salva l'azienda dal metterla di fronte al cliente. "Molti tester del QA ritengono rapidamente di diventare essi stessi proprietari di prodotti, trovando la possibilità di lavorare con questo, non contro di esso."

Stai facendo le domande sbagliate. Per uno, l'intero team è responsabile per la qualità del software, quindi non è solo che i tester mancano dei difetti. Anche gli sviluppatori.

La domanda più importante è: perché i tuoi team aggiungono i difetti "semplici e ovvi" per cominciare? Non focalizzare la tua attenzione sulla cattura di altri bug, concentra l'attenzione sulla scrittura di meno bug.