Menu

Come testare un'applicazione senza requisiti?

how test an application without requirements

Prova Il Nostro Strumento Per Eliminare I Problemi

Tecnicamente non ci sono applicazioni senza requisiti. Immagina un software che non fa nulla di specifico ma è semplicemente riga dopo riga di codice che si estende. Sarà una scala che non porta da nessuna parte.

Tutto il software ha dei requisiti ed è mirato a un compito particolare; in particolare, è una soluzione a un problema. Così senza requisiti il software non è una possibilità.

Tuttavia, il software senza requisiti documentati è una realtà che purtroppo la maggior parte di noi deve affrontare più spesso ci piace. L'unica cosa peggiore potrebbe essere che la documentazione è insufficiente, imprecisa o terribilmente obsoleta. Purtroppo, succede anche questo.

prova senza requisiti

Onestamente, non c'è davvero alcun sostituto a un documento di requisiti funzionali / di sistema ben documentato con casi d'uso elaborati e schermate di simulazione. Anche se dobbiamo ammettere che questa sta diventando una rarità nel settore a causa dei rapidi cicli di sviluppo e di un cambio di paradigma verso una documentazione minima o nulla.

Pertanto, questo articolo è un tentativo di alcune pratiche che abbiamo seguito quando ci siamo trovati in queste situazioni.

Leggi anche:

come posso riprodurre file mkv

Vediamone prima alcuni motivi per cui potrebbe non esserci documentazione, per cominciare:

  1. Progetto accantonato in fase di riapertura
  2. Documentazione meno formato del processo di lavoro
  3. La documentazione potrebbe esistere, ma potrebbe non essere dettagliata o completa
  4. Le versioni continue e le informazioni relative alla versione precedente non sono state archiviate, con conseguente lacuna nella comprensione di come la funzionalità esistente reagisce con quella nuova

Sono tutti ostacoli che noi tester dobbiamo superare coraggiosamente ed emergere con successo. Ma come esattamente, vero?

Ecco i 3 metodi principali per testare un'applicazione senza requisiti:

Metodo # 1:

Lavora con qualsiasi piccola documentazione su cui puoi mettere le mani. Potrebbe essere un semplice backlog di base (in progetti agili), un file di aiuto, un'e-mail, una versione precedente di BRD / FRD o vecchi casi di test (verificali nei tuoi strumenti ALM e potresti trovarli), ecc.

Indaga, chiedi in giro e c'è sempre qualche processo documentato anche se è scarno.

Quando questo non funziona, non sottovalutare la tua esperienza come utente di software.Per esempio, se devi testare un'operazione di trasferimento per un conto bancario, nessuno ha bisogno di dirci come farlo, no? Perché come clienti di online banking sappiamo tutti che abbiamo bisogno di conti da e verso con un numero di fondi disponibili per essere trasferiti.

Ho convenuto che non tutte le situazioni saranno così semplici, ma ancora una volta potrebbero esserlo.

Metodo n. 2:

Utilizzare la versione precedente / corrente dell'applicazione come riferimento per testare la versione futura di un prodotto software. Ora, ammetto che ciò è in contrasto con la regola 'Non scrivere mai casi di test utilizzando l'applicazione come riferimento'. Tuttavia, quando lavoriamo in una situazione tutt'altro che perfetta, dobbiamo modellare le regole per soddisfare le nostre esigenze.

Aiuta a mantenere i seguenti aspetti in prospettiva quando lo fai:

  • L'applicazione potrebbe contenere bug, quindi se dopo la registrazione il sistema ti porta direttamente a Screen1 (una certa schermata ipotetica per il bene del nostro esempio) - Non dare mai per scontato che sia il comportamento corretto. Anche se un campo accetta caratteri alfanumerici ed è un numero di telefono, una domanda che e assicurati di non prendere l'applicazione come un esempio scontato per la funzionalità prevista.
  • Nelle situazioni di cui sopra usa il tuo giudizio e prendi l'aiuto dell'applicazione per darti un rapido inizio, ma sii critico per mettere in dubbio che funzioni.

