Implementazione nuove funzionalità CRM: Procedure di esecuzione Test
Qui di seguito sono riportate alcune informazioni di natura metodologica relativamente ai vari test e procedimenti da eseguire nel processo di implementazione delle funzionalità per lo sviluppo e la personalizzazione di un CRM.
- Requisiti Utente: REQUISITI CLIENTE e ANALISI FUNZIONALITA’
- Requisiti di Sistema: ANALISI TECNICA
- Requisiti del Software: PROGETTO ESECUTIVO D’IMPLEMENTAZIONE
- Sviluppo
- Verifiche
Ecco uno schema esaustivo di quanto sopra elencato (Fonte: ing. E. Tramontana – Ingenieria del software), che riporta gli input ed i ruoli/persone coinvolte nel processo:
Riporto qui di seguito il dettaglio delle tipologie di verifica e di Test che sono necesarie, sia durante la fase del PROGETTO ESECUTIVO D’IMPLEMENTAZIONE (test sui prototipi) che, ovviamente, durante e dopo la fase di SVILUPPO/PRODUZIONE/IMPLEMENTAZIONE.
A. TEST FUNZIONALI (o di funzionalità)
Servono per confermare le funzionalità implementate in rapporto alla lista delle specifiche.
Chi fa il test non conosce i dettagli della programmazione ma i risultati attesi
· Tale test deve garantire il funzionamento di quanto sviluppato.
· Tale funzionamento è riscontrabile dalle documento di ANALISI TECNICA, funzionalità ad esempio, del v-CRM
· Si conviene che i Test Funzionali si articolino in tre tipologie, dalla più semplice alla più complessa: il test di funzione, test di modulo e test d’integrazione.
· TEST DI FUNZIONE
test effettuato dallo sviluppatore direttamente al rilascio della funzionalità sviluppata (pagina, task o insieme di task componenti una funzionalità)
In tal caso i BUG rilevati dal TEST FUNZIONALE, dovranno essere risolti all’interno del task di sviluppo (senza creare un apposito item)
Per le funzionalità che hanno una certa complessità, il test funzionale deve essere effettuato i TEST DI MODULO
Importante: in questa fase l’approccio migliore è quello di adottare il Test Driven Development (TDD) (vedi anche Blogs.ugidotnet>>)
· TEST DI MODULO
effettuata da un altro collega sviluppatore
In tal caso i BUG rilevati dal TEST FUNZIONALE, rileverà la seguente tipologia avranno (prevalentemente) la seguente codifica/type nell’ambiente di sviluppo (esempio TFS – Visual Studio 2005 Team Foundation Server):
A1 – Errore di funzionamento
A2 – Errore di comportamento (eventuale
Pre-test delle componenti:
verifica ciascuna componente della pagina web prima dell’assemblaggio e dell’integrazione
· TEST D’INTEGRAZIONE
effettuata dal responsabile tecnico
In tal caso il test rileverà la seguente tipologia dei BUG rilevati dal TEST FUNZIONALE avranno (prevalentemente) la seguente codifica/type nell’ambiente di sviluppo (esempio TFS – Visual Studio 2005 Team Foundation Server):
A1 – Errore di funzionamento
A2 – Errore di comportamento (eventuale)
B1 – Funzionalità/Adeguatezza
B2 – Funzionalità/Interoperabilità
B3 – Funzionalità/Aderenza standard
E – Affidabilità
F2 – Qualità d’uso/Sicurezza
· TEST DI RILASCIO (Deployment):
test di carico:
si simulano un gran numero di accessi simultanei per verificare i limiti di carico di lavoro che il server riesce a sostenere
controllo finale:
svolto a posteriori, dopo aver effettuato il debugging. Garantisce che tutti i bug siano stati coretti e che il codice funzioni dopo le correzioni.
test di sicurezza:
verifica che hacker e accessi illeciti ai dati raccolti siano esclusi
B. ALFA TEST
Rientrano in questi test:
testing informale:
senza un piano formalizzato, è quello più frequentemente utilizzato
alpha testing:
è il controllo iniziale di un sito dopo il completamento di produzione e funzionalità (e dei test funzionali) che avviene prima della pubblicazione
Test che serve a riscontrare quanto segue:
L’adeguatezza, la comprensibilità, la navigazione, ecc. ed altri requisiti di usabilità
Tale test viene effettuato successivamente al TEST FUNZIONALI.
Tale test viene effettuato da personale diverso dagli sviluppatori, personale interno, che tende a simulare il comportamento degli utenti finali
Tipologia dei BUG rilevati dall’ALFA TEST avranno (prevalentemente) la seguente codifica/typenell’ambiente di sviluppo (esempio TFS – Visual Studio 2005 Team Foundation Server):
C – Usabilità/Comprensibilità
D1 – Usabilità/Apprendibilità
D2 – Usabilità/Operabilità
D3 – Usabilità /Attrattività
D4 – Usabilità /Conformità
F1 – Qualità d’uso/Produttività
F2 – Qualità d’uso/Sicurezza
F4 – Efficienza
G – Nuova Feature
H – Personalizzazione
I – Altro
C. BETA TEST
Rientrano in questi test tutto ciò che riguarda la User Experience:
test di utilizzo:
è un’analisi delle effettive interazioni tra utente e software/sito. Sono stabiliti dei task da raggiungere e l’utente è osservato direttamente
· user acceptance:
è una batteria di test che dipendono dalle caratteristiche del progetto e hanno l’obiettivo di verificare la rispondenza ai requisiti degli utenti
· check up contenuti:
controllo dell’esatta collocazione e correttezza dei contenuti pubblicati (testi, labelling e immagini)
· beta testing:
controllo finale di tutto il software/sito appena prima del lancio (quando il software/sito è stato già caricato sul server)
· Test che servono a rilevare i requisiti di accessibilità e di usabilità.
Tale test viene effettuato dai KeyUser (rappresentanti di categorie di utenti finali)
· Tipologia dei BUG rilevati BETA TEST avranno (prevalentemente) la seguente codifica/type nell’ambiente di sviluppo (esempio TFS – Visual Studio 2005 Team Foundation Server):
C – Usabilità/Comprensibilità
D1 – Usabilità/Apprendibilità
D2 – Usabilità/Operabilità
D3 – Usabilità /Attrattività
D4 – Usabilità /Conformità
F1 – Qualità d’uso/Produttività
F3 – Qualità d’uso/Soddisfazione
F4 – Efficienza