STLC - Testing Fundamental Principles

L'obiettivo comune del test è trovare i bug il prima possibile. E, una volta risolti i bug, assicurati che funzioni come previsto e non rompa altre funzionalità.

Per raggiungere questi obiettivi, vengono forniti sette principi di base per il test del software:

Cosa mostra il test?

I test possono dimostrare che sono presenti difetti ma non c'è modo di dimostrare che non ci siano difetti nel prodotto. Le fasi di test assicurano che l'applicazione sottoposta a test funzioni in base al requisito specificato e aiuta a ridurre la probabilità di difetti non rilevati nell'applicazione. Ma, anche se non vengono rilevati difetti, non significa che sia assolutamente corretto. Possiamo presumere che AUT corrisponda ai nostri criteri di uscita e mantenga i requisiti secondo SRD.

È possibile eseguire test esaustivi?

La copertura o il test del 100% di tutte le combinazioni di input e possibili combinazioni non sono possibili tranne che in casi banali. Invece di test esaustivi, l'analisi del rischio e le priorità vengono utilizzate per definire l'ambito del test. Qui, la maggior parte degli scenari in tempo reale può considerare di includere anche lo scenario negativo più probabile. Questo ci aiuterà a rintracciare l'errore.

Test precoci

Le attività di test dovrebbero iniziare il prima possibile e concentrarsi su obiettivi definiti nella Strategia di test e sui risultati attesi. La fase iniziale del test aiuta a identificare i difetti dei requisiti o le discrepanze a livello di progettazione. Se questi tipi di bug vengono rilevati nella fase iniziale, ci aiuta a risparmiare tempo ed è anche conveniente. La risposta al motivo per cui il test dovrebbe iniziare in una fase iniziale è molto semplice: non appena viene ricevuto l'SRD, i tester possono analizzare il requisito dal punto di vista del test e possono notare una discrepanza tra i requisiti.

Difetto di clustering

Sulla base della precedente analisi dei difetti del prodotto, si può affermare che la maggior parte dei difetti vengono identificati da un piccolo insieme di moduli che sono critici per l'applicazione. Questi moduli possono essere identificati in base alla complessità, alla diversa interazione del sistema o alla dipendenza da diversi altri moduli. Se i tester possono identificare questi moduli cruciali, possono concentrarsi maggiormente su questi moduli per identificare tutti i possibili bug. In uno studio, si è riscontrato che 8 difetti su 10 sono identificati dal 20% della funzionalità di AUT.

Paradosso dei pesticidi

Cos'è il paradosso dei pesticidi - se i pesticidi sono usati frequentemente sulle colture, arriva quando gli insetti sviluppano un certo tipo di resistenza e gradualmente i pesticidi così spruzzati sembrano essere inefficaci sugli insetti.

Lo stesso concetto è applicabile anche ai test. Qui, gli insetti sono insetti mentre i pesticidi sono casi di test che vengono utilizzati per funzionare ancora e ancora. Se gli stessi set di casi di test vengono eseguiti ripetutamente, questi casi di test diventano inefficaci dopo un certo periodo di tempo e i tester non saranno in grado di identificare alcun nuovo difetto.

Per superare queste condizioni, i casi di test dovrebbero essere rivisti e riesaminati di volta in volta e possono essere aggiunti nuovi e diversi casi di test. Questo aiuterà a identificare nuovi difetti.

Il test dipende dal contesto

Questo principio afferma che due diversi tipi di applicazione non possono essere testati utilizzando lo stesso approccio fino a quando entrambe le applicazioni non sono della stessa natura. Ad esempio, se un tester utilizza lo stesso approccio per l'applicazione basata sul Web e l'applicazione mobile, ciò è completamente sbagliato e vi è un alto rischio di scarsa qualità del rilascio del prodotto. I tester dovrebbero utilizzare approcci, metodologie, tecniche e copertura differenti per diversi tipi e natura di applicazioni.

Assenza di errore - Fallacia

Questo principio afferma la ricerca di difetti e la loro correzione fino a quando l'applicazione o il sistema non è stabile, richiede tempo e consuma anche le risorse. Anche dopo aver riparato il 99% dei difetti, c'è un alto rischio di applicazione instabile. La prima cosa essenziale è verificare la stabilità dell'applicazione e i prerequisiti dell'ambiente. Se queste due condizioni soddisfano, solo allora possiamo iniziare con il test dettagliato.