Come posso iniziare i test in una campagna di test? [chiuso]

L'ho fatto personalmente con notevole successo. I fattori chiave per il successo:

• Ottieni supporto (provvisorio) per la gestione. I vantaggi dei test automatici sono ben documentati e dovrebbero convincere qualsiasi manager almeno a provarlo. Ciò include trovare un punto nel VCS e un server di build, perché
• I test automatici forniscono il loro valore completo solo se vengono eseguiti frequentemente e automaticamente in modo da essere presto informati sui problemi e non devono fare affidamento su persone che non dimenticano di eseguirli. È necessario un server di build che li esegua almeno giornalmente. Questa può essere una vecchia workstation. Jenkins impiega pochissimo lavoro per funzionare.
• Guida con l'esempio. Scrivi test, parla del vantaggio che ti stanno offrendo e quando rivelano errori introdotti da altri sviluppatori ne parli in termini di protezione da un potenziale imbarazzo maggiore.
• Vai per il frutto a bassa attaccatura. Alcune parti dell'applicazione saranno difficili da testare, altre facili. Alcuni saranno robusti, altri fragili. La scrittura di test per parti fragili, ma facili da testare fornisce il massimo valore nel minor tempo possibile.
• Verifica se riesci a scrivere test riutilizzabili, ad es. convenzioni o caratteristiche di test che tutti i moduli (pagine web, servizi REST, qualunque) devono avere ma che vengono spesso dimenticati.

Senza supporto gestionale sei morto nell'acqua. Il management affermerà che non stai facendo un lavoro utile, verrai penalizzato nelle tue recensioni e alla fine verrai licenziato. Ci sono modi per portare il management a vedere che i primi test costano meno e tutto il resto. È possibile cambiare la cultura ma stai mettendo il tuo collo sul ceppo.

Suggerirei di leggere Machiavelli The Prince su come introdurre il cambiamento prima di fare qualsiasi cosa.

Nella mia esperienza, se la cultura è anti-test, non puoi introdurla ragionevolmente. O i test saranno considerati una perdita di tempo e verrai rimproverato per "perdere tempo" o "impiegare troppo tempo", o il codice è tormentato da anni di non essere scritto in modo verificabile (ad esempio, nessuna interfaccia, tutto strettamente accoppiato) e dovrai dedicare molto tempo al refactoring e / o riscrittura del codice (correndo così il rischio di "impiegare troppo tempo" e "perdere tempo") per renderlo testabile in modo da poter scrivere test in primo luogo .

Potresti avere una possibilità se stai facendo cose di tipo greenfield che devono solo interagire con cose esistenti (creare un bel wrapper attorno alle aree danneggiate) o se puoi farlo in piccole quantità dove non causerà problemi o richiede di "lavorare su compiti che non ti sono stati assegnati" che possono metterti nella cuccia.

Non penso che riuscirai ad andare molto lontano fino a quando non sarai in grado di dimostrare che c'è un problema (che potrebbe non essere attualmente riconosciuto) che i test automatizzati possono affrontare.

Se esiste una cultura del test manuale rispetto agli script definiti, esiste un costo per l'esecuzione di tali script insieme al rischio di risultati incompleti o inaccurati. Potrebbe esserci una storia (documentata o in forma di "racconto di guerra") di questo. Suggerisci un progetto pilota per automatizzare alcuni di questi test manuali al fine di ottenere un risparmio a lungo termine.

Se non c'è nemmeno una funzione di test manuale, suggerirei che l'azienda non percepisce alcun tipo di test formale, automatizzato o meno, che abbia valore. In tal caso, considererei la strada da percorrere lunga e in salita, ma di nuovo è probabile che sia necessario dimostrare chiaramente che l'azienda può trarre vantaggio dall'adozione di un approccio meno casual alla qualità del software. Se non puoi farlo, è difficile vedere come possa esserci un supporto per l'idea per motivi commerciali.

Un'idea è che il tuo obiettivo è scrivere un test che dimostri che il codice scritto da qualcun altro è difettoso. Dovrebbe vendere il concetto.