Gli impatti dei Bias congnitivi nel Software testing

Nel Gruppo Telegram dell' Oracolo mi hanno chiesto di approfondire il tema dei "Bias", prova ad immaginare, sei al telefono e dici al tuo interlocutore "scusami devo chiudere perchè non trovo il telefono"... La stessa cosa può capitare anche durante i test, infatti nella certificazione "ISTQB Foundation" viene ribadito l'importanza dell' "indipendenza dei tester", appunto per ridurre l'opportunità che diversi problemi diventino "invisibili" ai nostri occhi.
Facendo seguito alla richiesta ho trovato questo articolo di "Geoffrey Shenk" pubblicato su questo Blog dal titolo "Gli impatti dei Bias congnitivi nel Software testing".

In molti aspetti della vita personale, pubblica e aziendale, perseguire l'obiettività o l'equità significa spesso trovare un terreno comune. L'ideale è trovare uno stato di neutralità in cui tutti possano lavorare e comunicare in un ambiente privo di pregiudizi (bias). Il problema è che questo è semplicemente irraggiungibile perché i pregiudizi umani e organizzativi sono pervasivi, anche all'interno di discipline tecnologiche che sembrano inattaccabili. Il testing del software è soggetto a pregiudizi cognitivi durante tutte le fasi di creazione, esecuzione e consumo dei risultati.

Un pregiudizio (bias) è una particolare visione o inclinazione del temperamento. È una tendenza naturale a vedere il mondo attraverso una lente colorata dall'esperienza passata. Ogni essere umano ha dei pregiudizi e i pregiudizi possono moltiplicarsi o rafforzarsi notevolmente nel contesto di un'associazione, di un'organizzazione, di un team o di un'azienda. È molto difficile per ognuno di noi modificare i propri pregiudizi. Ciò che è molto più facile - e più efficace per i team che lavorano insieme - è riconoscere i pregiudizi. Sapendo che i pregiudizi esistono, ci si può impegnare per mitigare gli effetti dannosi che essi hanno sulla produttività e sulla qualità. Questo può essere molto utile per i team di sviluppo software, soprattutto per migliorare l'efficacia dei test.

Il filosofo della scienza Karl Popper ha scritto:

"Se siamo acritici troveremo sempre quello che vogliamo: cercheremo e troveremo conferme e distoglieremo lo sguardo da tutto ciò che potrebbe essere pericoloso per le nostre teorie".

Anche se non ci pensiamo più di tanto, ognuno di noi ha molte di queste "teorie degli animali". Una delle poche cose che si possono dire senza pregiudizi è che ogni persona mantiene diversi tipi di pregiudizi.

Il testing del software è un'arte e una scienza al tempo stesso, una professione che consiste principalmente nell'effettuare scelte, valutazioni e conclusioni sulle caratteristiche del software. Tutto questo si ripercuote sui tipi di test da costruire e sulle modalità di esecuzione. Anche se le moderne metodologie di sviluppo, come Agile, possono aiutare un team a migliorare l'efficienza di tutte queste attività, rimane la possibilità di avere grossi buchi nella copertura dei test. Questi buchi sono di solito il risultato di omissioni da parte del QA, ma il team QA potrebbe essere del tutto inconsapevole del fatto che la radice del problema è in realtà la sua negligenza involontaria.

Esistono molti tipi di pregiudizi (bias)cognitivi che possono colpire i team di QA del software, tra cui:

• Pregiudizio di conferma
• pregiudizio di congruenza
• Pregiudizio di sopravvivenza
• Errore di attribuzione fondamentale
• Pregiudizio di negatività

Vediamo brevemente ogni tipo.

Pregiudizio di conferma

Il Pregiudizio di conferma favorisce la selezione dei casi di test verso quei casi che i tester prevedono verranno eseguiti secondo le loro aspettative. Ciò si verifica tipicamente nei test manuali, se non altro perché - nella mente dei tester - un livello adeguato di test viene eseguito in una quantità di tempo modesta. Per molti team, questo pregiudizio influisce anche sulla formazione della suite di regressione (che contiene test con esiti noti). L'effetto di questo pregiudizio è che non c'è alcun incentivo a testare una gamma più ampia di risultati inattesi o sorprendenti.

Questo pregiudizio è forse il più difficile da mitigare, a causa della tendenza all'affermazione, alla conferma e al successo. Il team vuole che il software funzioni ed è attratto magneticamente dalle prove che confermano questo desiderio. Un buon approccio per gestire questo impulso è quello di continuare a rivedere tutte le ipotesi ed esplorare altri modi per testare "fuori dagli schemi".

Pregiudizio di congruenza

Si tratta di un fenomeno simile al pregiudizio di conferma, in cui i tester pianificano ed eseguono i test in base alle loro ipotesi più evidenti, evitando di considerare le alternative. In sostanza, l'QA tende a convalidare le funzionalità in linea con le proprie aspettative. Il team non si preoccupa di verificare se esistano altri modi per eseguire i test o altri modi in cui gli utenti possono interagire con l'applicazione. Questo non solo fa sì che un certo numero di casi di test negativi venga omesso dalla considerazione. Può anche causare problemi, soprattutto nei rilasci più importanti che contengono nuove funzionalità e/o richiedono la formazione degli utenti.

Quando il team di sviluppo matura, ridurre al minimo gli effetti dei pregiudizi di conferma e di congruenza significa che i tester devono impegnarsi maggiormente nei test differenziati ed esplorativi. Ciò significa che si deve cercare di rompere l'applicazione o il sistema in modo tale da anticipare il modo in cui vari tipi di utenti potrebbero romperlo. Si comincia con cose semplici come l'inserimento di lettere in un campo solo numerico, ma si dovrebbe andare ben oltre la variazione del comportamento, le permutazioni e i casi limite. Strumenti di test della qualità come Functionize migliorano notevolmente la capacità del team di pianificare ed eseguire tali test.

