Test nella vita di un programmatore

Perché i programmatori hanno bisogno di test?

I prossimi due livelli saranno dedicati ai test nel modo in cui i programmatori ne hanno bisogno . Ma prima, scopriamo cos'è il test e perché è necessario.

Per quanto riguarda il software, possiamo dire che il compito del test è verificare che il programma:

• fa quello che deve fare
• non fa quello che non dovrebbe fare

Il secondo punto, a proposito, non è meno importante del primo, ma ne parleremo più avanti.

Partiamo dal primo punto. Cosa significa "il programma fa quello che deve fare"?

Innanzitutto, qualcuno deve fare un elenco di tutti i casi d'uso per il programma. In secondo luogo, devono descrivere come dovrebbe funzionare il programma, come dovrebbe comportarsi l'utente e quali risultati sono attesi. Non puoi continuare oltre.

Non appena abbiamo scritto "come dovrebbe comportarsi l'utente", l'intera idea di scrivere una buona documentazione è crollata. Le persone non sono macchine, inoltre, le persone molto spesso si comportano con il software a loro piacimento . Nessuno inizia a conoscere la tecnologia studiando le istruzioni. È un fatto.

Pertanto, otteniamo un fatto nuovo: la particolarità del software è che ha molti scenari di lavoro diversi. Alcuni di essi sono ovvi, altri possono essere documentati, altri possono essere assunti, altri possono essere indovinati e l'altro 50% non ti verrà nemmeno in mente.

Dal punto di vista di un programmatore, la maggior parte dei bug non sono affatto bug. Un errore è quando un programma non funziona come dovrebbe o come previsto. E ci sono molte situazioni in cui non è chiaro come dovrebbe funzionare il programma o scenari che si contraddicono a vicenda ...

Esiste un numero infinito di scenari e ci saranno sempre casi nel prodotto in cui il programma non si comporta come previsto (il programmatore ha scritto il codice solo per un paio di dozzine di scenari). Pertanto, si può sostenere che ci sono sempre bug in qualsiasi programma e qualsiasi prodotto può essere migliorato all'infinito .

Dopodiché, tutto si riduce all'opportunità. Innanzitutto, il programmatore corregge i bug più grandi, poi i bug più piccoli e così via. E infine, arriva una fase in cui il proprietario del prodotto ritiene che non sia economicamente fattibile continuare a lavorarci.

Ma torniamo agli errori che tutti riconoscono come errori: il programma ovviamente fa qualcosa di sbagliato, è caduto, ha rotto qualcosa, ecc. Tali errori possono essere suddivisi condizionatamente in 3 categorie: grandi, medi e piccoli.

E molto spesso capita che un programmatore stia lavorando per correggere bug medi o anche piccoli, sebbene ci siano ancora molti problemi più seri nel progetto. Semplicemente non li ha trovati , quindi sta lavorando su quelli più grandi che conosce.

Pertanto, in qualsiasi progetto dovrebbero esserci tester. Queste persone imparano specificamente a guardare il prodotto da diverse angolazioni. Quindi puoi vedere più scenari del programma. Il loro compito è trovare gli errori e annotarli (in modo da non ritrovare lo stesso errore più volte).

Il test è un processo volto a trovare errori. Questi bug dovrebbero essere trovati, descritti e ordinati in ordine di priorità. Solo dopo la prioritizzazione degli errori si può parlare di un efficace processo di miglioramento del software.

Ricorda, il primo passo per risolvere un problema è riconoscere che c'è un problema . Non puoi correggere un errore che non conosci.

Test di automazione

Penso che siamo tutti d'accordo sul fatto che i test siano importanti, quindi diamo un'occhiata ai test come ai programmatori. Come vedono i programmatori i test? I programmatori automatizzano il lavoro di altre persone. L'ultima professione a scomparire sarà la professione di programmatore.

Automatizziamo tutti i processi che incontriamo. Quindi i test devono essere automatizzati. E come automatizzare la ricerca degli errori? Risposta breve: no. Ma anche qui ci viene in aiuto il fatto che siamo programmatori.

