Se abbiamo TDD e BDD, perché abbiamo bisogno del QA? [duplicare]

Gli sviluppatori sono molto, molto bravi nell'astrazione. Se ci dai metà problema, arriveremo alla soluzione completa. In effetti, siamo così bravi in questo, non ci accorgiamo nemmeno che abbiamo solo metà del problema. Siamo persone "spazio soluzione". Il nostro compito è risolvere i problemi.

I tester, d'altra parte, sono persone dello "spazio problematico". Sono quelli che chiedono: "E X? O Y? Hai pensato a Z?" Sanno come infrangere il nostro codice prima ancora di averlo scritto. Se siamo davvero gentili con loro, ce lo diranno. Il loro compito è comprendere il problema all'indietro.

Un analista o una PMI potrebbero essere bravi a capire quali sono i problemi più importanti da risolvere, ma una volta presa quella decisione, i tester sono altrettanto bravi quanto a capire la natura del problema scelto. Gli sviluppatori tendono a non essere bravi a causa delle nostre teste "spazio soluzione"; ci rendiamo ciechi alle cose che non conosciamo.

In un ambiente in cui stai facendo BDD o TDD, i tester sono inestimabili per aiutare te e l'azienda a individuare i test o gli scenari che hai perso. Sono anche ottimi per fare test di esplorazione, quindi trovano le cose che i test automatizzati non possono (per esempio, uno dei miei tester preferiti ha notato che avrei messo una chiamata SQL nel posto sbagliato e che un particolare comportamento stava facendo 10 chiamate al DB dove doveva solo fare 1).

In questi giorni tendo a riferirmi a "tester" piuttosto che a "QA", dal momento che garantire la qualità è davvero, come ha detto Gurun, più di una sola persona e un po 'di processo.

TDD è uno strumento design usato dagli sviluppatori, riguarda più la progettazione che i test e le verifiche.

BDD è uno strumento di comunicazione per colmare il divario tra sviluppatori, QA, proprietari di prodotti o analisti aziendali. BDD si assicura che condividiamo la stessa visione di ciò che è necessario creare utilizzando esempi concreti anziché fare affidamento su una specifica astratta.

QA è un ruolo con la responsabilità dei test di verifica su funzionalità, sicurezza, prestazioni, conformità, ecc ... QA può anche essere responsabile della fornitura di strumenti di automazione del test .

Quindi come puoi vedere sono tre cose ortogonali (naturalmente in uno spazio tridimensionale).

È certamente discutibile che tu abbia non bisogno di "QA", anche se ciò dipende da cosa intendi per "QA". Hai bisogno di un team o dipartimento di QA separato? Probabilmente no. Hai bisogno di professionisti qualificati per la qualità? Probabilmente sì.

Il test è un'abilità e in genere non è un'abilità che la maggior parte degli sviluppatori ha. Ogni squadra dovrebbe avere personale esperto e qualificato. Il loro compito dovrebbe essere quello di assicurarsi che il software sia ben testato sia lavorando con gli sviluppatori per scrivere buoni test durante lo sviluppo, sia per eseguire i propri test come test di esplorazione end-to-end.

Per analogia, pensa a un ispettore edile. Ad esempio, se un falegname controlla che il tetto che hanno costruito non perde, perché un ispettore edile? Prendi solo la parola del falegname? Hai ancora bisogno di un ispettore edile perché conoscono gli errori comuni che vengono fatti e come individuarli.

Quindi, anche se si dispone di un team di sviluppo che fa coscienziosamente TDD, ATDD, BDD o una delle sue varianti, è comunque necessario disporre di tester esperti per assicurarsi di disporre di un software ben testato.

Gli script di test automatici aiutano la logica e fanno clic intorno all'applicazione per garantire che tutti si connettano bene.

Ciò che non conta è:

lo script automatizzato è stato controllato per tutte le funzionalità create? controlla correttamente la logica?

Infine: Il layout del design non è controllato qui. I tester con occhio attento per i dettagli sono molto utili per catturare molte piccole cose nell'interfaccia utente tra diverse dimensioni dello schermo, piattaforme e dispositivi. Inoltre, più eyeball sul software che controlla le cose tende a migliorare il flusso logico per una migliore esperienza di interfaccia utente con meno confusione.

Hai scritto "Se questo è vero come si inserisce un QA?" il che implica che stai parlando di una persona responsabile del controllo qualità. Tornerò a quello alla fine della risposta.