Pregiudizio di sopravvivenza

Ecco un'idea sbagliata comune: Se volete raggiungere il successo, concentratevi solo su ciò che ha avuto successo. La realtà è che quando si ignora il fallimento, potrebbe non esserci più una distinzione tra successo e fallimento.

Il pregiudizio di sopravvivenza è un tipo di pregiudizio di selezione in cui la valutazione di un set di dati viene distorta concentrandosi sui casi di successo e ignorando i fallimenti. È importante tenere presente che i fallimenti possono essere ignorati passivamente, poiché non persistono o "sopravvivono" in modo tale da poter essere misurati.

I tester sono in possesso di qualcosa di silenzioso. O meglio, molto silenzioso. Ma non è vantaggioso che rimanga silenzioso. Il quasi silenzio sulla questione in questione è probabilmente la causa di alcune pratiche irrazionali che caratterizzano in parte i team di test mal funzionanti. Ci riferiamo al catalogo silenzioso di tutti i bug che sono stati scoperti e che non sono stati spediti con la release. Si tratta di tutti i difetti potenzialmente dannosi a cui il team ha posto rimedio prima che potessero sfuggire e fare danni. Dopo il rilascio, nessuno ci pensa più. E perché no? È come se non esistessero più, se non come voci dimenticate in un database su un server dinosauro. Ma restano lì, nel buio. Centinaia: prove inequivocabili di disastri che non si sono mai verificati, di reputazioni che sono state rispettate e di denaro che è stato risparmiato.

Nel frattempo, il prodotto software è nelle mani degli utenti finali, e mette a nudo i suoi inevitabili difetti, spingendo i team di vendita e i senior manager a sfogarsi: "Ma cosa fa il QA tutto il giorno? Come possono trascurare la qualità in questo modo? Questo tipo di risposta è un classico esempio di pregiudizio di sopravvivenza. La presenza di errori li induce a sottovalutare il personale addetto ai test, perché è ignaro di tutti i bug che sono stati trovati con successo e non sono stati spediti con il software.

Un modo per mitigare la distorsione da sopravvivenza è quello di convertire tutte le prove archiviate in prove ben documentate e pubblicare in modo trasparente un registro di tutti i bug trovati in ogni ciclo di rilascio.

Errore di attribuzione fondamentale

Questo pregiudizio si manifesta quando le persone tendono a incolpare gli altri per i problemi o i problemi, ma tendono a essere molto accomodanti o a sviare quando sono loro stessi la fonte di problemi simili. Ad esempio, se uno sviluppatore crea inavvertitamente un difetto, viene spesso considerato negligente da un particolare tester. Tuttavia, se quel tester crea un difetto nel codice di test, potrebbe cercare di spiegarlo come il risultato di una scadenza imminente, della stanchezza o della scarsa definizione dei requisiti. Se la cultura di un intero team è di questo tipo, è probabile che l'atmosfera sia conflittuale e divisiva.

Per mitigare gli effetti di questo pregiudizio, un team deve trovare intenzionalmente e costantemente dei modi per ridurre il potenziale di altri fallimenti. Per molti team, ciò comporta un certo livello di automazione dei test per garantire che gli stessi problemi non si ripresentino. I tester e gli sviluppatori devono anche lavorare in modo collaborativo per assumersi la responsabilità del proprio lavoro e dei propri errori. Ciò contribuirà a ridurre la negatività e a fornire un percorso di miglioramento della qualità.

Pregiudizio di negatività

Il pregiudizio di negatività è la tendenza a prestare maggiore attenzione o considerazione a ciò che è concettualmente negativo, invece di mantenere un equilibrio con le esperienze o le informazioni positive. Il pregiudizio della negatività è particolarmente comune nei team QA. Poiché i tester si occupano principalmente di trovare difetti, un aspetto importante del loro lavoro può essere percepito negativamente. È fin troppo facile per un tester dare per scontato che una funzionalità del software non sia distribuibile a causa di tutti i difetti scoperti.

Ciò evidenzia l'importanza della responsabilità del product manager nel definire i criteri di accettazione insieme al responsabile della QA. Ci sarà una sana tensione tra il responsabile dei test, che vuole mantenere una posizione di zero difetti, e il product manager, che probabilmente rifiuterà qualsiasi criterio di accettazione che richieda una comprensione tecnica approfondita.

Il riconoscimento è la chiave

Gli autori del libro "Lessons Learned In Software Testing, A Context-Driven Approach" avvertono che:

"non è possibile evitare questi pregiudizi. Sono, in larga misura, radicati nel nostro cervello. Quello che si può fare è gestire i pregiudizi. Per esempio, studiando i pregiudizi ed esercitandosi a prenderne coscienza, si può diventare più attrezzati per compensarli nel proprio pensiero. La diversità è anche una protezione contro i pregiudizi eccessivi. Se più tester fanno brainstorming insieme, si può ridurre al minimo l'impatto dei pregiudizi di un singolo tester".

Per quanto riguarda ogni tipo di pregiudizio, lo sforzo più importante è quello di riconoscere che è probabile che esistano nel team di sviluppo e tra gli stakeholder. Vale la pena di identificarli, riflettere sul contesto e adottare misure per migliorare le relazioni o i processi di conseguenza.

ecco il link all'articolo originale