BDD / TDD vs JAD?

Probabilmente stai ricevendo il push-back perché stai visualizzando (e quindi comunichi al tuo team) i due come mutuamente esclusivi, e non lo sono.

Quello che hai a disposizione è un buon modello. Sarebbe un errore "abbandonare" qualcosa che funzioni. Fortunatamente TDD riguarda solo quando vengono scritte le specifiche del test . Ciò non significa che i tester scrivano le specifiche del prodotto.

Se vuoi fare TDD, le specifiche del tuo prodotto dovrebbero essere scritte nello stesso modo in cui sono ora. Quindi i tester dovrebbero scrivere casi di test secondo queste specifiche. Quindi i tuoi sviluppatori sviluppano il codice di passaggio per questi casi di test (non hanno bisogno di essere ciechi rispetto alle specifiche del prodotto - mentre il tuo team è nuovo, i casi di test potrebbero non essere sufficienti per illustrare le specifiche del prodotto).

Questo non dovrebbe per niente sentirsi a disagio per la tua squadra. In effetti, dovrebbe dare più conforto al management e al tuo team UX - 1) prima sapendo che le sue specifiche sono state convalidate e hanno senso in scenari testabili prima che il codice venisse scritto, e 2) sapendo che il codice che viene scritto è in realtà ben testato. (Vantaggi a questo già risposto).

Ho lavorato per diversi anni in una squadra che aveva il processo esatto che descrivi (quello che hai chiamato JAD), e ho aggiunto gradualmente TDD, e per noi la combinazione dei due concetti è stata sicuramente l'approccio migliore.

TDD ha poco a che fare con il test del QA o la creazione di specifiche. TDD è uno stile di processo di programmazione che si focalizza su cosa e come sviluppare, data una specifica. Il risultato finale è il codice "appena sufficiente" per superare un test. Questo assicura due cose. Prima di tutto, la tua applicazione è testata al 100% alle specifiche, come gli sviluppatori le comprendono. In secondo luogo, e soprattutto, con quel set di test unitari ora puoi refactoring con fiducia quando lavori sulla prossima cosa.

Il QA riguarda sia il fare in modo che il sistema faccia ciò che gli utenti si aspettano sia che si accerti che il codice sia privo di errori.

Le prime domande che dovresti porvi:

• I prodotti della tua azienda vengono venduti?
• I tuoi clienti sono soddisfatti?
• Il prodotto è redditizio?

Se puoi rispondere "più o meno sì" (o meglio) a quelle domande, allora spero che tu possa capire perché c'è poco entusiasmo per il dondolio della barca. Se non è rotto ... come dice il proverbio.

Detto questo, se sei ancora legato e determinato a creare un caso, allora concentrati a determinare esattamente come definire - > design - > build - > il ciclo di test viene chiuso all'interno del sistema corrente. Significa, quando le persone che scrivono le specifiche di alto livello verificano che il sistema si comporti in base a ciò che hanno scritto?

Se la risposta è: "questo è il lavoro del team di test", allora potenzialmente hai qualcosa su cui puoi fare il tuo caso perché il ciclo non viene chiuso. E anche se il processo stabilisce che gli autori delle specifiche originali devono eseguire "test di accettazione", assicurati che ciò avvenga effettivamente.

Il BDD riguarda la chiusura del ciclo di sviluppo riducendo l'impedenza di comunicazione tra i definitori e gli implementatori tramite meccanismi chiaramente strutturati per l'acquisizione dei requisiti.

Questa è la tua argomentazione in poche parole, se necessario.

Il bonus è che puoi anche mostrare loro i "giocattoli brillanti" che sono stati prodotti dal mondo BDD (es. Cucumber / Gherkin) che puoi usare per dimostrare i vantaggi dell'automazione processo (ad esempio riduzione della comunicazione errata, aumento della produttività, maggiore manutenibilità della suite di test, ecc ...).

(BTW: quando dico BDD, intendo BDD / TDD perché sono due facce della stessa medaglia, imho Dove il BDD è focalizzato sui test black-box e TDD è focalizzato sui test white-box.)

Onestamente, mi sembra che questi acronimi a più lettere descrivano semplicemente uno specifico sottoinsieme dell'intero processo di sviluppo. È bello che siano formalizzati in modo che possano essere discussi, ma la realtà secondo me è che le organizzazioni di successo del software implementano un ibrido tra tutti loro. Però, penso che le implementazioni formali di JAD siano spazzatura in quanto la progettazione da parte del comitato è improduttiva. Certamente non funzionerebbe in organizzazioni più grandi.

Per rispondere alla tua domanda in modo più specifico, penso che ci sia molto spazio per i fraintendimenti nei documenti dei requisiti funzionali. In particolare sul lato gestionale. Noi agiamo in modo contrario avendo due componenti nei nostri documenti sui requisiti.

