Test del Software di Reporting Stato
“L’accordo che una certa informazione, in un certo formato, saranno inviate da una certa squadra/individuali, a determinati intervalli di tempo, ad alcuni membri – è come una stretta di mano – di un riconoscimento che non importa quale sia l’esito di un compito a portata di mano, si sarebbe tenuto pubblicato su di esso, prima che poi.”
Questa è la prima sezione del giuramento di un professionista IT. Beh, sto scherzando! Non c’è giuramento, ma se ce ne fosse uno, questo sarebbe sicuramente in cima alla lista degli elementi in esso contenuti. Vero?
Responsabilità e trasparenza (A & T) sono essenziali per ogni progetto IT a vari livelli: livello di progetto, livello di team, livello di attività e anche livello individuale. Come ci assicuriamo che questi attributi siano soddisfatti? La risposta è – comunicare, più formalmente-Segnalazione di stato!
A livello individuale, non tutti inviamo rapporti, per lo più, EOD ogni giorno per comunicare il compimento (o non realizzazione) dei vostri doveri quotidiani. Questo va a dimostrare che, in realtà “sono” consapevoli di ciò che i vostri doveri dovevano iniziare con.
Rapporto sullo stato giornaliero
Le informazioni che devono essere parte del “Rapporto sullo stato giornaliero” di un individuo sono:
- Cosa hai fatto oggi?
- Cosa pensi di fare domani?
- Hai affrontato problemi durante la tua giornata? Se sì, come li hai risolti o sono ancora aperti?
- Hai bisogno di input per domani? Se sì, da chi e cosa sono?
Il destinatario di questa Email/Report è generalmente il manager, anche i membri del team possono essere cc’ed in alcuni casi – questo dipende dal protocollo di comunicazione che il team segue.
Rapporti di prova
Ora, è il momento di ottenere specifici e imparare tutto sui rapporti che i team di test/QA inviano.
I team di test inviano vari report in diverse fasi dell’STLC.
- Stato del piano di test
- Stato della documentazione di test
- Stato di esecuzione del test(stato del difetto)
Piano di test: è sufficiente comunicare con il resto dei team di progetto, quando viene creato un piano di test o quando viene apportata una modifica importante.
Documentazione di test: informa tutti i team quando è iniziata la progettazione dei test, la raccolta dei dati e altre attività e anche quando sono terminate. Questo rapporto non solo far loro sapere circa lo stato di avanzamento del compito, ma anche segnalare le squadre che hanno bisogno di rivedere e fornire signoff sugli artefatti, che sono il prossimo.
Esecuzione del test: L’esecuzione è la fase di un progetto in cui il team di test è l’obiettivo primario – positivamente e negativamente – siamo sia gli eroi che i cattivi.
Una giornata tipica durante un ciclo di test non viene eseguita a meno che non venga inviato il rapporto sullo stato giornaliero. In alcune squadre, potrebbero concordare un rapporto settimanale, ma averlo inviato quotidianamente è la norma.
Non è inoltre raro avere una riunione di stato ogni giorno (o settimana) per presentare lo stato del team QA alle parti interessate.
Quindi, la modalità di un rapporto di stato può essere:
- Email/document
- Meeting / presentation
- Entrambi – e-mail giornaliera e riunione settimanale o giù di lì.
Rapporto sullo stato di esecuzione del test
Rapporto di esecuzione del test giornaliero/settimanale:
Che cos’è? Generalmente, questa è una comunicazione inviata per stabilire la trasparenza delle attività del team QA del giorno durante il ciclo di test-include sia le informazioni sui difetti che le informazioni sull’esecuzione del caso di test.
A chi dovrebbe andare? – Normalmente, il team di sviluppo, il team di supporto ambientale, l’analista aziendale e il team di progetto sono i destinatari/partecipanti alla riunione. Il piano di test è il posto migliore per voi per trovare queste informazioni.
Cosa contiene un report sullo stato di esecuzione del test? – 10 punti
- Numero di casi di Test prevista per quel giorno
- Numero di casi di Test eseguiti in quel giorno
- Numero di casi di Test eseguiti generale
- Numero di Difetti riscontrati che giornata/e rispettivi stati,
- Numero di Difetti riscontrati finora/e rispettivi stati,
- Numero di Difetti critici – ancora aperta
- Ambiente di fermo – se
- Showstoppers – se
- fissaggio di un test di esecuzione foglio / Link per il Test strumento di Gestione in cui i casi di test sono collocati
- Allegato al Bug report / link al Difetto / Test / Strumento di gestione utilizzato per la gestione degli incidenti
I 10 punti di cui sopra, se si nota da vicino è i dati grezzi. Riportare i fatti è una cosa e riportare alcuni fatti “intelligenti” è un altro. Come raffinare queste informazioni?
- Mostra lo stato generale con un indicatore di colore. Ad esempio, verde – in tempo, Arancione – Leggermente dietro ma in grado di assorbire il ritardo, Rosso – In ritardo.
- Include alcune metriche semplici come Pass % dei casi di test finora, densità dei difetti, % di difetti gravi; in questo modo non stai solo dando numeri, stai effettivamente fornendo un assaggio della qualità del prodotto che stai testando.
- Se una fase significativa è completa, evidenziala.
- Se c’è un difetto critico che bloccherà tutto/una parte dell’esecuzione futura, evidenzialo.
- Se si utilizza una presentazione, assicurarsi di includere alcuni grafici per avere un impatto migliore.
Ad esempio, il grafico sottostante è una rappresentazione del numero di difetti aperti, in base al modulo:
Oltre a questi, è anche possibile includere opzionalmente:
- Quali sono le attività previste per il prossimo anno?
- Hai bisogno di input da uno qualsiasi degli altri team e, in caso affermativo, cosa?
Infine, alcuni suggerimenti per aiutare il processo lungo:
- Essere conciso allo stesso tempo completo
- assicurarsi che i risultati del report sono accurate
- Utilizzare puntato i punti di rendere la relazione molto leggibile
- fare Doppio controllo per includere la data, l’oggetto, la lista e gli allegati.
- Se il report è troppo grande e ha troppi fattori da segnalare: posizionarlo in una posizione comune come file e inviare un collegamento nell’e-mail anziché nel file stesso. (Assicurati che i destinatari abbiano le autorizzazioni di accesso a questa posizione e al file)
- Se si tratta di una riunione di stato – Preparati per la presentazione, arriva in tempo e, soprattutto, mantieni un tono uniforme (non essere troppo orgoglioso dei difetti – sono in generale “cattive notizie”).
Rapporto sullo stato del campione
Rapporto sullo stato del test QA:
Seguendo queste linee guida, siamo arrivati al seguente Rapporto sullo stato.
Per la comodità dei nostri lettori, abbiamo incluso 3 fogli che trasportano diversi livelli di informazioni che possono trasmettere.
Foglio 1 – è una sintesi dello stato generale del progetto.
Foglio 2 – è più sul dettaglio individuale dello stato del test case.
Foglio 3 – è una segnalazione di bug di esempio.
Scarica questo modello Xls di report sullo stato di esempio con tutti e tre i fogli. (Tasto destro del mouse sul link e selezionare ‘ Salva collegamento con nome..’per scaricare)
Chi autore-Questo è un articolo di STH membro del team Swati Seela. Puoi saperne di più su di lei sulla nostra pagina del corso di test del software.
