Menu

Flusso del processo di QA per il test pratico del software (requisiti per il rilascio)

practical software testing qa process flow

Prova Il Nostro Strumento Per Eliminare I Problemi

Una panoramica completa del flusso del processo di test del software QA end-to-end:

Nota: stiamo ripubblicando questo utile post con contenuti aggiornati.

Il lavoro del professionista del test del software non è facile. È pieno di sfide, il che è altrettanto impegnativo. I tester dovrebbero essere attenti ed entusiasti in ogni fase del ciclo di vita dell'applicazione.

Sebbene ci siano delle sfide, ci sono anche molte enormi opportunità per apprendere ed esplorare i vari aspetti delle metodologie di test, dei processi e, naturalmente, del software in dettaglio.

Il ruolo di un ingegnere collaudatore inizia molto presto. E fin dalla concettualizzazione del progetto, i tester sono coinvolti nelle discussioni con il proprietario del prodotto, il project manager e le varie parti interessate.

Requisiti per il rilascio

Questo tutorial sul 'Flusso del processo di test del software' offre una panoramica completa delle varie fasi in STLC insieme alle sfide coinvolte e alle migliori pratiche per superare tali sfide in modo facilmente comprensibile.

Cosa imparerai:

Requisiti per il rilascio: una panoramica completa

Ciclo di vita del test del software

Dal requisito al rilascio, ogni fase è spiegata chiaramente. Diamo un'occhiata in dettaglio.

# 1) Requisito

Un progetto non può decollare senza avere un chiaro requisito. Questa è la fase più cruciale in cui le idee devono essere scritte in un documento ben comprensibile e formattato. Se fai parte del progetto in cui stai partecipando alla fase di raccolta dei requisiti, considerati fortunato.

come installare il file .bin

Chiedersi perché? È perché stai assistendo a un progetto in fase di realizzazione da zero. Sebbene sia orgoglioso di esserlo sin dall'inizio, comporta anche alcune responsabilità e sfide.

Sfide

Non si possono immaginare tutti i requisiti per riunirsi in una sola seduta. Sii abbastanza paziente.

Si svolgeranno molte discussioni, alcune delle quali potrebbero essere semplicemente irrilevanti per il tuo progetto, ma anche in questo caso potrebbero contenere alcune informazioni vitali per il tuo progetto. A volte la velocità delle discussioni può superare le tue capacità di comprensione o semplicemente non presteresti attenzione al proprietario del prodotto.

L'immagine seguente evidenzia i passaggi cruciali coinvolti nella raccolta dei requisiti:

Requisiti LifeCycle

Ogni pezzo di informazione che viene perso ha un enorme impatto sulla comprensione e sul test generale del progetto. Per ovviare a questo, ecco alcune best practice che dovrebbero essere seguite durante questa fase.

Migliori pratiche

  • Tieni la mente aperta e presta attenzione a ogni parola del proprietario del prodotto.
  • Non limitarti ad ascoltare, chiarisci il tuo dubbio per quanto piccolo possa sembrare.
  • Usa sempre i taccuini per tenere rapidamente gli appunti. Dovresti usare un laptop, solo se puoi davvero digitare a una velocità adeguata.
  • Ripeti le frasi e falle chiarire dal PO che pensi sia quello che hai capito.
  • Disegna diagrammi a blocchi, link di testo, ecc. Per rendere i requisiti più chiari in un secondo momento.
  • Se le squadre si trovano in luoghi diversi, prova a creare un WebEx o una registrazione simile. Aiuterà sempre quando hai un dubbio dopo che le discussioni sono finite.

Sebbene non esista un muro separato in quanto tale per ciascuna fase, i requisiti cambiano anche molto tardi negli sviluppi. Quindi, l'idea è di afferrare la maggior parte dei requisiti e documentarli correttamente.

