Software Quality Attributes in Agile with Visual Studio Online, pt.2

Technical User Story: scenario complesso

Continuiamo il nostro viaggio nel mondo delle Technical User Story (TUS), ovvero la rappresentazione dei constraints non funzionali, fondamentali per la realizzazione di una soluzione di qualità in linea con le aspettative dell’utente.

Nel precedente post ci si è concentrati sullo “scenario semplice”, ovvero sul caso in cui la TUS sia strettamente legata ad una singola User Story, diventandone un’Acceptance Criteria che ne condiziona lo sviluppo e il passaggio in “Done State” in modo stringente. Più comunemente, però, i constraints non funzionali sono cross-User Story, rappresentando un aspetto trasversale del sistema e ponendo tutta una serie di problemi, sia nella loro gestione sia “nel quando” diventa possibile considerare una User Story in “Done State”

nfr cross us

Cross User Story constraints

Nello scenario cross-User Story è fondamentale individuare uno scope più ampio da considerare per lo sviluppo delle TUS, che, quasi sicuramente, non possono essere “contenute” in una singola iterazione. Per supportare in modo ottimale tale attività, è opportuno dividere il “generico” constraint introdotto precedentemente in due tipologie ben delineate:

  • Rule: è un constraint che limita la libertà nella scelta del come sviluppare la soluzione. Si tratta di un vincolo difficilmente percepibile da parte dell’utente finale.
    • Simplicity, Maintainability, Testability, Portability, Extensibility, ecc…
  • Restriction: più che porre limiti, contribuisce a definire i livelli di qualità annessi all’esecuzione della soluzione, inquadrabili come “vincoli” architetturali. È evidente che tale aspetto è percepito in modo diretto dall’utente.
    • Correctness, Performance, Reliability, Scalability, Security, Usability, ecc…

Per esplicitare meglio le differenze tra le due tipologie di constraint, si considerino i seguenti scenari-tipo annessi alla Simplicity e alle Performance:

 

Scenario, Simplicity::Coding Convention (Role constraint)
Elemento Specifica (specifiche)
Sorgente dello Stimolo Un Dev deve modificare la soluzione dopo diversi mesi dal suo completamento
Stimoli Lettura e comprensione del codice senza documentazione esterna
Artefatti Codice Sorgente (aka: Intera Soluzione)
Ambiente Sviluppo
Risposta Definizione di una “Coding Convention”
Misura delle Risposta ???????????

Tab.1: Simplicity

Scenario, Performance::Login Response Time (Restriction constraint)
Elemento Specifica (specifiche)
Sorgente dello Stimolo Un Utente esterno chiede di utilizzare il sistema
Stimoli Richiesta di accesso alle funzionalità del sistema
Artefatti Log-in Module
Ambiente Erogazione
Risposta Il sistema deve espletare la procedura di autenticazione in non più di 2 sec. Se il tempo di log-in supera i 10sec. per più di 10 utenti, la funzione va messa in Suspend e va inviato un alert al gruppo di supporto.
Misura delle Risposta Utenti loggati nel range di 2 secondi, utenti loggati oltre i limite dei 2 sec.

Tab.2: Performance

La differenza sostanziale tra le due tipologie di constraint è ben leggibile nello Scenario annesso alla Simplicity (tab.1). In esso si evidenzia come sia estremamente difficile, se non impossibile, definire in modo univoco la “Misura della Risposta” e i possibili test per la verifica della “Risposta” del sistema, essendo lo “Stimolo” non meccanizzabile. Ciò porta all’impossibilità di asserire in modo sistematico che la User Story è completata e far evolvere il suo stato in “Done State”. Tale condizione di incertezza non persiste, invece, per lo scenario Performance (tab.2) che esplicita elementi misurabili e direttamente testabili.

Nonostante queste profonde differenze, da un punto di vista schematico, i constraint cross-User Story possono essere visti esattamente come quelli single-User Story, ovvero come vincoli al Dominio di riferimento funzionale.

nfr rule

Rule & Restriction Constraints

Cosa diversa è, invece, la loro rappresentazione e gestione all’interno di strumenti di ALM, e in particolare di Visual Studio Online.
Nel caso delle Rule, esse sono assimilabili a dei Global Work Item a cui vanno collegate le varie Feature da realizzare: sarebbe inutile legare le Rule ai singoli PBI (singole User Story), perché impattano l’intero ciclo di sviluppo della soluzione e devono essere viste come uno stimolo al continuo refactoring durante le iterazioni, in funzione del raggiungimento dell’optimo relativo.  È del tutto evidente, quindi, che una Rule Feature ha un ciclo di sviluppo assimilabile a quello della soluzione (Release, Increment, ecc…).

In VSO, non essendo ancora contemplata la possibilità di modificare il Process Template e creare specifici Work Item type, possiamo utilizzare un item di tipo Feature per definire una Rule Feature, caratterizzata da una specifica naming convention del tipo: RULE::Name e con la Value Area settata ad Architecture.

nfr feature rule

RULE Feature

Successivamente si potrà procederà a “linkare” direttamente come “reference” la singola Feature alla Rule Feature:

nfr feature rule linking

RULE PBI Linking

Nel caso delle Restriction, i work item di riferimento sono le User Story che in VSO sono genericamente rappresentate sotto forma di PBI. Anche qui, per ora, è necessario adattare un PBI generico con una specifica naming convention: Restriction::Name, dando vita ad un Restriction PBI con la Value Area sempre settata ad Architecture.

nfr pbi restriction

Restriction PBI

A questo punto i PBI vanno linkati, come per le Feature, alla Restriction PBI che le vincola nel loro sviluppo, come accade per lo scenario semplice descritto per il post precedente. Se è vero, però, che il PBI va completato nella singola iterazione, lo stesso non vale per la Restriction PBI che resterà “In Progress” finché tutte le User Story/PBI annesse saranno completate. Da ciò risulta fondamentale la granularità della definizione degli Scenari di qualità al fine di non avere Restriction PBI che durino l’intero ciclo di sviluppo, difficilmente giustificabili e tollerabili, a differenza delle Role Feature.

