Testare per la Conformità—O per la Qualità?
Il mondo è pieno di software che rispettano perfettamente tutti i requisiti documentati ma che comunque non riescono a creare valore per i loro utenti.
Quando ho studiato ingegneria del software - secoli fa - qualità significava conformità, cioè aderire ai requisiti. Ho anche imparato che l’assicurazione della qualità comprende tutte le misure attuate per consentire, creare e verificare la qualità, e che il testing è un metodo chiave di assicurazione della qualità.
Oggi Wikipedia definisce il testing come l’atto di esaminare i prodotti e il comportamento del software sotto test mediante validazione e verifica. Il testing è definito come un’attività, lasciando aperto il suo scopo. Le definizioni che ho imparato a ingegneria sono molto compatibili con la definizione Wikipedia di compliance testing: test che determinano se un processo, prodotto o servizio rispetta i requisiti di una specifica, standard tecnico, contratto o regolamento. Curiosamente, nessuna di queste definizioni utilizza la parola qualità.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Cos'è la qualità?
Oggi evito la tentazione di definire la qualità se non indirettamente attraverso quattro dimensioni: benefici, funzioni, processo ed esperienza. Pensiamo a qualcosa che tutti conoscono, ad esempio Paypal. Le persone lo usano per trasferire denaro online; questa è la sua funzione. I benefici che cercano sono facilità, sicurezza e basso costo. Utilizzare PayPal coinvolge vari processi utente, e il software guida l’utente lungo di essi. Le sensazioni, come felicità, frustrazione o successo, che l’utente prova mentre utilizza Paypal, costituiscono l’esperienza. Qualunque cosa sia la qualità, difficilmente può esserci senza tutte queste quattro dimensioni.
Generalmente il testing si concentra sulla conformità funzionale, cioè controllare che il software faccia ciò che prescrivono i requisiti e non faccia altro. Ci possono essere anche requisiti non funzionali, come i tempi di risposta, il numero di transazioni parallele gestite e la sicurezza dei dati dell’utente. Standard e regolamenti, come SOC2 o GDPR, introducono requisiti aggiuntivi, così come gli accordi di Paypal con le compagnie di carte di credito. Questi possono avere poco a che fare con le funzioni e il valore reale del software, ma rispettarli è un prerequisito per entrare nel mercato.
La qualità va oltre la semplice conformità. Per ottenere entrambe, guarda la nostra lista curata delle migliori piattaforme di testing software
Il mondo ideale
I migliori tester applicano sia una visione basata sulla conformità, che si concentra sulla soddisfazione dei requisiti, sia una visione basata sugli outcome, che si focalizza sulla realizzazione dei benefici. In un mondo ideale, soddisfare i requisiti documentati implicherebbe il raggiungimento dei benefici dell’utente, ma raramente il mondo è ideale. Anche se il software fosse perfetto, gli utenti non lo sono. La realizzazione dei benefici dipende molto dalle azioni dell’utente e le sue azioni dipendono da come il software interagisce con l’utente e lo guida. Questi aspetti a loro volta influenzano la qualità dell’intera esperienza. Tali caratteristiche del software difficilmente possono essere catturate nei requisiti di conformità o nei casi di test formali. Di nuovo, in un mondo ideale, tutte queste sfide verrebbero risolte abbastanza presto tramite una progettazione centrata sull’utente – ma il mondo è tutt’altro che ideale, e il tester deve farsi portavoce dell’utente reale.
Conformità vs Outcome Testing
Il compliance testing e l’outcome testing richiedono approcci mentali diversi. Il compliance testing è come mettere delle trappole: leggere i requisiti, immaginare cosa può andare storto e progettare le condizioni di test sotto cui il software probabilmente fallirà. L’outcome-based testing è più un atto di curiosità: capire ciò che l’utente deve raggiungere, immaginare tutto ciò che potrebbe fare, capire come il software dovrebbe reagire e poi provarlo.
La conformità è un prerequisito della qualità. In molte industrie, soddisfare i requisiti formali di conformità è perfino necessario per poter partecipare al business. Inoltre, si possono mitigare i rischi di responsabilità producendo una prova documentata che la conformità sia stata adeguatamente testata. Tendo a pensare che il testing di conformità aiuti a ridurre il rischio di fallimento e che quello orientato agli outcome migliori la probabilità di successo.