Una volta che è stato documentato con tutti i punti necessari, distribuire e discutere tutti gli stakeholder in modo che eventuali suggerimenti o modifiche vengano colti in anticipo e prima di andare avanti, tutti siano sulla stessa pagina.

# 2) Strategia di test

I tester dovrebbero presentare una strategia di test che non solo è sufficiente per testare meglio il software, ma dovrebbe anche instillare fiducia in ogni stakeholder riguardo alla qualità del prodotto.

Strategia di test

Sfide

L'aspetto più cruciale di questa fase è creare una strategia che, una volta elaborata, dovrebbe fornire un prodotto software privo di errori, sostenibile e accettato dai suoi utenti finali.

Le strategie di test sono qualcosa che non cambierai a giorni alterni. In alcuni casi, è necessario discutere anche con i clienti delle strategie di test. Quindi questa parte dovrebbe essere trattata con grande importanza.

Migliori pratiche

  • Ecco alcune delle migliori pratiche che, se seguite, possono fornire un grande sollievo e portare a test senza problemi.
  • Esamina nuovamente il documento dei requisiti. Evidenziare i punti di importazione rispetto all'ambiente del software di destinazione.
  • Fai un elenco degli ambienti in cui il software verrà effettivamente distribuito.
  • Gli ambienti possono essere intesi come un tipo di sistemi operativi o dispositivi mobili.
  • Se il sistema operativo è Windows, elenca tutte le versioni della finestra in cui testerai il software. Se le versioni vale a dire. Windows 7, Windows 10 o Windows Server non sono ancora definiti nel documento dei requisiti, quindi è giunto il momento in cui questi dovrebbero essere discussi.
  • In una nota simile, ottieni i browser di destinazione con le versioni discusse e documentate se l'AUT è un sistema basato sul web.
  • Fai un elenco di tutti i software di terze parti di cui l'applicazione avrà bisogno (se richiesto / supportato). Questi possono includere Adobe Acrobat, Microsoft Office, eventuali componenti aggiuntivi, ecc.

Qui l'idea alla base è di mantenere tutte le piattaforme, i dispositivi e i software necessari e richiesti che la nostra applicazione dovrà funzionare prima di noi in modo da poter formulare una strategia completa.

La figura seguente ti aiuterà a comprendere lo schema della strategia di test se stai lavorando a un progetto agile:

Strategia di test

# 3) Pianificazione dei test

Dopo che i tester sono armati di tutte le informazioni riguardanti l'AUT, la fase di pianificazione è dove viene implementata la Strategia.

Come una strategia di test, anche la pianificazione dei test è una fase cruciale.

Piano di test

Sfide

Poiché il successo (o il fallimento) dell'AUT dipende in gran parte da come sono stati effettuati i test, questa fase diventa un aspetto importante dell'intero ciclo di vita del test. Perché? Perché una parte del test è definita in questa fase.

Per superare alcune sfide, queste migliori pratiche possono essere davvero utili.

Migliori pratiche

  • Tieni sempre a mente di non lasciare nulla di intentato quando si tratta di testare la tua applicazione.
  • È tempo di formulare una strategia di test.
  • Crea una matrice dell'ambiente in modo che il software venga testato su tutte le piattaforme.
  • Ad esempio, Windows 10 + Internet Explorer 11+ Windows Office 2010+.
  • Come il browser Chrome Android 4.2.2+.
  • Se la tua applicazione funziona con più database (se documentati), mantieni i database (MySQL, Oracle, SQLServer) nella matrice di test in modo tale che siano troppo integrati con alcuni test.
  • Configurare le macchine di prova di conseguenza e denominarle come SetUp1, SetUp2, ecc.
  • SetUp1 avrà Windows 7+ IE 10+ Office 2007+.
  • SetUp2 può avere Windows 10+ IE Edge + Office 2013+.
  • SetUp3 potrebbe avere un telefono Android con il tuo file .apk installato.
  • Congratulazioni! La tua configurazione di prova è pronta e hai anche incluso ogni possibile combinazione di piattaforme su cui funzionerà la tua applicazione.

