Sono uno sviluppatore di back-end e creo sempre test per le mie applicazioni. Recentemente ho studiato e applicato i test dell'interfaccia (utilizzando il selenio), ma dubito che io che dovrei creare questi test, sviluppatore o controllo qualità?
Come possiamo decidere se il test dell'interfaccia automatizzata debba essere responsabilità QA, o responsabilità degli sviluppatori, o entrambi?
E se entrambi, c'è il rischio di creare test duplicati?
Questo dipende interamente dall'azienda o dall'organizzazione in cui lavori, quindi chiedi alle persone responsabili della definizione delle strutture organizzative. Tuttavia, ci sono alcune regole empiriche che la distribuzione delle attività funzionerà meglio.
Ad esempio, se il dipartimento QA è composto da persone senza conoscenze di programmazione, non avrà senso affidare loro il compito di scrivere test automatici. Se i "test di interfaccia" che hai in mente non sono completamente test "black box" e hai bisogno di una certa conoscenza del funzionamento interno del tuo programma, non avrà molto senso neanche.
Se, tuttavia, i test dell'interfaccia sono test della scatola nera e il reparto QA ha alcune conoscenze di programmazione e identificano attività di test noiose e ricorrenti, perché non dovrebbero automatizzare queste attività scrivendo test automatici?
In alcune organizzazioni il dipartimento QA si concentra in modo specifico su test difficili da automatizzare e non ha bisogno di alcuna conoscenza di programmazione. In tale organizzazione, l'automazione dei test ricorrenti può essere delegata dal personale di controllo qualità agli sviluppatori.
Riguardo al rischio di creare test duplicati: parlare tra loro aiuterà! Chiarire le responsabilità di volta in volta. E se una piccola quantità di test viene eseguita due volte, questo è molto meno problematico come se i test necessari non venissero applicati perché ogni gruppo pensa che quei test siano di competenza dell'altro gruppo.
I test di accettazione devono essere scritti prima, prima che il codice sia scritto. Quando passano, sai che la funzione è completa e fa ciò che dovrebbe fare. Tuttavia, la maggior parte di questi test segue solo il percorso felice. Consideriamo due scenari:
In questo caso, hai risparmiato loro la fatica di scrivere test di percorso felice, in modo che possano concentrarsi su casi limite, test di mutazioni, test di stress, test esplorativi e test di regressione. Inoltre, possono rimuovere i test dalle proprie esecuzioni di test se preferiscono avere il proprio test di accettazione. Hai prodotto codice che ha meno probabilità di essere bacato, ha risparmiato tempo e ha permesso loro di concentrarsi su ciò che sono bravi a ... Il QA non è fare in modo che il software faccia ciò che dovrebbe fare - non dovresti spedire il codice a loro se c'è qualche domanda su questo - si tratta di assicurarsi che il software non faccia quello che non dovrebbe fare.
In questo caso, hai scritto test automatici che non possono scrivere, il che è utile. Forse impareranno a leggere i test automatici e capiranno cosa testate, cosa che li aiuterà a sviluppare un piano di test. Avete anche spedito il software che sapete funziona su un percorso felice, il che significa che il reparto QA ha più tempo per concentrarsi su esplorazione, regressione, ecc. Il loro compito è quello di violare il vostro software, non verificare di essere minimamente competenti.
In entrambi i casi, seguendo un piano di sviluppo guidato dal comportamento si risparmia tempo e denaro e si produce software più robusto.
Leggi altre domande sui tag tdd web-development qa selenium acceptance-testing