Robert Whitney
Eseguire test software precisi e corretti segue numerosi principi. Il Consiglio Internazionale delle Qualifiche di Testing Software distingue sette principi fondamentali, di cui discuteremo oggi. Curioso di scoprirli? Leggi un articolo sui principi chiave del testing ISTQB!
Principi di testing ISTQB – indice:
- Il testing rivela difetti ma non può provare la loro assenza
- Un testing approfondito è impossibile
- Il testing precoce fa risparmiare tempo e denaro
- Effetto valanga dei malfunzionamenti
- Paradosso del pesticida
- Dipende dal contesto
- Pubblicizzare software impeccabile è un no-go
- Riepilogo
Il testing rivela difetti ma non può provare la loro assenza
Il testing aumenta la probabilità di trovare errori, il che a sua volta facilita le possibilità di correggerli. Tuttavia, non può garantire completamente che il software sia privo di tutti i difetti anche se la stragrande maggioranza viene individuata e corretta. A causa dell’incapacità di creare software impeccabile, molti considerano il processo come negativo per design, poiché non si otterrà mai un risultato positivo e si troverà sempre un po’ di “sporcizia” nei programmi.
Un testing approfondito è impossibile
La regola empirica sopra menzionata afferma che rilevare tutti i malfunzionamenti del software è futile. Tuttavia, ciò non si applica a programmi semplici e brevi. Questo, a sua volta, indica che c’è la possibilità di vedere tutte le combinazioni di input e precondizioni per testare completamente alcuni programmi. Quando si valuta software sofisticato, anche la migliore intelligenza artificiale non può eseguire tutte le misurazioni necessarie, per non parlare dei tester manuali. Gli assessori automatizzati eseguiranno le app in modo più efficiente e preciso, ma non possono comunque garantire prestazioni impeccabili. Per farlo, è necessario intraprendere ulteriori compiti come la prioritizzazione, l’analisi dei rischi, così come trovare e applicare altre tecniche di testing.
Il testing precoce fa risparmiare tempo e denaro
Molti professionisti chiamano anche questo principio “spostare a sinistra.” Prima si individuano i difetti, più facile sarà correggerli, quindi il testing statico e dinamico dovrebbe iniziare il prima possibile. In breve:
- Testing statico – valutazione del prodotto senza eseguire il codice.
- Testing dinamico – valutazione del codice di un modulo o sistema durante le sue prestazioni
Rilevare difetti nelle prime fasi di implementazione facilita ulteriori diagnosi. Ma quando due aree del software interagiscono, correggere i difetti diventa problematico a causa dell’incapacità di individuare quello che ha l’errore. In tali casi, ci vuole tempo, sforzo e manodopera extra per affrontare la situazione. In definitiva, è la risposta rapida agli ostacoli emergenti che può prevenire la moltiplicazione delle crepe.
Effetto valanga dei malfunzionamenti
La maggior parte dei glitch tende a concentrarsi nei moduli più critici, quindi la loro esaminazione approfondita rivela e elimina sufficientemente la maggior parte. Questi gruppi diventano il principale obiettivo dell’analisi del rischio per mappare e stabilire la futura condotta delle azioni. La maggior parte dei difetti emerge seguendo i percorsi che gli utenti prendono, ma in questi casi, la sola conoscenza non rende i moduli impeccabili.
Il principio di Pareto afferma che l’80% dei risultati deriva solo dal 20% delle cause. In altre parole, l’80% dei bug esiste nel 20% dei moduli. Se incontri numerosi malfunzionamenti in un modulo, continua a scavare poiché saranno lì.
Paradosso del pesticida
Eseguire gli stessi test ripetutamente può fallire perché potrebbero essere stati progettati in modo errato in primo luogo e non dimostreranno mai di essere efficaci. Devi modificare e aggiornare il testing per aumentare la possibilità di trovare nuovi difetti nel software.
Creare un sistema di diagnosi completamente nuovo non funzionerà nemmeno. Seguire le combinazioni precedenti potrebbe fermare il processo di valutazione allo stesso livello. Questo principio è stato coniato ‘paradosso del pesticida’ perché i pesticidi che controllano i parassiti perdono anche efficacia dopo un certo utilizzo.
Dipende dal contesto
Il modo di eseguire il testing dipende dagli oggetti esaminati. Pertanto, testare un programma di contabilità, un videogioco o un’applicazione di social networking varia sostanzialmente. Dipende anche dalla situazione, ad esempio, un’analisi focalizzata sulla praticità di un’app come il controllo della sua attrattiva per gli utenti, facilità d’uso, aspetto visivo, ecc. differisce anche da quelle valutazioni mirate agli attributi funzionali del programma, ad esempio, eseguire calcoli corretti.
Pubblicizzare software impeccabile è un no-go
Applicare vari tipi di strumenti diagnostici non può garantire app perfette. Molti che affermano e pubblicizzano le loro app come tali si sbagliano, e probabilmente è solo per gli sforzi di marketing che fanno tale affermazione. Puoi eseguire numerosi test manuali e automatizzati per aumentare la probabilità di scoprire e correggere il maggior numero possibile di errori, ma comunque, non c’è garanzia di prestazioni perfette. In alcuni casi, gli ostacoli riguardano il software operativo, ad esempio, il programma potrebbe non soddisfare tutte le aspettative degli utenti.
Principi di testing ISTQB – riepilogo
Questo è come ISTQB, a un livello base, presenta sette principi di testing ISTQB che un tester software dovrebbe seguire. Innanzitutto, indicano l’impossibilità di una diagnosi software completa, quindi è cruciale, tra le altre cose, modificare i test, così come condurre una ricerca approfondita nei moduli chiave. Queste azioni migliorano la ricerca e la rimozione della maggior parte dei difetti diminuendo la probabilità di guasti in futuro.
Cos’è il testing software? Ora conosci la risposta! Dai un’occhiata alle nostre altre serie su Python e Javascript!
Se ti piace il nostro contenuto, unisciti alla nostra comunità di api operose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Robert Whitney
Esperto di JavaScript e istruttore che forma i dipartimenti IT. Il suo obiettivo principale è aumentare la produttività del team insegnando agli altri come cooperare efficacemente durante la programmazione.
