Menu

Implementazione pratica in 7 fasi del test manuale prima del rilascio in produzione

7 step practical implementation manual testing before production release

Prova Il Nostro Strumento Per Eliminare I Problemi

Nel post precedente di questa serie sul test manuale, ho cercato di gettare più luce possibile sulle basi del test manuale.

Se te lo sei perso Potete leggerlo qui .

Spero sia riuscito a portarti il ​​più vicino possibile alle risposte che stavi cercando.

In tal caso, non ti piacerebbe saperne di più sull'implementazione pratica del test manuale, su come acquisire maggiore familiarità con esso e su come iniziare effettivamente una carriera in esso?

Questo articolo farà luce su tutti questi aspetti.

Implementazione del test manuale

Iniziamo.

Cosa imparerai:

Ciclo di test manuale

Capire Ciclo di test manuale o Software Test Life Cycle (STLC), prima di tutto, dobbiamo comprendere il Software Development Life Cycle (SDLC), che sono sicuro che tu abbia già una comprensione.

Le persone si riferiscono a loro separatamente ma non sono sicure se possono davvero coesistere. Sono così strettamente integrati l'uno con l'altro. Ebbene, anche questi cicli ne hanno così tante versioni create e fluttuanti nello spazio Internet, che variano principalmente a seconda del modello di sviluppo selezionato.

Come la maggior parte dei file il mondo sta diventando Agile in questi giorni, manterrò le mie cose semplificate attorno ad Agile.

7 Pratiche fasi di test manuale prima del rilascio in produzione

Eccomi qui.

Ricorda che sto parlando sia di SDLC che di STLC.

# 1) Raccolta dei requisiti

Fase di raccolta dei requisiti

Analista aziendale (persona / team responsabile della raccolta dei requisiti) documenta i requisiti. Documentano i requisiti, questo è il punto forte, puoi concentrarti solo su quello. Dove è documentato conta meno.

Le persone usano qualsiasi cosa per documentare ciò che si adatta a loro, ma non limitato alle piattaforme tradizionali come MS word doc, piattaforme moderne come Jira / Rally e strumenti new age come Trello.

# 2) Discussione / condivisione dei requisiti

Fase di discussione dei requisiti

L'analista aziendale dovrebbe quindi condividere i requisiti documentati con il team di sviluppo, il team di test e il team UX (se necessario). Questo di solito avviene tramite una riunione formale in cui gli SPOC (Single Point Of Contacts o un intero team, a seconda) di tutte e tre le funzioni soddisfano e comprendono l'intero requisito.

In una sana cultura del lavoro, i requisiti vengono discussi da ogni angolazione e ogni membro della riunione può porre domande e dubbi. Dopo aver risposto a tutte le domande e aver apportato le modifiche necessarie al requisito, questa fase può essere considerata completata. Ancora una volta ciò che si chiama questo particolare incontro / passaggio e la sua documentazione differiscono da azienda ad azienda.

Ulteriore lettura=> Come rivedere il documento SRS

Dopo aver risposto a tutte le domande e aver apportato le modifiche necessarie al requisito, questa fase può essere considerata come Fatto .

Ancora una volta ciò che si chiama questo particolare incontro / passaggio e la sua documentazione differiscono da azienda ad azienda.

Per esempio, la documentazione viene richiamata o suddivisa come SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point (possibilmente, la più piccola unità richiesta), ecc. Riunione di discussione sui requisiti, toelettatura, riunione di perforazione, ecc., Spero che tu abbia capito il mio punto?

Premendo su queste terminologie in modo da ricordare sempre l'idea principale indipendentemente dai diversi nomi.

Pubblica questo incontro due passaggi vengono attivati ​​contemporaneamente, in nessun ordine particolare, fai riferimento ai due passaggi successivi.

# 3) Progettazione

Il team di sviluppo inizia con la progettazione tecnica non appena vengono discussi i requisiti e quando non ci sono punti importanti in sospeso. Ciò che viene fatto in questa fase differisce ancora una volta da azienda ad azienda.

Questa fase può comportare ma non limitarsi alle seguenti attività:

  • Decidere l'approccio allo sviluppo
  • Preparazione del documento di progettazione
  • Progettazione dei diagrammi di flusso
  • Stimare gli sforzi
  • Capire l'impatto di questo nuovo requisito su qualsiasi funzionalità esistente
  • Necessità di patchare dati esistenti, ecc.

