Esecuzione della traccia del lavoro e di build

Questi argomenti descrivono come creare record baseline e build e come eseguire la traccia e completare attività, operazioni e richieste.

Un tipo di record progetto (Project) può essere utilizzato per tracciare la produzione di un release di prodotto attuale. Un progetto potrebbe includere un nome di prodotto, informazioni sulla release e l'insieme di iterazioni associate al progetto. Potrebbe inoltre includere informazioni sul componente per un progetto.

Ogni volta che il codice sorgente viene modificato, viene eseguito la build dell'applicazione e verificato se è di qualità sufficiente per iniziare l'esecuzione del test. Una volta eseguita la verifica, la build viene distribuito ai server per l'esecuzione del test. Questo modello di consegna delle modifiche del codice sorgente, di esecuzione della build dell'applicazione e di esecuzione del test si verifica indipendentemente dall'ambito o dalla grandezza di un release (ad esempio, se è una revisione principale di un'applicazione esistente, una patch o hotfix). Quando vengono rilevati errori, i difetti vengono registrati e il codice sorgente viene modificato per correggere il difetto. Quindi, deve essere eseguito la build dell'applicazione ed eseguita la distribuzione ai server per l'esecuzione del test.

I record ALM Baseline e Build possono essere utilizzati con progetti che utilizzano le integrazioni UCM (Unified Change Management) IBM Rational ClearCase/ClearQuest, così come con quelli che non le utilizzano. I record Baseline e Build possono anche essere utilizzati per assicurare una corretta consegna di progetti o release di prodotti oppure di informazioni per i clienti. Ad esempio, i record Baseline e Build possono abilitare il trasferimento automatizzato delle informazioni dallo sviluppo all'esecuzione del test, informando i tester su quali build di prodotto contengono le fix a richieste specifiche.

Lo schema ALM supporta un modello di flusso di lavoro in cui si verifica sviluppo parallelo iterativo ed esecuzione di test. Viene eseguito la build e quindi il test delle modifiche:

In questo modello, tutte le attività sono correlate. Come gli sviluppatori implementano la funzionalità e correggono i difetti, i tecnici release devono conoscere quale origine includere nella build o quando eseguire la build (ovvero, quando tutto il lavoro previsto è completo). Quando emergono problemi con la build i tecnici di release devono individuare la causa del problema, se questo è nello script della build stessa o in qualche errore introdotto dal team di sviluppo. Contemporaneamente, i tester devono conoscere quando è disponibile una build appropriata da testare, quale funzionalità è inclusa nella build e quali test eseguire in tale build. Ogni volta che viene notificato un difetto, è necessario conoscere gli scenari di test utilizzati per scoprire il difetto insieme ai riferimenti al requisito di origine. E quando lo sviluppatore corregge il difetto e consegna il codice, il ciclo inizia di nuovo.

Nei progetti di sviluppo del software l'esecuzione di build si verifica in modo costante. Le domande comuni per i team di sviluppo sono relative a cosa è implementato nella build e cosa è stato sottoposto a test nella build. Il record Build consente ai team di catturare informazioni su ogni build, incluso il relativo stato. Il record Baseline consente di tracciare le attività consegnate in ogni build e può essere utilizzato per catturare lo stato delle attività in un dato momento. L'uso dei record Baseline, Build e Activity abilita i tester a sapere di cosa eseguire il test e la traccia e quali test sono stati eseguiti nella build.

Concetti correlati
Panoramica
Gestione di progetti
Gestione del lavoro
Dati di esempio
Campi obbligatori per i tipi di record ALM
Attività correlate
Guida introduttiva per gli amministratori

Feedback