Il processo di sviluppo del software consiste in continue modifiche ad esso. proprio nel processo di apportare costantemente modifiche, i programmatori molto spesso rompono qualcosa che ha funzionato bene fino a poco tempo fa.

E i tester, invece di cercare nuovi errori, sono costretti a verificare costantemente se abbiamo rotto qualcosa che funziona bene da molto tempo. Il cosiddetto test di regressione. È questo tipo di test che può e deve essere automatizzato.

Qui tutto il software può essere diviso in due parti:

• il programma interagisce con la persona
• programma interagisce con un altro programma

La prima opzione è più difficile da automatizzare, richiede speciali tester di automazione, sono anche chiamati QA Automation o Software Test Engineer.

Ma la seconda opzione può e deve essere automatizzata in modo indipendente. Se hai un software che:

• funziona bene
• già testato
• implementato come modulo separato o blocco logico
• non ha intenzione di cambiare
• altri moduli o programmi dipendono da esso
• il fallimento funzionale è costoso

Consiglio di dedicare del tempo a scrivere test che catturino gli aspetti chiave della sua attuale funzionalità. Sarebbe ragionevole allocare il 5% del tuo orario di lavoro per questo , o 1 giorno al mese.

Non è necessario scrivere test per motivi di test.

Nessuno sosterrà i tuoi test. Non altri programmatori, non te stesso. Nessuno lo fa. Il 99% di tutte le prove scritte viene abbandonato e/o disabilitato. Se non puoi scrivere test, non scrivere. Scrivi solo se non puoi assolutamente farne a meno.

Tipi di test

Ogni programmatore, se non ha seguito una formazione specifica, potrà dire con parole sue cos'è il testing: controllare se il programma fa quello che dovrebbe. Tuttavia, i professionisti in questo campo distinguono intere aree (tipi) di test.

Tutti i test ruotano davvero attorno all'affidabilità e alla disponibilità del software, ma per comprendere meglio la direzione del test, diamo un'occhiata ad alcuni esempi.

Diciamo che stai testando un tipico negozio online. Quindi le aree di test possono essere suddivise nelle seguenti tipologie: test delle prestazioni, test funzionali, test di integrazione e unit test.

Se il proprietario del sito decide di lanciare una seria campagna pubblicitaria, molti utenti verranno sul sito contemporaneamente. Può darsi che il sito non cada, ma alcune delle sue sezioni potrebbero essere lente o addirittura smettere di funzionare.

Per evitare che ciò accada, è necessario identificare tali problemi in anticipo e adottare misure per eliminarli. Questo viene fatto utilizzando il test di carico o è anche chiamato test delle prestazioni.

Potresti anche voler testare come funziona la tua API di back-end e testarne ogni funzione: registrazione, accesso, aggiunta al carrello, elaborazione dei pagamenti, scritture del database, ecc. Tutto dovrebbe funzionare secondo il TOR. In questo caso, è necessario eseguire test funzionali .

Il tuo negozio online è molto probabilmente integrato con servizi di terze parti: invio di lettere e SMS, sistemi di pagamento, chat di supporto online, raccolta di feedback dagli utenti, sistemi pubblicitari, ecc. Per assicurarti che tutto funzioni come previsto, devi eseguire test di integrazione .

Infine, i prodotti complessi sono spesso suddivisi in moduli indipendenti. Da tali moduli è possibile assemblare il prodotto finale, come da un costruttore. Se stai sviluppando un modulo di questo tipo o interagendo con tali moduli, dovrai eseguire unit test .

Riassumendo, possiamo dire che il test funzionale è necessario per testare ogni singola funzione del sito. Integrazione - per testare l'interazione di grandi moduli e sistemi del tuo prodotto. Modulare - per testare un modulo separato, beh, test delle prestazioni - per verificare il funzionamento del tuo sito sotto carico.

Possono esserci ancora più tipi di test: più complesso è il prodotto, più aspetti del suo sviluppo devono essere controllati.