how tester can think
Scena : In un ristorante è arrivata una famiglia di 3 persone: genitori e un bambino. Dopo aver ordinato la pizza più amata, la famiglia si è rilassata e il bambino ha iniziato a giocare con le bacchette posate sul tavolo. Gli piacevano e decise di cenare usando solo le bacchette.
Ha annunciato il suo desiderio ei genitori, impegnati a parlare, sono stati d'accordo. Quando la pizza è stata servita, il bambino ha iniziato a usare le bacchette e non è riuscito più volte a prendere la pizza in bocca. All'improvviso i genitori se ne accorsero e ordinarono al bambino di non usare le bacchette. Il bambino non ha convinto perché i genitori avevano già concordato il suo desiderio in precedenza.Quando i genitori hanno iniziato a insegnare a mangiare la pizza solo con coltello e forchetta, il bambino ha messo in dubbio la convinzione, ma io voglio mangiarla solo con le bacchette e perché è sbagliato? E mentre usava le bacchette quando non era in grado di mangiare la sua pizza preferita, si è spazientito e alla fine ha buttato via le bacchette e ha deciso di non mangiare anche la pizza. I genitori, anche loro frustrati, non potevano fare nulla e l'ora della cena in famiglia si presentava come il momento peggiore della giornata.
Ora, sostituisci alcune parole nel paragrafo precedente come segue e ripensaci:
Genitori: Team di gestione del progetto che include analista aziendale, venditore, responsabile dello sviluppo e team di architettura.
Bambino piccolo: Cliente / utente finale
Pizza: prodotto / applicazione
Bacchette: sbaglio
L'applicazione più preferita è preferita solo fino a quando l'utente non commette errori e non vede il comportamento peggiore dell'applicazione. Una volta sperimentato, l'utente non torna più all'applicazione. E quindi, come tester, è assolutamente necessario capire mentalità dell'utente , come ci si aspetta che si comporti, cosa può fare di sbagliato con l'applicazione, quale potrebbe essere il peggior errore commesso e molto altro ancora.
Il più delle volte, nei forum e dai membri del team interno, mi è stato chiesto come replicare l'esperienza dell'utente durante i test. La mia risposta è sempre stata semplice: Sii un utente :)
Sebbene sia facile a dirsi che a implementare, è il momento giusto per l'industria del test del software per andare nella direzione della rivoluzione in cui l'esperienza dell'utente e il feedback sono più importanti di qualsiasi altra cosa.
Come può pensare un tester come utente finale?
Presentandone alcuni esempi tipici di comportamento da utente finale e ricerca di sorprese , Ho osservato negli ultimi giorni:
# 1) Durante il test di un campo data, quando un utente ha selezionato o inserito manualmente il valore della data corretto, ha funzionato bene. Ma quando l'utente ha finito per inserire un valore totalmente errato come 12/00 // e ha fatto clic su OK, gli è stato presentato un messaggio di errore sul valore della data non valido.
Ora l'utente non corregge la data ma aggiorna la pagina. Cosa dovrebbe succedere? Bene, molti di voi possono indovinare cosa dovrebbe accadere, ma riescono a pensare a cosa è successo con l'applicazione? Dopo aver aggiornato la pagina, a un utente è stato presentato un seguito e lo stesso valore è stato salvato anche in un database.
Quindi… ..il tester ha replicato l'utente qui, d'accordo?
#Due) Durante il test di un'applicazione, in cui il flusso di lavoro consiste nell'inviare vari moduli in una sequenza speciale se si segue l'ordine, ha funzionato bene. Ma cosa succede se l'utente prova a tornare al modulo n. 3, dal modulo n. 5?
Ancora una volta, invece di pensare a cosa dovrebbe accadere, vediamo cosa è successo ...
Il Tester era sbalordito ma si sentiva orgoglioso di presentarsi come utente… ..Accordato?
# 3) Dopo aver effettuato correttamente l'accesso, l'utente fa clic sul pulsante Indietro del browser. Di nuovo, vediamo cosa è successo ...
Le credenziali avrebbero dovuto essere pulite, ma non è stato così. Andando oltre, in questa pagina di accesso, un utente fa clic sul collegamento Password dimenticata. Sia chiaro che l'utente aveva già effettuato l'accesso ed era stato sulla pagina di accesso facendo clic sul pulsante Indietro del browser. Il clic su Password dimenticata ha portato l'utente alla home page dell'applicazione.
Il tester si è rivolto all'utente… ..Accordato?
differenza tra test unitario e di integrazione
# 4) Dopo aver osservato l'URL della pagina di ricerca (http: //x.x.x.x: y / # / Search) dell'applicazione, il tester ha modificato l'URL come http: //x.x.x.x: y / # / Search / test? e riesci a pensare cosa sarebbe successo?
Bene, l'applicazione si è arrestata in modo anomalo e di nuovo il tester si è rivolto all'utente ... Spero che non sarai in disaccordo.
Conclusione
Immagino di aver trasmesso abbastanza di ciò che volevo tramite questi esempi.
In realtà, testare non significa controllare il flusso di lavoro dell'applicazione e nemmeno interrompere l'applicazione, ma certamente significa farlo controlla l'esperienza dell'utente anche quando fa gli errori.
Circa l'autore: Questo post è stato scritto dal membro del team STH Bhumika Mehta. È responsabile del progetto, con oltre 10 anni di esperienza nel test del software. Apprezza anche le buone idee, le innovazioni e i rischi. E ovviamente odia il lavoro monotono, le persone e l'ambiente.
E sì, trasformiamo il tester in noi stessi per l'utente finale ... Concordato? :)
Quindi ... .. vorremmo sentire altri esempi come questi da te e vorremmo avere anche le tue opinioni.
Lettura consigliata
- Esercitazione sul test della GUI: una guida completa al test dell'interfaccia utente (UI)
- Test dei cookie del sito Web e casi di test per il test dei cookie delle applicazioni Web
- Autenticazione utente in MongoDB
- Test di convalida della posta elettronica: come testare la funzionalità di posta elettronica di un'applicazione
- Guadagnare soldi, carriera nel test del software e segreti di un tester più ricco
- 5 cose che uno sviluppatore principiante (e un tester) dovrebbe sapere sui test del software
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)
- Test ad hoc: come trovare i difetti senza un processo di test formale