MODEL-DRIVEN TESTING PER L’ACCESSIBILITÀ

In questo post propongo di adottare i metodi del model-driven testing anche per testare aspetti di accessibilità di interfacce utenti web.

L’idea di base è di usare modelli della dinamica dell’interfaccia, basati su macchine a stati UML, e automaticamente compilare tali modelli producendo codice sorgente Java che pilota WebDriver di Selenium.

Nei suoi post Karl Groves sostiene che i test di accessibilità di un sito Web potrebbero essere inquadrati nel contesto dei test del software e quindi potrebbero essere basati sugli stessi strumenti e pratiche adottati dagli sviluppatori. In particolare suggerisce di utilizzare il servizio Tenon e di costruire script di test per l’accessibilità conformi a determinati standard in modo che questi script possano essere eseguiti automaticamente e produrre automaticamente rapporti di test; anche incluso in servizi di integrazione continua come Jenkins.

I vantaggi previsti per gli sviluppatori sono che possono eseguire questi test automaticamente ogni volta che viene resa disponibile una nuova build del sito, e quindi sapere se le modifiche applicate influiscono in qualche modo sullo stato di accessibilità del sito web.

In questo post vorremmo fare un passo avanti ed esplorare alcuni problemi relativi alle idee dei test basati su modelli. Il test model-driven è la pratica di utilizzare modelli e derivare automaticamente da essi il codice sorgente del sistema di test-harness (TH) (nel nostro caso gli script di test e l’eventuale infrastruttura di test) che può essere utilizzato per testare un altro sistema, il sistema -under-test (SUT), nel nostro caso il sito/webapp.

Il TH è necessario per far fronte alla fragilità degli script di test rispetto ai cambiamenti nei dettagli dell’implementazione dell’interfaccia utente. Se dovessimo seguire un approccio di registrazione e riproduzione (come quando si utilizza Selenium IDE per registrare una sessione di interazione dell’utente e quindi riprodurla di nuovo), gli script risultanti sarebbero entrambi:

non parametrici rispetto ai dati, richiedendoci di aggiungere variabili e parametri, oltre a dataset, in modo che lo stesso script possa essere riutilizzato più di una volta; come uno script di accesso che potrebbe accettare più di un set di credenziali e fragili contro i cambiamenti nella struttura del DOM: infatti, gli script di test registrati farebbero riferimento a ID di elementi specifici, espressioni XPATH o selettori CSS per identificare elementi nel DOM al fine di attivare collegamenti o pulsanti o valutare asserzioni di test. Qualsiasi modifica nel DOM potrebbe potenzialmente interrompere la maggior parte dei nostri script di test, richiedendoci di mantenere ed eseguire il debug non solo del SUT, ma anche degli script di test e del TH.

Il TH potrebbe aiutare a ridurre tale onere di manutenzione, fornendo astrazioni appropriate che isolano questi dettagli dal codice. Analogamente all’approccio degli oggetti di pagina utilizzato quando si applica Selenium ai siti Web, qui suggeriamo di seguire un approccio che potrebbe essere chiamato oggetti di stato, in cui ogni stato identifica uno stato dell’interfaccia utente di SUT.

Le caratteristiche e i benefici attesi da queste pratiche sono che:

il codice sorgente può essere generato automaticamente dai modelli, e quindi può essere eseguito gratuitamente tutte le volte che è necessario;

i casi di test sono indipendenti dai dettagli di come l’interfaccia utente è implementata; di conseguenza possono essere facilmente scritti, possono essere riutilizzati attraverso i cambiamenti dell’interfaccia utente, sono stabili contro molti cambiamenti dell’interfaccia utente;

i casi di test possono essere resi parametrici, con dati specificati separatamente dagli script, in modo che questi possano essere riutilizzati;

non sono necessarie particolari competenze per scrivere il TH né i casi di test.

Sebbene in molti casi queste pratiche basate su modelli siano utilizzate per test comportamentali o di accettazione, qui vogliamo esplorare la loro fattibilità nel contesto dell’accessibilità.

Concentriamoci su un esempio concreto.

Un tipico selettore di date, un componente dell’interfaccia utente che richiede funzionalità di accessibilità.

La figura mostra il componente dell’interfaccia utente di un sito web; il componente implementa un selettore di date. Da un punto di vista funzionale, il selettore di date può essere utilizzato per selezionare una data del mese corrente, per selezionare la data odierna, per spostarsi avanti e indietro tra i mesi, per aprire un sottomenu (tramite il menu a discesa sul nome del mese) e scegliere un data particolare del mese selezionato o chiudere il sottomenu.

Questo è esattamente il comportamento rappresentato nel modello mostrato di seguito.

Il modello è scritto come una macchina a stati UML. Lo stato ChooseADate è lo stato iniziale (per questo widget) quando l’interfaccia utente mostra solo il campo di testo, dal quale l’azione dell’utente chiamata StartTyping porta allo stato TypingDate dove l’utente effettuerebbe ripetutamente Digitando per comporre la data; se la data è Valida l’utente può completarla digitandola e tornare a ChooseADate. In alternativa, l’utente può aprire il selettore di date e poi ChooseADay(d) (dove d è il parametro che contiene il giorno effettivo del mese), oppure può OpenMenuData (facendo clic sul nome del mese) e da lì scegliere direttamente un anno o mese o chiuderlo.

