testing

Come conviene nominare le funzioni, come conviene nominare i test?

Secondo Kent Beck ci sono buone ragioni per preferire nomi corti (ma non troppo) per le funzioni, nomi più lunghi per i test, anche quando i test, nei framework di automazione, vengono specificati come "funzioni".

"La Quality Assurance (operare con un alto livello di qualità) è molto più efficace del Quality Control (controllare il livello di qualità quando si ha finito di operare). Meglio introdurre criteri di usabilità dall'inizio - ancora prima di iniziare la progettazione - che aspettare fino a quando il sistema è completo per poi sottoporlo ad una validazione nel testing utente."

Jacob Nielsen, esperto di usabilità, in questo articolo su Quality Assurance e User Experience ricorda anche quella che chiama la "prima legge dell'usabilità":

"La vostra progettazione sarà comunque testata dagli utenti - potete solo scegliere se fare voi stessi i test prima del rilascio, per mettere a posto a costi inferiori gli inevitabili problemi, oppure spendere molto di più dopo il rilascio."

"Separare completamente le responsabilità sul testing da quelle sullo sviluppo, creando gruppi rigidamente distinti per le due attività, produce sistemi con minore qualità", sostiene Elisabeth Hendrickson in questa intervista sull'organizzazione delle attività di testing, sull'automazione dei test di accettazione e sugli strumenti utili per il testing.

"ATDD by Example: A Practical Guide to Acceptance Test-driven Development" , di Markus Gärtner, è una introduzione alle pratiche di automazione dei test di accettazione funzionale. Tratta sia i concetti generali che gli aspetti relativi alle tecnologie da usare. Consigliato.

Nei display dei vagoni del Frecciarossa, usati per proiettare vari messaggi di autocompiacimento, Trenitalia in questo periodo afferma di aver ricevuto due premi internazionali per la qualità della propria Information Technology.

Immagino ne stia per arrivare anche uno sull'usabilità, vista la chiarezza di questo messaggio:

Il rapporto tra requisiti, casi d'uso e test è centrale per lo sviluppo software.

L'individuazione e la descrizione dei casi d'uso sono attività molto efficaci per agevolare la scoperta dei requisiti, e per favorire una validazione degli scenari di utilizzo da parte degli stakeholder. Ma i casi d'uso, in sé, non sono requisiti, e certamente non sono sufficienti per scoprire tutti i requisiti.

D'altro lato, la definizione precoce dei test di accettazione è eccellente per eliminare le ambiguità dai requisiti, perché costringe a precisarli. Ma i test non possono essere sostituiti ai requisiti.

Il rapporto tra requisiti, casi d'uso e test (oggetto dei miei corsi "Gestione dei requisiti con i casi d'uso" e "Test di sistema e di accettazione") è descritto in dettaglio da Bertrand Meyer. Vale la pena leggere tutto il suo intervento, di cui riporto il passo centrale:

"The insight, which has significantly improved the practice of software development, is that the regression test suite is a key asset of a project and that tests should be run throughout. The bad advice is to ditch upfront requirements and specifications in favor of tests. The property that tests lack and specifications possess is generality. A test is an instance; a thousand tests can never be more than a thousand instances. [...] the relationship is not symmetric: one can generate tests from a specification, but not the other way around.

The same relationship holds between use cases and requirements. It is stunning to see how many people think that use cases (scenarios) are a form of requirements. As requirements they are as useless as one or ten values are to defining a function. Use cases are a way to complement the requirements by describing the system’s behavior in selected important cases. A kind of reality check, to ensure that whatever abstract aims have been defined for the system it still covers the cases known to be of immediate interest. But to rely on use cases as requirements means that you will get a system that will satisfy the use cases — and possibly little else."

CAST è la Conference of the Association for Software Testing. Conferenza annuale, che nel 2012 si è tenuta a San Jose, USA, dal 16 al 18 luglio.

I video della conferenza CAST2012 sono disponibili su YouTube. Interessante in particolare la keynote di Elisabeth Hendrickson, The Thinking Tester Evolved.

Sempre da CAST2012, da seguire l'intervento Software Metrics: Threats to Validity di Cem Kaner sulla validità delle metriche usate nell'ingegneria del software, ed in particolare nel testing.

"Più di metà degli apparecchi medici venduti in America (il maggior mercato di strumenti medici) è basata su software, spesso su molto software. Il software di un pace-maker può contenere oltre 80.000 righe di codice, un infusore di farmaci 170.000, e un apparato per la risonanza magnetica oltre 7 milioni di righe di codice."

L'affidabilità di questo software è ovviamente critica. Uno studio condotto su apparati venduti negli USA dal 1999 al 2005 ha scoperto che un terzo di tali apparati sono stati tolti dal servizio per problemi legati al software.

Una strada per rendere il software medico più affidabile potrebbe essere l'open source, per permettere una migliore visibilità e la possibilità di esaminare il codice. Purtroppo, i regolamenti di approvazione del software stabiliti dagli enti di validazione (come la FDA, la Food and Drug Administration degli USA) sono fatti in modo da scoraggiare il ricorso alle pratiche collaborative tipiche dell'open source.

"When code can kill or cure", The Economist, Technology Quarterly, June 2nd 2012.

La copertura dei test indica quali porzioni del codice software non sono controllate da test. Ma non è un indicatore assoluto di qualità del software.

Su questo, oltre a un classico (1997) di Brian Marick, un recente articolo di Martin Fowler.

Black Box Software Testing (BBST) è una serie di corsi online creati da Cem Kaner e gestiti dalla Association of Software Testing (AST).

I corsi della serie sono:

• Foundations - Introduzione alle tematiche principali del testing del software
• Bug Advocacy - Gestione del rapporto tra chi fa test, chi sviluppa, e gli altri ruoli coinvolti nei progetti software
• Test Design - Panoramica e confronto tra le tecniche di progettazione dei test

Sono corsi impegnativi (anche Foundations), progettati con un'attenzione particolare agli aspetti didattici e formativi, molto utili. Sia per chi si sta avvicinando al testing che per chi già lo pratica a livello professionale.

Una descrizione più approfondita in questo articolo di Cem Kaner.