Esempio di uso

In questo post proseguiamo la serie di articoli dedicati ai Workflow di JIRA. Vedremo come crearci il nostro Workflow, come personalizzarcelo e che operazioni possiamo fare.

Prerequisiti

Vediamo, in prima battuta, chi può creare Workflow.  Infatti non tutti gli utenti possono eseguire questa operazione. In aggiunta, prima di procedere con la generazione di un Workflow, conviene sempre verificare se esiste già un Workflow che risponde alle nostre esigenze.

Un Workflow può essere creato solo da utenti che dispongono delle JIRA Administration Global Permission, ovvero da utenti amministratori, i quali sono autorizzati ad eseguire tale operazione. La seguente immagine, disponibile nella documentazione, consente di aiutare a capire meglio le differenze che sussistono tra i vari gruppi di utenti.

Iniziamo

Quello che un utente autorizzato può fare è una tra le seguenti operazioni:

• Creare un nuovo
• Modificarne uno esistente
• Importarne da marketplace/file o XML.

Facciamo una piccola precisazione. Ci sono delle piccole differenze tra versione Server e versione cloud di JIRA, relativamente alla questione dei Workflow. Ritengo molto importante ribadire le differenze, in modo da aiutare gli utenti nella scelta di una soluzione piuttosto dell’altra.

Mentre per la versione server possiamo eseguire l’importazione da file, come mostrato in figura:

abbiamo a disposizione un menù Import, che presenta le seguenti opzioni:

• Import Workflow
• Import XML

per la versione cloud, possiamo solo eseguire un import da Marketplace, come mostrato nella seguente immagine:

Si tratta di scelte e, come conseguenza, meglio conoscerle :-), in questo modo evitiamo di trovarci con delle sorprese dell’ultimo minuto.

Creazione di un Workflow

Iniziamo con la creazione. Supponiamo di voler creare un semplice Workflow, che presenta solo alcuni stati. Selezioniamo Add Workflow, opzione comune alle due installazioni. Il risultato che otteniamo è il seguente:

ovvero ci viene richiesto di fornire un Nome al Workflow e una semplice Descrizione , che ci consenta di poter identificare meglio il nostro. Una volta forniti questo elementi, si passa all’editor grafico, attraverso i quali si definiscono gli stati ed i relativi passaggi da  uno stato all’altro.

L’editor grafico è molto semplice ed intuitivo. Selezionand Add status si aggiungono nuovi stati, mentre con Add transition si aggiungono nuove transizioni tra gli stati.

Per chi lo desidera, è possibile impostare anche un editor di testo per definire i Workflow.

Sostengo che l’editor grafico risulti assai meglio per definire il tutto, e che permetta anche di capire meglio se i passaggi di stati sono quelli che ci aspettiamo.

In aggiunta, se siamo con l’editor grafico, abbiamo delle autocomposizioni che ci aiutano nella creazione, come mostrato in figura:

Altra precisazione: Il Workflow viene creato in stato Inactive, come mostrato in figure precedenti. La sua attivazione avverrà solo dopo che sarà assegnato ad un Progetto.

A questo punto, con tali strumenti già integrati in JIRA, è possibile creare il Workflow che ci serve. Una volta generato, lo possiamo assegnare al progetto per attivarlo, come mostrato nel post inerente la gestione degli Asset Manager con JIRA.

Una volta creato il Workflow, occorre anche definire il Workflow Scheme, ovvero indicare quali Workflow utilizzare in base a Issue Type e progetto.

Conclusioni

Abbiamo visto in questo articolo come creare il nostro Workflow, chi lo può creare e che operazioni possono essere eseguite. Nei prossimi post vedremo come estendere il tutto ed integrarlo con altri addons.

Esempio di uso

In questo post andremo ad esaminare un semplice esempio di uso di JIRA.

Iniziamo

