how review srs document
Questo è il secondo tutorial nel nostro 'Formazione online gratuita sul test del software su un progetto dal vivo' serie. Se sei nuovo qui, controlla il primo tutorial introduttivo: Formazione end-to-end sul test del software su un progetto live.
Passiamo ora a un'analisi dettagliata di come avviene una procedura dettagliata SRS, cos'è che dobbiamo identificare da questo passaggio, quali passaggi preliminari dobbiamo intraprendere prima di iniziare, quali sono le sfide che potremmo affrontare, ecc. modo dettagliato.
Fase di progettazione di SDLC:
La fase successiva dell'SDLC è il 'Design': è qui che i requisiti funzionali vengono tradotti in dettagli tecnici. I team di sviluppo, progettazione, ambiente e dati sono coinvolti in questa fase. Il risultato di questa fase è in genere un documento di progettazione tecnica - TDD.
L'input è il documento SRS sia per la creazione del TDD che per il team QA per iniziare a lavorare sull'aspetto QA del progetto, che è quello di rivedere l'SRS e identificare l'obiettivo del test.
Cosa imparerai:
- Che cos'è una revisione SRS?
- Passaggi preliminari alla revisione delle specifiche dei requisiti software
- Il modello è richiesto per gli scenari di test?
- Alcune importanti osservazioni sulla revisione SRS
- Lettura consigliata
Che cos'è una revisione SRS?
SRS è un documento creato dal team di sviluppo in collaborazione con gli analisti aziendali e i team ambiente / dati. In genere, questo documento, una volta finalizzato, verrà condiviso con il team QA tramite una riunione in cui viene organizzata una procedura dettagliata.
A volte, per un'applicazione già esistente, potremmo non aver bisogno di un incontro formale e di qualcuno che ci guidi attraverso questo documento. Potremmo avere le informazioni necessarie per farlo da soli.
char alla stringa c ++
La revisione di SRS non è altro che passare attraverso il documento di specifica dei requisiti funzionali e cercare di capire come sarà l'applicazione di destinazione.
Il formato formale e un campione sono stati condivisi con tutti voi nell'articolo precedente. Ciò non significa necessariamente che tutti gli SRS verranno documentati esattamente in questo modo. Sempre, il la forma è secondaria rispetto al contenuto .
Alcuni team sceglieranno semplicemente di scrivere un elenco puntato, alcuni includeranno casi d'uso, alcuni team includeranno screenshot di esempio (come il documento che avevamo) e alcuni descriveranno semplicemente i dettagli nei paragrafi.
Passaggi preliminari alla revisione delle specifiche dei requisiti software
Passo 1) I documenti subiscono più revisioni, quindi assicurati di avere la versione corretta del documento di riferimento, l'SRS.
Passo 2) Stabilire linee guida su ciò che ci si aspetta alla fine della revisione da ogni membro del team. In altre parole, decidere quali deliverable sono attesi da questo passaggio: in genere, l'output di questo passaggio è identificare gli scenari di test. Gli scenari di test non sono altro che indicatori di una riga di 'cosa testare' per determinate funzionalità.
Passaggio 3) Stabilire anche linee guida su come presentare questo deliverable, intendo il modello.
Passaggio 4) Decidi se ogni membro del team lavorerà sull'intero documento o se lo dividerà tra loro. Si consiglia vivamente a tutti di leggere tutto perché ciò impedirà la concentrazione della conoscenza con alcuni membri del team.
Ma nel caso di un progetto enorme, con i documenti SRS che corrono vicino a 1000 pagine, l'approccio di suddividere il modulo del documento in modo saggio e assegnarlo ai singoli membri del team è molto pratico.
Passaggio 5) La revisione di SRS aiuta anche a comprendere meglio se ci sono prerequisiti specifici richiesti per il test del software.
Passaggio # 6) Come sottoprodotto, viene identificato un elenco di query in cui alcune funzionalità sono difficili da comprendere o se è necessario incorporare maggiori informazioni nei requisiti funzionali o se vengono commessi errori in SRS.
Di cosa abbiamo bisogno per iniziare?
- La versione corretta del documento SRS
- Istruzioni chiare su chi lavorerà su cosa e quanto tempo hanno a disposizione.
- Un modello per creare scenari di test.
- Altre informazioni su chi contattare in caso di domande o chi segnalare in caso di incoerenza nella documentazione
Chi fornirebbe queste informazioni?
I responsabili del team sono generalmente responsabili della fornitura di tutti gli elementi elencati nella sezione precedente. Tuttavia, gli input dei membri del team sono sempre importanti per il successo dell'intera impresa.
I responsabili del team spesso chiedono: che tipo di input? Non sarebbe meglio assegnare un determinato modulo a qualcuno interessato piuttosto che a un membro del team che non lo è? Non sarebbe bello decidere la data obiettivo in base all'opinione della squadra piuttosto che spingere una decisione su di loro? Inoltre, per il successo di un progetto, i modelli sono importanti.
Come regola generale, i modelli hanno un tasso di efficienza più elevato quando sono adattati alla comodità e al comfort del team specifico. Va quindi notato che i team leader più di ogni altra cosa sono membri del team. Coinvolgere il tuo team nelle decisioni quotidiane è fondamentale per il corretto svolgimento del progetto.
Il modello è richiesto per gli scenari di test?
Perché un modello per scenari di test non è sufficiente se facciamo solo un elenco?
Lo è di sicuro. Tuttavia, i progetti software non sono spettacoli 'one-man'. Coinvolgono lavoro di squadra .
Immagina un team di 4 persone se ognuno di loro decide di rivedere un modulo della specifica dei requisiti software ciascuno. Il membro del team A ha stilato una lista su un foglio di carta. Il membro del team 2 ha utilizzato un foglio Excel. Il membro del team 3 ha utilizzato un blocco note. Il membro del team 4 ha usato una parola doc. Come consolidiamo tutto il lavoro svolto per il progetto alla fine della giornata?
Inoltre, come possiamo decidere quale è lo standard e come possiamo dire cosa è giusto e cosa no se non abbiamo creato le regole, per cominciare?
Questo è il modello: Una serie di linee guida e un formato concordato per l'uniformità e la concorrenza per l'intero team.
Come creare un modello per gli scenari di test QA?
Modelli non devi essere complicato o inflessibile.
Tutto ciò che devono essere sono un meccanismo efficiente per creare un utile artefatto di test. Qualcosa di semplice come quello che vediamo di seguito:
come aprire .jar su Windows 10
L'intestazione di questo modello contiene lo spazio necessario per acquisire le informazioni di base sul progetto, il documento corrente e il documento di riferimento.
La tabella seguente ci consentirà di creare scenari di test. Le colonne incluse sono:
Colonna n. 1) ID scenario di test
Ogni entità nel nostro processo di test deve essere identificabile in modo univoco. Quindi, a ogni scenario di test deve essere assegnato un ID. Le regole da seguire durante l'assegnazione di questo ID devono essere definite.
Per il bene di questo articolo seguiremo la convenzione di denominazione come TS (prefisso che sta per Test Scenario) seguito da '_', nome del modulo ME (Modulo My Info del progetto Orange HRM) seguito da ‘_’ e quindi dalla sottosezione ( Per esempio, ME per il modulo Le mie informazioni, P per fotografia e così via) seguito da un numero di serie. Un esempio potrebbe essere: 'TS_MI_MIM_01'.
Colonna # 2) Requisito
È utile che quando creiamo uno scenario di test dovremmo essere in grado di mapparlo di nuovo alla sezione del documento SRS da cui lo abbiamo scelto. Se i requisiti hanno ID, potremmo usarli. In caso contrario, i numeri di sezione o anche i numeri di pagina del documento SRS da cui abbiamo identificato un requisito verificabile andranno bene.
Colonna # 3) Descrizione dello scenario di test
Una frase che specifica 'cosa testare'. Lo chiameremmo anche l'obiettivo del test.
Colonna # 4) Importanza
Questo per dare un'idea dell'importanza di alcune funzionalità per l'AUT. A questo campo possono essere assegnati valori come alto, medio e basso. Puoi anche scegliere un sistema di punti, come 1-5, 5 è il più importante e 1 meno importante. Qualunque sia il valore che questo campo può assumere, deve essere deciso in anticipo.
Colonna # 5) Numero di casi di test
Una stima approssimativa di quanti casi di test individuali potremmo finire per scrivere quell'unico scenario di test. Per esempio, Per testare il login, includiamo queste situazioni: Nome utente e password corretti. Nome utente corretto e password errata. Password corretta e nome utente errato. Quindi, la convalida della funzionalità di accesso si tradurrà in 3 casi di test.
Nota: Puoi espandere questo modello o rimuovere i campi come meglio credi.
Per esempio , è possibile aggiungere 'Revisionato da' nell'intestazione o rimuovere la data di creazione, ecc. Inoltre nella tabella è possibile includere un campo 'Creato da' per designare il tester responsabile di un determinato scenario di test o rimuovere il 'No. di casi di test '. La scelta è tua. Scegli quello che funziona meglio per l'intera squadra.
Esaminiamo ora il nostro documento Orange HRM SRS e creiamo gli scenari di test
Suggerimento professionale: controlla il sommario nell'esempio SRS che abbiamo fornito nei primi tutorial per avere una buona idea di come fluirà un documento e quanto lavoro potrebbe comportare.Sezione 1 è lo scopo del documento. Nessun requisito verificabile lì.
Sezione 2.1 : Panoramica del progetto - Pubblico - neanche qui requisiti verificabili.
moduli Oracle e rapporti domande di intervista
Sezione 2.2 : Hardware e hosting: questa sezione parla di come sarà ospitato il sito Orange HRM. Ora, questa informazione è importante per noi tester? La risposta è Sì e No. Sì, perché quando testiamo dobbiamo avere un ambiente simile all'ambiente in tempo reale.
Questo ci dà un'idea di come deve essere. No, perché non è un requisito verificabile, una sorta di prerequisito per l'esecuzione del test.
Sezione 3: C'è una schermata di accesso qui e i dettagli del tipo di account che dobbiamo avere per accedere al sito. Questo è un requisito verificabile. Quindi deve far parte dei nostri scenari di test.
Si prega di consultare il documento sugli scenari di test in cui sono stati aggiunti scenari di test per alcune sezioni dell'SRS. Per esercitarti, aggiungi il resto degli scenari in modo simile. Tuttavia, vado direttamente alla sezione 4 del documento.
Sezione 4: Requisiti e linee guida estetici / HTML: questa sezione spiega meglio come alcuni requisiti potrebbero non avere senso per il team di test al momento della revisione SRS, ma il team dovrebbe comunque prenderne nota come requisiti testabili.
Come testarli e se abbiamo bisogno di una configurazione specifica / dell'aiuto di qualsiasi team per convalidarli sono dettagli che potremmo non sapere in questo momento. Ma renderli parte del nostro ambito di test è il primo passo per assicurarci di non perderli.
Esempi di scenari di test per l'applicazione OrangeHRM: (clicca per ingrandire l'immagine)
=> Si prega di fare riferimento a e scarica il documento Scenari di prova per maggiori informazioni.
Alcune importanti osservazioni sulla revisione SRS
# 1) Nessuna informazione deve essere lasciata scoperta.
#Due) Eseguire analisi di fattibilità per verificare se un determinato requisito è corretto o meno e anche se può essere testato o meno.
# 3) A meno che non esista una prestazione / sicurezza separata o qualsiasi altra forma di team di test, è nostro compito assicurarci che tutti i requisiti non funzionali debbano essere presi in considerazione.
# 4) Non tutte le informazioni sono destinate ai tester, quindi è importante capire cosa annotare e cosa no.
# 5) L'importanza e no. dei casi di test per uno scenario di test non deve essere accurato e può essere compilato con un valore approssimativo o può essere lasciato vuoto.
Per riassumere, la revisione SRS si traduce in:
- Elenco degli scenari di prova
- Risultati della revisione - Errori di documentazione / requisito rilevati passando / verificando staticamente il documento SRS
- Un elenco di domande per una migliore comprensione, in caso di qualsiasi
- L'idea preliminare di come dovrebbe essere l'ambiente di test
- Identificazione dell'ambito del test e un'idea approssimativa di quanti casi di test potremmo finire per avere, quindi quanto tempo abbiamo bisogno per la documentazione e infine l'esecuzione.
Punti importanti da notare:
# 1) Gli scenari di test non sono risultati finali esterni (non condivisi con analisti aziendali o team di sviluppo) ma sono importanti per il consumo interno di QA. Sono il nostro primo passo verso un obiettivo di copertura del test del 100%. Una volta completati, gli scenari di test vengono sottoposti a una revisione tra pari e, una volta eseguita, vengono tutti consolidati.
Per maggiori dettagli su come vengono esaminati i documenti del controllo di qualità, consulta l'articolo: Come eseguire le revisioni della documentazione di prova in 6 semplici passaggi.
#Due) Potremmo usare uno strumento di gestione dei test come HP ALM o qTest per creare gli scenari di test. Tuttavia, la creazione di scenari di test in tempo reale è un'attività manuale. Secondo me è più conveniente manualmente. Poiché è il passaggio 1, non è ancora necessario tirare fuori i pezzi grossi. Semplici fogli Excel sono il modo migliore per farlo.
Il passo successivo di questa serie è quello - lavoreremo sulla creazione di casi di test e approfondiremo la fase di progettazione dei test. Prima di ciò, entreremo anche in: Che cos'è la pianificazione dei test?Dove si inserisce nell'intero progetto QA? Come sempre, lavora con noi per i migliori risultati.
3 ° giorno di formazione QA: Come scrivere un documento SRS da zero.
Per favore continua a ricevere domande e commenti. Apprezziamo moltissimo i tuoi lettori!
Lettura consigliata
- Programma del corso di test del software - Piano di formazione dettagliato del corso online
- Corso di test del software: quale istituto di test del software dovrei iscrivermi?
- Formazione sul test del software: formazione end-to-end su un progetto in tempo reale - Formazione QA online gratuita, parte 1
- Migliori strumenti di test del software 2021 [Strumenti di automazione del test QA]
- Feedback e recensioni sul corso di test del software
- Domande frequenti sul corso di formazione QA sul test del software
- Risorse e download per il test del software QA
- QA Outsourcing Guide: Software Testing Outsourcing Companies