Come posso giustificare la gestione dei test del software?

Credo che dovresti convincere il tuo management non usando i numeri, ma spiegando il razionale.

Joel Spolsky fa alcuni punti molto intelligenti sui vantaggi dei testimoni assoldanti nel suo articolo Top Five (Wrong) Motivi che non si fa " t Hanno tester , che possono aiutare a convincere la gestione.

Anche qui :

If your team doesn't have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers. Skimping on testers is such an outrageous false economy that I'm simply blown away that more people don't recognize it.

Altre perle di saggezza qui :

There is no better way to improve a programmer’s morale, happiness, and subjective sense of well-being than to have dedicated testers who get frequent releases from the developers, try them out, and give negative and positive feedback. Otherwise it’s depressing to be a programmer. Here I am, typing away, writing all this awesome code, and nobody cares. Boo hoo.

Non perdere tempo con il crunch del numero. Non è irresistibile. Tutti contestano i dettagli.

Invece, concentrati su scenari di rischio specifici.

Test scadente (o no) == errore nella produzione == perdita di entrate (o peggio). Segui questa linea di ragionamento con le specifiche perdite che possono derivare da errori del software.

Sii dettagliato e concentrato in modo che la logica della "perdita derivante da software scadente provenga da test non corretti" sia inevitabile.

Quello che succede è - ovviamente - concentrarsi sugli scenari di rischio specifici. Ma è meglio di niente.

Le storie molto specifiche sono più facili da usare rispetto agli studi generali e ai numeri riassunti. È ancora meglio quando puoi collegare eventi storici, specifici clienti o prodotti o altri dettagli fattuali allo scenario di rischio.

"Ricorda quando abbiamo impiegato 18 ore a provare a sistemare il software [X]? Quanto fatturato abbiamo perso dagli ordini annullati e le chiamate all'help desk?"

Se non esegui un test sufficiente, perdi profitti da pagare per riparare software buggy sul campo. Se testate molto e consegnate in ritardo, perdete profitti perché il software è stato consegnato in ritardo.

Dal punto di vista di un business leader, il primo è solitamente preferibile perché il software consegnato viene effettivamente utilizzato, probabilmente è stato pagato, ed è quindi più facile giustificare le spese di bug fixing dopo che è stato distribuito e pagato.

Se si desidera test migliori, è necessario mostrare in che modo i test aiuteranno il business leader a commercializzare il software più rapidamente, entro lo stesso budget. In un progetto software di grandi dimensioni, il time-to-market viene potenziato quando la copertura del test è buona nei livelli più bassi del sistema (ad es. Sistema operativo, livello dati) perché ciò significa che gli sviluppatori che lo sviluppano non devono risolvere i loro bug e gli errori di livello inferiore. Aiuta anche a garantire una buona verifica dei percorsi di successo dei casi d'uso chiave.

Potresti considerare di esternalizzare alcuni test in un negozio in India o in Vietnam. Fanno un buon lavoro, e il loro carico di lavoro è molto inferiore a quello del Nord America. E testeranno mentre dormi.

Sembra che tu abbia un primo passo critico:

As anyone who has done any meaningful tests knows, testing takes a lot of time - and at my company, it takes too much time to justify to management, so we generally do what little we do on the sly. I don't think this is serving us well, as we keep coming up against otherwise avoidable problems when we ship under-tested software.

Sembra che tu abbia bisogno di fare il business case per testare e incorporare il programma prima di fare qualsiasi altra cosa.

Ecco come ho fatto qualcosa di simile:

1. I progetti utilizzavano test classici Big Bang . Ci sono molte risorse che dimostrano che questo metodo è il meno affidabile, il più costoso e (quindi) molto probabilmente tagliato ai fini del "risparmio".

2. Per "nascondere" i test all'interno del progetto (anziché alla fine), mi dedicavo ogni quattro settimane a testare e pianificare. Ciò significa che nessuno sviluppatore è mai stato più di tre settimane da qualcosa a cui stavano lavorando. Significava anche che ogni attività è stata testata più di zero.

3. Poi ho presentato il caso aziendale ai project manager. La mia giustificazione è che (a) le persone devono testare solo per sapere se hanno effettivamente finito il loro compito e (b) con i primi test, potrei facilmente richiedere un risparmio netto di almeno il 50% di risparmio.

L'ultimo punto è stato un po 'drammatico per alcune persone. Considerando che le correzioni dei bug post-release sono considerate almeno dieci volte più costose per trovare e correggere, è stato un argomento abbastanza facile da vincere.

The four of us have been making strides in transitioning to better practices, and one of the next logical steps is to improve our testing.

Sono d'accordo ma non sono d'accordo sul fatto che il primo passo sia assumere. Stai parlando di un aumento del budget salariale del tuo gruppo del 20% senza prima dimostrare il ritorno sull'investimento. Investire nelle capacità di test e nelle risorse delle persone che hai ora. Dimostrare il valore del test come pratica di sviluppo di base. Quindi inizia a lavorare sul business case per una nuova assunzione quando hai la cronologia per il backup.