Il team UX può anche essere coinvolto in questa fase quando c'è una modifica dell'interfaccia utente o deve essere sviluppata una nuova schermata. Il team UX aiuta il team di sviluppo e il team di test con il prototipo dell'interfaccia utente per la funzionalità / caratteristica nella discussione. Può essere un documento Photoshop, una semplice immagine, una presentazione PowerPoint o qualsiasi altra cosa che farà capire al team di sviluppo come dovrebbero essere sviluppati gli schermi.

Nota: Idealmente queste schermate o almeno le loro versioni in bozza vengono mostrate nella sessione di discussione sui requisiti solo per aiutare il team a costruire una migliore comprensione. Viene etichettato in base al requisito originale in modo che possa essere consultato in qualsiasi momento.

# 4) Scenario di test / Progettazione di casi di test

Scenario di test Fase di progettazione

Parallelamente alla fase di progettazione, il team di test inizia con la creazione di scenari di test e / o casi di test basati sui requisiti discussi. Se gli scenari di test vengono sempre scritti prima e poi si suddividono in casi di test è qualcosa che ancora non è costante.

A mio parere, che documentiate o meno gli scenari di test, essi sono sempre presenti prima dei casi di test. Lo scenario di prova è il tuo punto elenco che puoi dire, ti guidano ad approfondire ulteriormente le cose. Una volta che la scrittura del test case è terminata, può essere condivisa con il team di sviluppo per dare loro un'idea dell'ambito del test e possono anche assicurarsi che lo sviluppo che è avvenuto o in corso soddisfi i test case scritti.

Una volta che la scrittura del test case è terminata, può essere condivisa con il team di sviluppo per dare loro un'idea dell'ambito del test e possono anche assicurarsi che lo sviluppo che è avvenuto o in corso soddisfi i test case scritti.

