ISTQB 3/8: Capitolo 1, Fondamenti del Testing (180 minuti)

Iniziamo ad entrare nel vivo. In questo capitolo, il primo della certificazione, impareremo:

• Cos’è il Testing?
• Perché il Testing è Necessario? (e magari perchè il Sillabus usa tante lettere maiuscole impropriamente..)
• Principi del Testing
• Attività di Test, Testware e Ruoli del Test
• Competenze Fondamentali e Buone Pratiche nel Testing

Qui il link diretto al PDF in inglese e qui a quello in italiano (ultima verifica: 07/04/2024)

Cos’è il Testing?

In breve. Un’insieme di attività. Con uno scopo preciso: a scoprire i difetti e a valutare la qualità degli artefatti software.

Gli artefatti software quando sottoposti ad attività di Testing, prendono il nome di oggetti di test, nel senso grammaticale / dell’azione: Giovanni (= Tester) esegue la suite di no-regression (= Test Activity) della mobile app myBank (= Test Objective).

Attività in senso lato: non solo run di test suite, ma anche progettazione di una sessione di test, scrittura di un Defect, redazione di un report di un’attività di test, e cosi via…

Proprio perchè si parla di software e di attività “contro” di esso (dall’inglese against, che ha anche il significato etimologico “averne oggetto”), diventa chiaro che le attività del Testing sono parte integrante del processo di sviluppo software, o Software Development Life Cycle (SDLC).

E qui la prima cosa che “inizia a piacermi”. ISTQB afferma che non solo il Testing verifica che il software soddisfi i requisiti e non presenti difetti di funzionamento. Ma anche che soddisfi l’utente e gli stakeholder nel suo contesto di esecuzione. Un requisito può presentare “difetti” logici o funzionali (o di business, tante volte..) tali per cui la miglior implementazione software del miglior ingegnere del pianeta lo renderà un prodotto… inutile. Il Tester quindi deve agire fin dalla definzione dei requisiti fornendo proattivamente early feedbacks prima ancora di spendere tempo prezioso nell’implementazione.

Il Testing può essere:

• Testing statico: non prevede l’esecuzione (= run) del software. Parliamo di analisi statica del software e di review. Una pull-request su Bitbucket scatena un’analisi statica con SonarQube sulle porzioni di codice modificato e fornisce un report, che viene ispezionato.
• Testing dinamico: prevede che il software sia in funzione e lo si testi mediante l’uso dei Test Case. Ad esempio, un tester verifica che il form di login fornista un messaggio di cortesa in caso di username e password errati. Qui il software sta girando, è in esecuzione.

Le attività di Testing non sono solamente “attività da fare”, attività tecniche. Ma l’intero processo di test deve essere pianificato, monitorato, gestito, controllato. Il Testing è a tutti gli effetti una vera e propria attività aziendale. Naturalmente, diversi sono i modi per mettere in pratica la gestione del test. Da una semplice e-mail o una chat su Slack si può passare a pagine e pagine di documenti Word e Gantt diagram di supporto all’esecuzione. Poco importa, come lo Sviluppo Software non è solo coding, anche il Testing non è solo Test Case execution.

Le attività di Testing sono eseguite dai Tester: la loro attività consiste nell’utilizzo di tool ma principalmente è un’attività intellettuale. Il Tester pensa, progetta, riflette, mette a punto strategie.

Il Tester applica il Critical Thinking. Wow, questo mi interessa. Qui viene citato un libro, Myers, G. (2011) The Art of Software Testing, (3e), John Wiley & Sons: New York NY.

Senza leggere in questo momento tutto il libro di Myers, che è dai tempi della Fortitudo che non lo seguo, mi sono imbattutto in questo articolo di Marina Osnaghi: Cos’è il “critical thinking” o pensiero critico. In breve:

Il Pensiero Critico è la capacità di esaminare una situazione e di assumere una posizione personale in merito. Tale capacità costituisce il fondamento di un atteggiamento responsabile nei confronti delle esperienze e relativamente autonomo rispetto ai condizionamenti ambientali“.

Umberto Galimberti

Affascinante.

Il Tester applica il System Thinking. Anche questo, di brutto. Qui si cita un secondo libro, Roman, A. (2018) Thinking-Driven Testing. The Most Reasonable Approach to Quality Control, Springer Nature Switzerland.

Anche qui, senza leggere ora il libro, mi sono imbattutto in quest’altro articolo di Spremute Digitali, che cito:

Il System Thinking, tradotto in italiano come Pensiero Sistemico, è un’analisi che mira a comprendere qual è il meccanismo che permette a un sistema complesso di far coesistere tutti i suoi ingranaggi, ognuno dei quali provoca delle interazioni e definisce il comportamento globale del sistema.

Spremute Digitali

Apro una parentesi. Nell’introduzione si dice che l’esame non comprende contenuti esterni, libri, articoli, approfondimenti suggeriti. Ma il Syllabus ne contiene veramente tanti e.. perchè no, li colleziono strada facendo, se mi avanza del tempo, lo investirò nella lettura.

Infine, un riferimento allo standard ISO/IEC/IEEE 29119-1

Si parla poi di Obiettivi del Testing

• Valutare i prodotti di lavoro come requisiti, user story, progettazione e codice
  • Ecco qui. Bingo. Non si parla di software funzionante, ma di “tutto quello che viene prima”. Il cui test esplicito non viene quasi mai fatto.
• Generare failure e rilevare difetti
  • Hacking, insomma.
• Garantire la copertura richiesta di un oggetto di test
  • Lo devo testare in ogni parte (richiesta)
• Ridurre il livello di rischio di una qualità del software inadeguata
  • Ovvero. Ho un form di login, che è rischiosa per definzione. Progetto, eseguo e preparo report della funzionalità di login, con lo scopo di ridurne il rischio.
• Verificare se i requisiti specificati sono stati soddisfatti
  • In altre parole: verificare che si è lavorato in linea con le direttive aziendali, in linea con il business.
• Verificare che un oggetto di test sia conforme ai requisiti contrattuali, legali e normativi
  • Qui… boh, sinceramente lo trovo ridondante rispetto al punto precedente, sempre di verifica di requisiti si sta parlando.
• Fornire informazioni agli stakeholder per consentire loro di prendere decisioni informate
  • Report. Considerazioni. Osservazioni. E’ un’azione attiva, di comunicazione. Che non prende decisione, ma riporta osservazioni e rischi.
• Creare fiducia nella qualità dell’oggetto di test
  • Basti pensare a rilasciare in prod senza testare. Altro che se il Testing crea fiducia.
• Validare che l’oggetto di test sia completo e funzioni come richiesto dagli stakeholder
  • Completezza. E adeguatezza agli stakeholder (quindi anche agli utenti finali, ai clienti)

Importante sottolineare che tutti questi obiettivi sono “blended”: è il contesto di test che ne prescrive alcuni, ne raccomanda altri, ne privilegia alcuni rispetto ad altri e cosi via (= Test Analysis / Test Design)

Il primo capitolo si chiude sottolineando la differenza tra Testing e Debugging:

• Testing (statico, dinamico): cerca difetti
• Debugging a seguito di failure generato da Testing dinamico: si occupa di
  • Riprodurre il failure, per determinarne la sistematicità
  • Effettuare una diagnosi, per trovarne la causa
  • Risolvere la causa
  • Debugging a seguito di failure (o meglio, defect in questo caso) generato da Testing statico: si occupa di risolverlo direttamente, senza necessità di diagnosi e fix. Si sta guardando del codice fermo.

A seguito delle attività di Debugging, serve un test confermativo (è bene che lo faccia la stessa persona che ha trovato il Defect perchè è già allenata in maniera critica e sistemica al contesto di test necessario) e un test di regressione: lo sviluppo software che ha risolto la causa del failure potrebbe aver generato altri difetti, anche su parti del software già testate in precedenza.

Perchè il Testing è necessario?

Risposta intuitiva, ingenua. Perchè i Bug sono dietro l’angolo.

Risposta da ISTQB: perchè contribuisce al successo dell’iniziativa.

Anche qui, risposta interessante perchè ampia la concezione diffusa che fare software testing vuol dire aprire un browser e cercare di trovare difetti in un sito, installare un’app su Android e vedere se la funzionalità di print-screen è stata disattivata dalle ultime pull-request sul repo.

Fare Testing vuol dire fare qualità. E un prodotto senza qualità non ha (probabilmente) successo.

Successo è raggiungere gli obiettivi dell’attività:
– entro l’ambito: in scope, si fa quello che il Business richiede, non altro
– con qualità: non solo bug, ma anche adeguatezza dei requisiti ai clienti, compliance, …
– nei tempi: rilasciare oggi in produzione un text editor sperando di essere rivoluzionari, beh.. non rispecchia il time-to-market
– nei vincoli di budget: spendere 40h in attività di Testing per un form di login potrebbe non essere un investimento proficuo del tempo, e quindi del denaro, di lavoro (o forse si, se è l’accesso al pulsante di lancio di una bomba atomica…).