# 4) Test

Trovare bug

Finalmente, la build della tua applicazione è disponibile e sei pronto per trovare bug! Ora è il momento di lavorare sulla pianificazione dei test e trovare il maggior numero possibile di bug. Ci saranno alcune fasi intermedie se lavori in un ambiente agile, quindi segui semplicemente quei metodi di scrum.

Il diagramma sottostante mostra la categorizzazione di vari tipi di test:

Tipi di test

Sfide

Il test è un processo complicato che di per sé è soggetto a errori! Si trovano molte sfide durante il test di un'applicazione. Di seguito sono riportate alcune best practice per il salvataggio.

Migliori pratiche

Tirati su! Stai cercando di trovare difetti nel codice. È necessario prestare attenzione al funzionamento generale del software.

  • È sempre consigliabile guardare l'applicazione con un aspetto nuovo, SENZA PASSARE PER CASI DI PROVA.
  • Segui il percorso di navigazione del tuo software (AUT).
  • Acquisisci familiarità con l'AUT.
  • Ora leggi i casi di test (Tutti) di qualsiasi modulo particolare (forse di tua scelta).
  • Ora vai all'AUT e abbina i risultati con quelli menzionati nella sezione prevista dei casi di test.
  • L'idea alla base di questo è testare ogni funzionalità menzionata su ogni piattaforma supportata.
  • Prendi nota di ogni deviazione per quanto banale possa sembrare.
  • Annotare i passaggi su come raggiungere qualsiasi deviazione, acquisire schermate, acquisire registri degli errori, registri del server e qualsiasi altra documentazione di supporto che possa dimostrare l'esistenza di difetti.
  • Non esitare a chiedere. Sebbene tu abbia il documento dei requisiti, ci saranno momenti in cui sarai in dubbio.
  • Rivolgiti agli sviluppatori (se siedono accanto a te o sono raggiungibili) in caso di dubbio prima di contattare il Product Owner. Comprendere la prospettiva dello sviluppatore sul funzionamento del software. Capiscili. Se ritieni che questa implementazione non sia conforme ai requisiti, informa il responsabile del test.

# 5) Prima del rilascio

Prima di rilasciare qualsiasi prodotto sul mercato, è necessario garantire la qualità del prodotto. I software vengono sviluppati una volta, ma in realtà vengono testati fino a quando non vengono sostituiti o rimossi.

Sfide

Il software deve essere testato rigorosamente per molti dei suoi parametri.

I parametri non possono essere limitati a:

  • Funzionalità / comportamentale.
  • Prestazione.
  • Scalabilità.
  • Compatibile con le suddette piattaforme.

La sfida è anche prevedere il tasso di successo di un'applicazione che dipende da molte iterazioni dei test eseguiti.

Migliori pratiche

  • Assicurati che tutte le funzionalità su tutte le piattaforme siano testate.
  • Evidenzia le aree che non sono state testate o quella che necessita di ulteriori sforzi di test.
  • Conserva una matrice di tutti i risultati del test prima del rilascio. La matrice di prova fornirà un quadro generale della stabilità del prodotto. Aiuterà anche la direzione a prendere una chiamata sulle date di rilascio.
  • Fornisci i tuoi input / suggerimenti al team sulle tue esperienze durante il test del prodotto.
  • Il tuo contributo considerando te stesso come l'utente finale andrà a vantaggio del software in larga misura.
  • A causa della crisi di tempo o di qualsiasi altra situazione simile, perdiamo alcuni test o non approfondiamo questo aspetto. Non esitare a comunicare lo stato del test al tuo manager.
  • Presentare la tessera sanitaria della domanda agli stakeholder. Le tessere sanitarie dovrebbero contenere un numero di tutti i difetti registrati, aperti, chiusi e intermittenti con la loro gravità e priorità.
  • Redigere un documento di rilascio e condividerlo con il team.
  • Lavorare sul documento di rilascio preparato.
  • Migliorare le aree suggerite dalla direzione / team.