Il nostro obbiettivo è quello di avere a disposizione un sistema che, attraverso una email sui inviamo delle richieste, abbiamo la contestuale creazione di email da parte di JIRA. Questa è una funzione nativa su JIRA e ci consente di poter implementare un semplice Help Desk per situazioni molto semplici.

Configurazione

Passiamo subito all’azione e configuriamo il tutto. Il primo passo è di disporre di una email per poter eseguire queste operazioni. Per questo ci viene incontro GMAIL. Creiamo la nostra email di servizio e da li procediamo di conseguenza.

Successivamente passiamo alla fase di configurazione di JIRA: Configuriamo le Incoming Mail. Posizioniamoci nella sezione di amministrazione di sistema e selezioniamo la sezione dedicata:

A questo punto, procediamo con la autocomposizione, completando tutte le sezioni richieste.

Terminata questa fase, si procede con la configurazione del Mail Handler, che di eseguire le varie operazioni

specificando la tipologia di Handler che si intende creare, ovvero (come mostrato in figura)

Quello che ci interessa è il primo, ovvero creare una nuova Issue/aggiungere i commenti alla esistente.

Anche in questo caso, una agevole autocomposizione, ci guida nella configurazione. In particolare ci indica quale progetto dobbiamo fare riferimento per generare queste Issue.

Una volta completato questa fase, possiamo iniziare a generare le nostre Issue. Semplicemente, basta inviare le mail all’account di posta che abbiamo creato in precedenza. In prima battuta, sarà creata una Issuedove:

• il titolo della mail sarà il titolo della Issue 
• il corpo della mail sarà la descrizione della Issue
• Gli allegati della mail saranno allegati alla Issue

A questo punto, se nel titolo della Issue andiamo a specificare la chiave della Issue, ovvero:

<CHIAVE>-<NUMERO>

allora, invece di creare una nuova issue, semplicemente andrà a generare un commento nella Issue indicata. Gli allegati alla mail saranno allegati alla Issue.

Conclusioni

Abbiamo un semplice esempio di Help Desk, che si può realizzare attraverso le funzionalità standard di JIRA. Questo è sicuramente molto comodo se si vuole realizzare una soluzione semplice.

Workflow & JIRA

In questo post, introduciamo il concetto di Workflow su JIRA, spiegando che cosa si intende per Workflow su JIRA ed approfondendo l’argomento in altri post.

Iniziamo dalle definizioni

Partiamo dalle definizioni, ovvero: Con il termine Workflow su JIRA si intende l’insieme degli stati e delle transazioni che una Issue può assumere nell’ambito di un progetto JIRA. La seguente figura rappresenta un esempio di Workflow.

Quando si JIRA si definisce un Workflow, si definisce quali stati una  Issue può assumere, quali passaggi di stato sono possibili, in che stato viene aperta una Issue. Un esempio di tale situazione può essere vista nel post, dove ho descritto come realizzare un Asset manager con JIRA.

JIRA mette a disposizione Workflow standard, come indicato in questo post.

Come JIRA Administrator, possiamo eseguire delle customizzazioni e crearne di nuovi, in base alla nostre esigenze:

Il  Workflow sopra riportato è stato utilizzato per dimostrare come realizzare un Asset manager con JIRA :-).

Occorre tenere presente i seguenti punti:

• Ogni JIRA Project dispone di un suo Workflow. In base alla tipologia di progetto, JIRA assegna un determinato Workflow;
• Il JIRA Administrator può creare dei Workflow ad hoc, in base alle esigenze del progetto.
• Lo stesso Workflow può essere utilizzato da più progetti;

Perchè personalizzare il Workflow?

La risposta è: Dipende. Quello che posso consigliare è verificare le esigenze del progetto e valutare in che modo si può eseguire l’operazione. Occorre però tenere presente che il Workflow di JIRA non è in grado di fare qualsiasi cosa. Rimanete con i piedi per terra :-).

Proprio in base alla definizione data all’inizio, si tratta di definire sia quali stati può possedere una Issue, sia quale sequenza di cambio stato può essere eseguita. Se si vuole eseguire delle operazioni più complesse, allora occorre tenere presente che si deve integrare JIRA con ulteriori addon, da valutare molto attentamente e con un determinato giudizio.