Il Testing è necessario perchè contribuisce alle decisioni progettuali. Un progetto software avanza (Software Development Life Cycle, SDLC) quando si decide che è necessario farlo avanzare, ovvero quando le condizioni per l’avanzamento sono soddisfatte e qualcuno (il team? il PM? …) decide cosi. Per facilitare queste fasi decisionali, servono misure, servono dati oggettivi: il Testing ne fornisce una buona dose.

Giusto per fare un esempio: per passare dalla fase di Analisi Funzionale all’Implementazione, è necessario valutare la qualità dei requisiti, esplodere i concetti, pensare olisticamente al sistema impattato, valutare effetti che il cambiamento richiede, evidenziare assunzioni, ragionare su ipotesi , elencare dipendenze esterne da tenere in considerazione. Procedure di Testing “su carta” possono venire in aiuto fornendo evidenze (es: uno User Test) che possono aiutare nel dire “ok, il requisito è maturo ed è stato sviscerato in ogni sua parte, il cambiamento è descritto bene. Pronti via, si fa coding”.

In un contesto waterfall, potrebbe essere questo lo schema:

In un contesto Agile (Scrum) invece potrebbe essere cosi:

Quando si parla di Quality Assurance (“la QA”), spesso si intende “il dipartimento aziendale di chi esegue test sul software”. Nulla di più sbagliato.

Quality Assurance = approccio preventivo orientato al processo. Un’azienda fa QA quando valuta i processi e cerca di ottimizzarli. LEAN è una filosofia che ha fatto di questo approccio il cuore pulsante. La Quality Assurance si basa sul principio che:

Un buon processo seguito in modo corretto, genera un buon prodotto

ISTQB Syllabus 4.0

Quality Control = approccio correttivo orientato al prodotto. Il Testing è il principale processo di Quality Control, ma ve ne sono altri (es: prototipizzazione, validazione formale, simulazione).

Che relazione c’è tra QA e QC? Sono complementari: i risultati del Testing sono feedback per ottimizzare il processo di Testing (QA) e per correggere il prodotto (QC).

Errori, Cause, Difetti, Failures, … serve uno schema.

