Se si esegue un progetto utilizzando BDD con una copertura del 100% delle storie degli utenti con test di accettazione automatizzati, quale sarebbe il ruolo di un tester / persona di controllo qualità?
Immagino che sto immaginando che gli sviluppatori scriverebbero i test di accettazione in collaborazione con il proprietario del prodotto, fammi sapere se sembra un'assunzione folle.
Risposte:
Forse sono troppo vecchio stile, ma anche le più moderne tecniche di sviluppo o di elaborazione non possono sostituire un altro set di occhi, occhi nuovi, prima di rilasciare un prodotto al tuo cliente.
Anche se il tuo prodotto è semplicemente un'API per un altro sviluppatore, puoi utilizzare il QA per pensare come utente API, fornendo scenari di test / utilizzo che tu o il tuo cliente non pensavate in anticipo.
Se il tuo prodotto è fortemente basato sull'interfaccia utente, sicuramente vuoi che un'altra persona (che non sia tu o qualcuno del tuo team) cerchi il risultato finale prima di inviarlo al client.
Come qualsiasi altra parola d'ordine nel nostro settore, BDD - anche con una copertura del 100% - non è un proiettile d'argento .
Il 100% di copertura non è uguale al 100% testato.
Vedrei una persona addetta al controllo qualità in un progetto ATDD come qualcuno che potrebbe aiutare a scrivere i test ed eseguire gli altri tipi di test ancora esistenti. Vale a dire test dell'interfaccia utente, test di distruzione e test di carico / sollecitazione.
Ma non ho mai elaborato un progetto ATDD.
Il compito del QA è quello di rompere l'applicazione, il lavoro degli sviluppatori è di non romperlo. Pertanto scrivono i loro test da una prospettiva diversa. Ad esempio gli sviluppatori scrivono test per vedere se si verifica il comportamento previsto, il QA scrive test per vedere cosa succede quando gli utenti fanno qualcosa che lo sviluppatore non considererebbe mai l'utente. Inoltre, gli sviluppatori spesso interpretano erroneamente i requisiti e i test di controllo qualità verranno catturati quando la loro interpretazione è diversa da ciò che lo sviluppatore pensava significasse e quindi si riuniscono con le parti interessate del progetto per determinare quale sia l'interpretazione corretta. I test scritti dagli sviluppatori che hanno scritto il codice hanno spesso grandi punti ciechi perché lo sviluppatore aveva un grande punto cieco. Ad esempio, potrebbe verificare ciò che accade il 97% delle volte, ma non i casi limite.
In un precedente datore di lavoro, il ruolo del controllo qualità non era quello di testare il prodotto ma di garantire agli sviluppatori essenzialmente quello che avevano dichiarato di voler fare in relazione ai test di accettazione precedentemente definiti definiti dal controllo qualità.
Il proprietario del prodotto, d'altra parte, non aveva assolutamente nulla a che fare con i test. Gestire i test a qualsiasi livello IMHO non è il ruolo del proprietario del prodotto.
Ad un certo punto devi avere fiducia nei tuoi dipendenti; i controlli e gli equilibri sono buoni, ma non è necessario forzare una soluzione all'interno del ciclo di sviluppo che, in realtà, deve affrontare solo un piccolo sottogruppo dell'etica del lavoro dei dipendenti.
In un mondo perfetto, vedo la collaborazione con dev e QA formalizzarsi con la scrittura dei test di accettazione in modo congiunto. Il QA dovrebbe portare un aspetto diverso al tavolo come dovrebbe fare il team di sviluppo. Il controllo qualità dovrebbe avere una mano nella torta all'infanzia del prodotto e rimanere impegnati per l'intero ciclo. Il proprietario del prodotto, d'altra parte, dovrebbe quindi impegnarsi nel controllo qualità per comprendere quale sia lo stato attuale del prodotto, i rischi, ecc ... e concentrarsi sul prodotto in modo olistico; non le sfumature specifiche che compongono il prodotto.
Dalla mia esperienza: stavamo usando Unit test per coprire oltre il 90% del codice. Ci sono stati anche test di integrazione e build orarie. Test jBehave per BDD.
Ruolo QA: - adozione di user story per i test - scrittura di codice dietro i passi - test di esplorazione utilizzando il plug-in RestClient per IDEA (quindi abbiamo trovato alcuni bug importanti)
Parte del BDD sta applicando l'approccio 3 Amigos in cui le parti interessate collaborano per produrre i criteri di accettazione. QA / Dev può scrivere il codice del passaggio per eseguire gli scenari come test di accettazione. Dov'è il valore del QA per eseguire manualmente gli stessi test di accettazione che uno strumento BDD eseguirà automaticamente? Il valore aggiunto del QA è convalidare i test di accettazione ed eseguire test esplorativi manuali al di fuori dei test di accettazione con script. La duplicazione di solito produce lo stesso risultato.
Gli sviluppatori non riscrivono i requisiti e le specifiche, il QA non riscrive il codice dell'app ... è possibile che il QA non debba eseguire gli stessi test con script che gli sviluppatori eseguono come test di accettazione. È tempo che gli sviluppatori indossino un po 'del cappello QA!