Metodo n. 3:

Parla con i membri del team di progetto:

  • Offriti di partecipare alle loro riunioni.
  • Chiedi se puoi partecipare alle fasi di test unitario e di integrazione.
  • In caso contrario, chiedi se il team di sviluppo può condividere la loro unità e i risultati del test di integrazione.
  • Stabilisci un momento per il trasferimento delle conoscenze in un momento conveniente.

Ora, applichiamo i metodi in un esempio:

Supponiamo che esista un sito di acquisti in cui è possibile aggiungere articoli al carrello. Idealmente, se c'era della documentazione, ha bisogno di dirci come aggiungere articoli ad essa, quanti articoli può avere in un dato momento, cosa succede quando l'articolo che hai aggiunto diventa improvvisamente esaurito, qual è il numero massimo degli stessi articoli che puoi acquistare allo stesso tempo, ecc. La nostra situazione è che NESSUNO di questi è disponibile in questo momento.

Applicare il metodo n. 1:

Trova tutta la documentazione che potresti. Chiedi al tuo team di sviluppo se hanno schermate di mock-up / guarda nello strumento ALM o qualcosa del genere. Se trovi qualcosa, sarebbe un buon punto di partenza. Ma se questo metodo non rivela nulla, puoi usare il tuo giudizio / intuizione del tester.

Sappiamo tutti come funzionano i carrelli della spesa, quindi fai le tue supposizioni e arriva ad alcuni scenari di base come:

  • Gli articoli possono essere aggiunti al carrello dopo essere stati sfogliati o cercati
  • Dopo aver aggiunto gli articoli al carrello, l'elenco degli articoli dovrebbe essere aggiornato
  • L'utente dovrebbe essere in grado di continuare a fare acquisti anche dopo aver aggiunto pochi articoli al carrello
  • Aggiungendo due volte lo stesso elemento, il conteggio degli elementi aggiunti verrà incrementato
  • Gli articoli possono essere aggiornati
  • Gli elementi possono essere rimossi
  • Il totale dovrebbe essere equivalente alla somma di tutti i prezzi aggiunti
  • Le tasse devono essere calcolate in base al codice postale inserito
  • Le spese di spedizione devono essere aggiunte di conseguenza

Possiamo andare avanti, ma sono sicuro che avrai capito.

Applica il metodo n. 2:

Se è disponibile una versione precedente dell'applicazione, ciò può essere utile per scrivere i tuoi casi di test poiché dovrai scrivere i passaggi esatti di dove fare clic, dove inserire l'input, cosa controllare ecc. Screenshot / mockup / wire- frame - se disponibili possono essere anche ottimi sostituti.

Come puoi vedere dalla schermata sottostante, queste cose sono evidenti: i nomi dei campi, i pulsanti o altri elementi presenti ecc. (clicca sull'immagine per ingrandirla)

prova senza requisiti

Ora, a questo punto i tester hanno alcune domande come:

  1. Cosa succede quando do un carattere nella casella dell'importo?
  2. Quando aggiungo troppi articoli?
  3. Qual è il massimo no. di elementi che questo può richiedere? Eccetera.

Applica il metodo n. 3 :

Porta il tuo elenco di domande al BA, allo sviluppatore o persino al cliente e chiedi chiarimenti. Una volta completato il metodo 3, dovresti essere praticamente dotato di tutte le informazioni necessarie per scrivere casi di test dettagliati ed eseguire i test con la stessa sicurezza che avresti quando fosse disponibile una documentazione elaborata.

Concordato sul fatto che sono molti più passaggi e molto più follow-up, ma per garantire i test di qualità, questi passaggi sono inevitabili.

Insomma, non tutto è perduto quando la documentazione non esiste o è insufficiente. C'è ancora speranza! Per favore condividi le tue esperienze in situazioni simili.

Circa l'autore: Questo utile post è stato scritto dal nostro membro del team STH Swati S.

Come sempre i tuoi commenti, domande e suggerimenti sono i benvenuti.

Lettura consigliata

^