Esempio di uso

In questo post andremo ad esaminare un addon, forse non molto considerati, ma che può sicuramente risultare utile nel proprio lavoro di tutti i giorni.

A cosa serve?

Questo addon consente di poter copiare una pagina, e la relativa alberatura sottostante, da uno space ad un’altro, specificando lo space dove andare a copiare, come mostrato nella figura precedente.

L’addon mette a disposizione la possibilità di poter modificare i nomi delle nuove pagine copiate e di poter eseguire delle operazioni di renaming/aggiunta prefissi e suffissi agli attachments. Viene anche data la possibilità di poter copiare o meno gli attachments stessi 🙂

UN agevole LOG consente di poter visionare l’avanzamento della operazione di copia, mettendo a disposizione uno strumento agevole.

Che utilizzi possiamo avere?

Questa è sicuramente la domanda più importante. Per quale motivo possiamo utilizzare questo addon?

Schede Clienti

Un primo utilizzo che mi viene in mente potrebbe essere quello di utilizzarlo come sistema per creare delle alberature standard nel nostro Confluence Cloud. Se abbiamo la necessità di disporre, anche su space differenti, di una particolare alberatura di pagine, che sia sempre la medesima, questo sistema è sicuramente il più semplice.

Un esempio banale, potrebbe essere quello di creare delle schede clienti. Potremmo avere necessità di una alberatura standard, dove andare a posizionare le varie informazioni del cliente, e con questo sistema, basta disporre di uno Space che contenga il template, ed il gioco è fatto. 🙂

Template standard

Nel caso in cui il semplice Template non sia sufficiente ai nostri obbiettivi, ovvero abbiamo la necessità di disporre di template di pagine standard per gestire i vari meeting, analisi, documentazione, etc. Questo può essere realizzato sia su installazioni Server che su installazioni Cloud.

Conclusioni

Anche se a prima vista gli addon non sembrano svolgere chissà quale funzione, consiglio vivamente di far correre la fantasia. Vedrete che i vari addon possono sopperire a necessità inaspettate, arrivando a sorprendere sempre 🙂

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

Workflow su Confluence

In questo post andremo ad introdurre un concetto di Workflow su Confluence.

Che cosa è un Workflow?

Come prima cosa, cerchiamo di dare una definizione di Workflow Per fare ciò, consiglio questo link, dove ho trovato una bella definizione di workflow e consiglio anche la pagina di wikipedia (in inglese, ma la consiglio).

Fondamentalmente, andando al sodo, un Workflow è il flusso di lavoro che deve essere eseguito per svolgere una determinata operazione, in ambito di un business.

Come si può introdurre il concetto di workflow su Confluence?

Spieghiamo in che modo possiamo calare questo concetto su Confluence 🙂

In ambito wiki, si ha la necessità di un Workflow quando si devono pubblicare delle pagine in cui, per evidenti motivi, le informazioni devono essere prima vagliate/approvate da un responsabile che deve accertare che tutte le informazioni presenti siano corrette.

Basti pensare ad un sistema in cui ogni pagina wiki presenta delle informazioni finanziarie di una società. Se questa pagina è visionata da un numero molto elevato di utenti, la pubblicazione di una informazione errata potrebbe scatenare problemi non indifferenti.

Quindi, in situazioni come questa, dove se viene eseguita una pubblicazione senza controllo esiste un grosso rischio, trova la sua naturale applicazione un Workflow.

Come possiamo applicare un Workflow in Confluence?

In Confluence abbiamo a disposizione un Addon che consente di poter aggiungere un Workflow su Confluence. SI tratta del Comala Workflow.

Questo addon consente di poter assegnare uno stato specifico alle pagine di uno space. In aggiunta, possiamo assegnare un Workflow specifico ad ogni singolo space.

Possiamo assegnare task specifici ad un singolo utente, come mostrato nella precedente figura. Questi riceverà una opportuna segnalazione, in modo da poter poi procedere con le operazioni richieste.

Opportune macro consentono di poter creare delle pagine, in cui riassumere gli stati assunti dalle pagine

Nei prossimi post andremo a collaudare questo addon per saggiarne le potenzialità e limiti.

Alternative?

Come prima cosa, l’addon indicato è disponibile solo per installazioni Server, mentre non è affatto disponibile per Cloud. Quindi, sorge spontanea la domanda: Esistono delle alternative?

La risposta è si, e sarà oggetto di un post dedicato esclusivamente a questo punto.

L’idea è la seguente e si basa sull’uso di funzionalità standard.

Come prima cosa, occorre disporre di due space:

• Space Pubblicato, ovvero lo space effettivamente disponibile al pubblico utenti
• Space privato, clone dello space pubblicato, dove gli autori eseguono le correzioni/modifiche/aggiunte.

Come seconda cosa, possiamo associare degli stati agli space basandoci sulle Page properties, descritte in questo mio post, e usate anche in tanti altri esempi 🙂

