Menu

Test guidato dal contesto: 7 principi di base con un esempio

context driven testing

Prova Il Nostro Strumento Per Eliminare I Problemi

7 principi di base del test guidato dal contesto con un esempio:

quali sono le fasi del sdlc

Quando guido verso l'aeroporto, di solito prendo l'autostrada che mi porterà lì nel minor tempo possibile ed evita i pedaggi. Ma quel giorno ho preso una strada locale più lunga con un pedaggio. Perché volevo qualche minuto in più con il mio amico durante il viaggio, che ha viaggiato molto per trascorrere il fine settimana con la nostra famiglia. La scelta peggiore normale, in questo caso, si è rivelata la migliore.

Ma considera questo.

E se fossi a corto di benzina?

E se avessi pochi soldi?

Sceglierei un'opzione diversa. Perché? Il contesto.

Che cos

(Immagine credito )

Quando prendi decisioni basate su, quanto segue è una decisione guidata dal contesto:

  • Le persone coinvolte
  • Circostanze
  • Obiettivi
  • Opzioni disponibili
  • Emozioni, ecc.

Allora, cos'è il test guidato dal contesto?

Il Context Driven Testing è un cambiamento di mentalità (o School of testing) sviluppato da Cem Kaner, James Bach e Bret Pettichord. I dettagli a riguardo possono essere trovati nel loro famoso libro: Lezioni apprese nel test del software .

Ci sono 7 principi di base. I seguenti sono selezionati direttamente dal loro libro:

# 1) Il valore di qualsiasi pratica dipende dal suo contesto.

#Due) Esistono buone pratiche nel contesto, ma non ci sono buone pratiche.

# 3) Le persone, che lavorano insieme, sono la parte più importante del contesto di qualsiasi progetto.

# 4) I progetti si sviluppano nel tempo in modi che spesso non sono prevedibili.

# 5) Il prodotto è una soluzione. Se il problema non viene risolto, il prodotto non funziona.

# 6) Un buon test del software è un processo intellettuale impegnativo.

# 7) Solo attraverso il giudizio e l'abilità, esercitati in modo cooperativo durante l'intero progetto, siamo in grado di fare le cose giuste al momento giusto per testare efficacemente i nostri prodotti.

Non ho intenzione di spiegarli ciascuno perché è fatto per noi da esperti qui .

Farò semplicemente una spiegazione basata su uno scenario sulla mia opinione sul test guidato dal contesto.

Un esempio di test guidato dal contesto:

Supponiamo che sto iniziando un progetto di test - Progetto A che include test end-to-end per un'applicazione basata sul web.

Quale sarebbe la mia strategia?

Secondo i processi standard, questa sarà la sequenza degli eventi:

  • Raccogli i requisiti e comprendi l'applicazione
  • Crea un piano di test
  • Creare documentazione di test: scenari di test, casi di test, matrice di tracciabilità, ecc.
  • Far esaminare e approvare tutta la documentazione
  • Configurare l'ambiente QA e i dati di test
  • Eseguire l'esecuzione del test
  • Crea segnalazioni di bug
  • Genera e condividi rapporti sullo stato di esecuzione dei test, ecc.

Se mi pongo la domanda: 'Come ho deciso che questo è ciò che devo fare?' La mia risposta sarebbe: best practice, standard di QA, linee guida del settore, linee di base dell'esperienza passata, ecc., Giusto?

Sto ripetendo quello che mi è stato insegnato a fare o quello che ho visto fare gli altri.

elenco di collegamenti in c ++

Ora, c'è qualcosa di sbagliato in questo? Affatto. Anche questo potrebbe funzionare perché c'è un certo senso di ripetibilità e di prova nel tempo in questo approccio. Tuttavia, apre la strada a risultati ottimali?

Dubbioso. Perché?