Conclusioni

In questo primo post è stato dato il first look al Workflow su JIRA. Nei prossimi post andremo ad esaminare come gestirli, modificarli e come crearne di nuovi.

Reference

• Definizione
• Manualistica

Addons per Cloud

In questo post iniziamo ad analizzare come realizzare un addon per i prodotti Atlassian su Cloud. Parleremo di Atlassian Connect.

Due parole prima di iniziare

Lo sviluppo su Atlassian Connect non può essere fatto allo stesso modo degli addon per installazione Server. Essendo un sistema configurato in maniera differente, deve ragionare in maniera differente. Già in questo post, avevo indicato quali sono le differenze tra i Server e Cloud. Queste differenze si riflettono anche nello sviluppo degli addon per la versione Cloud.

Occorre tenere presente che, fondamentalmente, l’addon per Cloud è una webapp a se stante che si interfaccia con la componente Cloud, sfruttando le chiamate REST e controllandone le risposte che restiruisce.

Che cosa è Atlassian Connect?

Connect è un framework che la Atlassian mette a disposizione per mettere in comunicazione gli Addons, che come indicato in precedenza sono delle web application, con Confluence e JIRA Cloud.

Come indicato nel seguente diagramma, presente nella documentazione Atlassian:

l’addon si interfaccia con l’istanza cloud Atlassian. L’utente finale non vede alcuna differenza: non si deve preoccupare di dover modificare alcuna configurazione: Sarà il Confluence o il JIRA di turno a richiamare la web application e a comunicare con essa.

Come sarà organizzata?

L’addon sarà costruito secondo opportuni criteri e deve essere impostata in modo da riportare delle informazioni (in particolare, determinati contenuti) nella UI dei prodotti Atlassian, in modo da poter richiamare le funzionalità della web application.

L’addon dovrà poi comunicare con i prodotti Atlassian attraverso le chiamate REST e attendere/rispondere a Webhooks.

Conclusioni

Come precedentemente esposto, la realizzazione di addon per Cloud richiede un differente approccio rispetto agli addon per le versioni Server. Nei prossimi post andremo a vedere il classico Hello World .

Reference

La manualistica può essere reperita qui

Ultime news

In questo post, proseguiamo quanto iniziato nei post dedicati agli addon della Kanoah.

• Presentazione
• Test su strada – 1
• Test su strada – 2

Andiamo in dettaglio

Il 2 luglio 2015 è stata rilasciata la versione 1.2.0 dell’addon Kanoah Tests. Di seguito riportiamo le ultime novità:

Possibilità di poter aggiungere dei campi custom nei Test Cases e nei Test Plans

Viene data la possibilità di poter aggiungere campi custom ai Test Cases ed ai Test Plans. Questo consente di poter aggiungere informazioni supplementari che prima non era possibile gestire. Nel caso di situazioni che richiedono informazioni ad hoc, possiamo aggiungere nuove informazioni 🙂

Validazione di campi custom

Viene offerta la possibilità di poter eseguire una validazione dei campi custom, proprio in base ai campi stessi.

Aggiornare i Test Cases massivamente

Viene offerta la possibilità di poter selezionare più Test Cases al fine di poterli aggiornare massivamente.

Conclusioni

Si tratta di migliorie operative, che sicuramente aiuteranno gli operatori nell’espletare il proprio lavoro nelle sessioni di test.

Reference

Maggiori dettagli sono reperibili qui

Prova su strada

In questo post andremo a verificare il funzionamento di questo addon. Facciamo seguito al post pubblicato in precedenza.

Installazione

L’installazione, come sempre molto semplice, non ci preoccupa più di tanto. Una volta rintracciato l’addon, procediamo

Una volta accettata la EULA, possiamo procedere con il download

Terminato quest’ultimo, si procede con l’installazione