Il Testing va a caccia di Difetti e lo fa osservando un sistema, alla ricerca di Failure. A questo punti viene applicata un’analisi per capire le radici del problema, le cause profonde. Prende il nome di Root Cause Analysis e, in senso critico, fornisce indicazioni chiare al Debugging (attività che rimuove il Difetto. Occhio alle condizioni esterne (una credenziale a database scaduta) che potrebbero trarre in inganno.. sono sempre in agguato.

Principi del Testing

Sette sono i mari, e anche i Principi del Testing (= linee guida sempre valide, assiomi).

1. Il testing mostra la presenza di difetti, ma non la loro assenza: vedi sopra, un Difetto potrebbe non rivelarsi mai in produzione in quanto non viene scatenato (per vari motivi).
2. Il testing esaustivo è impossibile: si usa la prioritizzazione e tecniche basate sul rischio per alzare la probabilità di aver trovato un buon numero di difetti.
3. Il testing anticipato permette di risparmiare tempo e denaro: nonchè uno dei principi di base dell’Agilità (early feedbacks a go-go). E mi viene da affermare: un semilavorato difettoso (es: una User Story poco curata) ha buona probabilità di generare un prodotto finito con ulteriori difetti.
4. I difetti si raggruppano in cluster. Un piccolo numero di componenti del sistema di solito contiene la maggior parte dei difetti rilevati. Un po’ il principio di Pareto o legge della L.. Ma si può anche riassumere: hai un’architettura software con un componente mal pensato, è probabile che i difetti software si “concentreranno” nei flussi dati che passeranno in un intorno di quel componente. Provare per credere.
5. I test perdono di efficacia. Una Test Suite “ferma” da 10 anni troverà meno difetti di quando è nata, per un semplice concetto evolutivo: è cambiato il sistema operativo, alcuni test non saranno più “affidabili”, ecc… serve manutenzione, soprattutto se si parla di Test Automation e di pipeline.
6. Il testing è dipendente dal contesto: ogni azienda ha un approccio diverso al testing. Una banca esegue Testing in un modo completamente differente rispetto ad una Web Agency. Una Web Agency Sud Coreana di medio livello del settore ortofrutticolo esegue test in modo differente rispetto ad una Web Agency “top di gamma” del settore della moda newyorkese.
7. L’assenza di difetti è un’idea sbagliata. Cito testualmente il Syllabus: “Il testing approfondito di tutti i requisiti specificati e la correzione di tutti i difetti rilevati potrebbe comunque portare al rilascio un sistema che non soddisfa le esigenze e le aspettative degli utenti, che non aiuta a raggiungere gli obiettivi di business del cliente, o che risulta inferiore rispetto ad altri sistemi concorrenti.”
   Punto e a capo, che dire…

Attività di Test, Testware e Ruoli del Test

Sebbene ogni attività di Test è specifica e dipende fortemente da molte variabili (più in generale, dal contesto di test), può essere comunque descritta da un processo generale, cosi costituito.

• Planning: si pianifica (nel verso senso strategico del termine.. a tavolino) l’attività di test, si considerano i rischi, quanto scendere nel dettaglio (per rispettare i constraint di budget e di tempo), dove vale la pena concentrare gli sforzi.
• Monitoring & Control: dopo il planning, si da il via alle danze con le attività principali. Che necessitano, nel pieno senso critico del termine, di un monitoraggio attivo e di un controllo. Ogni mattina è necessario svegliarsi e, dopo un sano caffè, ispezionare i risultati del test del giorno prima (monitoring): dai dati acquisiti si può decidere se intervenire (control) con azioni correttive / rafforzative. Tradizionalmente il processo di Monitoraggio e Controllo viene eseguito dal Test Manager, un responsabile dell’ufficio QA; negli ultimi anni l’agilità invita il Team Crossfunzionale ad auto-regolarsi, analizzando i risultati di test al momento dello stand-up e prendendo decisioni di comune accordo
• Test Analysis: questa fase risponde alla domanda “Cosa si deve testare“? Si studia la base di test (= tutti i documenti necessari che costituiscono i requisiti software) al fine di derivare le condizioni di test (= un aspetto del software, oggetto di test) e di calcolare il rischio.
• Test Design: questa fase risponde alla domanda “Come si deve testare”? Dopo aver analizzato i requisiti, si traducono le condizioni di test in Test Cases, mediante strumenti come ad esempio un Test Charter. Questa fase ha lo scopo di descrivere quali dati ho bisogno, quali ambienti di esecuzione, quali strumenti usare e come usarli.
• Test Implementation: questa fase raccoglie tutte le attività necessarie per creare i test, per scrivere gli script che saranno poi usati manualmente o automaticamente durante la fase di Test Execution. Si creano cosi procedure di test, organizzate in Test Suite, elenchi ordinati e prioritizzati di Test Cases. Viene creato l’ambiente di Test.
• Test Execution: finalmente si testa! Si eseguono le Test Suite in diverse modalità (es: continuous testing, pair testing, …). Si registra l’esecuzione (Test Log) e si confrontano i risultati ottenuti con i risultati attesi. Nel caso di un risultato non atteso (= failure) si traccia un Defect (finalmente!). I defects vengono analizzati per cercare di capirne la Root Cause, essenziale per innescare un Debugging.
• Test Finalization: accade in prossimità delle milestones di progetto. I risultati delle fasi di test vengono comunicati (Test Completion Report) agli stakeholder e archiviati, tutto il testware viene salvato in ottica futura (ripetibilità del test), vengono create le Change Requests o attività evolutive ulteriori, atte ad aumentare la qualità del software. Si riguardano le attività fatte e si riflette su come migliorare il processo in una futura occasione (lesson learned activity / retrospective).

Il Processo di Test nel Contesto

Le varie fasi descritte qui sopra non sono mai ripetitive: ogni attività di Test dipende fortemente dal contesto in cui accade. Sono infatti molti i fattori che possono influenzare il Testing:

• Stakehoders: tanto più uno stakeholder è esigente o ha aspettative elevate, tanto più l’esecuzione del test viene influenzata. E poi dipende molto da quanto uno stakeholder è disposto a collaborare (es: chi scrive / valida i requisiti?)
• Membri del team: le competenze, le conoscenze, il livello di esperienza ma anche il livello di team (= quanto tempo hanno lavorato insieie)…
• Dominio di business: testare un robot che opera a cuore aperto un paziente non è la stessa cosa che testare il software per la produzione di gelati industriali.
• Fattori tecnici: come sopra, anche il tipo di software e la sua architettura influenzano i test. Testare un software legacy, di nicchia, basato su tecnologie obsolete richiede test manuali. Il test invece di software basato su tecnologie moderne può basarsi su sistemi di test “nativi”, framework già integrati nell’IDE o molto vicino al SDLC.
• Vincoli di progetto: budget e risorse (umane, tempo, …) influiscono molto sui test da fare e sul determinare i fattori di rischio
• Fattori organizzativi: la struttura organizzativa, le politiche esistenti… ad esempio, potresti avere un team QA che “presta” risorse al team di sviluppo, ma facendo cosi risponde a due “padroni”: il manager della QA e il manager dello sviluppo. Chi risolve i conflitti?
• Ciclo di vita dello sviluppo software: testare in agilità non è come testare in waterfall, testare in XP non è come testare in approcci più tradizionali
• Strumenti: nell’azienda in cui lavoro, quando ancora mi occupavo di sviluppo software “da vicino”, ricordo di aver automatizzato un centinaio di casi d’uso della mobile app utilizzando Postman, in versione gratuita. Il tool permetteva già anni fa di eseguire “in un click” un completo test di no-regression ad ogni rilascio dell’app. In altre aziende, si faceva tutto a mano.

Testware

Nelle fasi di sviluppo si producono dei “deliverable”, degli strumenti di lavoro, dei documenti, … Tutto questo, prende il nome di Testware.

• Planning: test plan, schedulazione, risk register, input/output criteria
• Monitoring & Control: test progress report (= le e-mail che il Test Manager manda ogni sera alla fine delle sessioni di test…), documentazione o log delle decisioni / direttive di controllo (si, sono gli ordini di scuderia..)
• Test Analysis: condizioni di test prioritizzate, report sui difetti della base di test (= difetti sui requirements…). Molto interessante questo aspetto e devo dire che in azienda da me accade molto di raro.
• Test Design: Test Cases, Test Charter, elementi di copertura, requisiti dei dati e requisiti dell’ambiente.
• Test Implementation: procedure di test, Test Suite (manuali / automatizzate), dati di test (= si, le credenziali da usare…)
• Test Execution: test log e test report. Easy, come tenere un diario.
• Test Finalization: Test Completion Report, correctioni items (es: elenco di User Stories a Backlog), lesson learned.

Tracciabilità tra la Base di Test e il Testware

Il processo di Testing è un fluire di attività e dati strettamente correlati tra loro.

Si parte dai requisiti, e per ogni requisito, vi sono numerose attività: l’analisi, la progettazione dei test, la loro esecuzione.

I Defects individuati possono essere collegati ai fattori di rischio progettuali, al fine di valutarne mitigazioni o aggiornamenti del rischio di progetto.

Le User Stories a Backlog, risultato di un’attività di Retrospective durante la fase di Test Finalization, possono essere collegate ai requisiti che hanno originato i Defects alle quali sono collegate.

Insomma, in breve: è importante poter percorrere la Base di Test e il Testware, per poterne raccontare una storia e veicolare valore. Altrimenti si rischia di agire senza sapere il perchè.

Ruoli nel Testing

Il Syllabus è chiaro in questo. Ci sono 2 ruoli:

• Test Management: pianifica, controlla e monitora le fasi di test, finalizza. Ha la responsabilità generale (= di business…) del processo di Testing, è leader in campo nelle attività
• Testing: è il ruolo tecnico, ha la responsabilità generale dell’aspetto ingegneristico del Testing

Competenze fondamentali e buone pratiche nel Testing

Questo capitoletto si apre con una citazione. Che copio, pari pari, e faccio mia.

La competenza è l’abilità di fare bene qualcosa che deriva dalla conoscenza, dalla pratica e dall’attitudine.

ISTQB Syllabus 4.0

In altre parole: cosa serve per essere un buon tester?

Competenze Generiche Richieste per il Testing

• Conoscenza del testing (per aumentare l’efficacia del testing, ad esempio utilizzando le tecniche di test)
• Accuratezza, cautela, curiosità, attenzione ai dettagli, metodicità (per identificare i difetti,
  soprattutto quelli difficili da rilevare)
• Buone competenze di comunicazione, di active listening (ascolto attivo), di gioco di squadra (team player, per interagire efficacemente con tutti gli stakeholder, per trasmettere informazioni agli altri, per farsi capire, per segnalare e discutere i difetti)
• Pensiero analitico, pensiero critico, creatività (per aumentare l’efficacia del testing)
• Conoscenze tecniche (per aumentare l’efficienza del testing, per esempio utilizzando strumenti di
  test appropriati)
• Conoscenza del dominio (per essere in grado di comprendere e comunicare con gli utenti
  finali/rappresentanti di business)

Come si vede, i “cluster” di competenza sono divisi al 50% per “cose che uno impara a scuola” e per il restante 50% “cose che ognuno impara a vivere”. Le soft-skills sono fondamentali, il pensiero analitico-critico, l’attenzione, la metodicità… fantastico, sono tutte caratteristiche umane e sociali del buon tester.

Tra tutte, le competenze di comunicazione sono probabilmente le più importanti, in quanto dire a qulcuno “che il tuo software ha un bug”, non è una missione facile. Occorre far capire che la tua osservazione mira ad aumentare la qualità del software complessivo, o permette ai manager di compiere scelte basate sui dati, non alla cieca. Bisogna saper comunicare bene.

Approccio Whole-Team

Un tempo c’era la QA, che stava nei sotterranei dell’azienda, rispondeva al telefono solo se sollecitata e produceva tabulati di cose strane, che chissà come, venivano a stento capite (e penso anche lette) dallo sviluppatore che quel defect l’aveva pure causato.

Un approccio moderno, team-based, è quello derivato dalle tecniche XP / Agile. Un team cross-funzionale, dove ogni membro è capace di fare tutto (= di assumere ruoli diversi) facilita alcuni aspetti del Testing, la comunicazione in primis. Il team ha un obiettivo comune, ogni critica emersa in retrospettiva alimenta azioni correttive (= Continuous Improvement), i Daily Scrum mattutini mantengono il focus sul plan e attuano tempestivamente azioni correttive, il know-how è condiviso.

Ma non tutto è oro quel che luccica. Alcune aziende (es: quelle “a gestione famigliare nate ne”legacy”, gestioni famigliari radicate profondamente negli anni 50) possono fare più fatica nel perseguire un approccio whole-team. Amano i sotterranei e sono a loro agio con i tabulati. In questi casi, sarebbe più dannoso “strappare” il tessuto sociale inculcando con la forza approcci differenti rispetto a quella che è l’anima aziendale. Meglio procedere per step iterativi, incrementali, piccoli e misurabili. Ma è un’azione tutt’altro che nobile e tutt’altro che facile, a volte.

Indipendenza del Testing

Un criterio per cui l’approccio whole-team potrebbe non essere cosi efficace in alcuni casi è proprio il concetto di indipdendenza del Testing.

Durante un progetto, c’è chi scrive codice e testa unitariamente il prodotto del proprio lavoro. Poi la palla passa alla QA, che dopo aver analizzato i requisiti (e ahimè, questo accade ogni tanto in ritardo.,..) procede nella fase di attacco: mira a mettere in difficoltà il software, cercando più defects possibili. Passa il tempo e una versione “Release Candidate” del software diventa oggetto di un Penetration Test ad opera di una società esterna di consulenza, esperta di sicurezza informatica. In parallelo, partono gli User Acceptance Test, dove il Business prova in anteprima le nuove feature del prodotto, validandone l’adeguatezza “business” al requisito.

Diverso nei 4 casi citati è il grado di indipendeza:

• bassa indipendenza = chi ha scritto il codice o è vicino a chi ha scritto il codice (es: nello stesso team)
• media indipendenza = stessa azienda, ma settori e responsabilità differenti
• alta indipendeza = consulente esterno

Più bassa è l’indipendenza, più BIAS cognitivo ci sarà nel Testing, ma allo stesso tempo alta sarà la conoscenza del dominio, del modo di comunicare e di governare le dinamiche aziendali.

D’altro canto, più alta è l’indipendenza, meno BIAS cognitivo ci sarà nella fase di Test. Il sistema verrà testato senza pregiudizi, in modo più “asettico” ma allo stesso tempo si farà più fatica a comprenderne il dominio, a recepire requisiti non scritti, dati per scontati dal team di sviluppo (e capiti però dal membro interno della QA che lavora a stretto contatto con gli sviluppatori).

Siamo arrivati in fondo al primo capitolo, decisamente il più lungo della serie. Mi ci sono volute 3 sere per scrivere questa pagina, per un totale di circa 5h di lavoro. Circa 300 minuti, considerando che ho scritto e commentato (per iscritto), siamo vicini ai 180 minuti “consigliati” dal Syllabus per lo studio.

Prossimo capitolo: il Testing all’interno del ciclo di sviluppo software