Operando con una naming convention di riferimento è possibile, inoltre, costruire delle query ad-hoc che consentono di tenere sempre evidenza di quelle che sono le Rule e le Restriction attive nel sistema, andando anche eventualmente a “pinnare” il risultato sulla home.

nfr restriction query

Simple Restriction query

nfr restriction pin

Simple Restriction query “pin”

Va puntualizzato che nel caso di Team Foundation Server, essendo possibile modificare il Process Template, è opportuno creare appositi Work Item in grado di rispecchiare in modo specifico le caratteristiche delle Rule e delle Restriction.

 

Stay tuned!

DotNetPodcast n°48 – DB & Source Control

Ho avuto di recente la possibilità di passare una piacevolissima serata con gli organizzatori di DotNetPodcast, Roberto Albano e Antonio Giglio, e con un amico MVP Visual Studio ALM, Felice Pescatore

Grazie alla disponibilità di Roberto e Antonio, abbiamo fatto un “salotto informatico”, nel tentativo di rendere interessante ed, allo stesso tempo, divertente l’ora passata insieme. Il tutto è partito come “intervista” ma poi ci siamo coinvolgere dall’argomento, più attuale che mai.
Nel podcast si è cercato di fondere quelli che sono i concetti fondamentali dell’agile con le pratiche di gestione del source control (e non solo) su database.
Ovviamente, siccome Felice ed io “parliamo POCO”, sono stati anche accennati topic non necessariamente legati al controllo del codice sorgente, come la gestione del team, le metriche per la risoluzione dei problemi di allineamento dei membri del team, ecc.
Vi consiglio vivamente di ascoltare il podcast qui. Personalmente, mi sono divertito tanto durante la serata e credo proprio che il risultato sia buono.
Stay Tuned! 

Software Quality Attributes in Agile with Visual Studio Online

Lo sviluppo di una soluzione software è finalizzato alla creazione di Valore per il cliente, e, più in generale, per tutti gli stakeholders collegati. Proprio il Valore è l’elemento portante su cui si basa l’intera azione di deploy del prodotto, guidandone le varie fasi di realizzazione e di supporto.

Le varie metodologie Agili ci portano ad “osservare” la nostra soluzione dal punto di vista funzionale, andando a creare un Product Backlog (PB) contenente Epic o User Story che rispondono alla forma: “As a USER… I Want… So…”, mettendo al centro del discorso l’utente finale e, appunto, la sua visione funzionale del sistema.

Questo approccio è assolutamente valido per rappresentare il Valore della soluzione in funzione alle aspettative del cliente, ma trova dei profondi limiti quando si vuole andare a rappresentare i requisiti qualitativi/non-funzionali (NFR) del sistema.

In un post specifico (NFR: come definire correttamente uno scenario) si è già affrontato l’argomento che riguarda una possibile definizione formale degli NFR attraverso Scenari composti da 6 elementi lineari:

  • Stimolo (Stimuls), ovvero l’evento che sollecita il sistema;
  • Source of Stimuls (Sorgente dello Stimolo), la sorgente da cui proviene lo stimolo;
  • Artefatto (Artifact), la parte del sistema sottoposta allo stimolo. Chiaramente può essere l’intero sistema;
  • Environment (Contesto), il contesto in cui si verifica lo stimolo;
  • Response (Risposta), come il sistema risponde allo stimolo;
  • Response Misure (Misura della Risposta), permette di valutare se la risposta del sistema è soddisfacente.

specify nfr 

Figure 1 – Quality Scenario

Messo che gli scenari siano stati definiti, ragionando in chiave Agile evitando un Big Design Up Front (BDUF), come è possibile rappresentarli correttamente all’interno del processo Agile utilizzato, ad esempio Scrum? come è possibile sfruttare Visual Studio Online (o TFS) per tenerne traccia e farli convivere con le User Story?

Per trattare correttamente la tematica, la discussione verrà improntata su “scenari semplici”, in cui il requisito non funzionale è legato esclusivamente solo ad una sola User Story, e su “scenari complessi”, in cui l’NFR è cross-User Story.

 

Technical User Story: scenario semplice

Come detto, le User Story sono direttamente legate agli aspetti funzionali:

            “Essendo un Operatore di Sportello, voglio potermi loggare in modo da assistere il cliente

Esse coinvolgono, idealmente, diversi aspetti tecnici del sistema che ci si approccia a realizzare, poggiandosi sull’Intentional Architecture di riferimento.

In Agile si è abituati a lavorare in funzione del cliente, ma spesso ciò viene portato all’estremo e la presenza di riferimenti di tipo tecnico vengono banditi dal Product Backlog. Ma se si guarda alla definizione stessa di Product Backlog:

“The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product.”

si nota che non viene fatto nessun riferimento esplicito a User Story o a requisiti funzionali, ma ad una lista generica di funzionalità che si desidera avere nel prodotto. Un PB può quindi avere:

  • Features;
  • Bugs;>
  • Technical work;
  • nowledge acquisition;
  • ecc…

in pratica, il PB contiene tutto quello che il Product Owner, coadiuvato dal team, ritiene utile inserire per raggiungere l’obiettivo in funzione del cliente. È bene, quindi, non confondere il Product Backlog con “il documento dei requisisti”… sono due cose completamente differenti!

Nessun problema, quindi, nell’avere delle Technical User Story (TUS) che rappresentino i requisiti non funzionali della soluzione in essere. Inoltre, non vi è alcun vincolo relativamente alla forma che essi debbano avere. In generale è più facile pensare alle TUS se si ha una visione complessiva della soluzione che si sta realizzando, discutendone durante un Story Brainstorming Workshop (rif. Mike Cohn) o un Release Planning, che consentono di andare al di là della singola iterazione di sviluppo.

