Suggerimenti per il bilanciamento tra Dogfood e QA? [chiuso]

Question

La maggior parte degli sviluppatori è a conoscenza dell'idea di mangiare il proprio cibo per cani, ma allo stesso tempo ha dimostrato matematicamente che è più economico avere personale addetto al controllo qualità (o tester) che esegue il controllo qualità rispetto al fatto che gli sviluppatori eseguano il controllo qualità.

Ora, ovviamente, non ha senso essere estremisti in entrambe le direzioni, ma ho notato che a seconda del progetto e dello sviluppatore (o del personale addetto al QA o del manager) il bilancio oscilla in un modo o nell'altro, ma io ' Sono curioso di sapere quali sarebbero alcune buone regole pratiche da applicare quando si determina la quantità di QA da fare in ciascun campo.

Aggiornamento: sebbene non matematicamente in ogni caso, l'articolo di Joel Il QA dovrebbe essere abbastanza chiaro, in realtà ha anche uno dei dogfood : )

Answer 1

Sono quasi d'accordo con la risposta di Garry - tranne che sostiene che non si tratta di migliorare la qualità del codice. Penso che assolutamente sia a che fare con ciò, così come l'usabilità che menziona nel suo primo paragrafo.

Se puoi avere un ampio cibo per cani, otterrai:

• È probabile che vengano utilizzati dati più realistici rispetto al QA (dato che si tratta di dati reali!)
• È probabile che venga utilizzato un intervallo più ampio di dati rispetto al QA, per pura forza di numeri

Ho sicuramente corretto un sacco di bug trovati nel cibo per cani molte volte, in cui la situazione non era stata testata dal QA. In molte situazioni non puoi testare tutte le possibilità, ma il cibo per cani aiuta a testare più .

Porta quante più persone possibile al cibo per cani (avendo impostato aspettative adeguate su potenziali problemi, ovviamente). Certamente non dovrebbe essere un & Quot; solo per sviluppatori & Quot; cosa (a meno che tu non stia costruendo un prodotto per soli sviluppatori, ovviamente). Questo non toglie il prezioso lavoro di QA - si aggiunge ad esso.

Dipende in modo massiccio da ciò che stai sviluppando. Sono stato in un'azienda in cui i dipendenti non avrebbero mai avuto motivo di utilizzare il prodotto nella vita di tutti i giorni, quindi il cibo per cani non era davvero fattibile. In un'altra società stavamo costruendo un proxy Web, quindi era logico far sì che un grosso pezzo della società sfogli il proxy. Di recente ho lavorato su un prodotto di sincronizzazione rivolto ai consumatori, quindi ha di nuovo senso ampiamente il cibo per cani.

Answer 2

Il cibo per cani non riguarda affatto il QA. Si tratta di utilizzare il prodotto che si sta sviluppando in modo da poter vedere dove le cose potrebbero essere migliorate nel flusso di lavoro e in generale sentire i punti dolenti dell'utilizzo del software.

Non si tratta di migliorare la qualità del codice, si tratta di semplificare l'utilizzo del software e guidarti nelle scelte di sviluppo delle funzionalità.

Answer 3

Formale contro informale

L'uso del proprio prodotto (" mangiare il cibo del proprio cane ") fa parte dell'assicurazione della qualità e lo metterei nella categoria dei test informali rispetto ai test più formali di solito effettuati da un dipartimento di controllo qualità separato .

Profondità vs. Larghezza

& # 8220; Mangia il tuo cane & # 8217; s cibo & # 8221; mira a offrire un'esperienza diretta di utilizzo di un prodotto o servizio a persone direttamente responsabili della sua progettazione e sviluppo. Per un'applicazione ricca di funzionalità potrebbe andare più in profondità dei test formali e allo stesso tempo mettere una prospettiva specifica per l'utente, quando i test formali normalmente coprono l'ampiezza dei casi d'uso del software e cercano di operare in termini più obiettivi e misurabili.

Piccoli fastidi che fanno la differenza

Esiste anche una categoria di carenze molto specifiche di un ambiente che può essere diagnosticata solo & # 8220; nel campo & # 8221; (come questo suono sibilante davvero fastidioso che sembra provenire dal nulla ogni volta che & # 8217; stai girando a 72,52 miglia all'ora e ti fa impazzire assolutamente, ma nessuno dei meccanici è in grado, né disposto a scendere alla causa quando l'auto è al garage).

Software nudo vs. Applicazione + Set di pratiche