L'immagine sotto mostra la mappa del ciclo di vita della versione software:

Prima del rilascio

# 6) Rilascio

Infine, arriva il momento in cui dobbiamo consegnare il prodotto agli utenti previsti. Tutti noi come team abbiamo lavorato duramente per firmare il prodotto e lasciare che il software aiuti i suoi utenti.

Sfide

Gli ingegneri di test del software sono i principali responsabili del rilascio di qualsiasi software. Questa attività richiede un flusso di lavoro orientato al processo. Di seguito sono riportate alcune delle migliori pratiche coinvolte in questa fase.

Migliori pratiche

  • Ricorda sempre che non stai lavorando al documento di rilascio alla data di rilascio effettivo.
  • Pianificare sempre l'attività di rilascio prima della data di rilascio effettiva.
  • Standardizzare il documento secondo le politiche aziendali.
  • Il tuo documento di rilascio dovrebbe cercare di stabilire aspettative positive dal software.
  • Indica chiaramente nel documento tutti i requisiti software e hardware specifici delle loro versioni.
  • Includere tutti i difetti aperti e la loro gravità.
  • Non nascondere le principali aree colpite a causa di difetti aperti. Dai loro un posto nel documento di rilascio.
  • Ottenere la revisione del documento e la firma digitale (potrebbe differire in base alla politica aziendale).
  • Sii sicuro e spedisci il documento di rilascio insieme al software.

Processo di verifica del controllo qualità su un progetto reale: metodo a cascata

Ho ricevuto una domanda interessante da un lettore, Come vengono eseguiti i test in un'azienda, ovvero in un ambiente pratico?

Coloro che lasciano l'università e iniziano a cercare lavoro hanno questa curiosità: come sarebbe l'ambiente di lavoro effettivo in un'azienda?

Qui mi sono concentrato sul processo di lavoro effettivo di Software Testing nelle aziende .

Processo di test effettivo nelle aziende

Ogni volta che riceviamo un nuovo progetto, c'è un incontro iniziale di familiarità con il progetto. In questo incontro, fondamentalmente discutiamo chi è il cliente? qual è la durata del progetto e quando viene consegnata? Chi sono tutti coinvolti nel progetto, ovvero manager, responsabili tecnici, responsabili del controllo qualità, sviluppatori, tester, ecc.?

Dal piano di progetto SRS (specifica dei requisiti software) viene sviluppato. La responsabilità dei tester è creare un piano di test del software da questo SRS e da questo piano di progetto. Gli sviluppatori iniziano a scrivere codice dal design. Il lavoro del progetto è suddiviso in diversi moduli e questi moduli del progetto sono distribuiti tra gli sviluppatori.

Nel frattempo, la responsabilità di un tester è creare uno scenario di test e scrivere casi di test in base ai moduli assegnati. Cerchiamo di coprire quasi tutti i casi di test funzionali di SRS. I dati possono essere mantenuti manualmente in alcuni modelli di casi di test Excel o strumenti di tracciamento dei bug.

Quando gli sviluppatori finiscono i singoli moduli, questi vengono assegnati ai tester. Il test del fumo viene eseguito su questi moduli e se falliscono questo test, i moduli vengono riassegnati ai rispettivi sviluppatori per una correzione.

Per i moduli passati, il test manuale viene eseguito dai casi di test scritti. Se viene rilevato un bug che viene assegnato allo sviluppatore del modulo e viene registrato nel file strumento di tracciamento dei bug . Alla correzione del bug, un tester esegue la verifica del bug e il test di regressione di tutti i moduli correlati. Se il bug supera la verifica, viene contrassegnato come verificato e contrassegnato come chiuso. Altrimenti, il ciclo di bug sopra menzionato viene ripetuto. (Tratterò il ciclo di vita del bug in un altro post)