Le TUS possono essere di vario tipo:

  • Quality Requirements: sono dedicate agli aspetti qualitativi/non funzionali della soluzione;
  • Product Infrastructure: di supporto allo sviluppo dei requisiti funzionali. Si pensi ad esempio all’individuazione di una libreria per la compressione dei dati, che va provata, testata ed integrata nella soluzione;
  • Team Infrastructure: si tratta di sperimentare strumenti che sono di supporto alle attività del team. Si pensi ad una nuova piattaforma ALM;
  • Refactoring: di supporto alle attività di refactoring. Da non intendersi solo relativamente al codice, ma anche all’Intentional Architecture, al Desing, ecc;
  • Bug Fixing: di supporto alla risoluzione di bug o di malfunzionamenti olistici;
  • Spikes: sono una particolare categoria che evidenzia la necessità di apprendere know-how relativamente a uno qualsiasi degli aspetti della soluzione, sperimentando le ipotesi sul campo.

Nel contesto specifico della discussione in essere, ci si concentrerà sui Quality Requirements.

Si ipotizzi che l’Intentional Architecture di riferimento preveda un NFR che declini la Security in funzione dell’accesso al sistema, rappresentato secondo il seguente Scenario:

Elemento Specifica (specifiche)
Sorgente dello Stimolo Un Utente esterno chiede di utilizzare il sistema
Stimoli Richiesta di accesso alle funzionalità del sistema
Artefatti Intera soluzione
Ambiente Erogazione
Risposta L’utente deve autenticarsi attraverso una 2-phase authentication
Misura delle Risposta Reazione in funzione di un numero massimo di tentativi errati

Lo Scenario, è, di conseguenza, un constraints di Dominio, secondo quanto rappresentato dalla figura seguente (fig. 2):

functional vs nonfunctional

Figure 2 – Scenario constraints

Partendo da questi elementi, come è possibile inserire tale requisito all’interno del Product Backlog? La cosa non è fonte di particolare problemi, potendolo esprimere in linguaggio naturale:

Un utente per poter accedere alle funzionalità del sistema deve autenticarsi con una procedura di tipo 2phase authentication: inserendo le credenziali statiche e poi il pin che viene inviato al proprio cellulare.

o anche nel formato che contraddistingue una tipica User Story:

Essendo un utente voglio potermi autenticare tramite una 2phase authentication con credenziali statiche e poi con pin inviato al mio cellulare, per poter accedere alle funzionalità del sistema.

È evidente che quest’ultima forma è una forzatura e sacrifica la chiarezza del linguaggio naturale in favore di una forma standard-de-facto. Se proprio si vuole utilizzarla, potrebbe essere opportuno non esprimerla in funzione dell’utente, ma di una fantomatica personas di sistema, ad esempio l’Amministratore:

Essendo l’Amministratore del sistema, voglio che gli utenti si autentichino tramite una 2phase authentication con credenziali statiche e poi con pin inviato al proprio cellulare, per poter accedere alle funzionalità del sistema.

In fondo, però, l’Agile non deve semplificare al massimo il processo e rendere chiaro cosa fare? Per questo la prima forma è fortemente consigliata. L’NFR riportato non è casuale, ma può essere considerato alla base della User Story di login presentata pocanzi (fig. 3):

login functional vs nonfunctional 

Figure 3 – Login constraint

In pratica, in questo caso, la TUS si configura come un nuovo Acceptance Criteria della User Story che ne vincola lo sviluppo a un requisito non funzionale definito tramite uno Scenario contemplato dall’Intentional Architecture. Tale definizione può avvenire sia ad inizio del percorso di sviluppo sia durante una delle sue revisioni periodiche.

Ma la TUS stessa ha un set di Acceptance Criteria che deve essere opportunamente definito e convalidato, prima di poterla considerare completa. Tornando all’esempio, una sua possibile definizione potrebbe essere la seguente:

  • Verificare che la fase di login avvenga in 15 secondi;
  • Verificare che dopo tre tentativi errati l’accesso per l’utente venga inibito;
  • Verificare che il messaggio di risposta arrivi nell’arco di 5 secondi;
  • ecc….

Bene, il requisito specifico di Sicurezza è ora espresso in modo diretto all’interno del PB, con tanto di criteri di accettazione, la possibilità di creare test automatici di validazione e tracciarne lo sviluppo. Si tratta di un risultato non di poco conto, che consente, inoltre, di parallelizzare le attività di sviluppo della User Story di login.

Resta un ultimo dubbio, però: quando si può considerare conclusa la User Story di login? Ebbene la User Story può ritenersi in “Done state” solo quando la stessa TUS è in “Done State”, essendo doveroso inserire nei relativi criteri di accettazione qualcosa tipo:

  • Tutti i constraints devono trovarsi in “Done” state.

Quanto detto può essere facilmente gestito in Visual Studio Online. Seguendo l’ordine di cui sopra, si crei la login User Story:

login user story 

Figure 4 – Login User Story

Notare che la Value Area è di tipo Business e che negli Acceptance Criteria si è specificato la necessità di superare i constraints. Si crei ora la login TUS di Security:

login tus 

Figure 5 – Login TUS

nessuna sorpresa che la Value Area sia di tipo Architectural.

L’ultimo passaggio è quello che lega la login User Story alla login TUS:

login us link 1

Figure 6 – Link login User Story to login TUS

da cui si ottiene il risultato seguente:

login us link 2

Figure 7 – login User Story linked to login TUS

Per avere anche una indicazione “visuale” della differenza tra i due PBI, è possibile creare una swimlane sulla Board di tipo “Constraints” che, una volta presi in carico sia la login User Story che la login TUS, le daranno un aspetto simile al seguente:

login us link 3

Figure 8 – Constraints swimlane

Si conclude qui la prima parte dell’approfondimento dedicato alle Quality Attributes in chiave Agile. Nel prossimo post verrà affrontato il caso in cui un NFR sia cross-User Story.

Kanban Board e Swim lanes

Nell’ultimo update di Visual Studio online è stata introdotta una nuova migliora per la Kanban Board, ovvero l’implementazione delle Swim Lanes. In una Kanban Board infatti la suddivisione in colonne permette di visualizzare immediatamente il “work in progress” per tutti gli stadi di sviluppo, ma nelle varie colonne non esiste differenza nella priorità delle card. Questo significa che se nella colonna Testing vi sono 4 card una sotto all’altra non implica, come per un backlog, che le card in alto sono in qualche modo più importanti o prioritarie delle altre.