L'uso del proprio prodotto va ben oltre il software stesso; comprende inevitabilmente l'intero & # 8220; viaggio dell'utente & # 8221 ;. & # 8220; Mangiare il cibo per cani & # 8221; consente di sviluppare e comprendere meglio le tecniche di utilizzo del software all'interno di un dominio. È corretto affermare che alcuni software vengono utilizzati in numerosi contesti ampiamente diversi. I test formali potrebbero non essere in grado di coprire in profondità ciascuno di questi contesti, semplicemente perché potrebbe essere difficile definire formalmente quali test specifici è necessario eseguire una volta che qualcosa è cambiato. Oppure potrebbe essere troppo costoso imitare questi contesti internamente o passare attraverso tutti i casi di test noti ogni volta che il software è leggermente cambiato.

Modifica interna rispetto a esterna

I test formali sono davvero efficaci nel verificare che le modifiche apportate al software funzionino, ma l'altra importante area di evoluzione in cui i test formali sono in difficoltà è quando è necessario rilevare i cambiamenti nell'ambiente software o i modelli di utilizzo che provengono dal mondo esterno. L'uso del tuo prodotto ti aiuterà a rilevare queste modifiche molto prima, probabilmente prima che gli utenti ti comunichino (a seconda della qualità del canale di feedback degli utenti).

Cosa c'è di sbagliato in " il saldo " ;?

In quanto tale non vi è alcun equilibrio tra l'utilizzo del proprio prodotto e il test formale (fare entrambe le cose per quanto possibile, vale a dire restituire & # 8217; ottenere il valore vale lo sforzo). Uno è complimentarsi con un altro, non servire come sostituto.

Chi dovrebbe fare i test: la distinzione

Questo a meno che non ci siano risorse dedicate per eseguire i test formali (unico sviluppatore, sviluppatori che fanno tutti i test) e devi selezionare quanto tempo puoi dedicare a una delle due attività. Bene, don & # 8217; t. Una distinzione importante qui è che i test formali vengono eseguiti meglio da un'autorità indipendente, vale a dire persone che non riferiscono al team di sviluppo e progettazione. D'altra parte tutti (designer, sviluppatori, esperti di marketing e persino CEO) dovrebbero usare il più possibile prodotti o servizi dell'azienda, perché l'idea alla base di & # 8220; dogfooding & # 8221; è offrire a tutti i soggetti coinvolti l'esperienza diretta del servizio o del prodotto a cui contribuiscono in un contesto di vita reale.

Non puoi Dogfood Tutto! O puoi?

Per quanto riguarda & # 8220; puoi & # 8217; t dogfood determinati tipi di software & # 8221; l'argomento va bene, non concentriamoci su come appare il cibo per cani: mangiare il cibo del tuo cane, ma piuttosto pensa invecedi cosa significa: ottenere un'esperienza di prima mano e & # 8220; allineare gli interessi & # 8221; con questi degli utenti reali.

La prossima cosa migliore per mangiare da soli il cibo è osservare il cane mentre mangia il cibo, invece di fare affidamento su qualcun altro che ti dice ciò che il tuo cane, presumibilmente, piace o non piace.

Mentre i membri del team di sviluppo potrebbero non essere in grado di utilizzare personalmente il software di controllo delle acque reflue da utilizzare nelle loro attività quotidiane, nulla impedisce loro di passare un po 'di tempo ad osservare regolarmente un ingegnere delle acque reflue utilizzando l'app, che non segue! la lettera di & # 8220; cibo per cani & # 8221 ;, ma certamente cattura lo spirito.

Answer 4

Sono completamente d'accordo con la risposta di Jon & # 8217; con l'addendum che il test del cibo per cani è importante anche per il controllo qualità, e spesso non è fatto! Più di una volta ho & # 8217; ho iniziato a utilizzare un prodotto che altre parti del QA (a volte anche io & # 8212; ouch) hanno presumibilmente terminato i test e ho trovato bug inconcepibili nell'uso normale. A volte questo, come osserva l'articolo di Joel on Software, è solo uno scarso test; è sorprendentemente comune che il primo esempio in un tutorial fallisca (ad es. Deja Gnu). Ma più spesso & # 8217; s perché il cibo per cani è un processo molto diverso dai test sistematici: & # 8217; non stai facendo ciò che & # 8217; ti viene detto di fare, & # 8217; stai facendo quello che fai quando & # 8217; non non cercando di trovare dei bug.

Un piano di test molto, molto buono potrebbe coprire alcuni di questi casi, ma nell'esempio più imbarazzante nella mia azienda, il piano di test faceva parte del problema: un'opzione cospicua, che la maggior parte degli sviluppatori hard-core sarebbe certa bisogno, era ufficialmente non supportato, e quindi non testato, ma necessario comunque. Suppongo che una definizione di requisiti funzionali più ragionevoli non avrebbe commesso questo errore; se conosci aziende di cui FRD & # 8217; s sono sempre del tutto ragionevoli e che stanno assumendo, fammi sapere :-)

