Come incoraggiare il cliente a svolgere alcuni test interni sul QA?

Aggiornamento / Chiarimento Il mio cliente comprende la necessità di eseguire i test interni e giura sempre che "farà di meglio" (ovvero che fa qualcosa) ma non succede. Non hanno il budget per i test esterni. Immagino di chiedere (vagamente, lo riconosco) cosa potrebbe instillare un "test precoce, testare spesso, test sull'etica delle macchine target?

Domanda: come incoraggiare gli utenti a dedicare del tempo a testare e segnalare esplicitamente problemi con le nuove versioni, non a "testare come vanno" nei progetti di produzione.

Background: ho un piccolo cliente per il quale ho scritto una suite di strumenti di presentazione multimediale. Sono un bel cliente e abbiamo un buon rapporto. Il progetto è in corso, aggiungendo funzionalità man mano che procediamo.

Ci sono due problemi che ho:

1. La definizione della funzione viene eseguita al volo, spesso al telefono, soggetta a modifiche, revisione, inversione. (un po 'come "Andremo sulla luna e faremo le altre cose" di Kennedy - Sono sempre stato divertito dalla parte delle "altre cose")

2. Praticamente non viene eseguito alcun test QA.

Posso occuparmi del numero 1, più o meno. Questo non è un client che vorrebbe anche leggere una specifica prima di una riunione, per non parlare di scriverne una. Ci sono abituato. È l'articolo n. 2 con cui ho il problema: non testano o non testeranno le nuove versioni. Quello che fanno è usarli per la produzione, quindi quando si presentano dei bug, trovano una soluzione alternativa e non lo segnalano, oppure hanno così fretta di andare avanti con il progetto, che le segnalazioni di bug sono vaghe.

Abbiamo discusso molte volte di tutto ciò, ma sono stato in grado di spingerli solo un po '(ad es. Usiamo github per il monitoraggio dei problemi, anche se principalmente lo uso). Le ragioni alla radice sono duplici: sono una piccola società di consulenza e non hanno (o non pensano di avere) le risorse per i test (né il budget per esternalizzarlo). E culturale: sebbene si considerino "sviluppatori", in realtà sono solo utenti di un pacchetto software multimediale. (ad es. non hanno nessuna nevrosi attenzione ai dettagli di sviluppatori "reali").

Questo mi influenza come ti aspetteresti: senza feedback non posso dire se una funzionalità è completa (vedi # 1) o se ci sono altre conseguenze. Mi rende anche un po 'pigro.

non hanno nessuna ossessiva attenzione alla nevrosi per i dettagli di sviluppatori "reali"

Prefazione : il tipo di linguaggio che hai usato qui è in genere una bandiera rossa per me. Quando sento che la gente parla di sviluppatori "reali" o del (solo e unico) modo "giusto" di fare le cose, inizio a pensare agli sviluppatori di cult-cargo con visione a tunnel .

Ora, non sto dicendo che sei sicuramente uno di questi sviluppatori (non ho prove sufficienti per affermarlo), ma se lo sei, potresti trarre beneficio da questa risposta.

Risposta

Sembra che tu e il tuo cliente stiate ottimizzando per cose diverse. È un fatto spiacevole nell'ingegneria del software che spesso le esigenze del business e i desideri degli sviluppatori non si allineano necessariamente.

Gli sviluppatori di software sono spesso persone appassionate che si concentrano sull'improvvisazione. A loro piace migliorare le prestazioni del software, il processo di sviluppo, i processi aziendali, i metodi di comunicazione, ecc. Ed è fantastico. Concentrarsi su queste cose è ciò che separa gli artigiani e le artigiane dai keypushers insensati.

Ma il tuo cliente non è un artigiano del software. Il tuo cliente è un'azienda con un insieme di priorità completamente diverso. E, a volte, quelle priorità sembrano ridicole per noi artigiani del software ... ma questo è solo perché stiamo ottimizzando per cose diverse.

Le aziende spesso desiderano ottimizzare soluzioni quali il rilascio anticipato sul mercato e risparmi sui costi a breve termine. Nel fare ciò potrebbero dover sacrificare cose come QA, User Experience, risparmi a lungo termine e altre cose che fanno battere gli sviluppatori.

È una brutta cosa? Bene, non necessariamente. Non posso parlare per tutte le aziende, ma nella mia esperienza i miei clienti fanno queste cose per aumentare il loro ROI (ritorno sull'investimento). Fare cose come QA, affinamento UX e pianificazione a lungo termine offre loro un ROI più basso. Ancora peggio, molte aziende hanno strutture di investimento che premiano solo le vincite a breve termine rispetto agli approcci sostenibili e alle vincite a lungo termine.

Così, mentre si potrebbe provare a vendere l'idea di QA per il vostro cliente si può sprecare il vostro tempo e tendendo il rapporto con loro. Nel migliore dei casi avrai qualcuno desideroso di provare le tue idee (improbabile). Nel peggiore dei casi dovrai convincere l'intera azienda a rielaborare le sue strutture di incentivazione in modo da premiare gli investimenti a lungo termine come il QA. In entrambi i casi, le probabilità di successo sono basse.

La domanda interessante è quando vieni pagato, non se il tuo cliente esegue dei test da solo.

• se vieni pagato in base al tuo tempo, nessun problema.
• se vieni pagato in anticipo, nessun problema.
• se vieni pagato quando il cliente dichiara il progetto "fatto", grosso problema.

Il problema è come puoi sapere quando il client accetta il software e ti pagherà. Ciò chiaramente non funziona quando il cliente modifica continuamente il progetto con nuove richieste vagamente definite. Se questo significa che il giorno di paga è sempre differito - e diventa più improbabile da ogni richiesta - questo diventa insostenibile per te.

Un contratto fisso che specifica attentamente tutte le funzionalità e definisce a quali condizioni il cliente accetterà queste funzionalità è chiaramente molto scomodo, ma consente di pianificare il progetto in anticipo (anche il progetto successivo). Garantisce inoltre che otterrai i tuoi soldi per il software consegnato, se all'altezza delle specifiche. In un tale scenario, l'unica responsabilità di un cliente è durante la fase di definizione del contratto e alla fine per i test di accettazione .

Tale test di accettazione eseguito da un cliente è separato da altre forme di test:

• test unitari
• test di integrazione del sistema
• test di usabilità
• prove di carico
• test pre-release

Per quanto possibile, dovresti anticipare i test di accettazione ed eseguirli tu stesso prima di fornire la funzionalità per evitare imbarazzi. A parte i test di accettazione (che misurano solo l' adempimento del contratto , non la qualità del software ), tutte le garanzie di qualità sono sotto la tua responsabilità. In particolare, il cliente non ha necessariamente una mentalità di QA, il background tecnico necessario o l'obbligo contrattuale di fare QA. Inoltre, trovo che la ricerca di bug in outsourcing per il cliente sia poco professionale.

Ciò non significa che i bug non si verifichino. Supponendo che tu abbia una relazione basata sul progetto con il tuo cliente, vorrai fare un passo tra l'essere cortesi e fornire rapidamente correzioni e spiegare che hanno accettato la versione corrente come sufficiente per le loro esigenze - grandi cambiamenti richiedono un nuovo contratto. Se hai un contratto di assistenza in corso, dovrai ovviamente attenerti al tuo livello di servizio concordato.

In un ambiente agile, rispondere alle esigenze del cliente è valutato più che attenersi alla lettera del contratto, ma ti consigliamo comunque di essere pagato. Pertanto, molte metodologie di progetto orientate all'agile valorizzano la stretta interazione con il cliente, al punto che il cliente potrebbe entrare a far parte del team. Puoi quindi sempre parlare con questo "proprietario del prodotto" per chiarire eventuali punti necessari. Poiché l'OP ha l'autorità di concederti il ​​tempo di lavorare su qualsiasi funzione che ritenga utile, questo può funzionare anche quando inizi con vaghe esigenze del cliente. Se non hai una comunicazione così stretta, dovrai seguire un approccio più formale.

• Quando venite a conoscenza delle nuove esigenze dei clienti, collaborate con il cliente per tradurle in requisiti. Questo aiuta il cliente a ottenere ciò che realmente desidera.
• I requisiti sono oggettivamente misurabili: sono soddisfatti o no. Ciò salva il cliente da mezze soluzioni che funzionano solo in modo analogo.

• Tutte le richieste dei clienti devono essere fornite in forma scritta in modo da poterle fatturare. Questo li protegge dalla fatturazione di cose su cui ti è venuta voglia di lavorare, come riscrivere l'intera interfaccia quando chiedi di allineare un pulsante in modo diverso.

  Molte comunicazioni possono essere fatte di persona o per telefono, ma alla fine vorrai un pezzo di carta per documentare che il cliente voleva che tu lavorassi su questi requisiti. In casi semplici, potrebbe essere sufficiente ricapitolare una telefonata e inviare loro un'e-mail per verificare cosa ti hanno chiesto di fare.

Le segnalazioni di bug sono sempre difficili. Se i tuoi clienti sono gli stessi sviluppatori che dovrebbero aiutarti poiché possono comprendere le tue esigenze: avere passaggi chiari per riprodurli. Un modo semplice per ottenere informazioni approfondite è abilitare la registrazione nel software distribuito. A condizione che i problemi di privacy dei dati possano essere risolti, richiedendo che ogni segnalazione di bug abbia il registro corrente allegato non solo garantisce una comunicazione scritta, ma ti dice anche cosa ha effettivamente fatto l'utente (al contrario di ciò che pensava di voler provare) .

Il modo per incoraggiare la comunicazione di bug è incoraggiare la comunicazione frequente e granulare delle funzionalità. Se formi una società che può chiedere qualsiasi cosa con zero cerimonie, userà quella funzione anche per bug minori. Smetti di cambiare il flusso di lavoro del tuo cliente a meno che questi cambiamenti non ne facilitino la vita.

Fare in modo che il tuo cliente esegua test interni è difficile, ma indurlo a segnalare i bug non è così difficile come sembra. Il modo per ottenere più feedback è ridurre l'attrito dell'utente ... anche se ciò significa trasferire un po 'di quell'attrito a te stesso.

1. Utilizzare strumenti più semplici, anche se tali strumenti sono inadeguati e inappropriati. Ad esempio, BaseCamp è un inseguitore di bug piuttosto terribile (perché è destinato alla gestione dei progetti), ma le persone sono effettivamente disposte a usarlo.

2. Dato che i tracker dei bug che stavamo usando non supportavano il copia-incolla dell'immagine, in realtà ho scritto un programma banale che copia l'immagine attuale degli appunti su disco (come guida), quindi copia la guida negli appunti. Dopo una formazione minima, un utente può allegare immagini degli appunti ai problemi semplicemente premendo la schermata di stampa, facendo clic su un pulsante e quindi incollando nella finestra di dialogo di selezione dei file dello strumento di invio dei bug.

Uno screenshot (eventualmente modificato in MS Paint con annotazioni) e 1-2 frasi è sufficiente per individuare la maggior parte delle funzionalità / bug.

Entrambi questi suggerimenti sono rivolti ai punti di attrito che ho riscontrato ed entrambi hanno aumentato il rapporto di un fattore superiore a 10. Tuttavia, dovrai indirizzare i tuoi punti di attrito.

Semplifica i test per il tuo client, ma rende davvero difficile per il tuo client utilizzare qualsiasi nuova funzionalità in una versione non testata in produzione. Questo può essere realizzato come segue:

Ogni volta che offri una nuova funzionalità, questa viene implementata per prima in una "versione beta", chiaramente contrassegnata con un segno "non destinato alla produzione". Questa versione beta viene messa a disposizione del client per il test. Fornisci anche l'ultima "versione di produzione" che utilizzerà per la produzione reale (senza le nuove funzionalità, ma con le ultime correzioni di bug) e rifiuti di trasferire le nuove funzionalità beta nella versione di produzione fino a quando non ricevi un feedback da parte di qualcuno il lato client ha almeno provato prima.

Se il client inizia a utilizzare la versione beta sui suoi dati di produzione reali sebbene mostri sempre un messaggio importante "Non per uso in produzione" ogni volta che avvia il programma, non puoi aiutarlo, ma almeno hai chiarito che ogni volta che perde la produzione funziona perché ha usato la beta per scopi sbagliati che è chiaramente colpa sua. Se il client non impara da ciò, potresti considerare di disabilitare la capacità del tuo client di utilizzare la "beta" in produzione disattivando alcune funzioni cruciali come il salvataggio dei risultati su disco nella "beta", se necessario.

Fornire una "beta" separata ti costringerà a stabilire il controllo della versione / la gestione della configurazione corretti, in modo da poter gestire un ramo di produzione e un ramo di test beta fianco a fianco senza problemi. Ma dal momento che stai lavorando con Github, suppongo che tu usi già qualcosa come GIT, il che rende questo tipo di gestione molto semplice.