In alcune situazioni è però comodo poter dare priorità ad alcune card, indicando appunto che il team deve in qualche modo focalizzarsi nel fare avanzare alcune card rispetto ad altre. Un esempio pratico potrebbe essere costituito da una card che rappresenta un bug bloccante in produzione. Quando si verifica un bug bloccante in produzione, molto probabilmente tutto il team deve collaborare per far si che il bug sia corretto nel minor tempo possibile e quindi la card (o le card) che sono collegate al bug debbono avanzare con priorità rispetto alle altre.

Per visualizzare in maniera chiara ed evidente questo fatto, è comodo avere nella board delle suddivisioni orizzontali, in modo da suddividere la board in più fasce orizzontali. In realtà la fascia principale, rimane la board come la si conosce, mentre le fasce aggiuntive sono appunto dette Swim Lanes e servono appunto a raccogliere particolari card che debbono essere gestite con priorità differente rispetto al resto.

image

Nella swimlane le colonne sono esattamente le stesse della board principale, dato che ogni card ha comunque un percorso ben definito nella vostra organizzazione. In generale la visualizzazione normale della board può mantenere la SvimLane collassata, dato che appena qualcuno vi sposta dentro un item è possibile comunque visualizzare nell’header quante carte sono presenti per ogni colonna.

image

In questo modo, anche se la SwimLane priorità massima è normalmente collassata per non sprecare spazio, appena un elemento vi viene spostato l’header cambia e si può quindi espandere la SwimLane per visualizzare le card che in questo caso hanno Priorità Massima.

La regola di base è non abusare delle Swim Lanes, se il PM o chi per lui si abitua ad inserire frequentemente molte card in Priorità Massima, il team inizierà a considerare le card in Priorità Massima come tutte le altre e quindi si perde il significato originale. D’altra parte far lavorare un team sempre “in emergenza” è il modo migliore per diminuire le performance del team stesso.

Come ultima nota, si può verificare che le card poste nelle swim lanes vanno a sommarsi al conteggio totale delle card nelle varie colonne. Questo significa che se il Work In Progress Massimo per la colonna di testing è 4 e vi sono all’interno già 4 card, in teoria non sarebbe possibile spostare una card in Testing nella swimlane di Priorità Massima. Nella pratica, se la Swim Lane è usata con cognizione di causa e contiene solamente gli elementi con reale Priorità Massima, si può eccedere il WIP nelle varie colonne. Se la colonna di testing è piena ma è necessario fare una verifica per una patch di un bug bloccante in produzione, si può tranquillamente pensare che il team di testing dedichi risorse al bug bloccante, trascurando le card su cui stava lavorando attualmente.

Chiaramente deve essere chiaro che questa violazione del Work In Process può avvenire solamente per le Swim Lanes associate ad eventi eccezionali e non può costituire la normalità. Se i bug bloccanti diventano molto frequenti (la speranza è che questo non accada, ma potrebbe avvenire), significa che la Swim Lane di Priorità Massima è spesso piena di card, a questo punto il team potrebbe decidere di lasciare costantemente uno slot libero in ogni colonna, dato che la probabilità di avere un elemento nella Swim Lane è grande. D’altra parte in caso di frequenti bug bloccanti, è doveroso lasciare il team scarico in modo da poter affrontare i bug velocemente.

Gian Maria.

0  

Cloud Load Test con Visual Studio Online – parte 2: Visual Studio

Questo articolo è il secondo di una serie di 3 in cui parlo del Cloud Load Testing con Visual Studio Online.
Nella prima parte abbiamo visto come eseguire dei semplici test di carico usando solamente il portale di VSO.
In questo articolo invece vedremo un soluzione più complessa (ma più completa), l’integrazione tra Visual Studio e Visual Studio Online.

Remainder

Prima di iniziare a parlare nello specifico dell’esecuzione dei Cloud Load Test è importante ricordare alcuni aspetti:

  • Per poter utilizzare la funzionalità di Cloud Load Test è necessario avere una sottoscrizione MSDN Ultimate
  • L’applicazione da testare deve essere esposta sul web (visto che i test agent sono nel cloud e devono poter raggiungere l’applicazione)
  • Gratuitamente si possono utilizzare fino a 20.000 minuti al mese. Si tratta di “virtual user minutes”, quindi ad esempio eseguendo 1 test da 2 minuti con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.

Inoltre, la funzionalità di Load test è disponibile solamente su Visual Studio Ultimate/Enterprise.
Fatte queste precisazioni, vediamo come si possono creare ed eseguire i test di carico con Visual Studio e Visual Studio Online.

Introduzione

Facendo un Load test con Visual Studio, avremo un sacco di impostazioni che potremo configurare. Si tratta quindi della soluzione più personalizzabile e configurabile per eseguire questo tipo di test.
Inoltre, dopo l’esecuzione avremo a disposizione molte informazioni, dati e grafici che ci permetterranno di capire come la nostra applicazione si comporta in uno scenario di carico.
Ultimo ma non per importanza, utilizzando VS possiamo fare un test multi step (multi pagina), anche con pagine sottoposte ad autenticazione, e possiamo registrare tutti i passaggi che vogliamo fare nell’applicazione allo stesso modo di come li farebbe l’utente (quindi non è richiesta configurazione manuale!).

Iniziamo

Prima di tutto dobbiamo creare un test project in Visual Studio. Il project template da usare è “Web Performance and Load Test Project”.

Quando clicchiamo sul bottone “Ok”, VS crea per noi una soluzione (come sempre) con all’iterno un progetto “WebTest1.webtest”. Non si tratta di un progetto di “Cloud Test”, bensì di un progetto “Web Performance”. Avremo bisogno di questo progetto per “istruire” il load test su cosa e come testare.
In alto a sinistra della schermata c’è un piccolo bottone con un grosso punto rosso: è il bottone che ci permette di resgistrare tutti gli step che faremo nella nostra applicazione.