Answer 5

Esistono due ruoli comunemente descritti come " QA " ;.

• Garanzia di qualità: persone che assicurano che il piano di qualità sia in esecuzione.

• Tester: sviluppatori che non codificano.

Se la tua domanda era focalizzata su " assicurare che il piano di qualità fosse in esecuzione " ;, allora è facile: gli sviluppatori fanno che soddisfano il piano di qualità e il QA verifica che sia stato seguito il piano di qualità.

Dal momento che la tua domanda è focalizzata su " sviluppatori che non codificano " ;, allora non hai molto piano di qualità in primo luogo. In questo caso, gli sviluppatori devono (1) integrare i tester nei loro ranghi, (2) creare un piano di qualità e (3) lavorare secondo quel piano.

Il piano potrebbe comportare alcuni test indipendenti. Questo può essere fatto facendo test di scrittura dello sviluppatore A per lo sviluppatore B. Può anche essere fatto facendo test di scrittura dello sviluppatore A ed esaminando i peer quei test prima di iniziare la codifica.

L'idea è che gli sviluppatori scrivano, controllino e testino il proprio codice. Un'organizzazione di sviluppo. Tutti codificano, alcuni più di altri.

Il QA si assicura che gli sviluppatori lo stiano davvero facendo in modo coerente e completo.

Non vedo " sviluppatori che non codificano " come lavoro praticabile. Questi sono davvero sviluppatori di livello junior. Puoi sfruttarli per far crescere alcune abilità tecniche aggiuntive; o sperperarli in una posizione in cui trascorrono un bel po 'di tempo a essere picchiati dagli utenti e litigare con gli sviluppatori.

Un modo per sfruttare " sviluppatori che non codificano " è iniziarli a scrivere i test; quindi usali per correggere il codice non funzionante; quindi codice dal design di qualcun altro; quindi fai il lavoro di progettazione da solo.

Esistono molti modi per scoraggiare questi " sviluppatori che non codificano " ;. Uno è lasciarli indovinare cosa intendevano gli utenti. Fallo restringendo la loro conoscenza del processo a ciò che trovano nei documenti di analisi aziendale. Un altro è metterli in una posizione in cui devono discutere con gli sviluppatori sull'interpretazione dei documenti di analisi commerciale.

Answer 6

Sono sicuro che puoi trovare un'equazione sul risparmio sui costi, ma sarebbe un punto nel tempo. Gli sviluppatori dovrebbero sempre "mangiare il proprio cibo per cani" quando possibile (perché uno sviluppatore dovrebbe creare un IDE per gli altri e non usarlo da soli ???) - ma dovrebbero sempre essere coinvolti in una certa misura nelle attività di QA di base. Sono stato in molte aziende in cui gli sviluppatori lanciano codice oltre il muro (la "sindrome dell'ho merda d'oro") - causando il test ciclo dopo ciclo di codice errato, non riparato completamente e testato di nuovo.

Il manager dovrebbe determinare il livello di test che ogni gruppo esegue e modificare / sintonizzare nel tempo e specifico per ogni persona coinvolta. Il peggio è il codice che viene consegnato, più tempo sarà necessario testare (TDD) con la capacità di migliorare lo sviluppatore.

Answer 7

Generalmente DogFooding non è così utile, a meno che tu non stia sviluppando strumenti di sviluppo che anche tu come sviluppatori devi usare.

Dove lavoro, utilizziamo il nostro prodotto, ma non così ampiamente come fanno i nostri clienti. Dal momento che i nostri clienti non sono impegnati nello sviluppo di software.

Answer 8

Il cibo per cani è una buona soluzione se stai costruendo qualcosa che è utilizzabile dal tuo personale su base giornaliera, ma sfortunatamente non credo sia fattibile per ogni applicazione. Se stai scrivendo un client di messaggistica istantanea, il cibo per cani è facile. Se scrivi sistemi di controllo per un impianto di trattamento delle acque reflue, allora forse no.

Il QA riguarda il controllo di qualità professionale per il tuo software. Penso che la decisione se ne hai bisogno o meno dipende interamente dal sistema in esame in termini di complessità e costo del fallimento. Esiste un'analogia (possibilmente semplificata) della produzione. Potrei comprare una matita che non ha superato un dipartimento di controllo qualità, ma sicuramente non comprerò un biglietto su un aereo che non lo ha fatto.