Come seconda cosa, utilizziamo i Tasks di Confluence, per assegnare i compiti alle persone e mandare loro delle segnalazioni, un pò come avviene con l’addon, ma facendo uso solo delle funzionalità standard.

In questo modo, ed usando un pò di organizzazione, gli utenti lavorano nello space privato, a meno di correzioni del tipo:

• errori di battitura;
• correzioni dell’ultimo minuto, etc

cambiando stato (nelle page properties) ed impostando i task su di una opportuna pagina di uno space di lavoro.

Conclusioni

Abbiamo a disposizione degli strumenti opportuni per poter impostare un Workflow su Confluence, sia come addon specifici, sia come unione di funzionalità standard che, alla fine dei giochi, possono metterci a disposizione un Workflow molto primordiale ma, nel contempo, semplice e funzionale. Questi argomenti saranno approfonditi su altri post.

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.

Nuove migliorie

In questo post andremo a visionare le ultime novità introdotte dalla Atlassian, su JIRA Service Desk per la versione 2.5. Continuiamo quanto riportato nei post:

• JIRA Service Desk 2.0
• JIRA Service Desk 2.2
• JIRA Service Desk 2.3
• JIRA Service Desk 2.4

Ultime novità

Le ultime novità riguardano i seguenti aspetti:

• Reporting: Migliorato ed aggiunte nuovi reports, per meglio monitorare le attività degli agenti.

• Portal: Migliorata ulteriormente la possibilità di personalizzare il Portal

• Queue Update: Migliorato il comportamento delle code e migliorato l’update

Conclusioni

Si tratta mi piccole migliorie, ma sono sicuro che introducono un grande miglioramento. Nei prossimi post andremo ad esaminarle nel dettaglio, continuando il percorso iniziato con i seguenti post:

• Esempio di uso – Parte 1
• Esempio di uso – Parte 2
• Esempio di uso – Parte 3

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

Cloud o Server?

In questo primo post, di una serie dedicati all’argomento, andremo ad esaminare quali sono le differenze principali tra le due release dei prodotti. Obbiettivo è quello di fornire tutte le informazioni necessarie per operare la scelta migliore, in base alle esigenze.

Andiamo nel dettaglio

Credo che il primo punto da chiarire sia dare una prima spiegazione del perché di queste differenze. Innanzitutto, si tratta di situazioni differenti. Le versioni cloud (ex onDemand) sono gestite centralmente dal personale Atlassian e, di conseguenza, alcune funzionalità sono controllate direttamente da loro. Fornirle in mano ai clienti potrebbe essere controproducente in quanto potrebbe arrivare ad impattare altre installazioni.

Quali prodotti sono disponibili in cloud?

Prima di vedere le differenze, vediamo quali prodotti Atlassian sono disponibili.

• Confluence
• JIRA
• JIRA Service Desk
• JIRA Agile
• JIRA Portfolio
• Hipchat
• Bamboo

Adesso vediamo il dettaglio delle varie caratteristiche.

Il ruolo di System Administrator  viene ricoperto dal personale Atlassian. Di conseguenza, tutte le funzionalità che ruotano a tale ruolo, non sono disponibili.

I Backup schedulati non sono possibili, ma è comunque possibile eseguire una esportazione dati, al fine di riportarla su installazioni Server. I backup giornalieri NON sono consentiti in quanto il personale Atlassian li gestisce a livello centrale.

User Macro, HTML Macro e tutto ciò che impatta HTML (come macro standard) è disabilitato. Non esiste altra possibilità di poter abilitare tali addon su Cloud. Tuttavia, sono disponibili degli addon di terze parti che consentono di includere pagine web di siti terzi.

Mail Account e Mail server sono configurati e gestiti a livello centralizzato. Questo per gestire il tutto a livello centrale. Di conseguenza non è possibile customizzare questa parte.

Le versioni cloud utilizzano dei propri layout, ma non risulta possibile inserire delle variazioni ai CSS per la versione Cloud nè personalizzare il layout della versione cloud.

Non tutti gli addon sono disponibili per la versione Cloud. Il motivo è da ricercarsi nel fatto che, essendo la versione cloud centalizzata, la Atlassian ha modificato il come impostare gli addon per la soluzione cloud. Di conseguenza, anche lo sviluppo deve avvenire in maniera differente. Il seguente link aiuta a capire quali addon sono, al momento, disponibili. Come ho già avuto modo di evidenziare in post pubblicati, il numero di addon per la versione cloud è notevolmente aumentato nell’ultimo anno. Per la tecnologia da usare, fare riferimento ad Atlassian Connect. dedicheremo post a questo argomento.

Conclusioni

In questo post abbiamo dato una prima scorsa alle differenze tra le due installazioni, dove abbiamo visto quali operazioni sono possibili per una o per l’altra installazione. Questo aiuta sicuramente nella scelta del prodotto che si vuole e nel bugdet a disposizione. Nei prossimi post andremo a dettagliare le differenze, evidenziandole e commentandole.

Riferimenti

Pagina della documentazione Confluence disponibile qui.