Quindi si procede con la richiesta della licenza (come sempre TRIAL)

Inseriti i dati dell’account atlassian, viene generata in automatico la licenza

quindi, se non ci sono stati intoppi, l’addon risulta disponibile.

Al termine della installazione, ci potrebbe essere richiesto di eseguire una operazione di reindex. Questo può capitare quando si installa un nuovo addon che potrebbe prevedere la generazione di nuovi campi custom. In questo caso, consiglio sempre di eseguire questa operazione di reindex subito. L’operazione è safe e normalmente non prevede alcuna controindicazione :-). Dalla immagine sottostante si vede che JIRA stesso richiede di eseguire tale operazione e fornisce il link diretto.

Selezionare l’opzione di Backgroud re-index e dopo pochi istanti l’operazione è conclusa.

Primi passi

A questo punto possiamo procede con l’utilizzo dell’addon stesso. Il primo passo è la generazione di un progetto XRAY Test Project, come mostrato in figura:

Una volta selezionato il progetto evidenziato, viene indicato quale tipologia di issue avremo a disposizione

Come indicato nel post di presentazione, i test sono gestiti sfruttando le ISSUE di JIRA. Proseguendo, assegniamo il nome al nuovo progetto:

Una volta confermato, il progetto viene generato e nella schermata di Overview di progetto.

Gestiamo un TEST

A questo punto, per creare un TEST, semplicemente creiamo una nuova ISSUE, di tipo Test, come mostrato in figura:

Inseriamo un pò di informazioni, per creare il nostro test

Dalla figura precedente, osserviamo che possiamo descrivere in ogni singola componente tutti i vari step che compongono il test, definendo ogni singolo passo che deve essere eseguito al fine di verificare la funzionalità oggetto del test. Possiamo associarlo ad una Test Sets, ovvero ad un insieme di test (lo possiamo definire anche in questa fase)

e possiamo anche eseguire il link alle issue JIRA del progetto

A questo punto a issue è pronta ed usabile per il nostro test. Vediamo adesso come procedere.

Creiamo il nostro Test Sets di lavoro

e quindi creiamo il nostro Test Execution

Procediamo quindi alla esecuzione del test. Spostiamoci nel dettaglio del Test Execution creato in precedenza. Quindi inseriamo i dati di quando iniziamo ad eseguire il test

quindi andiamo nella sezione Tests ed aggiungiamone uno nuovo, o il Test Sets o il Test creato in precedenza.

Supponiamo di aggiungere il nuovo test XRAY-1

A questo punto sarà visualizzata la sezione dedicata alla esecuzione del test.

e possiamo procedere con il test, o attraverso il menù cog, a fianco della colonna status, che compare non appena il mouse si porta proprio li sopra:

dove possiamo lanciare l’esecuzione del test oppure possiamo direttamente settare il risultato del test.

Fatto ciò, abbiamo concluso l’esecuzione del test e possiamo chiudere il task. Una volta selezionato il risultato del test, dalla interfaccia principale del progetto di test, possiamo visualizzare i risultati dei vari test, come mostrat in figura.

Conclusioni

Abbiamo a disposizione un addon molto semplice, che possiamo usare senza grandi problemi o addestramenti particolari. Questo è sicuramente un vantaggio: chiunque disponga di un addestramento su JIRA, può tranquillamente impostare i vari TASK ed usarli senza problemi :-).

In aggiunta, ma non meno importante, il costo molto contenuto, lo rende un addon appetibile  🙂

Gestiamo i test con JIRA

In questo post andremo ad esaminare un nuovo addon, che può estendere JIRA in modo da poter gestire dei TEST. Vediamo una alternativa a questi addon.

Vediamo le caratteristiche

Questo addon estende le funzionalità di JIRA e consente di poter gestire i test.

In particolare:

