Test basati sulle Priorità vs Test basati sul Rischio

Test basati sulle Priorità vs Test basati sul Rischio

Le strategie di testing definiscono l'approccio con cui pianificare l'attività di esecuzione del testing, rispondendo alla domanda essenziale: "Quali test dovremmo eseguire per primi?"

Tra le varie strategie di testing ne emergono due cruciali: i test basati sulle priorità e i test basati sul rischio.

Essenzialmente, queste strategie determinano l'ordine di esecuzione dei test, seguendo il principio fondamentale che, dando priorità a determinati test, ci sarà più tempo utile per risolvere i bug da essi rilevati.

  • Test Basati sulle Priorità:

Questa strategia si concentra sulle esigenze di business, assegnando maggiore priorità agli scenari ritenuti fondamentali per un particolare contesto. Ad esempio, in un'applicazione per prenotare delle visite mediche, sarebbe saggio programmare i test in modo da dare la massima priorità alla funzionalità core di prenotazione.

Altri test da prioritizzare riguardano sempre il dominio di utilizzo dell'applicazione.

  • Test Basati sul Rischio:

Questa strategia si basa invece sul concetto stesso di rischio, ovvero sulla probabilità che un evento futuro possa causare conseguenze negative. Oltre a valutare il danno potenziale (come nella strategia precedente), i test basati sul rischio considerano la probabilità che l'evento si verifichi.

Ad esempio, se la funzionalità core non è stata modificata con un rilascio, la priorità di esecuzione dei test associati ad essa sarebbe sicuramente inferiore.

In questa strategia, prima di ogni iterazione di test, è essenziale condurre un'analisi del rischio per identificare in anticipo le aree del software in cui sarà più probabile trovare difetti, proprio perché impattate dal rilascio.

È importante sottolineare che in entrambe le strategie, tutti i test dovranno comunque essere eseguiti. La differenza tra i due approcci (che comunque possono/devono coesistere) è utile a ottimizzare l'allocazione delle risorse per garantire più tempo utile a risolvere errori bloccanti.

Related Posts

Dynatrace Innovate: Observability & Application Security, Mandatory for Business Resilience

Dynatrace Innovate: Observability & Application Security, Mandatory for Business Resilience

Maggiore produttività, Software Sicuro e performante, l'observability estesa offerta da Dynatrace

Measuring results the right way - Avoiding OKR pitfalls

Measuring results the right way - Avoiding OKR pitfalls

Why measuring success requires more than just numbers

Learning a New Language

Learning a New Language

Useful tips for learning a new language

Cosa vuol dire davvero testare?

Cosa vuol dire davvero testare?

L’obiettivo principale del testing non è dato dalla tecnica usata o dal livello in cui si opera, ma dalla qualità che si vuole verificare. Le tecniche di test sono strumenti per raggiungere questo sco

Aumentare la copertura dei rischi: test case ad Alto Livello vs test case a Basso Livello

Aumentare la copertura dei rischi: test case ad Alto Livello vs test case a Basso Livello

Anche se un software supera tutti i test senza mostrare errori, non è garantito che soddisfi completamente i requisiti degli utenti o che funzioni come previsto in tutte le situazioni reali. I test c

 Grazie CrowdStrike per averci ricordato a che cosa serve il Testing

Grazie CrowdStrike per averci ricordato a che cosa serve il Testing

Il caso di CrowdStrike dimostra quanto sia essenziale investire in attività di QA e testing. Questi processi non solo migliorano l'affidabilità e la sicurezza del software, ma proteggono anche le azie

Case study: Automated tests for a certified webmail client

Case study: Automated tests for a certified webmail client

Questa intervista/case study si concentra sulle attività di testing svolte per una soluzione di posta elettronica certificata, con particolare attenzione alla versione client.

L'informatica, specchio della scienza anarchica di Feyerabend e di Lakatos: prima parte

L'informatica, specchio della scienza anarchica di Feyerabend e di Lakatos: prima parte

L'essere come fondamento dell'informatica