Quality assurance, or QA for short, refers to a program for the systematic monitoring and evaluation of the various aspects of a project, service, or facility to ensure that standards of quality are being met.
fonte wikipedia
Sarà che sono sempre stato abbastanza sensibile all’argomento (vedi anche il mio ultimo talk al phpDay 2010) e che ho sempre pensato al mio lavoro su criteri molto simili a quelle citati nel craftsmanship manifesto, ma ultimamente (diciamo nell’ultimo anno) mi pare che sempre più persone (e personaggi) che vivono nell’enorme calderone del mondo agile/xp/dialetti-vari parlino di QA.
Il problema è che, imho, ognuno riporta la QA al proprio mondo dimenticandosi di tutte le altre sfaccettature e che spesso QA nel mondo agile venga intesa in termini di code coverage.
Più volte ho parlato con sviluppatori estremi che affermano che se un software ha code coverage superiore a X% allora la QA è un processo inutile. Come fanno notare però gli UX-ari un software può anche funzionare egregiamente ma se l’output restituisce testo rosa su sfondo rosso, o l’interfaccia sia usabile girando il monitor di 62°, si può dire di qualità? Non penso.
Parallelamente chi si occupa di UX si aspetta test funzionali e/o di accettazione (ed aspetta a lungo, perchè non li vuole scrivere) sul prodotto finito fatti più o meno automagicamente (dai poveri sviluppatori già oberati da altri compiti?). Magari facendo svolgere gli stessi test anche ad un team di persone prese dalla strada, che però non si accorgeranno mai se il computo delle tasse è stato fatto bene o meno (a meno che non siano commercialisti, ma anche in questo caso la % di incertezza è alta).
Non dimentichiamoci dei copywriter, che vorranno fare un controllo maniacale dei testi, delle label e della maggior parte delle forme di comunicazione verbali del sito, togliendo la qualità ai webdesigner, e dei sistemisti che vorranno che il server sia conforme alle specifiche dettate e che il software non usi più risorse del dovuto, alla peggio impediamo agli utenti di accedere… Infine non parliamo di chi fa SEO che ha un concetto di qualità (del codice) divergente dal resto del mondo.
Pertanto la QA è appunto una valutazione dei vari aspetti di un progetto e significa che è un processo MULTIDISCIPLINARE, COSTOSO, (spesso) WATERFALL e per alcuni aspetti difficilmente AUTOMATIZZABILE. E soprattutto è un processo di MEDIAZIONE che necessita di un know-how sufficiente ad anticipare i problemi. E solo ad anticiparli in quanto risolverli è compito degli sviluppatori.
Bisogna ricordare che la Quality Assurance, attività da svolgere durante lo sviluppo per ridurre il rischio di difetti, non è il Quality Control, attività focalizzate a validare il (codice) prodotto subito prima del rilascio, e che oggi molte aziende confondono i due processi. Denny Stevens spiega molto bene cosa significa in un suo articolo intitolato “we are doing QA all wrong“.
Pertanto mettetevi l’animo in pace, se dovete (e vi assicuro che dovete) fare QA armatevi di pazienza e fatela, possibilmente con il cliente ed un team ad essa dedicata, su tutte le sfaccettature del progetto e durante tutto il processo di lavoro.
Non c’è nessuna scorciatoia, esistono solo limiti dati dal budget e dalla capacità di lavorare bene (ed in questo caso appoggio in pieno tdd, hudson, selenium, fitness e tutto il resto) per ridurre i possibili problemi.