Se stai conducendo un progetto utilizzando BDD con copertura al 100% delle storie degli utenti con test di accettazione automatici, quale sarebbe il ruolo di un tester / addetto all'assicurazione della qualità?
Immagino che sto immaginando che gli sviluppatori scriveranno i test di accettazione insieme al proprietario del prodotto, fammi sapere se questo sembra un assurdità.
Forse sono troppo vecchio stile, ma anche le tecniche di sviluppo o di elaborazione più moderne non possono sostituire un altro paio 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 avevate pensato in anticipo.
Se il tuo prodotto è basato pesantemente sull'interfaccia utente, sicuramente vuoi che un'altra persona (che non sei tu o qualcuno del tuo team) cerchi il risultato finale prima di inviarlo al cliente.
Come qualsiasi altra parola d'ordine nel nostro settore, BDD - anche con copertura al 100% - è nessun proiettile d'argento .
La copertura del 100% non è la stessa del 100% testato.
Vedrei una persona di controllo qualità in un progetto ATDD come qualcuno che potrebbe aiutare a scrivere i test ed eseguire gli altri tipi di test ancora esistenti. Cioè Test dell'interfaccia utente, test di distruzione e test di carico / stress.
Ma non ho mai elaborato un progetto ATDD.
Il lavoro di QA è di rompere l'applicazione, il lavoro dei dev è quello di non romperlo. Pertanto scrivono i loro test da una prospettiva diversa. Ad esempio, gli sviluppatori scrivono dei test per verificare se il comportamento previsto si verifica, il QA scrive i 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 della qualità si accorgeranno quando la loro interpretazione è diversa da ciò che lo sviluppatore pensava di voler dire e poi si uniscono agli stakeholder del progetto per determinare quale sia l'interpretazione corretta. I test scritti dagli sviluppatori che hanno scritto il codice hanno spesso grossi punti ciechi perché lo sviluppatore aveva un grosso punto cieco. Ad esempio, potrebbe testare cosa succede il 97% delle volte ma non i casi limite.
In un precedente datore di lavoro il ruolo di QA era quello di non testare il prodotto ma di garantire che gli sviluppatori facessero essenzialmente ciò che avevano detto che avrebbero fatto riguardo ai test di accettazione definiti in precedenza definiti dal QA.
Il proprietario del prodotto, d'altra parte, non aveva assolutamente nulla a che fare con il 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 dovresti forzare una soluzione all'interno del ciclo di sviluppo che in realtà è solo indirizzare un piccolo sottogruppo di etica del lavoro dei dipendenti.
In un mondo perfetto vedo la collaborazione con dev e QA formalizzare con la scrittura dei test di accettazione in modo congiunto. Il QA dovrebbe portare un aspetto diverso al tavolo come dovrebbe essere il team di sviluppo. Il QA dovrebbe avere la mano nella torta fin dall'infanzia del prodotto e rimanere impegnato durante l'intero ciclo. Il proprietario del prodotto, d'altra parte, dovrebbe quindi impegnarsi in QA per capire 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 il test unitario per coprire oltre il 90% del codice. C'erano anche test di integrazione e build orarie. Esegui test per BDD.
Ruolo QA: - l'adozione di user story per i test - scrivere il codice dietro i passaggi - test di esplorazione utilizzando il plug-in RestClient per IDEA (quindi abbiamo rilevato alcuni bug importanti)
Una 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 passo per rendere gli scenari eseguiti 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 di QA è quello di convalidare quei test di accettazione ed eseguire test di esplorazione manuale al di fuori dei test di accettazione programmati. La duplicazione di solito produce lo stesso risultato.
Gli sviluppatori non riscrivono requisiti e specifiche, il controllo qualità non riscrive il codice dell'app ... è possibile che il controllo qualità non esegua gli stessi test script che gli sviluppatori eseguono come test di accettazione. È tempo che i Devs indossino il cappello del QA!
Leggi altre domande sui tag bdd testing team qa acceptance-testing