test scenario vs test case
Differenza tra lo scenario di test e il caso di test.
6 anni fa , mentre lavoravo con una MNC di medie dimensioni, quando ho suggerito di documentare gli scenari di test piuttosto che perdere tempo a preparare il documento di prova completo chiamato casi di test, tutte le teste si sono rivolte a me irritate.
Lo sguardo sui volti indicava chiaramente che avevo commesso un grosso errore nel suggerirlo. Sebbene nessuno abbia negato l'idea, nessuno ha nemmeno accettato. Tutti pensavano che seguire la tradizione, cioè scrivere documenti di casi di test, sarebbe stato più sicuro. Non ho potuto discutere.
Dopo 4 anni , l'azienda ha ricevuto un progetto di test, in cui l'unico vincolo era il tempo e l'unica aspettativa era piena prova test.
Eravamo di nuovo nella riunione e stavamo discutendo idee per rispettare la scadenza critica. L'applicazione consisteva principalmente nella ricerca e nella generazione di rapporti diversi tramite diverse voci di menu. Si supponeva che la documentazione dei casi di test ci servisse per la maggior parte del tempo e non eravamo sicuri di quanto il documento avrebbe utilizzato per il cliente.
Ho suggerito di documentare gli scenari di test e in qualche modo con qualche esitazione, tutti sono stati d'accordo. Non c'è bisogno di menzionare che potremmo risparmiare tempo prezioso di documentazione e potremmo utilizzarlo per i test.
Cosa imparerai:
- I casi di test vengono sostituiti rapidamente con scenari di test?
- Quando è importante la documentazione dei casi di test?
- Differenze tra lo scenario di test e il caso di test in formato tabulare
- Conclusione
- Lettura consigliata
I casi di test vengono sostituiti rapidamente con scenari di test?
Con il tempo, poiché tutto sta cambiando, anche l'industria del software e i processi sono cambiati molto.
quando deve essere eseguito il test di regressione
Tradizionale Cascata e Modelli V. vengono sostituiti da modelli agili e iterativi. La documentazione è necessaria ma per rispettare le scadenze e rendere il processo facile e trasparente, è possibile modificare la modalità di documentazione.
Quando è importante la documentazione dei casi di test?
- Il cliente ha chiesto lo stesso come parte del progetto.
- Non ci sono limiti di tempo (non credo sia possibile).
- I tester sono più freschi o sconosciuti al prodotto.
- Politica aziendale (credo fermamente che possa essere modificata).
Permettimi di condividere con te un'esperienza:
Io e il mio team siamo stati coinvolti nel testare un progetto di un'azienda Fortune 500 con tempistiche flessibili. Abbiamo documentato casi di test con il miglior modello disponibile e ottenuto l'approvazione dal cliente.
Una volta che la build è iniziata a essere rilasciata al team QA, per la maggior parte della giornata, il nostro compito è stato quello di seguire meccanicamente 100 casi di test al giorno, aggiornare il documento con il risultato positivo / negativo e inviarlo al cliente alla fine della giornata. La maggior parte del i membri del team hanno iniziato a lamentarsi lavoro monotono ma la società stava generando entrate.
Poi c'è stata una pausa di un giorno senza nessuna nuova build da testare. Ci siamo seduti insieme all'inizio della giornata e stavamo discutendo di cosa avremmo fatto per la giornata. Quando ho proposto di generare più idee per migliorare il documento del caso di test, tutti i membri del team hanno negato di aver fatto sforzi.
Secondo loro, non c'era più nulla a cui pensare poiché avevamo coperto tutti gli scenari. E convincerli a farlo pensa fuori dagli schemi e genera più idee è stata davvero dura.
La maggior parte delle volte, quando documentiamo casi di test e anche quello una volta approvato dal cliente, quella mente umana pensa che abbiamo fatto il nostro lavoro e la nostra mente smette automaticamente di considerare qualsiasi sforzo per pensare ad altri modi per testare il prodotto.
E credimi, quando viene preparato il documento dei casi di test, vogliamo solo seguirlo meccanicamente. Dimmi quante volte nella tua carriera hai sperimentato che tu o il tuo compagno di squadra avete offerto casi di test aggiuntivi al documento dei casi di test approvato?
Un'altra esperienza:
Durante l'attività settimanale di sfida a squadre, abbiamo annunciato l'applicazione e chiesto ai membri del team di versare scenari di prova.
Tutti i membri del team, compresi quelli che hanno risposto in ritardo o quelli che non hanno risposto, hanno fornito idee. Perché? Non c'era documentazione formale in cui dovevano compilare il risultato atteso per ogni sequenza di funzionalità e pre-condizione per ogni caso di test. Abbiamo raccolto 40 scenari di test in un giorno ed è stata un'ottima esperienza.
Per favorire la mia esperienza, Vorrei presentare un esempio.
come testare il sito Web su browser diversi
Prendi un'applicazione di esempio, ad esempio pagina di accesso con nome utente, password, accesso e pulsanti di annullamento. Se ci viene chiesto di scrivere casi di test per lo stesso, finiremo per scrivere più di 50 casi di test combinando diverse opzioni e dettagli.
Ma se gli scenari di prova devono essere scritti, sarà questione di 10 righe come di seguito:
Scenario di alto livello: Funzionalità di accesso
Scenari di basso livello :
1. Verificare che l'applicazione sia in esecuzione
2. Per controllare il contenuto del testo nella pagina di accesso
3. Per controllare il campo Nome utente
4. Per controllare il campo Password
5. Per controllare il pulsante di accesso e la funzionalità del pulsante di annullamento
Guarda anche=> 180+ scenari di test di esempio per il test di applicazioni web e desktop.
Poiché abbiamo tutti poco tempo, gli scenari di test funzionano come spray antidolorifico piuttosto che come IODEX vecchio stile. Eppure l'effetto è lo stesso.
Differenze tra lo scenario di test e il caso di test in formato tabulare
Infine, vorrei riassumere la differenza tra Scenario di test e Scenario di test:
| Casi test | Scenari di prova | |
|---|---|---|
| Che cos'è => | Un concept che fornisce informazioni dettagliate su cosa testare, passi da compiere e risultato atteso dello stesso | Un concetto che fornisce informazioni su una riga su cosa testare. |
| Si tratta di => | Si tratta più di documentare i dettagli. | Si tratta più di pensare e discutere i dettagli. |
| Importanza => | È importante quando il test è off-shore e lo sviluppo è in loco. Scrivere casi di test con i dettagli aiuterà sia lo sviluppo che il team di QA nella sincronizzazione. | È importante quando il tempo è minore e la maggior parte dei membri del team può concordare / comprendere i dettagli dallo scenario di una riga. |
| Vantaggio => | La documentazione una tantum di tutti i casi di test è utile per tenere traccia di migliaia di cicli di test di regressione in futuro. Il più delle volte, è utile durante la segnalazione di bug. Il tester deve solo fornire un riferimento all'ID del test case e non richiede di menzionare ogni singolo dettaglio. | Un'attività che fa risparmiare tempo e generazione di idee, preferita dalla comunità di test del software di nuova generazione. La modifica e l'aggiunta è semplice e non specifica per una persona. Per un progetto enorme, in cui un gruppo di persone conosce solo moduli specifici, questa attività offre a tutti la possibilità di esaminare altri moduli, fare un brainstorming e discutere |
| Utile per => | Un documento di caso di prova a prova completa è una linea di vita per il nuovo tester. | Una buona copertura del test può essere ottenuta dividendo l'applicazione in scenari di test e riduce la ripetibilità e la complessità del prodotto |
| Svantaggio => | Tempo e denaro che richiedono più risorse per dettagliare tutto su cosa testare e come testare | Se creato da una persona specifica, il revisore o l'altro utente potrebbe non sincronizzare l'idea esatta alla base. Hai bisogno di più discussioni e sforzi di squadra. |
Conclusione
I casi di test sono la parte più importante del ciclo di vita dello sviluppo del software e senza di esso è difficile tracciare, capire, seguire e ragionare su qualcosa. Ma nell'era dell'Agile, i casi di test vengono sostituiti rapidamente con scenari di test.
Un comune lista di controllo del test per ogni tipo di test (test di database, test di GUI, test di funzionalità, ecc.) accoppiato con scenari di test è l'artiglieria moderna per i tester del software. Discussioni, formazione, domande e pratica possono sicuramente cambiare il grafico finale di la tua produttività così come una matrice di segnalazione di bug.
Come al solito, accogliamo con favore i tuoi pensieri e le tue domande. Per favore sintonizzati.
Tutorial PREV | PROSSIMO Tutorial
Lettura consigliata
- Differenza tra piano di test, strategia di test, scenario di test, script di test, scenario di test e condizione di test
- Tipi di test del software: diversi tipi di test con dettagli
- Come scrivere casi di test: la guida definitiva con esempi
- Come rivedere il documento SRS e creare scenari di test - Formazione sul test del software su un progetto live - Giorno 2
- Come classificare gli scenari di test positivi e negativi - Cheat sheet di un tester
- Test delle prestazioni vs test di carico vs stress test (differenza)
- Test statici e test dinamici - Differenza tra queste due importanti tecniche di test
- 101 Differenze tra le basi del test del software