Perché con ogni progetto affronterai circostanze diverse:

  • Requisiti documentati e non documentati
  • Stretto lavoro rispetto a team distribuiti geograficamente
  • Team di sviluppo e test appartenenti alla stessa azienda vs. concorrenza
  • Tempo sufficiente vs. Orari stretti
  • La composizione della tua squadra - Nuovi arrivati ​​contro quelli esperti. Quelli addestrati contro quelli non addestrati.
  • Disponibilità di strumenti: utilizzo manuale dello strumento di gestione dei test
  • Tipo di progetto: richiede una stretta aderenza alle regole (FDA o banche) rispetto a sperimentale (come i social media)
  • La tecnologia del progetto.Per esempio:non testeresti il ​​Web e un'app di Windows allo stesso modo
  • Requisiti dei clienti (alcuni vogliono report dettagliati giornalieri, altri vogliono solo i punti salienti)
  • Processo seguito (Agile vs. tradizionale, test con script e test esplorativo)

Questo elenco non è esaustivo e sai bene quanto me che ci sono molte variabili per ogni progetto.

Il test basato sul contesto è quando lasci che queste circostanze decidano le tue pratiche di test, tecniche e persino definizioni piuttosto che standard, percepiti dal settore ' migliori pratiche' .

Ora, diciamo che questi sono i dettagli con cui sto lavorando per il progetto A:

  • Sto lavorando con un team di 5-4 nuovi arrivati ​​e 1 tester esperto.
  • Non ho requisiti documentati.
  • Il mio team è in India e il team di sviluppo è negli Stati Uniti, quindi lavoriamo con fusi orari diversi.
  • Il cliente desidera un rapporto sullo stato dettagliato giornaliero
  • Usiamo uno strumento di tracciamento dei bug basato sul web, come Mantis o Bugzilla e questo è tutto ciò che abbiamo.
  • Devo fare 2 round di test in 10 giorni con 3 giorni per la documentazione del test

Ecco un piano di gioco approssimativo:

1) Poiché molti nuovi arrivati ​​fanno parte del team, abbiamo bisogno di molte revisioni tra pari.

Due) Abbiamo anche bisogno di almeno 2 riunioni di discussione sui requisiti con il team BA e Dev. Deve essere formale perché le squadre si trovano altrove e ho poche possibilità di andare da loro con domande.

3) È una sequenza temporale di test aggressiva per la documentazione. Più documentazione scriviamo, più revisioni abbiamo bisogno, il che equivale a più tempo. Quindi, dovremo mantenere una documentazione minima. Documenteremo solo l'essenziale TC end-to-end e il resto lo sarà testato in modo esplorativo .

4) I report di stato giornalieri durante l'esecuzione del test verranno creati e inviati EOD ogni giorno.

5) La maggior parte dei test è esplorativa, quindi consiglio il tempo di provare a fare una breve descrizione di ogni test eseguito. In questo modo sappiamo cosa viene testato e cosa no.

6) I difetti verranno segnalati in tempo reale in Mantis. Poiché il team sta lavorando in un fuso orario diverso, potrebbe dover attendere un giorno intero prima di ricevere notizie dal team di controllo qualità, nel caso in cui abbiano bisogno di un chiarimento. Pertanto, organizza una chiamata quotidiana presso un team conveniente, in cui il team QA dimostrerà la ricreazione dei bug. In questo modo, non ci sarà bisogno di aspettare o seguire.

E così via.

Una volta che hai una strategia generale, scrivi un piano di test di base che spieghi questi punti. Ora, sei pronto per entrare in un progetto di test dopo un'attenta considerazione e una strategia personalizzata per il successo.

In sintesi:

Questo è Test guidati dal contesto; rendendo le tue circostanze (non gli standard) gli input e gli influencer principali per la tua strategia di test. Ci spinge a guardarci intorno e prendere in considerazione tutto ciò che ti circonda.

Personalmente, sono innamorato di questo concetto perché troppo spesso le pratiche di sperimentazione sono percepite come rigide e basate sull'imitazione. Qualcuno l'ha fatto e ci è riuscito, quindi lo farò anch'io. Questo è il tipo di immagine che spaventa le persone dal provare e continuare una carriera di prova.

Ma c'è molto spazio per il pensiero creativo, le capacità analitiche e il processo decisionale. Per saperne di più, approfondisci l'argomento nei link forniti sopra.

Buon test guidato dal contesto

Lettura consigliata

^