Se clicchiamo su questo bottone, verrà aperto il browser (tipicamente IE) che avrà un piccolo pannello sulla sinistra. Si tratta del pannello che “fa il lavoro per noi”; è generato dal plugin “Web Test Recorder helper” che VS installa sulla nostra macchina.

Come nota a margine, ricordate di verificare che quel plugin sia abilitato sul browser altrimenti non verrà visualizzato nulla.

Ok, ora che la registrazione è attiva possiamo visitare ed usare l’applicazione che vogliamo testare esattamente come farebbe un normale utente. Possiamo anche eseguire azioni particolari se vogliamo testare qualche funzionalità o pagina specifica.
Per far iniziare la registrazione è sufficiente scrivere l’indirizzo dell’applicazione nella barra del browser ed iniziare ad usarla: il web recorder plugin farà tutto il resto.
Quando abbiamo finito, abbiamo cioè effettuato tutti gli step e le navigazioni che vogliamo testare, basta clicare sul bottone “Stop”. Abbiamo anche la possibilità di mettere in pausa la registrazione se magari non vogliamo registrare qualche step.

Mentre navighiamo la nostra applicazione, un sacco di “roba” viene aggiunta nel pannello di registrazione. Si tratta di tutte le richieste che la nostra applicazione fa.
Se ne selezioniamo una e clicchiamo sul bottone “comment” possiamo aggiungere un commento alla stessa che sarà possibile recuperare in un secondo momento.
Quando clicchiamo sul bottone “Stop”, succede “la magia”. Dapprima Visual Studio prende tutte le richieste e le informazioni dal web recorder plugin, le elabora e le inserisce nella finestra del webtest. Poi cerca di identificare se ci sono dei “parametri dinamici” nel nostro test.

I dynamic parameters sono tutti quei valori che possono cambiare se le richieste vengono fatte in momenti temporali differenti: user token, ricerche, autenticazioni, ecc. Se VS ne rileva qualcuno ci mostrerà una finestra in cui potremo decidere come e se utilizzarli. Possiamo selezionare di utilizzare per ogni iterazione di test esattamente quelli che sono stati registrati oppure se associare quei parametri ad una sorta di dizionario (che andremo a creare) da cui VS sceglierà di volta in volta valori differenti.

Un altro aspetto interessante che possiamo personalizzare riguarda i “Request details”. In questa finestra possiamo decidere se inserire dei “think time” tra le richieste (sostanzialmente dei ritardi) e, più importante, qual’è per noi il tempo “target” per le response. Se durante il test quella specifica richiesta avrà una response in un tempo maggiore di quello impostato come soglia, VS considererà il test come fallito.
Ora che abbiamo il webtest con tutti gli step ed i parametri impostati, possiamo finalmente aggiungere il progetto di Load Test alla nostra solution.

Il progetto di Load Test

Per aggiungere il test di carico ad un web performance test è sufficiente cliccare con il testo destro del mouse sul nome del progetto, scegliere “Add” e poi “Load test”.

Quest’azione farà comparire il “Load test wizard” che ci guiderà nel setup del test di carico.
Nel primo step dobbiamo scegliere se e come gestire i “think times” (i ritardi tra le request): possiamo usare gli stessi think time acquisiti durante la registrazione (attenzione che se mentre registravamo, tra un click e l’altro abbiamo fatto una pausa di ad esempio 5 minuti, durante il test quei 5 minuti saranno settati come delay tra quelle due richieste), possiamo scegliere “normal distribution” (che fa una sorta di media tra i tempi di delay registrati) oppure proprio di non usarne. Possiamo anche inserire un tempo di attesa tra iterazioni diverse dello stesso test.
Nel secondo step dobbiamo decidere quanto carico vogliamo generare verso la nostra applicazione e le modalità di generazione.

Possiamo selezionare di avere un carico costante (il test inizierà cioè con N utenti e continuerà con lo stesso numero di utenti fino alla fine) o di effetturare un test con “step load”.
Nell’immagine, ad esempio, ho deciso di utilizzare lo step load e di iniziare il test con 10 utenti aggiungendo ulteriori 10 utenti ogni 10 secondi, fino al raggiungimento di un massimo di 200 utenti.
Lo step load può essere molto interessante in quanto possiamo scoprire come (e se) la nostra applicazione scala in base all’incremento del carico applicativo.
Nello step successivo dobbiamo istruire il test di carico sul “cosa” fare. Per questa ragione inseriremo in questa schermata il web performance test che abbiamo creato precedentemente.

Cliccare su “Add”, selezionare il performance test che vogliamo, cliccare su “Ok” ed il test sarà aggiunto nella finestra “test mix”. Si chiama “Test Mix” perchè è possibile aggiungere quanti test vogliamo e se ne mettiamo più di uno possiamo definire la distribuzione percentuale di ognuno. In questo esempio abbiamo un solo test quindi la distribuzione sarà del 100%.
Possiamo anche decidere, negli step successivi, se e come utilizzare diversi tipi di connettività verso la nostra applicazione (attenzione: nel momento in cui scrivo VSO supporta solamente reti di tipo “LAN”) e che tipo di browser engine vogliamo che siano utilizzati dai test agent per effettuare le richieste.

Come potete vedere nell’immagine, possiamo scegliere da un elenco di molti browser ed anche in questo caso possiamo definire la distribuzione percentuale.
Nell’ultimo step possiamo personalizzare la durata dell’esecuzione del test.

Possiamo scegliere tra un tempo fisso oppure un numero di iterazioni di test. Se selezioniamo un tempo fisso (nel mio esempio 2 minuti), possiamo anche impostare un “Warm-up time” (10 secondi nell’esempio). Durante questo tempo verranno inviate alcune richieste all’applicazione per “risvegliarla” e non saranno collezionati dati. Questo comportamento è estremamente utile se dobbiamo testare applicazioni che necessitano di un cold start (come ad esempio webapp hostate su IIS che magari non sono state usate per un periodo di tempo e per le quali quindi IIS ha “disattivato” l’AppPool) per non avere dei falsi positivi nel risultato del test.
Cliccando su “Finish”, Visual Studio genererà il progetto di load test e lo salverà nella nostra soluzione.