Modello di macchina a stati UML della dinamica dello state picker.

Si noti che in tale modello non viene fatto alcun riferimento ai dettagli dell’interfaccia utente, come i nomi dei collegamenti, i locatori come espressioni XPATH oi selettori CSS. Infatti questi dettagli sono rappresentati separatamente in file di configurazione che associano stati e transizioni del modello a questi localizzatori.

Scrivere il TH è quindi solo questione di creare classi (se usiamo un linguaggio orientato agli oggetti per rappresentare il TH, ad esempio Java) e le loro operazioni per ciascuno degli stati che descrivono il SUT. Anche se questo può essere fatto manualmente, lo facciamo attraverso uno strumento che abbiamo sviluppato chiamato GENTEC (Generator of TEst Cases).

Una volta che il TH è pronto, ciò che resta da fare è scrivere i casi di test effettivi. Ma ora è facile, grazie all’alto livello di astrazione fornito dal TH. In effetti, l’ingegnere di test potrebbe ora fare riferimento a stati e transizioni e i casi di test risultanti sarebbero esenti dai problemi sopra menzionati. Ogni test case potrebbe essere inquadrato come test jUnit, ad esempio, in modo che possa essere eseguito da uno dei tanti motori di test (come attività Ant, all’interno di IDE come Eclipse, all’interno di strumenti di integrazione continua come Jenkins).

Ad esempio, per verificare che quando viene digitata una data errata appare un messaggio di errore appropriato e la data non viene accettata, si potrebbe scrivere:

sut.initialize();

sut.action(“StartTyping”);// sposta il focus sul campo di testo

sut.action(“Digitazione”, “22/05/9999”);// inserisci un anno errato

sut.action(“Digitazione completa”); // premi invio

sut.stateIs(“Data di battitura”); // controlla che lo stato risultante sia …

sut.check(“errorMessageContains”, “anno non corretto”);

In alternativa, per una data corretta lo script potrebbe essere:

sut.initialize();

sut.action(“StartTyping”);// sposta il focus sul campo di testo

sut.action(“Digitazione”, “22/05/2014”);// inserisci un anno corretto

sut.action(“Digitazione completa”); // premi invio

sut.stateIs(“ChooseADate”); // controlla che lo stato risultante sia …

sut.check(“NoErrorMessage”);

Questi sono casi di test che verificano la correttezza della funzionalità del SUT. È possibile scrivere altri casi di test per verificare se sono presenti funzionalità di accessibilità appropriate. Per esempio:

sut.initialize();

sut.stateIs(“ChooseADate”);

sut.check(“tableHasTH”, “ext-gen276”);// id della tabella

dove l’ultimo check() è definito nei termini del seguente frammento di codice (assemblato automaticamente da GENTEC dalle specifiche di configurazione appropriate):

// controlla che la tabella contenga tag TH

String selectorKey = “//table/tbody/th”;

Per selettore = Per.xpath(selectorKey);

List eltList = sut.findElements(selector);

assertNotNull(String.format(“Impossibile trovare TH per la tabella %s”, tableId), eltList;

sut.log(“controllato TH %s”, nome); // aggiungi una voce di registro

Un controllo simile può essere scritto per assicurarsi che gli elementi TH abbiano gli attributi di ambito appropriati:

// controlla che la tabella contenga tag TH con attributi scope

String selectorKey = “//table/tbody/th[@scope]”;

Per selettore = Per.xpath(selectorKey);

List eltList = sut.findElements(selector);

assertNotNull(String.format(“Impossibile trovare TH con attributo scope per la tabella %s”, tableId), eltList;

sut.log(“controllato TH[@scope] %s”, nome);// aggiungi una voce di registro

Notare che il tecnico del test non deve mischiarsi con i dettagli dell’interfaccia utente, che sono tenuti separati dal codice TH e dai casi di test effettivi (ed espressi come clausole XML).

Per riassumere, crediamo che i vantaggi di seguire questo approccio di “modellazione profonda” siano i seguenti:

I modelli sono indipendenti dalla piattaforma di test e potrebbero essere riutilizzati per testare ad esempio app web tramite Selenium Webdriver (come abbiamo fatto qui) o tramite QTestLib o Android Test Framework.

I modelli sono indipendenti dai dettagli di implementazione dell’interfaccia utente e il TH risultante potrebbe essere riutilizzato molte volte. Se il comportamento dell’interfaccia utente dovesse cambiare, allora dovremmo modificare i modelli, adattare alcuni dei casi di test e le clausole di configurazione e rigenerare il TH.

I modelli sono formulati utilizzando un linguaggio standard, UML e diagrammi di stato UML.

A causa delle interfacce fornite dal TH, i casi di test sono anche indipendenti dai dettagli dell’interfaccia utente, fornendoci un codice stabile e potenzialmente solido, facilmente riutilizzabile. I casi di test sono anche parametrici con dati che possono essere forniti in forma tabellare, come in Cucumber.

I test case di accessibilità possono essere definiti come qualsiasi altro test funzionale e quindi possono essere eseguiti come qualsiasi altro test case dai motori di test.

I casi di test di accessibilità possono essere specifici quanto necessario e fare riferimento ad aspetti profondi dell’interfaccia utente, riducendo quindi il numero di falsi positivi che di solito sono associati ai test automatizzati di accessibilità.