I casi di test una volta scritti idealmente vengono esaminati da un responsabile del test o da un collega da molti punti di vista come:

  • Copertura dei requisiti
  • Grammatica ortografica
  • Standard di scrittura del caso di test (nient'altro che un modello seguito da un team / azienda)
  • Retrocompatibilità
  • Compatibilità della piattaforma
  • Testare i riferimenti ai dati
  • Tipi di test mirati, ecc.

Ulteriore lettura=> Scrittura di casi di test dal documento SRS

Idealmente, solo dopo la revisione e le modifiche necessarie, vengono trasmessi al team di sviluppo.

Quando ho detto 'una volta terminata la scrittura del test case', intendevo una volta che 'tutti i test case sono stati scritti sulla base della completa conoscenza di un dato requisito e di possibili scenari di test scoperti fino a quel momento'. È quasi impossibile avere una copertura del test case del 100% al primo tentativo.

Ci saranno difetti che troverai in azioni casuali (ma intenzionali), in azioni puramente casuali (test delle scimmie) e in alcuni rari scenari. Ci sono possibilità che ti mancheranno alcune di queste. E a un certo punto potresti perdere anche quelli molto elementari, dopotutto, sei umano. Ma qui, almeno una buona revisione del test case e un modo strutturato di scrivere il test case possono salvarti.

Il più delle volte, un tester o un team di test continua ad aggiungere sempre più casi di test al blocco esistente mentre scoprono la verità o riflettono maggiormente sui requisiti.

Bene, ormai alcuni di voi dubitano della mia conoscenza del Software Testing poiché qualche parola (che è diventata una specie di norma nel Software Testing) non è ancora usata da me. Piano di test giusto?

Lasciami dire qualcosa al riguardo. Credo fermamente nella necessità della maggior parte delle informazioni menzionate nel Piano di test, ma documentarle tutte nello stesso punto e renderle assolutamente obbligatorie è qualcosa che trovo discutibile.

Ad ogni modo, questo è un argomento a parte da discutere. Condividere informazioni 'adatte a tutti' su questo è difficile, ma lasciami provare.

O tu, tu con il tuo cavo di prova o il tuo cavo di prova preparate il Piano di prova o documentate le informazioni richieste in luoghi diversi.

Ulteriori letture=> Come scrivere il documento del piano di test

Informazioni che dovrebbero essere assolutamente congelate in questa fase:

  • Lo scopo del test: Requisiti, compatibilità con le versioni precedenti, piattaforme, dispositivi, ecc.
  • Persona / squadra che sta per testare
  • Stima dello sforzo di prova
  • Limitazioni: Eventuali ipotesi fatte o limitazioni accettate in anticipo.
  • Le persone inoltre documentano i criteri di ingresso, i criteri di uscita, il rischio, ecc. Che penso non necessitino di una menzione separata in quanto dovrebbe essere piuttosto una comprensione normale.
    • Criteri di ingresso (Quando iniziare il test): pochi iniziano quando è disponibile una parte testabile della funzionalità per il test. Pochi aspettano che l'intera funzionalità sia testabile. Una volta scoperto che il flusso di base funziona, inizia il test.
    • Criteri di uscita (Quando fermarsi): quando non ci sono bloccanti, i difetti critici e gravi (soggetti a impatto) nei test in fase aperta possono essere fermati. O a metà, quando ci sono troppi difetti da affrontare, i test possono essere fermati dalle parti interessate appropriate.
    • Rischio : Rischio aziendale o rischio funzionale se i test non vengono eseguiti secondo il piano documentato.

# 5) Fase di sviluppo

Fase di sviluppo del software

Il team di sviluppo dopo la fase di progettazione inizia con lo sviluppo effettivo e il test unitario man mano che vengono completati con lo sviluppo di blocchi di requisiti testabili. Possono trasmettere la funzionalità per il test in blocchi man mano che viene implementata o possono passare l'intera funzionalità contemporaneamente.

In uno scenario ideale, la revisione formale del codice e il test white box avvengono prima di trasferire la funzionalità sviluppata per il test. idealmente, il team di sviluppo dovrebbe anche fare riferimento ai casi di test forniti dal team di test oltre ai requisiti e ai documenti di progettazione.

# 6) Fase di test

Come accennato in precedenza, l'inizio di questa fase differisce da azienda ad azienda, da squadra a squadra.

Il team di test inizia a testare quando viene sviluppata parte testabile (qualcosa che può essere testato in modo indipendente) dell'intero requisito o quando viene sviluppato l'intero requisito.

che aspetto ha un file json

Consentitemi di approfondire ulteriormente questa fase e di parlare dei compiti importanti:

  • Il team di tester / test inizia con il ciclo di test (test esplorativi ed esecuzione di casi di test scritti) e la registrazione dei difetti
  • Il team di sviluppo li risolve secondo priorità.
  • La nuova build (codice) viene eseguita nell'ambiente in cui vengono eseguiti i test
  • I difetti risolti vengono quindi verificati dal Tester / Team di test e contrassegnati come Risolti
  • Questo ciclo continua fino al raggiungimento del criterio di uscita temporale.
  • Tieni presente che, se necessario, i difetti sono anche contrassegnati come non validi, duplicati e possono anche essere classificati come miglioramenti.

Un'altra cosa che differisce da azienda a azienda è il numero di giri di test da eseguire. Come in alcuni casi, il primo ciclo di test avviene su parti di piccole funzionalità non appena sono pronte, seguito da un ciclo di test end-to-end su un altro ambiente una volta sviluppati tutti i requisiti. Ma ancora una volta, ho anche sentito di persone che fanno tre giri completi di test completi e il quarto come round di sanità mentale / fumo.

Il primo programma dietro l'esecuzione di più cicli di test è il test della funzionalità su ambienti diversi e il secondo per eseguire test end-to-end una volta sviluppati tutti i punti della storia. Il round di sanità mentale di solito guadagna rapidamente fiducia una volta che tutte le storie in una versione sono state sviluppate e testate in modo indipendente.

Leggi i passaggi dettagliati=> Fase di esecuzione del test

# 7) Revisione degli analisti aziendali (BA)

L'analista aziendale esamina la funzionalità richiesta facendo riferimento al risultato del test o facendo riferimento al risultato del test oltre a giocare con l'applicazione per avere un'idea reale. Anche questo passaggio è soggetto a diverse azioni tra le aziende.

Il BA può rivedere l'ambito dell'intero rilascio in una volta o in blocchi. A seconda dello stesso, questo passaggio potrebbe avvenire prima del test di sanità mentale finale o dopo il round di test di sanità mentale finale da parte del team di test.

I passaggi di cui sopra 7 avvengono per tutte le storie / requisiti degli utenti da soddisfare in particolare il rilascio (spedizione). Una volta completati tutti questi passaggi per tutti i requisiti, il rilascio è pronto per la spedizione.

# 8) Spedizione / Rilascio

Il rilascio è contrassegnato come Pronto per la spedizione dopo la revisione con esito positivo da parte dell'analista aziendale.

Lettura consigliata=> Prova il processo di rilascio

Tipi di test manuali (leggi umani)

Bene, se dobbiamo parlare dei tipi generali di test in numeri, allora ho trovato da qualche parte 100 tipi di test con nomi diversi . Ad essere onesti, non sono abbastanza intelligente da capire la distinzione tra tutti questi tipi (gioco di parole).

È diretto e semplice: Testare la funzionalità dell'applicazione rispetto al requisito dato con sforzi e intelligenza umani. Viene ulteriormente suddiviso in pochi tipi in base all'ambito e all'agenda del test. Tipologie elencate nel successivo par.

Viene ulteriormente suddiviso in pochi tipi in base all'ambito e all'agenda del test. Tipologie elencate nel successivo par.

Se mi è consentito, lasciatemi parlare alcune righe di Human Testing (che incoraggio ogni tester a eseguire solo test funzionali manuali). Ora non ti confondere, a mio avviso i test funzionali manuali sono un sottoinsieme dei test umani. Perché ci sono così tante cose che solo la mente umana può fare.

Di seguito è riportato l'elenco con alcuni dei tipi di test popolari e importanti che possono essere classificati in Human Testing:

  • Test funzionale manuale : Testare la funzionalità dell'applicazione rispetto al requisito dato con sforzi e intelligenza umani. Viene ulteriormente suddiviso in diversi tipi in base all'ambito e all'agenda dei test, come test di sistema, test di unità, test del fumo, test di integrità, test di integrazione, test di regressione, test dell'interfaccia utente, ecc.
  • Test delle prestazioni : Questo viene classificato in Test non funzionali, giusto? Ma ancora una volta è l'umano che lo implementa, sebbene l'esecuzione venga eseguita da un essere umano o da uno strumento. Il tester dovrebbe almeno eseguire questo test in termini di tempo di risposta (per vedere se è accettabile) se non dovrebbe utilizzare alcuno strumento per il test di carico e tutto il resto.
  • Browser / Test di compatibilità della piattaforma: L'applicazione in prova dovrebbe apparire e funzionare come previsto (ovviamente può esserci una piccola differenza a seconda del motore del browser) tra browser e piattaforme (o dispositivi se si tratta di un'applicazione mobile).
  • Test di usabilità : Consentitemi prima di tutto che questo sia un argomento enorme in sé e di solito di proprietà di specialisti nei test di usabilità. Continuo a credere che come tester dovremmo almeno segnalare o evidenziare se troviamo qualcosa di meno utilizzabile, o dovremmo condividere la nostra opinione.
  • Test di sicurezza : Ancora una volta un tipo di test molto grande e richiede ovviamente molte conoscenze pratiche. Il tester dovrebbe cercare di apprendere ed eseguire almeno test di base come manomissione di URL, cross-site scripting, SQL injection, dirottamento di sessione, ecc. A seconda delle conoscenze disponibili e laddove applicabile.
  • Test multi-tenancy: Se la tua applicazione è multi-tenant, ovvero una singola istanza che contiene dati di più client, questo test è un must. Indipendentemente dalla menzione esplicita nei requisiti, ciò dovrebbe essere fatto. I dati di un cliente che vengono mostrati a un altro sono una specie di crimine di sviluppo e verifica.

Nota: Le viste sopra sono le mie opinioni personali. Ti consiglio anche di dare un'occhiata all'ampio elenco di tipi di test per tua conoscenza e seguirli / usarli se lo ritieni necessario. Negli anni ho capito che se usi qualcosa o no, credi in qualcosa o no, dovresti comunque avere una certa conoscenza di concetti ampiamente utilizzati nel tuo campo.

Questo è tutto per questa parte. Grazie per aver letto. Condividi le tue opinioni / feedback nei commenti.

Nella prossima e ultima parte di questo serie di tutorial sui test manuali , Cercherò di aiutare tutti voi quale preparazione dovresti fare se stai cercando di entrare nel campo dei test e quali sono i modi possibili per entrarci.

Lettura consigliata

^