Esecuzione del test

Ora che abbiamo tutto pronto possiamo eseguire il test. Ma prima, ancora un piccola impostazione. Noi vogliamo, infatti, che il test di carico sia eseguito attraverso la funzionalità Visual Studio Online Cloud Load Test ma nessuno l’ha detto al nostro Load Test project locale.
Per farlo bisogna aprire (doppo clic) il file “Local.testsettings” e cambiare il puntamento di “Test run location” su Visual Studio Online.

È da notare comunque che se abbiamo effettuato il login in Visual Studio con un account che ha una sottoscrizione a VSO questo step non sarà necessario in quanto VS seleziona direttamente questo valore per noi.

Ok, iniziamo il test cliccando sul bottone di start in alto a sinistra.

Ma cosa succede quando facciamo partire il test?
Visual Studio si connette a Visual Studio Online ed accoda il test. VSO poi crea on demand un lab virtual di test da qualche parte in un datacenter di Azure e configura i test agent sulle VM con i parametri settati.

Non appena il lab è pronto e configurato, il test parte. Se abbiamo configurato un periodo di warm up esso inizierà e potete vedere che non vengono collezionati dati.

Poi, finito il warm up, gli agenti iniziano a generare il traffico verso le pagine della nostra applicazione (così come utilizzate nella nostra registrazione) ed i risultati sono mandati al nostro Visual Studio quasi in tempo reale in modo da poter avere una preview del risultato finale del test.

Aspettiamo la fine del test per avere un resultset completo.

Risultati

Quando il test giunge al termine, verranno visualizzati tutti i risultati e le performance raggiunte. Le informazioni disponibili sono veramente moltissime.

Abbiamo i tempi di risposta medi, con anche il minimo ed il massimo, assieme ai tempi di test medi, i tempi di pagina medi ed il carico utente.
Possiamo vedere dal grafico e dalle info visualizzate che il numero di utenti virtuali è cresciuto nel tempo da 10 a 120 (avevo impostato un max di 200 ma non ha avuto tempo di raggiungere il massimo in quanto il test era limitato a soli 2 minuti con incrementi ogni 10 secondi) e come l’applicazione ha scalato al crescere del carico.
Anche nella sezione “Throughput” possiamo vedere molte informazioni utili.

In questo esempio non abbiamo avuto errori o parametri fuori soglia, ma se ci fossero stati avremmo visto un report degli stessi con le cause ed i messaggi di errore.
Questi sono però solo una piccola parte dei dati che abbiamo a disposizione. Se infatti clicchiamo sul link “download report” in alto, Visual Studio scaricherà l’intero resulset da Visual Studio Online rendendo disponibile, in questo modo, un report con una miriade di dati e grafici su ogni aspetto del test che ci aiuteranno a capire meglio come la nostra applicazione si comporta in uno scenario di carico.

Conclusioni

Questo tipo di Load test è il più completo che possiamo fare. Come potete vedere ci restituisce tantissime informazioni, metriche e grafici che ci permettono di analizzare il comportamento della nostra applicazione.
Inoltre, il setup di questi test è abbastanza semplice ma soprattutto è completamente personalizzabile ed in un poco tempo possiamo ottenere un gran numero di dati da poter consultare.
Il prossimo ed ultimo articolo di questa serie sarà sull’utilizzo delle Load Test APIs. Stay tuned! :)

Nuovo deploy di VSO

Con l’ultimo deploy di Visual Studio Online sono state introdotte interessanti funzionalità. Prima tra tutte la possibilità di utilizzarele le swimlanes nella kanban board, di cui avrò modo di parlare in dettaglio in un post successivo.

Abbiamo poi la possibilità di fare menzioni di work item nei commenti al codice, ma soprattutto la nuova build, nome in codice vNext, è ora uscita dalla preview e sono stati aggiunti anche alcuni Build Steps interessanti per eseguire Web Performance test Cloud Based.

Potete leggere tutti i dettagli su queste novità nel post ufficiale su Visual Studio Online.

Gian Maria.

0  

Lean Startup, Livello di Interesse Iniziale e Continuato

La Terra del Pensiero è, al contempo, il luogo in cui le nostre idee si formano e il luogo da cui esse debbono uscire il prima possibile per non essere sopraffatte dalle Opinioni.

Ma come possiamo avere una misura iniziale del possibile successo della nostra idea, prima della realizzazione di un MVP che, per quanto ridotto, ha comunque un consto considerevole di realizzazione?

Ebbene, possiamo sfruttare due metriche empiriche fondamentali: Livello di Interesse Iniziale (LI0) e Livello di Interesse Continuato (LIc).

interest iconIl Livello di Interesse Iniziale consente di stimare l’interesse che la nostra idea suscita nei potenziali utilizzatori, ancor prima di realizzare un MVP che le dia una forma concreta:

LI0 = n° di azioni effettuate / n° di opportunità di azione offerte

  • numero di opportunità di azione offerte: rappresenta il numero di persone a cui è stata offerta l’opportunità di fare una certa azione associata con il tuo pretotipo;
  • numero di azioni effettuate: rappresenta il numero di persone che effettivamente hanno compiuto quell’azione.

Immaginiamo di avere pensato ad una nuova App per la pesca subacquea in realtà aumentata. Per avere qualche dato di interesse sulla nostra idea, creiamo una discussione sul più importante forum dedicato alla pesca subacquea e attendiamo, ad esempio, 2 settimane. Nel post si invita gli appassionati ad inviare una mail ad uno specifico indirizzo per prenotare la possibilità di scaricare in anteprima l’App.

Dopo il delta di tempo scelto, scopriamo che:

  • n. visualizzazione del post: 2.134
  • n. di email: 3

possiamo ora calcolare il nostro LI0 = 3 / 2.134 = 0,0014 = 0,14%, una percentuale decisamente bassa… forse dovremmo porci qualche domanda in più.

