Menu

6 competenze di base che ogni tester (principalmente più fresco) dovrebbe avere

6 basic skills that every tester should have

Prova Il Nostro Strumento Per Eliminare I Problemi

Software Testing o QA è la migliore piattaforma per i nuovi arrivati ​​per entrare nel settore IT nonostante l'idea sbagliata che si tratti di un lavoro meno o meno retribuito.

L'abilità più importante di cui ha bisogno un tester è il capacità di trovare bug . E se sei il tipo di persona che ama trovare insetti, allora amerai e crescerai in questo campo.

Detto questo, ci sono poche abilità in più che possono aiutarti a trovare bug e lavorare meglio con i processi di QA.

Questo è l'articolo che mostrerà il processo di QA così come viene seguito nella maggior parte delle aziende e fornirà chiarimenti ai nuovi tester sui test.

In dettaglio, impari il processo di documentazione e gli standard, il lavoro preliminare del tester, i test basati sui vincoli, i test durante lo sviluppo parziale e infine il processo di approvazione.

abilità di test di base

Cominciamo.

Cosa imparerai:

migliori app spia per telefoni Android

# 1. Documentazione

La documentazione è essenziale per il test. La maggior parte delle aziende assegna questo compito ai nuovi arrivati. Per avere successo, dovresti avere buon vocabolario perché il resto delle cose come gli standard di documentazione, ecc. non sono sotto il tuo controllo e dipendono dai processi del team e dell'azienda.

Inoltre, assicurati di vedere il valore del processo di documentazione. I vantaggi sono molti: ti aiutano a tenere traccia delle modifiche ai requisiti, tracciare i passaggi del test, registrare il tuo lavoro, ecc.

Lettura consigliata=> Perché la documentazione è importante nel test del software

# 2. Preparazione al test

Di tutti i documenti disponibili, non si può trascurare quanto segue. Questi sono anche chiamati documenti consegnabili e collegano la comprensione del cliente, dello sviluppatore e del tester.

a) Piano di test: traccia il flusso dei test dall'inizio alla fine .

Il piano di test descrive l'ambito e le attività della fase di test. Creato dal responsabile del QA, il team deve contribuire e rimanere aggiornato su tutto ciò che è scritto nel piano di test.

Alcuni team hanno più livelli di piani di test: piano generale e piani per fasi.

Un piano di test deve avere:

  • Nome e versione del progetto
  • Identificatori del piano di test: autore, bozza n., Data di creazione, ecc.
  • Introduzione - Panoramica del progetto, obiettivo e vincoli
  • Riferimenti: elenco di riferimenti utilizzati come input (assicurarsi di utilizzare le versioni accurate e più recenti)
  • Elementi di prova: moduli, versione, ambito, fuori ambito, ecc.
  • Approccio generale al test / Strategia di test: strumenti da utilizzare, processo di tracciamento dei difetti, livelli di test da eseguire, ecc.
  • Criteri elemento Pass / Fail - Linee guida per l'esecuzione del test
  • Criteri di sospensione e ripresa
  • Risultati del test: test case, rapporti di test, rapporto di bug, metriche di test, ecc.
  • Testare i dettagli dell'ambiente
  • Elenco dei team con informazioni sui punti di contatto. per ogni modulo o tipo di test
  • Stime dei test: tempo e impegno. I dettagli del budget sono riservati e non li troverai qui
  • Rischi e piani di mitigazione
  • Approvazioni
  • Altre linee guida

Leggi anche=>

b) Scenari di prova:

Una riga indica 'cosa testare' in base a ciascun requisito e di solito documentato e monitorato tramite fogli di lavoro.

La maggior parte di essi contiene:

  • Nome modulo / componente / funzione (login, admin, registrazione, ecc.)
  • L'ID scenario è di riferimento (ad es .: TS_Login_001)
  • Descrizione dello scenario: 'Cosa testare' Ad esempio: convalida se l'accesso consente agli utenti con credenziali valide di accedere correttamente
  • Importanza dello scenario - Per dare la priorità in caso di tempo insufficiente - Alta / Media / Bassa
  • ID requisito: per la tracciabilità

Ulteriore lettura=>

c) Casi di test:

Test case accurati forniscono risultati di test accurati. I fogli di calcolo sono ancora il mezzo popolare per la scrittura di casi di test, soprattutto per i principianti, anche se alcune aziende adattano gli strumenti di gestione dei test. La base per la scrittura del test case è il documento SRS / FRD / Req. Ma spesso non è sufficiente, quindi dovrai usare molte supposizioni e discussioni con i team BA / Dev.

Scrivere casi di test efficaci è la qualifica più importante che un tester deve avere. Di solito, tutti i casi di test sono classificati come positivi / negativi. Caso di test positivo sta dando validi input e ottenendo risultati positivi. Scenario di test negativo fornisce input non validi e riceve il messaggio di errore esatto.