• Crea i test come issue JIRA. Questo facilità l’approccio per tutti coloro che sono abituati alla gestione delle issue JIRA;
• Aiuta nella definizione dei passi del test stesso e nella definizione dei risultati aspettati.
• Consente di inserire le informazioni su quali argomenti sono coperti dai test, quali requireents e defects
• Precondizioni e informazioni associate al test
• Consente di poter raggruppare i test
• Aiuta nella gestione ,assegnazione, guida passo passo e verifica dei progressi del test

In aggiunta, reportistica e grafici sono a disposizione di chi deve gestire il tutto

Conclusioni

Da una prima analisi, l’addon sembra molto semplice e di rapido apprendimento. Sembra integrarsi molto bene con le caratteristiche e le funzionalità di JIRA ed i costi sono molto contenuti. Nei prossimi post andremo a eseguire la classica…. prova si strada.

Riferimenti

• Atlassianmarket
• Articolo (in Portoghese Brasiliano) che parla dell’addon.
• http://www.youtube.com/watch?v=w_9-Un6moGk

Proseguiamo il nostro confronto

In questo post, proseguiremo il nostro viaggio, verificando come possiamo gestire un progetto utilizzando altri prodotti Atlassian.

JIRA Service Desk

Ad un certo punto, il progetto sarà eseguito il deploy del progetto e sarà reso fruibile agli utenti. Da quest momento in avanti, quello che si andrà a dover gestire è la manutenzione dello stesso.

A tale proposito JIRA Service Desk è la soluzione migliore per poter gestire il Service Desk del progetto. Facilmente integrato con tutti i prodotti della Atlassian, consente di poter implementare un sistema di gestione delle anomalie/richieste/nuove evolutive, in maniera molto semplice.

In maniera molto semplice, e con pochi click, come già spiegato in questi posts, possiamo implementare un sistema molto semplice, con una interfaccia chiara e diretta. Pochi passi e anche chi si occupa di gestire queste situazioni, dispone di un quadro completo.

Pochi click e già si dispone di un sistema comprensivo di reportistica e di strumenti in grado di monitorare la produttività.

L’integrazione con JIRA, consente agli agenti di potersi interfacciare direttamente con il gruppo di sviluppo / manutenzione senza grandi difficoltà e, una issue generata con JIRA Service Desk viene subito reindirizzata alla persona giusta affinché la gestisca nel minor tempo possibile.

La possibilità di poter modificare il workflow, in modo da gestire tutte le situazioni di cui si ha la necessità, ci consente di poter coprire le nostre esigenze al meglio.

Conclusioni

Abbiamo uno strumento valido per gestire il servizio di trouble ticketing, che abbiamo già esaminato in dettaglio in altri posts, che nella gestione di un progetto non deve assolutamente mancare. Nei prossimi post, andremo ad inserire FISHEYE e JIRA Capture per andare a gestire meglio determinate situazioni.

Prova su strada – Parte 2

In questo post, concludiamo la prova su strada degli addons rilasciati dalla Kenoah, presentato nel post. La prima parte della prova su strada è visibile nel seguente post.

Test cases – Definizioni preliminari

Prima di iniziare la prova su strada, partiamo dalle definizioni preliminari e facciamoci aiutare da Wikipedia. Prima di continuare, fare riferimento a:

• Test Case o caso di test. Si tratta delle condizioni per verificare se il programma risponde correttamente
• Test Plan o piano dei test che devono essere eseguiti per verificare che le funzionalità, che compone un software, rispondono correttamente

Test test test test

Iniziamo con l’installazione dell’addon

Dopo aver eseguito l’installazione, l’addon è pronto all’uso 🙂

Possiamo usare subito l’addon. Tra i vari menù, abbiamo a disposizione una nuova voce: Tests.

Se selezioniamo questa nuova voce di menù, passiamo alla definizione dei vari Test Case

Procediamo con la definizione di un Test Case di prova :-). Selezioniamo NEW

Possiamo definire le seguenti sezioni:

