Test del software per lo sviluppatore [chiuso]

Un libro che mi è stato consigliato e su cui ho fatto affidamento come tester del software professionale è Testing Computer Software di Kaner, Falk e Nguyen. Gli argomenti includono il fatto che non puoi semplicemente testare tutto, come segnalare e analizzare i bug (più utile per un team più grande o quando si tratta di segnalazioni di bug da parte dei clienti), classi di equivalenza e valori limite, localizzazione, manuali utente, conseguenze legali, e gestione. Quindi copre una vasta gamma di aree rilevanti per i test, e introduce e definisce la terminologia chiave. Se trascorri molto tempo a testare o addirittura a lavorare con i tester, ti consiglio questo libro.

L'abilità più utile che abbia mai incontrato in uno sviluppatore / tester è la capacità di "dimenticare" tutte le ipotesi su come l'utente dovrebbe utilizzare il software. Non dirò "stupido", perché i tester devono essere molto intelligenti riguardo al loro lavoro, ma uno sviluppatore che testa il proprio lavoro deve abbandonare qualsiasi nozione preconcetta su come immagina l'utente interagire con esso.

Ad esempio, conosco un tester la cui prima azione quando si apre una sorta di schermata di "manutenzione dei record" è quella di colpire immediatamente "salva". Il tuo sviluppatore medio potrebbe pensare che il comportamento sia così ridicolo da non creare un controllo degli errori appropriato per un caso in cui NULLA è stato specificato dall'utente. Il test di navigazione è un altro punto debole, soprattutto nelle app Web; il tuo sito web reagisce correttamente al pulsante "Indietro"? Molti, infatti, non lo fanno, soprattutto se si basano molto su ViewState e sui postback.

Un buon tester si rende conto che nulla può essere assunto per il comportamento dell'utente finale. Questi sono i tester che gli sviluppatori odiano, perché torneranno con un caso limite che è un dolore e due terzi da coprire. Ma sono anche i tester che ti aiutano a produrre software affidabile e affidabile. Dopo un po 'di tempo, tu come sviluppatore, sottoponendo i candidati al rilascio a un tester come questo, inizierai ad adottare la stessa mentalità, scrivendo test automatici per casi limite e incorporando azioni utente "stupide" nell'interfaccia utente manuale e in end-to -end test.

Una cosa; TDD non è quasi mai "non applicabile"; l'unica volta in cui non devi fare qualcosa a TDD è quando non c'è un framework di test adatto per te da utilizzare, e questo sarebbe solo un valido motivo per un set molto ristretto di linguaggi "legacy" o "specialistici".

Per prima cosa, per evitare errori "stupidi", puoi generalmente utilizzare strumenti di analisi statica. Ciò ti aiuterà a cogliere le cose come non riuscire a soddisfare convinzioni di codifica, possibili dereferenze nulle, ecc. Direi che è una prima linea di difesa per scrivere software di qualità.

La tua seconda linea di difesa sono i tuoi test unitari, che forniscono un rapido riscontro sul fatto che il tuo codice fa quello che dovrebbe e continua a farlo quando viene cambiato.

Da lì, hai il concetto di test di integrazione / comportamento che verifica se il codice soddisfa effettivamente le tue esigenze. Questi saranno i tuoi "test del fumo" che eserciteranno la tua applicazione in uno stato più integrato. Non posso sottovalutare che credo che tu debba automatizzarli. Firmare un'applicazione e fare clic in modo casuale per far sì che le cose si rompano (ad esempio un "bug bash") non è un uso produttivo del tempo di uno sviluppatore esperto, secondo me. Puoi sempre automatizzare (questo è ciò che facciamo per vivere). Ci sono strumenti di esercitazione GUI se necessario: puoi testare tutti i livelli sotto la GUI. Puoi eseguire test di caricamento, puoi eseguire test a lungo termine, puoi randomizzare cose e registrare i passaggi di esecuzione, ecc.

Quindi, alla fine, direi che l'abilità di test del software di cui hai bisogno è come automatizzare i test delle parti integrate del tuo codice e come interpretare i risultati di tale automazione. Questo tipo di prove ripetibili e documentabili sarà molto più prezioso per te di "cercare di romperlo" (non che questa sia una cosa brutta da fare - semplicemente non ottimale per uno sviluppatore).