1. Requisiti di alto livello implementati in inglese semplice che spesso non presentano dettagli specifici. Descrive in modo specifico i casi d'uso tipici. I requisiti scritti in questo modo tendono a essere più digeribili da nessun tipo tecnico come vendite o marketing. Chiamerei questo BDD
2. Requisiti funzionali. Si tratta di requisiti esplicitamente definiti che possono essere testati. In genere, il nostro dipartimento QA e alcune volte il supporto sono i destinatari di questi. Chiamerei questo TDD.

Quindi, se dovessi presentare il caso per BDD, direi che limita la possibilità che la "gestione" fraintenda esattamente cosa farà il prodotto.

So, they ask, why should developers work against the test-cases created by testers?

Ottima domanda. TDD non suggerisce che i test vengano scritti dai tester. Il fatto che tu stia suggerendo la gente indica che non tutti si sentono a proprio agio con TDD e stanno inserendo ulteriori passaggi nel processo.

La loro domanda indica qualcosa di importante su TDD.

I tester non scrivono tutti i test. In effetti, non dovrebbero scrivere molti dei test. Alcuni dicono che non dovrebbero scrivere alcun test.

[Tests] are for verification and are based on the higher-level specs created by the UX team, which ... is sufficient for developers

Sì, ma.

Quelle "specifiche di alto livello create dal team UX" non sono sempre la migliore descrizione di un sistema. Questa affermazione - "[Test] ... si basa sulle specifiche di livello superiore create dalla UX" - è sospetta e spesso sbagliata.

What is the actual benefit of BDD/TDD, if you already have a test-team who's test cases are fully compatible with the higher-level specs currently given to the developers?

Ciò implica un falso presupposto, di nuovo. Nello specifico "i casi di test sono pienamente compatibili con le specifiche di livello superiore attualmente fornite agli sviluppatori".

Concept - > JAD - > Specifiche - > Test - > Codice

è ciò che hai in atto ora. Passi di trasformazione multipli e lineari. Ogni passaggio introduce qualche errore.

Concept - > Risultati dei test attesi - > Codice

Ha meno passaggi di trasformazione e meno errori introdotti lungo il percorso. Gli utenti (o gli utenti con l'aiuto dei facilitatori) possono scrivere direttamente i risultati del test.

L'ho fatto per la prima volta qualche anno fa e ha avuto un successo strepitoso. All'inizio volevano documenti di design, che tutti noi abbiamo scritto e passato in giro. Ma ho richiesto specifici risultati del test case. Ho creato i risultati dei test di esempio in fogli di calcolo. Ci è voluto un po '(in realtà settimane), ma gli utenti alla fine hanno corretto i miei errori e mi hanno inviato fogli di lavoro estremamente espansi. Hanno aggiunto i chiarimenti necessari sotto forma di casi di test.

Hanno anche scritto note e commenti. Una brutta abitudine.

Ho scritto una piccola utility per trasformare i fogli di calcolo direttamente in codice unittest.

Alla fine del primo tentativo di rilascio, gli utenti hanno ricevuto numerosi reclami e correzioni e bug da correggere. C'era un sacco di trouble ticket e rapporti sullo stato in corso. Controllo delle modifiche Tutta quella roba. Tutto in gran parte inutile.

Abbiamo esaminato il foglio di calcolo con i casi di test. Hanno corretto gli errori nei loro fogli di calcolo (ce n'erano uno o due). Hanno continuato a cercare di spiegare i loro appunti e commenti. Ho continuato a chiedere esempi invece di spiegazioni. Alla fine, hanno iniziato a revisionare e ampliare i fogli di calcolo per coprire completamente bug e funzionalità.

Alla fine ogni nota e commento esplicativo è stato supportato con un esempio concreto.

A questo punto, noi, gli utenti e io, facevamo il TDD completo. Casi di test foglio di calcolo per l'unittest del codice al codice di produzione. I responsabili IT stavano armeggiando con documenti di controllo delle modifiche e aggiornamenti delle specifiche. Tutta quella documentazione descriveva semplicemente i fogli di calcolo che contenevano i casi di test.

Una volta che la prima versione era in produzione, i requisiti della "Fase 2" erano interamente forniti come dati di test sui fogli di calcolo. 100% guidato dall'esempio. Nessun commento, nessuna nota, nessuna spiegazione di cui parlare. Si è tolto la strada e ha smesso di provare a scrivere le specifiche inglesi.

Concept - > Risultati attesi - > Codice

Questo è uno dei vantaggi di TDD. Non hai chiesto del refactoring, quindi salvo quella lunga e noiosa storia di guerra per la domanda di qualcun altro.