Vengono eseguiti diversi test sui singoli moduli e test di integrazione sull'integrazione dei moduli. Questi test includono test di compatibilità, ovvero test di applicazioni su hardware, versioni del sistema operativo, piattaforme software, browser diversi, ecc.

Anche i test di carico e stress vengono eseguiti secondo SRS. Infine, il test del sistema viene eseguito creando un ambiente client virtuale. Una volta eseguiti tutti i casi di test, viene preparato un rapporto di prova e viene presa la decisione di rilasciare il prodotto!

Fasi dei requisiti per il rilascio

Di seguito sono riportati i dettagli di ogni fase di test che viene eseguita in ogni qualità del software e ciclo di vita del test specificato da Standard IEEE e ISO.

# 1) Revisione SRS : Revisione delle specifiche dei requisiti software.

# 2) Obiettivi sono impostati per le versioni principali.

# 3) Data obiettivo pianificato per le uscite.

# 4) Piano di progetto dettagliato è costruito. Ciò include la decisione sulle specifiche di progetto.

# 5) Sviluppa un piano di test si basa sulle specifiche di progettazione.

# 6) Piano di test: Ciò include gli obiettivi, la metodologia adottata durante il test, le funzionalità da testare e non da testare, i criteri di rischio, la pianificazione dei test, il supporto multipiattaforma e l'allocazione delle risorse per i test.

# 7) Specifiche del test: Questo documento include i dettagli tecnici (requisiti software) richiesti prima del test.

# 8) Scrittura di casi di test

  • Fumo ( BVT ) casi test
  • Casi di test di sanità mentale
  • Casi di test di regressione
  • Casi di test negativi
  • Casi di test estesi

# 9) Sviluppo: I moduli vengono sviluppati uno per uno.

# 10) Binding per gli installatori: Gli installatori sono costruiti attorno al singolo prodotto.

b albero vs b + albero

#undici) Procedura di compilazione : Una build include programmi di installazione dei prodotti disponibili - più piattaforme.

# 12) Test: Smoke Test (BVT): test applicativo di base per prendere una decisione su ulteriori test.

  • Test di nuove funzionalità
  • Cross-browser e test multipiattaforma
  • Stress test e test di perdita di memoria.

# 13) Rapporto di riepilogo del test

# 14) Congelamento del codice

  • A questo punto non vengono aggiunte altre nuove funzionalità.

# 15) Test: Build e test di regressione.

# 16) Decisione di rilasciare il prodotto.

# 17) Scenario post-rilascio per ulteriori obiettivi.

Questo era un riepilogo di un processo di test effettivo in un ambiente aziendale.

Conclusione

Il lavoro di un tester di software è pieno di sfide, ma divertente. Questo è per qualcuno che è ugualmente appassionato, motivato e pieno di entusiasmo. Trovare difetti in qualcuno non è sempre un lavoro facile! Ciò richiede molte abilità e un occhio di bue per i difetti.

Oltre a tutte le qualità, anche un tester dovrebbe essere orientato al processo. Come tutti gli altri settori, anche i progetti nell'IT vengono elaborati in fasi, in cui ogni fase ha degli obiettivi ben definiti. E ogni obiettivo ha un criterio di accettazione ben definito. Un ingegnere di test deve portare sulle spalle molti carichi di qualità del software.

Mentre lavorano in qualsiasi fase del software, i tester dovrebbero seguire le migliori pratiche e dovrebbero allinearsi con il processo coinvolto nelle rispettive fasi. Seguire le migliori pratiche e un processo ben formulato non solo aiuta a facilitare il lavoro dei tester, ma aiuta anche a garantire la qualità del software.

Hai preso parte a una delle fasi precedenti? Sentiti libero di condividere le tue esperienze qui sotto.

Lettura consigliata

^