English version below

Un equivoco comune quando si parla di testing è pensare che consista solo nel verificare la correttezza del software, ossia assicurarsi che questo funzioni esattamente come previsto.

In realtà, testare un software, significa valutarlo in base a diverse qualità, come: Usabilità, Sicurezza, Efficienza delle prestazioni, Affidabilità, Manutenibilità, Portabilità e Adeguatezza funzionale.

Adeguatezza funzionale: molto più della correttezza

La correttezza funzionale è dunque solo una delle tre sottocaratteristiche dell’adeguatezza funzionale. Ma per testare l'adeguatezza nella sua interezza, bisogna prendere in considerazione:

• Correttezza funzionale: verifica che la funzionalità produca i risultati corretti rispetto alle specifiche.
• Appropriatezza funzionale: assicura che la funzionalità soddisfi il bisogno per cui è stata creata, rispondendo alle esigenze degli utenti.
• Completezza funzionale: garantisce che la funzionalità copra tutti i casi possibili, comprese le eccezioni e i percorsi alternativi, assicurando quindi che la funzionalità sia pronta per il rilascio.

Partire dalla qualità, non dalla tecnica, non dal livello

Un altro equivoco comune è pensare che le tecniche o i livelli di test definiscano gli obiettivi delle attività di test. Ma come anticipato, l’obiettivo principale del testing è sempre dettato dalla qualità che si vuole verificare. Le tecniche di test sono "solo" strumenti per raggiungere questo scopo, ma non lo determinano. Il livello di test indica "solo" il primo momento utile in cui è possibile verificare una determinata qualità.

Esempio pratico: il calcolo delle aliquote IRPEF

Immaginiamo di dover testare una funzionalità che calcola le aliquote IRPEF in un sistema fiscale. In questo caso, i test dovrebbero verificare:

1. Correttezza: Verificare che il sistema calcoli correttamente le tasse applicando le giuste aliquote ai vari scaglioni di reddito. Si possono usare tecniche come l’analisi dei valori limite per identificare dati e soglie critiche. Per quanto riguarda i livelli, si può partire già a livello di componente.

2. Appropriatezza: Occorre verificare che il calcolo delle aliquote risponda ai requisiti reali, cioè che soddisfi le esigenze degli utenti o rispetti la normativa fiscale vigente. Questo può essere validato dagli esperti del dominio fiscale o dagli utenti finali. Per quanto riguarda i livelli, è vero che si può aspettare fino al livello di accettazione, ma data la criticità della funzionalità sarebbe bene anticipare il testing della appropriatezza già in fase di definizione dei requisiti, coinvolgendo gli esperti di business già nel processo di raffinamento.

3. Completezza: I test devono assicurarsi che tutte le eccezioni siano gestite, ad esempio, redditi esenti o detrazioni specifiche, e che la funzione integri correttamente eventuali altre funzionalità fiscali. Anche percorsi alternativi, come la gestione di redditi da più fonti o altri regimi fiscali, devono essere considerati. Anche questo è verificabile a più livelli di test.

Costruire test case completi

Per tutti questi motivi, i test case devono sempre coprire non solo il comportamento principale della funzionalità, ma anche tutte le eccezioni e i percorsi alternativi.

Un buon test case deve anche riflettere come le tre sottocaratteristiche si interconnettano. Ad esempio, un test che verifica la completezza potrebbe rivelare che una particolare eccezione non è stata gestita correttamente, il che potrebbe influenzare sia la correttezza che l’appropriatezza della funzionalità. Pertanto, è importante adottare un approccio olistico nel design dei test case, assicurandosi che tutte le dimensioni dell’adeguatezza funzionale siano coperte.

What does it really mean to test?

When it comes to testing, a common misconception is to think that this activity only concerns verifying the correctness of the software, meaning ensuring that it does exactly what is intended. In reality, testing is not limited to this. Testing software means evaluating it under different qualities, such as usability, security, performance efficiency, reliability, maintainability, portability, and functional adequacy.

Functional Adequacy: Much More Than Correctness

Functional correctness is just one of the three sub-characteristics of functional adequacy. Testing adequacy in its entirety involves verifying:

• Functional correctness: checking that the functionality produces the correct results according to the specifications.
• Functional appropriateness: ensuring that the functionality meets the need for which it was created, addressing the users' requirements.
• Functional completeness: ensuring that the functionality covers all possible cases, including exceptions and alternative paths, thus ensuring it is ready for release.

Starting with Quality, Not Technique or Level

Another common misconception is thinking that testing techniques or levels define the objectives of testing activities. But as mentioned, the primary goal of testing is always dictated by the quality that needs to be verified. Testing techniques are "only" tools to achieve this purpose, but they do not determine it. The testing level indicates "only" the first point at which it is possible to verify quality.

Practical Example: Calculating Income Tax Rates

Let’s imagine we need to test a functionality that calculates income tax rates in a tax system. In this case, the tests should verify:

1. Correctness: The tests must verify that the system correctly calculates taxes by applying the right rates to various income brackets. Techniques such as boundary value analysis can be used to identify critical data and thresholds. Regarding levels, testing can start at the component level.

2. Appropriateness: It is necessary to verify that the calculation of rates meets the actual requirements, meaning that it satisfies user needs or complies with current tax regulations. This can be validated by domain experts or end users. As for levels, acceptance testing can be expected, but given the critical nature of the functionality, it would be wise to start appropriateness testing early in the requirements definition phase, involving experts in the refinement process.

3. Completeness: Tests must ensure that all exceptions are handled, such as exempt income or specific deductions, and that the function correctly integrates any other tax functionalities. Alternative paths, such as managing income from multiple sources or different tax regimes, must also be considered. This can also be verified at multiple testing levels.

Building Comprehensive Test Cases

For all these reasons, test cases must always cover not only the main behavior of the functionality but also all exceptions and alternative paths.

A good test case should also reflect how the three sub-characteristics interconnect. For instance, a test that checks for completeness might reveal that a particular exception has not been handled correctly, which could affect both the correctness and appropriateness of the functionality. Therefore, it is important to adopt a holistic approach in designing test cases, ensuring that all dimensions of functional adequacy are covered.