Controllo qualità e controllo qualità sono due concetti molto distinti. Credo che quando noi, come sviluppatori, parliamo di QA, ci riferiamo più spesso alle persone che creano i test, o li eseguono, o entrambi. Per me, la garanzia della qualità è la pianificazione e la documentazione sistematica delle attività legate alla qualità. Più spesso documentati in un sistema di qualità generale. Lo facciamo per fornire una sorta di "assicurazione" che ci interessa (in inglese). Il controllo di qualità, per dirla in parole semplici, è un'attività correlata alla verifica che stiamo seguendo il piano.

Quindi quando fai questa domanda devi inserire TDD, BDD (o qualsiasi altra pratica, metodologia, tecnica, ecc.) nella giusta categoria. Devi anche capire cosa intendi con QA.

Blunt; Solo perché qualcuno sta facendo TDD non significa che ci sarà la qualità. Inoltre, non significa che anche se qualcuno è bravo a fare TDD sarà sufficiente copertura. Anche il sistema di qualità includerebbe criteri per quanto sarebbero sufficienti le prove e spesso può essere semplice come "testare ciò che deve essere testato". Ma in un sistema di qualità reale questa definizione non sarebbe in grado di reggere da sola, naturalmente. Devi essere in grado di giudicare questo da una posizione imparziale quanto umanamente possibile.

Penso che spesso ci sia un equivoco sul fatto che il QA / QC abbia bisogno di requisiti di documento, test, ecc. Spesso devo discutere (con il nostro QA) che qualità non viene creata dal processo stessa . La qualità deve esistere nello sviluppo e il ruolo del processo è raccogliere prove sufficienti a dimostrare la qualità. Ciò significa che il controllo qualità dal punto di vista di "avere un piano" è in realtà più importante per me del controllo di qualità. Ed è qui che TDD e BDD svolgono un ruolo come attività e pratiche che pratichiamo per garantire la qualità del nostro lavoro.

Un QA come lo scrivi, come se fosse una persona specifica a cui stai pensando, probabilmente significa ciò che di solito etichettiamo come QAE (ingegneria). Questo è fondamentalmente l'arte e il business della creazione di materiale per la verifica e la convalida del risultato della codifica. Ed è veramente un'arte. Una persona / dipartimento che fa QAE di solito fa molto di più che testare il sistema individualmente, poiché le attività di verifica e convalida di solito si estendono ben oltre il BDD / TDD di base. Ma da una pura "prospettiva dei programmatori" tendo a considerare questo come una responsabilità. E poi dipende molto dalla struttura organizzativa, dalle dimensioni, dal business, ecc. Se tale responsabilità è connessa a un ruolo (o più).

Direi con forza che indipendentemente da come e da cosa fai, hai sempre bisogno e hai sempre il QA. Hai sempre il controllo di qualità. Hai sempre QAE. È solo che in piccoli gruppi questo potrebbe non essere una risorsa esplicita, un ruolo o un'organizzazione.

Quindi qual è il ruolo di TDD in tutto questo? Beh, per me potrebbe non avere alcun ruolo, o significare tutto. TDD per me è un approccio alla scrittura di codice, non alla scrittura di test. La gente sembra discutere di cose come "lo stile di Londra è migliore di Chicago o persino dello stile di Piteå". Direi che lo stile Piteå vince sempre, poiché è il mio stile . E lo stile di Piteå significa che la maggior parte delle volte, dopo aver scritto qualcosa di estremo nello stile TDD, mi ritrovo con qualsiasi cosa, da funzionalità, integrazione, unità, black-box, white-box. L'unica cosa che posso dire con certezza è che dallo stile TDD Piteå I always finisce con molto più semplice, più diretto, più coperto, migliore costruzione .. codice . Lo stile di Piteå impone anche che sia perfettamente OK non produrre alcun codice se la qualità lo richiede . Occasionalmente lo stile Piteå richiede una birra o più, ma questo è un tipo diverso di garanzia della qualità. Nel sistema di qualità Piteå, il TDD è la base per cui certifico che ciò che produco sarà di qualità sufficiente e che sarà in grado di mantenerlo in seguito. E il mio server CI è instancabile e controlla continuamente che non sbaglio.

Ma alla fine, per quanto riguarda la qualità reale, solo gli utenti del mio codice possono rendere testimonianza. Posso solo assicurarli che faccio qualità al meglio delle mie capacità. Qualità prima, sempre, poi TDD.

[Piteå è la mia città natale]