Introduzione al lavoro di Software Tester
Qual è la prima cosa che ti viene in mente quando pensi a un lavoro di test del software? Un'opera non codificante? O una professione che è molto semplice in quanto ti dà l'opportunità di trovare errori nel lavoro di altri (trovare errori quando negli altri è il compito più semplice per tutti noi)? O pensi che sia la professione che si occupa di verificare la correttezza del prodotto? Tutti questi pensieri sono corretti e sono le attività quotidiane per un lavoro di tester software. Tuttavia, i test del software non si limitano a queste attività.
Comprensione dell'applicazione
L'applicazione potrebbe provenire da qualsiasi dominio - Assistenza sanitaria, assicurazioni, finanza, ecc. L'apprendimento del dominio dell'applicazione è molto importante per qualsiasi lavoro software per aprire le porte al pensiero da varie angolazioni e varie prospettive dell'utente durante il test dell'applicazione. Scoprire e convalidare i percorsi di applicazione ovvi e non così ovvi è sempre l'aspettativa principale da questo. Avere una conoscenza approfondita dell'applicazione aiuta a convalidare il prodotto in modo efficace e allo stesso tempo il tester può diventare una risorsa per un progetto in cui è considerato una delle fonti primarie di conoscenza rispetto al comportamento del prodotto.
Mentre l'apprendimento del dominio e della funzionalità è un processo in corso per qualsiasi altro fattore importante è la conoscenza del processo di test.
Processo di test
Il processo di test può variare da una società all'altra o addirittura da un progetto all'altro. Oggi abbiamo vari modelli di sviluppo software come il modello V, il modello di prototipazione o una metodologia completamente diversa come l'approccio Agile allo sviluppo del software. Con la modifica del modello di sviluppo, varia anche l'approccio di test da seguire. Lavorare in un modello a V avrà processi ben definiti mentre si prevede che questo lavoro in metodologia agile testerà in condizioni in continua evoluzione.
Il lavoro non è ancora semplice con una conoscenza del dominio accettabile e la comprensione del processo di test, la prossima sfida che si presenta con la vita di è l'apprendimento di vari strumenti.
Utensili
Gli strumenti implicano strumenti di gestione dei test, strumenti di registrazione dei difetti, strumenti di gestione del database e così via.
Con vari software di registrazione dei difetti, qualità e strumenti, alcuni open source e alcuni con licenza, è sempre un vantaggio avere conoscenza di più di uno strumento. Aiuta a trasferire facilmente progetti o team seguendo diversi strumenti. Con un'adeguata conoscenza del dominio, del processo e degli strumenti, c'è di più nella vita del lavoro di Software Tester che rende i suoi giorni di lavoro stimolanti ed emozionanti. La collaborazione all'interno dei team è uno dei fattori importanti per il successo di qualsiasi progetto e per una collaborazione efficace, la comunicazione svolge un ruolo molto importante.
Corsi consigliati
- Corso completo J2EE completo
- Formazione online sulla programmazione R
- Vai al corso di programmazione
- Formazione sulla certificazione online nel programma Haskell
Comunicazione
La comunicazione svolge un ruolo molto importante per il software in quanto qualità fin dalle fasi iniziali dello sviluppo del software, i membri del team di testing sono coinvolti (come best practice) nella discussione dei requisiti, interrogando gli analisti aziendali in caso di domande o lacune nel requisito. Un tster con efficaci capacità comunicative può comunicare i rischi in modo efficace, può comunicare efficacemente con il team di sviluppo e può comunicare efficacemente i risultati dei test e i rapporti dei test.
Pianificazione delle opere di Software Tester
Come suggerisce il nome, la pianificazione dei test è la fase in cui viene effettuata la preparazione per i test. La preparazione per una tster coinvolgerà vari tipi di attività che una tster svolge in modo efficace per l'applicazione. Ciò contribuirà a convalidare l'applicazione e scoprire efficacemente i difetti nell'applicazione. Per iniziare la pianificazione, a teste passa attraverso i requisiti per comprendere le aspettative.
1. Requisiti
I requisiti potrebbero essere forniti al team di test sotto forma di wireframe, storyboard, fogli Excel. Scopo di tutti questi documenti è presentare i requisiti del cliente in modo efficiente e di facile comprensione. Il documento Wireframe non è altro che un documento che può essere sotto forma di presentazione di PowerPoint che descrive i requisiti del client. Sulla stessa linea, gli storyboard di solito raffigurano l'aspetto / il design richiesto degli schermi. Oggi sul mercato sono disponibili vari strumenti che possono essere utilizzati per preparare i documenti richiesti. La creazione dei documenti richiesti è la responsabilità primaria di un analista aziendale. Un assaggio dovrebbe comprendere a fondo i requisiti. Affinché sia i capi che gli sviluppatori possano comprendere correttamente i requisiti, gli analisti aziendali mantengono il forum aperto a tutti per sollevare e ottenere risposte alle domande su uno qualsiasi dei requisiti. La piattaforma per discutere e comunicare le domande e le domande aperte varia da progetto a progetto. Potrebbe essere la catena di e-mail o una chiamata in conferenza o anche un repository di unità condivise gestito per tenere traccia di tutte le domande aperte e delle loro risposte fornite dall'analista aziendale.
La comunicazione chiara e la registrazione della comunicazione svolgono un ruolo molto importante per una prova. Una piccola assunzione del requisito a volte potrebbe portare a un grave difetto del prodotto. In ogni fase, si consiglia a un tester software di mantenere pulite le comunicazioni. La comunicazione di Software Tester Work potrebbe essere con analisti aziendali o anche all'interno di un team. Una comunicazione chiara aiuta a tenere lontani i presupposti durante la pianificazione e l'esecuzione. Allo stesso tempo, si consiglia di avere un registro delle comunicazioni (preferibilmente comunicazione via e-mail). Avere una comunicazione scritta sulle domande nei requisiti aiuta nelle fasi successive dell'esecuzione del test in cui la funzionalità potrebbe non essere stata sviluppata come confermato nella comunicazione registrata.
2. Scenario
Una volta compresi i requisiti, il tester inizia a documentare gli scenari nel documento Scenario di prova. Uno scenario come suggerisce il nome è un flusso di funzionalità che l'utente segue per eseguire un'attività.
Esempi di scenari -
- L'utente dovrebbe essere in grado di accedere correttamente.
- L'utente dovrebbe essere in grado di prenotare i biglietti nel sistema.
- L'utente dovrebbe essere in grado di annullare i biglietti nel sistema.
- L'utente dovrebbe essere in grado di visualizzare / aggiornare i dettagli del profilo.
Queste sono le attività logiche che un utente esegue nel sistema. Queste attività logiche, quando raggruppate insieme, aiutano il prover a prendere nota di tutti i possibili scenari che un utente dovrebbe eseguire. Questi scenari sono generalmente documentati nei fogli di Excel o talvolta utilizzano alcuni strumenti. Un prover prospera per estrarre tutti questi scenari dai documenti dei requisiti. Un documento contenente tali scenari viene chiamato Documento scenari di test (o da qualche parte come Documento scenari di alto livello). Questo documento funge da documento di input per la redazione di casi di test.
3. Caso
Questo caso è la versione più dettagliata dello scenario di lavoro di Software Tester in cui lo scenario è suddiviso in passaggi più dettagliati che l'utente eseguirà effettivamente durante l'utilizzo dell'applicazione. Un semplice esempio basato sugli scenari di cui sopra è:
Scenario : l'utente dovrebbe essere in grado di accedere correttamente.
Casi test:
- Verifica che l'utente sia in grado di inserire il nome utente corretto.
- Verifica che l'utente sia in grado di inserire la password.
- Verificare quando si fa clic sul pulsante Accedi dopo aver inserito nome utente e password corretti, l'utente è in grado di accedere correttamente.
Un tale elenco di questi casi può includere un controllo di validazione su ciascun campo, il controllo di scenari negativi e così via.
Di seguito sono riportati alcuni esempi aggiuntivi di questi casi:
- Verifica che nome utente quando non inserito, il sistema genera un errore appropriato.
- Verificare che la password non venga immessa, il sistema genera un errore appropriato.
- Verificare che nome utente e password quando non inseriti, il sistema genera un errore appropriato.
- Verificare che inserendo una password errata, il sistema generi un messaggio di errore appropriato.
- Verificare che inserendo un nome utente errato, il sistema generi un messaggio di errore appropriato.
4. Matrice di tracciabilità dei requisiti (RTM)
La matrice di tracciabilità dei requisiti, come suggerisce il nome, aiuta a dimostrare e integrare la copertura dei requisiti forniti da Business nei documenti di test come scenari e casi di test.
Come best practice, si tratta di un documento separato che mostra la mappatura del numero del requisito con quella degli scenari / casi che incorporano tale requisito.
Questo documento non può essere utilizzato da tutti i tipi di progetti, ma quando utilizzato aiuta in modo efficace a tracciare la mappatura degli scenari di alto livello ai requisiti. Indica la copertura e può essere utilizzato per verificare la presenza di almeno uno di questi casi rispetto a tutti i requisiti. La creazione e la gestione del documento RTM è considerata la migliore pratica, tuttavia non tutti i tipi di progetti (come Agile) utilizzano il software Prova il documento di lavoro. Quando i requisiti cambiano molto frequentemente, la manutenzione di questo documento potrebbe essere ascoltata. Al fine di evitare questo sovraccarico e allo stesso tempo avere un modo per tracciare i requisiti, alcuni progetti incorporano la parte di tracciabilità nel caso di lavoro di Software Tester o nel documento dello scenario stesso.
L'aspetto importante è avere un modo per tracciare scenari / casi in base ai requisiti e viceversa. Requisiti ben documentati semplificano la creazione e la gestione di questi documenti da parte di Prover. Requisiti ambigui, requisiti in continua evoluzione rendono la vita del prover più impegnativa e possono portare ad avere documenti consegnabili incoerenti che si traducono in una mancata convalida e quindi un difetto nel prodotto finale.
Il viaggio finora per un tester stava pianificando e preparando per i test. Poiché la preparazione alla guerra fa parte della guerra, lo stesso vale qui. Più concisi vengono creati questi documenti, è più facile per il prover convalidare la funzionalità e scoprire quasi tutti i difetti. La fase successiva del viaggio del tester è Execution.
Esecuzione di tester software funziona
Questa è la fase in cui vengono messi in uso tutti i documenti sopra menzionati. I requisiti sono stati utilizzati per creare uno scenario, lo scenario è stato utilizzato per crearlo Casi. questo Documento del caso è il documento autosufficiente qui per iniziare a convalidare l'applicazione. Prover avvia la convalida dell'applicazione eseguendo i passaggi da questo documento del caso. Più di questi casi potrebbero essere utilizzati per convalidare un singolo scenario o anche un singolo caso di test può corrispondere a un singolo scenario di test. Tutto dipende dalla complessità degli scenari o talvolta dallo standard seguito nel team di test. Pertanto, un singolo documento del caso di test può contenere 20-50 casi di test o può contenere 100-120 casi di test. Questi numeri sono solo a scopo esplicativo, possono variare notevolmente da un progetto all'altro. Il risultato di questa fase è Difetti del test. Il numero di difetti validi rilevati in questa fase offre una buona idea della stabilità dell'applicazione, della qualità dei test, della qualità di costruzione e di molti altri fattori che incidono direttamente sul prodotto. Questa fase è la fase più importante in quanto il tester prospera per coprire tutti i casi di test (convalidando quasi tutti i percorsi utente richiesti) e allo stesso tempo solleva il maggior numero possibile di difetti validi. Tutta la preparazione, le capacità comunicative, le domande poste all'azienda entrano in azione in questa fase di test.
Difetti del tester software funziona
Durante l'esecuzione di questi casi, qualsiasi comportamento diverso dal risultato previsto viene generato come Difetto. Ogni caso di test ha una descrizione, il risultato atteso e una colonna per il risultato effettivo. Mentre questo documento di Software Tester Work di pianificazione ha una descrizione e i risultati previsti e una colonna vuota per i risultati effettivi. Durante l'esecuzione dei casi di test, si suppone che il tester riempia la colonna dei risultati effettivi. Allo stesso tempo, se il valore effettivo non è uguale al risultato previsto, il difetto viene registrato. Registrare un difetto non significa semplicemente informare lo sviluppatore del problema. È di nuovo un processo formale normalmente eseguito con l'aiuto di uno strumento. Attualmente, ci sono vari strumenti sul mercato, alcuni open source e alcuni con licenza. Qualsiasi strumento di registrazione dei difetti ha i seguenti campi:
- Nome progetto / rilascio
- Riepilogo difetti
- Descrizione del dettaglio del difetto
- Gravità del difetto
- Priorità ai difetti
- Fase in cui è stato riscontrato il difetto
- Assegnato a
- allegati
Come possiamo vedere lo scopo di tutti questi campi è quello di avere un processo formale saggio dettagli del problema riscontrato. Questo aiuta gli sviluppatori a riprodurre il difetto nel proprio ambiente e risolverlo. Di seguito è la breve descrizione di tutti questi campi -
- Nome progetto / versione : nome della versione in cui è stato rilevato il difetto, in genere il progetto ha più versioni e lo stesso progetto potrebbe avere più sottoprogetti. Questo campo aiuta a sollevare un problema per una versione specifica.
- Riepilogo dei difetti - Una breve descrizione del difetto riscontrato con una sola riga.
- Descrizione dettagli difetto - Questa è la descrizione dettagliata del difetto, dovrebbe includere dettagli come l'ambiente in cui è stato trovato il difetto, e i dati di test utilizzati, i risultati effettivi si aspettavano il risultato e qualsiasi informazione aggiuntiva che aggiunga informazioni più preziose per le parti interessate a comprendere difetto.
- Gravità del difetto : indica la gravità del difetto. Di solito, ha valori simili a Critico, Alto, Medio, Basso o valori numerici come 4, 3, 2, 1.
- Priorità ai difetti : indica quanto sia urgente riparare il difetto.
- Fase in cui è stato rilevato il difetto - Poiché vi sono molte fasi in cui è possibile registrare un difetto, fase di test dell'unità, SIT (test di integrazione del sistema), UAT (test di accettazione dell'utente) o persino fase di produzione.
- Assegnato a : nome dello sviluppatore o responsabile dello sviluppo.
- Allegati : questo ha fornito un'opzione al tester per allegare l'istantanea dello schermo in cui si è verificato il problema.
L'esecuzione del test e la registrazione dei difetti è la fase in cui ci sono molte sfide che un tester potrebbe dover affrontare. Alcuni di loro stanno comunicando efficacemente con gli sviluppatori. Potremmo sostenere che la registrazione di un difetto con tutte le informazioni necessarie non è sufficiente per consentire agli sviluppatori di comprendere il difetto?
Lo è e in alcuni casi richiede ulteriori spiegazioni / discussioni con gli sviluppatori. Ci sono casi in cui un tester incontra un comportamento inaspettato che potrebbe non essere sicuro se si tratta di un difetto. Queste circostanze sono di solito affrontate da un prover che è nuovo nel team, con una conoscenza del dominio limitata o con ambiguità sui requisiti. Bene, il tester non deve essere incolpato qui se ci sono scadenze strette e ci sono requisiti in continua evoluzione e nella maggior parte dei casi il prover impara a conoscere il dominio durante la pianificazione e l'esecuzione dei casi di test. Come possiamo vedere il percorso di un tester non è così facile come viene percepito. Richiede un atteggiamento di apprendimento costante, buone capacità comunicative, buone capacità di collaborazione e entusiasmo per adattarsi in condizioni in cui vi sono cambiamenti nei domini, strumenti, processi utilizzati. Mentre abbiamo parlato del viaggio dei tester manuali, il processo generale si applica anche ai tester di automazione. L'automazione, d'altra parte, ha cambiamenti significativi nel processo poiché l'ambito del test e della pianificazione, l'esecuzione varia in modo significativo.
Considerando il viaggio del prover come discusso sopra possiamo ancora dire che il lavoro delle qualità del tester del software è più facile di quello di uno sviluppatore?
Si può dire che, oltre a confrontare i ruoli degli sviluppatori di tester v / s, sarà più utile avere una discussione su come la collaborazione di due può portare a un grande successo del prodotto nel suo insieme. A volte dimentichiamo che il compito del tester è di trovare problemi nell'applicazione e non di individuare errori degli sviluppatori. Quando dimentichiamo l'idea stessa del nostro lavoro, a volte porta a discussioni inutili. Tuttavia, è stato osservato che esistono ugualmente buoni test, team di sviluppo in cui tutti comprendono che lo scopo finale è far funzionare l'applicazione come previsto. Speriamo che tutti vedano il lato positivo del lavoro di test come un ruolo che aiuta a pulire il prodotto e non come quello che trova errori!
Articoli consigliati
Questa è stata una guida per scoprire e convalidare i percorsi di applicazione ovvi e non così ovvi è sempre l'aspettativa principale da un lavoro di tester software. Questi sono i seguenti link esterni relativi al lavoro del tester software.
- Ciclo di vita dei difetti nei test del software
- 6 domande di intervista di test del software più sorprendenti
- Carriere nel test del software