Per ulteriori informazioni su questi, controlla:

Alcuni degli attributi comuni di tutti i casi di test sono:

  • ID scenario: tratto dal documento dello scenario di test
  • ID caso di test: per l'identificazione e il monitoraggio univoci. Ad esempio: TC_login_001
  • Descrizione del test - Breve spiegazione delle condizioni del test testate
  • Passaggi da eseguire - Istruzioni dettagliate passo passo su come eseguire il test
  • Dati del test: dati forniti alle fasi del test
  • Risultato atteso: risultato come previsto
  • Risultato effettivo: risposta dell'AUT quando viene eseguito il test
  • Stato - Riuscito / Non superato / Nessuna esecuzione / Incompleto / Bloccato - Descrive il risultato del test
  • Commenti - Per ulteriori dettagli
  • Eseguito da: nome del tester
  • Data di esecuzione: data in cui viene eseguito il test
  • ID difetto: difetto registrato rispetto allo scenario di test, in caso di errore del test
  • Dettagli di configurazione: sistema operativo, browser, piattaforma, informazioni sul dispositivo (opzionale)

Lettura consigliata=>

# 3. Processo di test: quali test eseguire?

Esiste un numero enorme di tipi di test, ma non tutti possono essere eseguiti su quell'AUT. Il tempo, il budget, la natura dell'attività, la natura dell'applicazione e l'interesse del cliente sono gli attori chiave nella scelta dei test da eseguire sull'applicazione.

Per esempio: Se si tratta di un portale di commercio online, sono obbligatori test di stress e test di carico. Tuttavia, alcuni dei tipi di test da non perdere sono:

# 4. Test in fase di sviluppo parziale

In generale, con aziende di livello medio e start-up, il tempo e le risorse sono limitati. I tester qui potrebbero iniziare il loro processo di test prima dell'integrazione del modulo, il che significa che potremmo eseguire test di integrazione di unità e intermedi.

È importante notare che i risultati di queste fasi non possono essere conteggiati come accurati, quindi potresti dover pianificare un test completo della scatola nera una volta che tutto è pronto per l'uso. Trascurare quella parte potrebbe rivelarsi costoso e test, inefficace.

# 5. Documento di segnalazione di bug

Presto, questo è il documento di controllo qualità più critico che farai mai.

I seguenti sono i campi che deve avere una buona segnalazione di bug:

  • ID difetto: generalmente un numero di serie
  • Descrizione del difetto: spiegazione di una riga del problema
  • Posizione - Modulo / area dell'AUT in cui si trova il problema
  • Numero build: versione e build codice n.
  • Passaggi da riprodurre: elenco dei passaggi che portano al problema
  • Gravità: imposta un livello per descrivere la gravità del problema: basso, medio, alto, bloccante, ecc.
  • Priorità: impostata dagli sviluppatori per determinare l'ordine in cui verrà corretto il difetto (P1, P2, P3, ecc. P1- il più alto)
  • Assegnato a - Proprietario del difetto in quel momento
  • Segnalato da - Nome del tester
  • Stato: stato diverso per rappresentare la fase del ciclo di vita del bug
    • Nuovo: è stato rilevato un bug e viene appena segnalato
    • Aperto: convalidato dal responsabile del controllo qualità
    • Assegnato: inviato al responsabile dello sviluppo per l'assegnazione al rispettivo sviluppatore
    • In Progress / Work in Progress - Dev ha iniziato a lavorarci
    • Risolto / Risolto - Lo sviluppatore ha finito di lavorarci
    • Verificato / chiuso: il team QA ha ripetuto il test e ha trovato il bug corretto
    • Ripeti il ​​test: il team QA non è d'accordo con la risoluzione di Dev e fa avanzare ulteriormente il bug per la rilavorazione
    • Duplica - Esiste già un bug simile
    • Rinviato: bug valido ma verrà corretto nelle versioni successive
    • Non valido: non è un bug o non è riproducibile o non ci sono informazioni sufficienti

Ulteriore lettura=>

# 6. Processo di approvazione

cancella la sottoscrizione e l'invio della documentazione finale è compito del responsabile / responsabile del controllo qualità. Tuttavia, il team deve inviare i documenti di cui sopra (scenario di test, scenario di test e documento di registro dei difetti) per le revisioni finali e l'audit.

Assicurati di correggerli tutti e di inviare le versioni finali.

Leggi anche=>

Conclusione

Questo è il processo come ho assistito e sperimentato in prima persona quando ero un tester e spero che questo ti abbia dato alcuni suggerimenti utili.

Infine, una carriera nei test è stata una gioia assoluta per me e spero lo sia anche per te.

Tutto il meglio per la tua carriera!

Lettura consigliata

^