Implementazione nuove funzionalità CRM: Procedure di esecuzione Test

Riportiamo qui di seguito alcune indicazioni metodologiche circa l'esecuzione dei test da effettuare nell'implementazione e sviluppo di nuove funzionalità per un CRM Personalizzato.

Analisi e documentazione necessria per l'implementazione di nuove funzionalità per il CRM:

1. REQUISITI CLIENTE e ANALISI FUNZIONALITA'
   • Da questa documentazione è possibile ricavare/elaborare:
   • un maggior dettaglio circa le architetture logiche ed il dettaglio dei requisiti
   • un primo PREVENTIVO COMMERCIALE
     • stima di massima del totale dei tempi di realizzazione in gg/uomo,margine di errore valutabile intorno al 30-40%
2. ANALISI TECNICA
   • Fattibilità di implementazione rispetto alle funzionalità ed ai requisiti cliente
     • Da questa analisi è possibile ricavare una stima del con a margine di errore valutabile intorno al 20-30%
3. PROGETTO ESECUTIVO D'IMPLEMENTAZIONE (creazione classi ed oggetti UML, prtototipi e test sui prototipi, ecc.)
   • Da questa analisi è possibile ricavare una stima del con margine di errore valutabile intorno al 10%
4. SVILUPPO/PRODUZIONE/IMPLEMENTAZIONE
   
5. VERIFICHE/TEST

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 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 e immagini)
  • beta testing:
    controllo finale di tutto il sito appena prima del lancio (quando il 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

Leonardo Milan