Suggerimenti per attività di test, debugging e deployment
Gestione team di sviluppo e della gestione dei test e del deployment.
TEST FUNZIONALE (o di funzionalità)
Tale test deve garantire il funzionamento di quanto sviluppato
- Nel caso del CMS tale funzionamento è riscontrabile dalle funzionalità definite nel doc.Requirements in fase di completamento
- N.B.: nel doc.Requirements dovranno essere evidenziati i QoS – Quality of Services e/o altri parametri dell’e-Business Model (es.: KPI – Key Performance Indicator)
- Test effettuato dallo sviluppatore direttamente al rilascio della funzionalità sviluppata (pagina, task o insieme di task componenti una funzionalità), da ogni sviluppatore.
- In tal caso i BUG rilevati dal TEST FUNZIONALE, dovranno essere risolti all’interno del task di sviluppo (senza creare un apposito item nel “PROGRAMMA DI GESTIONE BUG”)
TEST di INTEGRAZIONE FUNZIONALE
(inserimento della funzione sviluppata in + funzioni e/o moduli)
Per le funzionalità che hanno una certa complessità, il test funzionale deve essere effettuato:
(1) Dal responsabile tecnico.
- In tal caso il test rileverà la seguente tipologia dei BUG rilevati dal test di INTEGRAZIONE FUNZIONALE avranno (prevalentemente) la seguente codifica/type nel “PROGRAMMA DI GESTIONE BUG”:
- (i) A1 – Errore di funzionamento
- (ii) A2 – Errore di comportamento (eventuale)
- (iii) B1 – Funzionalità/Adeguatezza
- (iv) B2 – Funzionalità/Interoperabilità
- (v) B3 – Funzionalità/Aderenza standard
- (vi) E – Affidabilità
- (vii) F2 – Qualità d’uso/Sicurezza
(2) Oppure da una altro collega sviluppatore, nel caso del CMS, in futuro tale test funzionale sarà effettuato dal Responsabile Tecnico.
- In tal caso i BUG rilevati dal test di INTEGRAZIONE FUNZIONALE, rileverà la seguente tipologia avranno (prevalentemente) la seguente codifica/type nel “PROGRAMMA DI GESTIONE BUG”:
- (i) A1 – Errore di funzionamento
- (ii) A2 – Errore di comportamento (eventuale)
ALFA TEST
i) Test che serve a riscontrare quanto segue:
(1) L’adeguatezza, la comprensibilità, la navigazione, ecc. ed altri requisiti di usabilità
ii) Tale test viene effettuato successivamente al TEST di INTEGRAZIONE FUNZIONALE
iii) Tale test viene effettuato da personale diverso dagli sviluppatori, personale interno, che tende a simulare il comportamento degli utenti finali
- Nel caso del CMS tale test è stato effettuato dal Team Manager
iv) Tipologia dei BUG rilevati dall’ALFA TEST avranno (prevalentemente) la seguente codifica/type nel “PROGRAMMA DI GESTIONE BUG”:
- (1) C – Usabilità/Comprensibilità
- (2) D1 – Usabilità/Apprendibilità
- (3) D2 – Usabilità/Operabilità
- (4) D3 – Usabilità /Attrattività
- (5) D4 – Usabilità /Conformità
- (6) F1 – Qualità d’uso/Produttività
- (7) F2 – Qualità d’uso/Sicurezza
- (8) F4 – Efficienza
- (9) G – Nuova Feature
- (10)H – Personalizzazione
- (11)I – Altro
BETA TEST
i) Test che serve a rilevare i requisiti di usabilità e di accessibilità
ii) Tale test viene effettuato dal PMO – Project Manager e/o dal cliente (e dai KeyUser rappresentanti di categorie di utenti finali, in caso di progetti complessi)
iii) Tipologia dei BUG rilevati BETA TEST avranno (prevalentemente) la seguente codifica/type nel “PROGRAMMA DI GESTIONE BUG”:
- (1) C – Usabilità/Comprensibilità
- (2) D1 – Usabilità/Apprendibilità
- (3) D2 – Usabilità/Operabilità
- (4) D3 – Usabilità /Attrattività
- (5) D4 – Usabilità /Conformità
- (6) F1 – Qualità d’uso/Produttività
- (7) F3 – Qualità d’uso/Soddisfazione
- (8) F4 – Efficienza
AUTORIZZAZIONI E DEPLOYMENT/GO-LIVE
a) Ambito di applicazione:
- Deployment di software
- Deployment di funzionalità nuove di software esistenti
- Go-live per la pubblicazioni di pagine, siti, apertura agli spider, ecc..
b) Cliente esterno:
Le autorizzazioni di go-live devono essere date nel seguente modo/WorkFlow :
(1) Una volta effettuato l’iter di TEST – DEBUGGING sopra riportato:
- Viene chiesto al cliente di effettuare un beta-test finale
- Viene chiesta l’autorizzazione al cliente (da parte del commerciale e/o dal PMO – Project Manager)
- Il cliente autorizza il fornitore a mezzo e-mail
- Il PMO – Project Manager (o altro responsabile previsto dai WorkFlow codificati) autorizza il Team Manager a mezzo e-mail o avanzamento di stato nei WorkFlow automatizzati.
(2) Si procede per il go-live
c) Cliente interno dell’azienda:
Il personale tecnico non è tenuto a rilevare a propria discrezione le differenze di procedura tra richieste provenienti da clienti esterni e da richieste da clienti interni.
Ritengo, quindi, che il committente interno vada trattato come un cliente e pertanto uno sviluppatore, webmaster NON debbano assumersi la responsabilità di pubblicare pagine, sito o altro SENZA l’autorizzazione del cliente (sempre a mezzo e-mail).
Questa è una regola che prevede un normale WorkFlow di produzione, quale sia l’output. Si possono prevedere delle eccezioni, certo, ma che non vedano l’area tecnica responsabile della pubblicazione/output (senza un controllo di qualità o altre validazioni, ciò non vuol dire che debba essere io a farle, ben inteso).
Ogni area di eccezione prevede che le risorse non adottino un metodo e/o un processo, ma che lo interpretino a seconda della eccezione.