test coverage software testing
Guida completa alla copertura del test di test del software: Come testare di più, risparmiare tempo e ottenere risultati di test migliori:
Il test del software è un'attività essenziale nello sviluppo del software e nei cicli di vita della manutenzione. È una pratica spesso utilizzata per decidere e migliorare la qualità del software.
Lo sviluppo è più sistematico al giorno d'oggi e le organizzazioni cercano misure di completezza ed efficacia dei test per mostrare i criteri di completamento dei test. Di tutti, la copertura è considerata particolarmente preziosa.
Cosa imparerai:
- Cos'è la copertura del test?
- Copertura del test e copertura del codice
- La mia esperienza
- Testare il significato della copertura
- Come adottare un corretto metodo di copertura del test?
- Come assicurarsi che tutto sia testato?
- Aree critiche e metodi per test efficaci
- Vantaggi della consapevolezza della copertura dei test per un tester:
- Conclusione
- Lettura consigliata
Cos'è la copertura del test?
In poche parole, la copertura è 'Cosa stiamo testando e quanto stiamo testando?'
La copertura dei test aiuta a monitorare la qualità dei test e aiuta i tester a creare test che coprono aree mancanti o non convalidate.
La maggior parte dei team basa i propri calcoli sulla copertura solo sui requisiti funzionali. È anche giusto perché prima di tutto un'applicazione dovrebbe fare quello che dovrebbe fare. In caso contrario, la sua velocità, sicurezza o facilità d'uso non ha importanza.
Tuttavia, se dedicato e indipendente test non funzionali i team stanno lavorando su prestazioni, sicurezza, test di usabilità, ecc., quindi dovranno tenere traccia dei loro requisiti fino all'esecuzione attraverso l'analisi della copertura dei test.
Copertura del test e copertura del codice
La copertura dei test viene spesso confusa con la copertura del codice. Anche se i principi di base sono gli stessi, sono due cose diverse.
Copertura del codice parla davvero di pratiche di unit test che devono indirizzare tutte le aree del codice almeno una volta e vengono eseguite dagli sviluppatori.
La copertura del test, d'altra parte, lo è testare ogni esigenza almeno una volta ed è ovviamente un'attività del team di controllo qualità.
Ciò che realmente si qualifica per essere un requisito coperto dipende dall'interpretazione di ciascuna squadra.
Per esempio , Alcuni team definiscono un requisito coperto se esiste almeno un caso di test contro di esso. A volte, è coperto se ad esso è assegnato almeno un membro del team. Oppure, se vengono eseguiti tutti i casi di test ad esso associati.
- Se sono stati creati 10 requisiti e 100 test - quando questi 100 test hanno come obiettivo tutti i 10 requisiti e non ne tralasciano nessuno - chiamiamo questa copertura di test adeguata a livello di progettazione.
- Quando vengono eseguiti solo 80 dei test creati e vengono presi in considerazione solo 6 dei requisiti. Diciamo che 4 requisiti non sono coperti anche se l'80% dei test viene eseguito. Queste sono le statistiche di copertura a livello di esecuzione.
- Quando solo 90 test relativi a 8 requisiti hanno assegnato tester e gli altri no, diciamo che la copertura dell'assegnazione del test è dell'80% (8 su 10 requisiti).
È anche importante sapere quando calcolare la copertura.
Se lo fai troppo presto nel processo, vedrai molte lacune perché le cose sono ancora incomplete. Quindi è generalmente consigliato aspetta fino all'ultima build ovvero Build di regressione finale. Ciò fornirà una corretta copertura dei test eseguiti per i requisiti dati.
Leggi anche => Processo di gestione del rilascio e della distribuzione
La mia esperienza
Scena 8 anni fa: Quando avevo 2 anni di esperienza nel settore del test del software, pensavo che andava bene se non conosco alcuni fondamenti sul test del software come qualcosa che si può imparare con l'esperienza e lo farò anche io.
Avevo ragione e anche torto.
Proprio perché con l'esperienza impari a vedere un quadro più ampio, capisci il vero significato di 'Situazione critica' e capisci di più l'utente finale.
Sbagliato perché nessuna delle cose menzionate richiede esperienza, ma apprendimento precoce, che ho capito molto tardi. Questo è il fattore incoraggiante per scrivere questo post.
da youtube a mp3 più lunghi di 30 minuti
Ecco la mia esperienza da una delle interviste in quel momento:
Come ci si assicura che la copertura del test sia completa o massima? Mi è stato chiesto.
Ummmm …… Mi assicuro di testare ogni funzionalità , Ho detto.
S o stai dicendo che una volta testate tutte le funzionalità, senti di aver coperto al massimo l'applicazione / prodotto, in termini di test , l'intervistatore ha fallito.
Ummm ... beh ... .ummm .... Sì, perché quando testate tutte le funzionalità, siete sicuri del comportamento dell'applicazione / del prodotto, Ho sostenuto la mia risposta .
Sono d'accordo, ma la mia domanda è: ti darà la certezza che la copertura dei tuoi test è massima o completa? l'intervistatore non aveva voglia di lasciarmi andare.
Ora, stavo diventando impaziente, ignaro del fatto che stavo per imparare uno degli argomenti più importanti sul test del software - ' Copertura del test ' .
Piuttosto che riprodurre gli estratti dell'intervista, sto riassumendo qui quello che ho imparato su Testing Coverage, quel giorno. Ma prima è chiaro su un punto: la copertura del test non significa mai sapere se stai testando abbastanza o meno, né significa che stai testando perfettamente o meno.
Testare il significato della copertura
La copertura del test può avere un significato diverso in contesti diversi. Scopriamo questi contesti uno per uno:
Copertura del prodotto: quali aspetti del prodotto hai esaminato?
Sì, quando la copertura del test viene misurata in termini di prodotto, l'area principale su cui concentrarsi è: quali aree del prodotto sono state testate e quali rimangono non testate?
Esempio 1:
Se 'coltello' è un prodotto, stai testando; semplicemente non concentrarti sul controllo se taglia correttamente la frutta e la verdura. Ci sono altri aspetti da cercare come: l'utente dovrebbe essere in grado di gestirlo comodamente.
Esempio n. 2:
Se il 'blocco note' è un'applicazione, stai testando, controllare le funzionalità rilevanti è una cosa obbligata.
Ma altri aspetti di cui prestare attenzione sono: l'applicazione risponde correttamente mentre si utilizzano altre applicazioni contemporaneamente, l'applicazione non si blocca quando l'utente cerca di fare qualcosa di insolito , all'utente vengono forniti messaggi di avviso / errore adeguati, l'utente è in grado di comprendere e utilizzare facilmente l'applicazione, il contenuto della guida è disponibile quando richiesto.
Se non esamini gli scenari menzionati, non puoi affermare che la copertura del test per l'applicazione è completa.
Copertura dei rischi: per quali rischi hai testato?
La copertura del rischio è un altro aspetto per avere una copertura completa dei test. Non puoi contrassegnare il prodotto o l'applicazione come 'testato' finché non testerai anche i rischi associati. La copertura dei rischi associati è un fattore importante nella copertura complessiva dei test.
Esempio 1:
Durante il test di un aeroplano, se un tester ti dice che ha testato completamente il sistema interno dell'aereo e che funziona bene, ma solo la capacità di volo dell'aereo non è stata coperta durante il test, quale sarebbe la tua reazione?
Bene, questo è ciò che significa copertura del rischio. Identificare il rischio in base all'applicazione / prodotto e testarlo accuratamente è sempre una buona pratica.
Esempio n. 2:
Durante il test di un sito di e-commerce, il tester ha considerato ogni fattore efficace ma non ha considerato il rischio che un numero di utenti accedesse al sito contemporaneamente e nel giorno della Super OFFERTA, il rischio non considerato si è rivelato un errore enorme.
Lettura consigliata =>
Copertura dei requisiti: per quali requisiti hai testato?
Se un prodotto o un'applicazione è sviluppato molto bene ma se non corrisponde ai requisiti del cliente, non serve. La copertura dei requisiti durante il test è importante quanto la copertura del prodotto.
Esempio 1:
Entusiasta per la funzione di famiglia, hai chiesto al sarto di cucire il tuo vestito e di indossare quei bottoni blu pavone sullo scollo.
Durante la cucitura del vestito, il sarto ha pensato che mettere quei bottoni sulla scollatura non sarebbe stato bello, quindi ha invece cucito un bordo dorato. Il giorno della prova, sicuramente, il cliente insoddisfatto ha gridato al sarto per non aver rispettato i requisiti.
Esempio n. 2:
Durante il test di un'applicazione di chat, il tester si è preso cura di tutti i punti importanti come più utenti che chattano in un gruppo, due utenti che chattano in modo indipendente, tutti i tipi di emoticon disponibili, aggiornamenti inviati all'utente immediatamente ecc. Ma si è dimenticato di esaminare il documento dei requisiti, che chiaramente ha detto che quando due utenti chattano in modo indipendente, l'opzione di videochiamata dovrebbe essere abilitata.
Il client ha commercializzato l'applicazione di chat sostenendo che avrebbe consentito le chiamate, mentre due utenti chattano in modo indipendente. Puoi immaginare cosa sarebbe successo all'applicazione di chat.
Anche leggere => Come creare la matrice di tracciabilità dei requisiti
le migliori società di gioco per cui lavorare
Come adottare un corretto metodo di copertura del test?
La consapevolezza è tutto:
Per prima cosa, il team di controllo qualità deve sapere quanto lavoro è coinvolto e dove si trovano le attività di progettazione. In questo modo, saranno consapevoli se devono essere aggiunti altri test. Per fare ciò, potresti usare un RTM come è la pratica tipica.
=> Dai un'occhiata a questo articolo per saperne di più e come usarlo: Come creare la matrice di tracciabilità dei requisiti - Processo esatto con modello di esempio
In secondo luogo, controlla l'assegnazione delle risorse e processo di esecuzione del test per vedere se tutto viene testato nel modo più efficace.
Una tabella come quella di seguito può essere utile:
Tipo di test | Casi totali | Casi eseguiti | Stato | Commenti |
---|---|---|---|---|
Funzionale | 100 | 80 | 50 passaggi, 30 errori | |
Compatibilità | 100 | cinquanta | 45 passaggi, 5 errori | |
Usabilità | 100 | 100 | 98 passaggi, 2 falliti | |
Regressione finale | 100 | 100 | 99 passaggi, 1 fallito |
Come assicurarsi che tutto sia testato?
- Ogni tester dovrebbe essere a conoscenza dei requisiti e dei metodi di prova
- Dai la priorità ai tuoi requisiti e concentra la tua energia dove è più necessaria
- Essere informato su come una determinata versione è diversa dalla precedente in modo da poter identificare i requisiti critici in modo più accurato e concentrarsi sulla massima copertura positiva
- Adattare l'automazione del test
- Utilizza gli strumenti di gestione dei test per rimanere sempre al corrente
- Assegnazione di lavoro intelligente: canalizza le tue migliori risorse verso attività critiche e consenti ai nuovi tester di esplorare di più per una nuova prospettiva
- Mantenere un file lista di controllo per tutte le attività e attività varie
- Interagisci di più con i tuoi team Dev / Scrum / BA per ottenere informazioni dettagliate sul comportamento dell'applicazione
- Tieni traccia di tutti i tuoi cicli di costruzione e correzioni
- Identificare i problemi più impattanti nelle build iniziali stesse (quando possibile) in modo che quelle successive possano lavorare per una migliore stabilità e raggiungere quelle aree bloccate da problemi precedenti
Aree critiche e metodi per test efficaci
# 1)Risorsa confusa: Scambia le attività tra i membri del tuo team. Questo aiuta a migliorare il coinvolgimento e prevenire la concentrazione della conoscenza.
#Due)Copertura di compatibilità: Assicurati di essere consapevole e di includere il file browser diversi e piattaforme per testare la tua applicazione.
# 3)Proprietà: Rendere i tester responsabili e dare loro libero sfogo (con monitoraggio e supporto ovviamente) per il modulo / compito su cui stanno lavorando. Questo aiuta a costruire responsabilità e consente loro di provare modi creativi invece di seguire i battuti lungo la strada.
# 4)Scadenze: Conoscere le scadenze di rilascio prima dell'inizio della fase di test aiuta con una pianificazione efficace
# 5)Comunicazione : Resta in contatto con gli sviluppatori e altri team tra i cicli di rilascio per sapere cosa sta succedendo.
# 6)Mantieni un RTM: Agisce come un buon derivato di Stakeholder o clienti , in base al quale è possibile confermare il programma di rilascio
Vantaggi della consapevolezza della copertura dei test per un tester:
- Aiuta principalmente con l'assegnazione delle priorità alle attività di test
- Aiuta a raggiungere la copertura dei requisiti del 100% o, in altre parole, previene la perdita di requisiti
- Analisi degli impatti diventa più facile
- Utile per determinare il Criteri di USCITA
- Consente a un cavo di prova di preparare un chiaro rapporto di chiusura del test
Conclusione
La copertura del test non si esaurisce con i contesti menzionati. Ci sono molti altri punti che dovrebbero essere considerati quando si tratta di testare la copertura.
Non è sempre vero che quando si testano di più, i risultati sono migliori. In effetti, quando provi di più senza una strategia apparente, probabilmente finirai per investire molto tempo.
Con un approccio più strutturato, l'obiettivo di una copertura del 100% dei requisiti e metodi di test efficaci, non scenderete a compromessi sulla qualità.
Ci auguriamo che le tecniche descritte in questo articolo ti forniscano alcuni suggerimenti.
Aggiungi i tuoi commenti e opinioni sul post. Come al solito, ci piace sentire la tua opinione.
Lettura consigliata
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- Lavoro assistente QA test software
- Corso di test del software: quale istituto di test del software dovrei iscrivermi?
- Scegliere il test del software come carriera
- Lavoro freelance di scrittore di contenuti tecnici di test del software
- Il test del software è un'attività emotiva?
- Alcune interessanti domande di intervista sul test del software
- Feedback e recensioni sul corso di test del software