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à)

image 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)

image 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.

Leonardo Milan

Project Natal e Microsoft's Vision For 2019: la nuova frontiera dell’usabilità.

Riporto qui di seguito un’interessante novità ed evoluzione nel mondo dei video giochi che potrà portare interessanti novità anche nel mondo web e della fruizione dei media digitali in generale. Sono due video divertenti ma che nascondono importanti novità circa le tendenze e gli scenari strategici dell’usabilità e della convergenza digitale. I siti web consumer e di entertainment dovranno tener conto – secondo me a partire già dal 2010-2011 – della nuova esperienza d’uso che si sta lanciando con la sfida nei video giochi: l’interfaccia vuoi che sia un joystick, una tastiera o un mouse tendono ad essere superati da nuovi strumenti che riconoscono il movimento delle mani (e non solo): è la che prende il sopravvento.

Project Natal”: motion controller for Xbox 360

La nuova versione XBox prevista per il 2010

[youtube=http://www.youtube.com/watch?v=7wuUKGrT5rk&hl=it&fs=1&]

 

Questo video è interessante perchè pone la X-Box e i video game in generale, a traino di due aspetti che possono interessare gli utenti internet/web:
– Abilita una nuova frontirea dell’usabilità. Ben inteso la novità non è mai solamente tecnologica, ma è nell’uso (customer experience) e nella sua diffusione.
– Abilita anche una spinta alla convergenza. In questo caso la convergenza che viene spinta è quella PC-Televisore (nei video game è usato com monitor).
Sono convinto che se il canale di diffuzione del futuro sarà il cavo al posto dell’antenna o della parabola … (questo aspetto merita ben altro approfondimento), sarà anche vero che il televisore sarà sempre più convergente con i dispositivi computazionali (i PC, notebook, ecc.) che abbiamo in casa.

Microsoft’s Vision For 2019

La futura interazione mobile-desktop secondo Microsoft:

[youtube=http://www.youtube.com/watch?v=XiqgmAYrd3c&hl=it&fs=1&]

 

Mi ricordo che nel lontano 1993, alla SDA Bocconi ci vecero vedere un video simile, sempre della Microsoft, dove si illustrava la possibilità di condivisione dei documenti e delle informazioni aziendali a livello planetario. In quel video, tra l’altro la Microsoft non considerava internet come il driver/mezzo della condivisione ma la intranet aziendale.
Ovviamente l’enfasi era Server Microsoft centrica, applicativi e sistemi compatibil e integrati (è la forza della corporate americana). In quel video c’erano, col senno di poi, gli elementi che poi si sarebbero realizzati con la piattaforma Unified Communications e con la tecnologia VoIP.
Nella realtà si è realizzata la convergenza PC-Mobile con gli Smartphone ed è stata tutta un’altra storia. Perchè? Perchè innanzitutto la Microsoft NON poteva presidiare/controllare lo sviluppo del mobile (allora, nel 1993, i cellulari sfondavano le tasche, non c’erano le prepagate … e gli SMS non c’erano e quando sono stati disponibili, per l’utenza business,  arrivavano 3-4 ore dopo …) e quindi NON poteva prevederlo. concepirlo nel proprio futuro.
Questo Microsoft’s Vision For 2019 va preso come “il futuro secondo Microsoft”, quindi. Questo mi dice la mia esperienza. Qualcosa mi dice che l’usabilità e la convergenza del futuro non sarà fatta solo di windows …

Conclusioni

I due video propongono scenari interessanti (Microsoft’s Vision For 2019 è più futuribile …), di convergenza e di superamento dei joystick, delle periferiche, dei mouse, ecc. come strumenti di comando e controllo degli applicativi hardware. Guardando questi viene da pensare ad un progressivo superamento della dicotomia hardware/software, in favore dell’usabilità e della fruibilità delle nuove interfacce.
Riuscire a preveere il futuro nella tecnologia è difficile, in quanto il mercato si sposta a ondate e mode dove una soluzione/prodotto è presto sostituita da una nuova scoperta/innovazione.
Come diceva Lord John Browne:
Rinunciare all’illusione di poter prevedere il futuro è un momento liberatorio. Bisogna acquistare la capacità di reagire… la creazione di tale capacità è lo scopo della strategia“.
La strategia migliore, secondo me, non è solamente quella difensiva/adattiva, ma quella che è anche in grado di anticipare il futuro, anche senza prevedere, ma con l’intuito, il rischio e l’innovazione costante.

Leonardo Milan

Condividi questo articolo:

technoratiTechnorati oknotizieOKnotizie segnaloDelicious segnaloSegnalo segnaloDigg

 Contatore utenti connessi