Guardalo prima
Cosa ti serve
- Azure DevOps Services: un indirizzo come
dev.azure.com/yourcompany. (Azure DevOps Server sui tuoi server non è supportato.) - Un account che può creare work item nel progetto a cui devono andare i bug.
- Diritti di amministratore nella tua area di lavoro di UAT Studio.
Collega il tuo progetto Azure DevOps
Trova la tua organization, il progetto e il processo
Apri il tuo progetto in Azure DevOps e guarda la barra degli indirizzi: dev.azure.com/acme/Customer Portal. La prima parte è l'organization (acme), la seconda il progetto (Customer Portal), esattamente come scritti lì, spazi compresi.
Poi controlla il processo del progetto: Project settings › Overview › Process.
| Processo | Tipo di work item da usare |
|---|---|
| Agile, Scrum o CMMI | Bug: con Repro Steps, Severity, Priority e tag. |
| Basic | Issue: Basic non ha il tipo Bug. Il work item riceve titolo e descrizione; Basic non ha campi per gravità e priorità. |
Crea un personal access token
- In Azure DevOps, fai clic sull'icona User settings in alto a destra (la persona con l'ingranaggio, accanto alle tue iniziali) e scegli Personal access tokens.
- Fai clic su + New Token.
- Name: UAT Studio. Organization: la tua organization. Expiration: scegli Custom defined, fino a un anno.
- Scopes: scegli Custom defined e spunta Work Items › Read & write. Per leggere anche i casi di test da Test Plans, spunta anche Test Management › Read.
- Fai clic su Create e copia il token. Azure DevOps lo mostra una sola volta: tieni aperta la finestra finché non lo hai incollato al passo 4.
Aggiungi Azure DevOps in UAT Studio
Accedi su app.uat.studio, apri la tua area di lavoro e fai clic su Connections. In Add a connection, scegli Azure DevOps e fai clic su Add.
| Campo | Cosa inserire |
|---|---|
| Name | Il testo del pulsante: Send to Azure DevOps. Cambialo se colleghi più di un progetto. |
| Organization | La parte dopo dev.azure.com/, come acme. |
| Project | Il nome del progetto esattamente come in Azure DevOps, come Customer Portal. |
| Work item type | Bug, oppure Issue in un progetto Basic (vedi passo 1). |
| Area path | Facoltativo: dove vanno i work item, come Customer Portal\UAT. Vuoto: l'area predefinita del progetto. |
Fai clic su Save settings.
Salva il token
Incolla il token del passo 2 nel campo Personal access token e fai clic su Store token. Il campo mostra poi solo gli ultimi 4 caratteri.
Verifica la connessione
Fai clic su Test connection. UAT Studio controlla il token, il progetto e che il tipo di work item esista. Se è tutto a posto vedi Connected to project … in …; work items of type Bug can be created e OK accanto all'ultima verifica. Se il tipo non esiste, il messaggio elenca i tipi presenti nel progetto.
Inviare le anomalie ad Azure DevOps
Una singola anomalia
Apri l'anomalia. In Ticket in the development team's system, fai clic su Send to Azure DevOps.
Il numero del work item e un link compaiono sull'anomalia, e la sua cronologia mostra quando è stata inviata e da chi. Un'anomalia già collegata non può essere inviata due volte per errore.
Tutte le anomalie dopo la riunione di triage
In Issues › Triage, prendi una decisione su ogni nuova anomalia. Quando hai finito, fai clic su Send 3 to Azure DevOps (o quante sono) per creare tutti i work item in una volta.
Cosa contiene il work item
- Titolo: il numero e il titolo dell'anomalia, come ISS-012: Quote PDF shows the wrong VAT rate.
- Repro Steps e Description: ciò che ha scritto il tester, il caso di test con il passo fallito e il risultato atteso, e chi l'ha trovata, con un link di ritorno a UAT Studio.
- Severity, Priority e i tag
UATe il numero dell'anomalia (non in un progetto Basic). - Attachments: gli screenshot e i file dell'anomalia, fino a 10 file di massimo 10 MB ciascuno.
Unire i duplicati
Quando unisci due anomalie che hanno entrambe un work item, il work item duplicato riceve un commento, il collegamento Duplicate Of all'altro e viene chiuso (Closed, Done o Resolved, a seconda di ciò che il processo consente). Quando solo il duplicato aveva un work item, l'anomalia che resta lo eredita.
Quando la correzione è completata in Azure DevOps
Quando lo sviluppatore imposta il work item su Resolved, Done o Closed, l'anomalia in UAT Studio diventa Ready for retest e il tester riceve un'email. Active, Committed o Doing impostano l'anomalia su In progress. Lo stato in Azure DevOps è mostrato accanto al link.
Un retest fallito non viene mai annullato: se il tester riapre l'anomalia mentre il work item è ancora Resolved, UAT Studio la lascia aperta. Un'anomalia chiusa resta chiusa.
Da solo, o subito
Senza fare nulla, UAT Studio controlla lo stato ogni volta che un amministratore apre le anomalie, e con il pulsante Update ticket status.
Subito: lascia che sia Azure DevOps a informare UAT Studio quando un work item cambia, con un service hook. Devi essere amministratore del progetto in Azure DevOps.
- In UAT Studio, in Connections, nella connessione Azure DevOps, fai clic su Create webhook address e copia l'indirizzo. Viene mostrato una sola volta.
- In Azure DevOps, apri il progetto e vai su Project settings › Service hooks. Fai clic su Create subscription.
- Scorri l'elenco dei servizi, scegli Web Hooks e fai clic su Next.
- Trigger on this type of event: Work item updated. In Filters, imposta Field su State, così vengono inviati solo i cambi di stato. Area path e Work item type possono restare [Any], oppure restringili all'area e al tipo del tuo progetto. Fai clic su Next.
- URL: incolla l'indirizzo del passo 1. Lascia vuoti gli altri campi (username, password, headers). Fai clic su Test per verificare, poi su Finish.
Chi può fare cosa
Se qualcosa va storto
| Vedi | Cosa fare |
|---|---|
| Il token non viene accettato, o non ha accesso a questa organization | Controlla il nome dell'organization (la parte dopo dev.azure.com/), che il token sia stato creato per quella organization e che abbia lo scope Work Items (Read & write). Oppure crea un nuovo token e salvalo di nuovo. |
| Il progetto non ha il tipo di work item «Bug» | Probabilmente il progetto usa il processo Basic: inserisci Issue in Work item type. Il messaggio elenca i tipi disponibili. |
| Non trovato (404) | Controlla il nome del progetto: esattamente come nella barra degli indirizzi, spazi compresi. |
| Prima funzionava, ora no | Probabilmente il token è scaduto o è stato revocato. Creane uno nuovo e salvalo; il resto rimane com'è. |
| Lo stato non torna indietro | Apri le anomalie come amministratore, oppure fai clic su Update ticket status. Con un service hook: in Azure DevOps, Project settings › Service hooks mostra se è stato eseguito e cosa ha restituito; in Connections in UAT Studio vedi quando è arrivato l'ultimo messaggio. |
| Nessun pulsante Send to Azure DevOps | Lo vedono solo gli amministratori, e solo quando la connessione è On e ha un token salvato. |
| Le connessioni non fanno parte del tuo piano | Le connessioni sono incluse in Team, Business, Partner ed Enterprise, e come modulo aggiuntivo per Project. Il tuo amministratore può passare a un piano superiore in Plan & billing. |
Ancora bloccato? Scrivi a [email protected] con il messaggio che vedi. Non inviarci mai il token stesso.
Usi Jira? Vedi Collegare UAT Studio a Jira. Tutte le guide: Guida di UAT Studio.
Come gestiamo il tuo token
- Il token va dal tuo browser al nostro server una sola volta, su una connessione cifrata.
- Viene conservato cifrato (AES-256). La chiave per decifrarlo è conservata separatamente dal database, quindi una copia del solo database è inutile.
- Nessuno può rileggere il token: né nell'app, né tramite il supporto.
- UAT Studio usa il token solo per verificare la connessione, creare i work item che invii (con i relativi file), leggere lo stato di quei work item e chiudere un duplicato dopo un'unione. Gli serve solo lo scope Work Items.
- Rimuovi la connessione o revoca il token in Azure DevOps, e l'accesso termina immediatamente.