Se il risultato fosse invece stato più lusinghiero, ad esempio superiore il 10%, avremmo un primo riscontro che la nostra idea può essere quella giusta anche se manca ancora un tassello: dopo lo sprint iniziale, qual è il Livello di Interesse Continuativo degli utenti? I sub utilizzeranno l’App più volte o la lasceranno abbandonata dopo il primo tentativo?

In fondo, non dimentichiamoci mai che la Legge dell’Insuccesso (La maggior parte dei nuovi prodotti fallisce, anche se sono realizzati in modo impeccabile) è sempre in agguato, anche se l’interesse iniziale sembra alto.

metriche iconPer misurare l’LIc è necessario creare il nostro MVP, scegliere un parametro di riferimento e misurarlo in un lasso di tempo ragionevole. Ipotizziamo che il successo della nostra App sia misurabile in funzione del numero di banner che vengono visualizzati durante l’utilizzo, consentendo un ricavo di 5cent a impression: in pratica, più tempo l’App viene utilizzata più guadagnammo.

Ora, monitoriamo l’utilizzo dell’App per un mese e otteniamo che:

  • 1 sett:  n.utenti 300, impression 4000 -> 200€ ricavi
  • 2 sett: n.utenti 300, impression 2000 -> 100€ ricavi
  • 3 sett: n.utenti 400, impression 1000 -> 50€ ricavi
  • 4 sett: n.utenti 450, impression 23 -> 1,15€ ricavi

I dati non sono incoraggianti: nonostante gli utenti siano aumentati, il numero di impression è drasticamente diminuito, segno che, nonostante il download e il discreto LI0, nessuno usa la nostra App.

Per avere qualche possibilità (eh sì, purtroppo sono sempre poche!) che la nostra idea sia quella giusta occorre che l’LI0 sia interessante e che l’LIc abbia un trend quanto meno positivo.

Come rimuovere i TAG non più utilizzati su Visual Studio Online

Per tutti quelli che hanno avuto a che fare con i tag di Visual Studio Online in maniera corposa, saprete che creare un tag è semplicissimo. Basta scrivere la stringa nell’area relativa in un qualunque item:

Ogni tag aggiunto viene memorizzato sul team project ed è molto semplice andare a ripescarlo in un momento successivo, ad esempio, quando creiamo un altro item:
Fin qui tutto perfetto. Tuttavia, potrebbe succedere che alcuni tag non servano più nel tempo. In questo caso, eliminandoli da tutti gli elementi collegati, dovrebbero scomparire. Purtroppo questo non succede, almeno su Visual Studio Online, e, di certo non subito. Provando a controllare dopo una settimana, nulla è accaduto. Tutti i tag non usati esistono ancora. Non c’è niente di male a lasciarli, anzi, possono tornare utili, oppure, possono effettivamente essere tag nuovi ai quali ancora non è collegato nessun item. Ed ecco qui che viene comoda l’estensione che ho trovato sulla gallery, chiamata “Tag Admin For Visual Studio“, disponibile sia nella versione 2013 che 2015.
L’estensione, scaricabile direttamente dalla Visual Studio Gallery (anche tramite Visual Studio) ed è installabile in pochi click. Quello che troverete è un nuovo item di menu sul team explorer:
L’interfaccia è molto semplice, all’apertura vengono caricati tutti i tag immessi. Per ogni tag che andiamo a selezionare è possibile effettuare delle operazioni, quali:
  • Vedere gli tem collegati
  • Rinominare il tag (se non sono scelti più tag)
  • Cancellare i tag
  • Ed è proprio l’ultima opzione che consente di rimuovere definitivamente i tag che non ci servono più:
    Dopo un messaggio di conferma (da notare che nell’immagine si stanno eliminando tag legati ad altri item), i tag sono eliminati con successo:
    Dopo l’aggiornamento dell’eventuale pagina di backlog aperta, non ne troveremo più traccia sulla tendina di autocompletamento:
    Per scaricare le estensioni clickate sui seguenti link:
    Stay Tuned! 

    Thoughtland,la Terra del Pensiero

    idea mini Lean Startup presuppone che al neo imprenditore si sia “accesa la lampadina”, ovvero che abbia maturato un’idea che ritiene vincente e per la quale è disposto a mettersi in gioco.

    Ma come nasce un’idea e come si giunge alla conclusione che essa è perseguile?

    Prima di tutto bisogna ricordare che la grande maggioranza delle nuove startup fallisce, ovvero i nuovi prodotti/servizi realizzati sono un totale insuccesso. Questo fatto è stato riassunto in quella che Alberto Savoia ha definito la Legge dell’Insuccesso:

    “La maggior parte dei nuovi prodotti fallisce, anche se sono realizzati in modo impeccabile.”

    In quest’ottica, è bene rendersi conto che un buon modo per iniziare un “nuovo esperimento” con qualche chance di successo, è quello di partire da un’idea chiara, tenendo presente che qualsiasi idea è sempre sottoposta ad un periodo gestazione nella cosiddetta “Terra del Pensiero”:

    “La Terra del Pensiero è un posto immaginario abitato da due strane entità fluttuanti che interagiscono tra di loro: idee ed opinioni. Più precisamente: idee non realizzate ed opinioni riguardo quelle idee.” [Alberto Savoia]

    terra pensiero

    Si tratta di una interessante rappresentazione del processo di maturazione che ogni nuova idea attraversa prima di diventare la base del nostro nuovo “esperimento” di business. Finché le idee restano nella Terra del Pensiero, e quindi sono idee astratte, l’unica cosa che producono sono opinioni, che, però, possono essere estremamente pericoloso e portare a due conseguenze indesiderate:

    • Falsi negativi, generati da opinioni che ci possono spaventare e far abbandonare prematuramente la nostra idea;
    • Falsi positivi, generati da opinioni che ci possono rendere ciechi alla Legge dell’Insuccesso e farci imbarcare in iniziative troppo prematuramente.

    Nel primo caso la nostra idea è talmente tartassata da opinioni negative che la abbandoniamo a sé stessa, facendoci sopraffare dalla Legge dell’Insuccesso anche quando essa ha una possibilità su mille di essere quella giusta. Nel secondo caso, invece, ignoriamo completamente la fortissima probabilità di fallimento e ci buttiamo a capofitto nel nostro “esperimento”, anche se la nostra idea è destinata già in partenza al fallimento.

    In funzione delle opinioni, durante la gestazione nella Terra del Pensiero, le nostre idee possono subire sorti differenti, portandoci a:

    • non fare nulla: la nostra idea non lascia mai la Terra del Pensiero, siamo pigri e cauti ma tra le 1000 idee sbagliate potremmo buttare via anche quella buona;
    • avanti tutta!: lo sviluppo della nostra idea, surrogata dai falsi positivi, diventa la nostra ragion d’essere, ignorando quali sono le finalità della nostra startup. Cominciamo così a sviluppare un “prodottòtipo” senza curarci dei potenziali clienti e, se qualcosa non va, crediamo che sia colpa di come lo abbiamo realizzato ed investiamo nel suo miglioramento, senza renderci conto che nessuno ha bisogno di esso.

    Entrambe queste scelte sono estremamente pericolose e, nella stragrande maggioranza delle volte, portano alla morte, più o meno dolorosa, della nostra idea.

    Cosa possiamo fare allora? Beh, bisogna uscire quanto prima dalla Terra del Pensiero, dove tutte le idee nascono, ma dove si appesantiscono di falsi negativi, falsi positivi, paure e molta altra zavorra.

    make it happen featured

    Bisogna in sostanza “pretotipare” e avviare il “nostro esperimento”, velocizzando l’esperimento e imparando a conoscere il nostro business e i nostri clienti (Lean Startup docet): make it happen!

    Visual Studio Code

    Nei giorni scorsi si è svolta a San Francisco la più importante conferenza Microsoft dell’anno: //build/. Tante sono state le novità, tra cui un nuovo editor di sviluppo della famiglia di Visual Studio, il cui nome è Visual Studio Code. Questo editor, che è stato rilasciato attualmente in preview, consente la creazione di progetti orientati al cloud e al web ed è cross-platform: supporta infatti Windows, Linux e OSX. Il motivo principale che ha portato la nascita di questo IDE è stata la volontà di mettere a disposizione degli sviluppatori un ambiente leggero e di semplice utilizzo che aiuti a creare applicazioni che coinvolgono diverse tecnologie tra cui: ASP.NET, Node.js, HTML, CSS, LESS, SASS e JSON. E’ interessante sapere che questo IDE nasce come customizzazione di un editor già esistente chiamato Electron, che è stato utilizzato dietro le quinte anche da Visual Studio “Monaco” (il famoso editor online di Visual Studio). Inoltre, la presenza come il debugger, l’intellisense o l’integrazione con git, lo rendono un ambiente davvero attraente per il front-end developer. Il primo passo da fare per usare Visual Studio Code è quello di scaricare il pacchetto appropriato per il proprio sistema operativo da https://code.visualstudio.com/Download e installarlo sulla propria macchina (figura 1):

    Figura 1 – Le diverse piattaforme supportate da Visual Studio Code

    Inoltre, possiamo scegliere di installare oltre al pacchetto base, a seconda del nostro sistema operativo o di ciò che abbiamo già installato sullo stesso, una serie di tool aggiuntivi che ci aiuteranno nella realizzazione delle nostre applicazioni:

    • NET 5;
    • NodeJS (incudes NPM);
    • git: (command line tools);
    • Yeoman: un tool per fare lo scaffolding di applicazioni, ovvero genera per noi la struttura di un progetto;
    • generator-aspnet: generatore di yeoman per ASP.NET 5;
    • hottowel: un generatore di yeoman per applicazioni che usano AngularJS;
    • Express: un application framework per Node;
    • gulp: un task runner system;
    • mocha: un JavaScript test framework per Node;
    • bower: un client side package manager;
    • TypeScript: un framework tipizzato per estendere Javascript;
    • TypeScript definition manager: un repository di definition file da usare con Typescript.

    Al termine dell’installazione possiamo aprire l’editor per cominciare ad usarlo (figura 2):

    Figura 2 – Visual Studio Code

    L’IDE si presenta in questo modo: un menù principale (File, Edit…), un menù laterale con quattro pulsanti (Explore, Search, Git, Debug), al centro l’area di editing (in cui si possono affiancare fino a tre finestre) e in basso una barra di stato. Inoltre abbiamo una command palette che ci consente di eseguire comandi all’interno dell’ambiente in maniera rapida (figura 3).

    Figura 3 – La command palette

    Il primo aspetto interessante di Visual Studio Code riguarda il suo funzionamento: infatti si tratta di un editor file e folder based, che significa che basterà puntare ad una cartella o ad un file e non ad un file di progetto per iniziare a lavorare. Inoltre l’editor è in grado di riconoscere qualsiasi tecnologia supportata nel momento in cui viene aperta una cartella leggendo il suo contenuto. Per impostare invece una nuova cartella di lavoro, si può cliccare sul primo pulsante sul menù laterale (Explore), che apre una sezione che ci consente di visualizzare, aprire o aggiungere dei file presenti alla cartella selezionata (figura 4). In questa sezione, troviamo 2 sottosezioni, ovvero “Working Files”, dove troviamo i file aperti per la modifica, e “No Folder Loaded” (il cui nome cambierà a seconda della cartella in cui stiamo lavorando).

    Figura 4 – Scelta della cartella di lavoro

    Dopo aver cliccato su “Open folder”, siamo pronti per selezionare una cartella che rappresenterà il nostro workspace. Al suo interno possiamo aggiungere file usando i pulsanti accanto il nome della nostra cartella (figura 5):

    Figura 5 – I pulsanti di gestione dell’attuale workspace

    Supponendo di aver creato un file HTML, possiamo utilizzare il browser per visualizzarne il risultato (figura 6).

    Figura 6 – Un esempio di applicazione in Visual Studio Code

      Questa è per il momento solo una piccola introduzione su Visual Studio Code. Nei prossimi post entreremo in dettaglio sulle funzionalità di questo nuovo editor, come realizzazione di applicazioni ASP.NET e Node.js, supporto a Git, Debugging e configurazione.