• Details, intesi come i dettagli generali del test
• Test Script, dove definiamo il dettaglio dei vari passi che devono essere eseguiti
• Run History, dove vediamo le volte in cui il test è stato eseguito
• Coverage, dove abbiamo l’elenco delle issues che sono coperte da questo test
• Attachments, dove indichiamo tutti gli attachments che sono utili

Nel definire i Test Script, abbiamo la possibilità di poter definire quali passi devono essere eseguiti per eseguire il caso di test.

ovviamente si tratta di un esempio :-). Ma immaginate quali informazioni potete inserire. Possiamo dettagliare il test in tutti i passi che sono necessari per ricostruire la situazione. Questo significa che possiamo avere il dettaglio completo di quello che si vuole fare 🙂

A questo punto, dopo aver definito tutti i Test Case, possiamo costruire tutti i Test Plans. Vediamo come:

Come per i Test Case, andiamo a definire prima il Dettaglio generale.

Quindi, andiamo a selezionare i Test Case che vogliamo siamo eseguiti. Un drag & Drop ed il gioco e fatto.

Salviamo ed il gioco è Fatto

Quindi?? andiamo ad eseguire il nostro Test Plan interessato

Selezioniamo il tasto Run per procedere con il test vero e proprio.

Creando il Test Run, andiamo a indicare che caratteristiche deve possedere, indicando anche quando deve essere eseguita e conclusa.

Quindi, una volta indicate queste informazioni, passiamo al RUN vero e proprio. Abbiamo a disposizione un Timer, che indica quanto tempo ha richiesto il test vero e proprio.

Se Il test è passato, settiamo lo stato in Pass. Altrimenti indichiamo lo stato richiesto.

Al termine, possiamo vedere i risultati nella reportistica, che l’addon mette a disposizione.

Come si vede, abbiamo tutte le informazioni del caso.

Conclusioni

Abbiamo un addon che consente di poter pianificare e gestire in maniera semplice e ben fatta tutti i test di cui abbiamo bisogno. In questo modo, possiamo disporre di una libreria di test, rendendo la vita del Team di test …. molto più piacevole e sicura.

Prova su strada – Parte 1

In questo post andiamo ad esaminare la prova su strada degli addons, presentati nel precedente post.

Checklist

Partiamo dall’addon della checklist. Installiamo l’addon, come sempre:

L’addon viene scaricato e installato sulla nostra istanza server di JIRA.

Completata l’installazione, si passa a richiedere la licenza. Nel nostro caso, ho richiesto la licenza Trial.

Terminata l’operazione, si può usare l’addon. 🙂

Il primo passo è quello di creare un nuovo Campo Custom, come mostrato nelle seguenti immagini.

Possiamo creare direttamente dalla form di gestione della Issue oppure dalle form di amministrazione dei campi.

Come tipo del campo, selezioniamo Checklist, che consente di poter generare quello che ci serve.

Concludiamo la configurazione, indicando una descrizione. A questo punto possiamo definire le voci che compongono la checklist

oppure possiamo entrare nel dettaglio dell’editing della issue e procedere con la generazione della checklist

Possiamo, ad esempio, stabilire i passi per eseguire il test e verificare che l’anomalia sia effettivamente risolto. Il risultato è il seguente:

Quando si verifica che il passo è rispettato, su può selezionare il passo stesso

e come si vede, la barra di avanzamento, si modifica.

Risultato?

Questo addon mette a disposizione uno strumento visuale che, in maniera molto semplice, fornisce una indicazione dell’avanzamento della verifica anomalia. In questo modo, sia chi esegue il test, sia chi esegue la correzione, dispone di una indicazione per capire fino a che punto si è arrivato nella verifica o nello sviluppo.

Le potenzialità sono tantissime.

Conclusioni

Abbiamo un addon che introduce una piccola feature, ma mette a disposizione una funzionalità visuale non indifferente. Nel prossimo post, andremo a vedere il secondo addon della Kenoah.

https://marketplace.atlassian.com/plugins/com.kanoah.test-manager

https://marketplace.atlassian.com/plugins/com.kanoah.jira-checklist