Menu

Come affrontare i cattivi requisiti come tester

how deal with bad requirements

Prova Il Nostro Strumento Per Eliminare I Problemi

La silenziosa sala riunioni era soffocante e tutti all'interno erano confusi. Come potremmo perderlo , era la domanda riflessa dal volto di tutti.

Dopotutto, non presentarsi con alcun errore rilevante quando l'utente cerca di duplicare il record esistente e consentirgli di farlo non era un piccolo bug, anche questo per una compagnia di assicurazioni.

Dopo aver deciso di risolvere il problema, tutti si sono dispersi. E durante lo scavo, è stato osservato che il cliente non ha mai menzionato nulla sulla duplicità dei record nel documento dei requisiti e quindi nessuno ha posto domande pertinenti o ci ha pensato.

cattivi requisiti

Questo era solo un esempio.

In una carriera di oltre 10 anni , Ho osservato molti casi in cui i progetti hanno sofferto a causa di requisiti scadenti o insufficienti.

Ma come si suol dire, niente è perfetto in questo mondo e dovrai affrontarlo e occuparti di progetti che non hanno requisiti o requisiti poveri è una sorta di incubo.

Lasciatemi spiegare -

Cosa imparerai:

In che modo requisiti negativi, poveri e contrastanti creano problemi:

# 1) Nessun requisito - Nessun requisito implica supposizioni e ipotesi e quindi non c'è fiducia. È molto difficile testare un prodotto / un'applicazione senza alcuna linea di base. E questi risultati in più lavoro, più bug da parte del cliente e più sofferenza per il progetto.

  • Come vorresti che segnala un problema sul crash del sistema quando non è disponibile una definizione di come il comportamento dovrebbe essere gestito?
  • Come trasmettereste che il tempo di caricamento di 100 secondi per la home page è inaccettabile quando non vi sono requisiti rilevanti per le prestazioni?

Ulteriori informazioni su Nessun requisito e su come gestire la situazione durante il test sono disponibili nell'articolo pubblicato in precedenza - Come testare un'applicazione senza requisiti?

# 2) Requisiti scadenti - La citazione, Conoscere qualcosa di incompleto è pericoloso che non saperlo affatto , è molto vero quando si tratta di gestire un fabbisogno mediocre.

Interpretare un requisito scadente e implementarlo è un grosso rischio.

  • Come confermereste che il pop-up che mostra i risultati della ricerca è valido o meno quando l'unico requisito menzionato era: i risultati della ricerca dovrebbero essere corretti e non siete sicuri di quali criteri dovrebbero essere considerati durante la ricerca.
  • Come interpreteresti questo - La password dimenticata dovrebbe essere implementata per facilitare all'utente la rigenerazione / reimpostazione della password dimenticata. Non sapendo quale flusso di lavoro il cliente desidera per la password dimenticata, lo sviluppatore implementa ciò che ritiene sia migliore e iniziano i conflitti.

# 3) Requisiti in conflitto - Chiedere a qualcuno di fare due cose diverse allo stesso tempo è solo confonderlo e anche il sistema non è un'eccezione.

  • Come testereste un'applicazione con i requisiti menzionati, sono i seguenti:
    • L'applicazione dovrebbe sempre essere aperta sulla home page.
    • Gli utenti devono effettuare l'accesso per accedere all'applicazione.
  • Quale decideresti la priorità quando il documento dei requisiti è il seguente:
    • L'applicazione di gioco dovrebbe promuovere l'utente al livello successivo se l'utente ottiene 1000.
    • L'utente dovrebbe essere reindirizzato alla pagina di iscrizione gratuita una volta ottenuto 1000.

Ed è così che i requisiti cattivi, poveri e contrastanti creano problemi.

Essendo nell'industria del software, dovrebbe far parte del progetto poiché a volte anche il cliente non è sicuro di cosa vogliono esattamente e come esprimerlo.

Dal punto di vista dei test, sebbene sia difficile gestire questi requisiti ambigui o vaghi, non è del tutto impossibile.

Diamo un'occhiata alle possibili soluzioni:

Requisiti errati e come gestirli come tester:

Metodo n. 1)Esplora e impara:

Esplorare altre applicazioni, apprendere il comportamento generale previsto, comprendere il flusso di lavoro, pensare alla comodità dell'utente e applicare la logica è un modo per affrontare la situazione. Anche, basandosi su test esplorativi sarebbe utile in questo tipo di situazioni in cui i requisiti non sono chiari.

La maggior parte delle volte, è una buona scommessa dare la priorità all'esperienza utente e alla praticità quando i requisiti non sono chiari.

Metodo n. 2)Utilizza l'esperienza:

Utilizza l

Esperienza nel dominio , l'esperienza complessiva dei test, i problemi affrontati in passato e le intuizioni personali possono aiutare ad affrontare situazioni e requisiti confusi.

Metodo n. 3)Fare riferimento a wireframe:

I wireframe sono una sorta di requisito visivo in cui è possibile trovare piccoli dettagli e quei dettagli possono essere molto utili per creare l'immagine prevista del prodotto o dell'applicazione e aiutano a coprire gli aspetti dei test in un modo migliore.

Leggi di più => Wireframe: dovrebbero essere davvero testati? E se sì, come?

Metodo n. 4)Discussione tra pari:

generalmente, la maggior parte degli errori (difetti) si trovano in quali due periodi di prova?

Discussione tra pari

Non importa quale sia la confusione, se discusso con il giusto gruppo di persone, le cose vengono chiarite. Ognuno porta con sé esperienze, aspettative, punti di vista degli utenti e analisi differenti e la discussione di queste scarse esigenze con i colleghi servirà a concretizzare la comprensione e aumentare la fiducia in se stessi.

Metodo # 5)Chiarimento dal cliente:

Il cliente è il proprietario del prodotto / dell'applicazione ed è sempre saggio rivolgersi a lui quando si tratta di chiarezza dei requisiti. Ma ricorda, non è consigliabile attaccare il cliente con centinaia di domande. Prima di farlo, sono necessari alcuni compiti.

Cerca di scoprire le migliori pratiche disponibili, comprendere i vantaggi dell'implementazione e quindi contattare il cliente con domande e possibili soluzioni.

Conclusione

Infine, requisiti vagamente definiti o indefiniti fanno parte della vita del tester e dobbiamo accettarli, ma cerchiamo di essere ottimisti e di determinare le soluzioni. Dopotutto, siamo tester, aiutiamo a mantenere le applicazioni in pista e ad evitare che cadano a terra. YAY a noi :)

Circa l'autore: Questo post stimolante è stato scritto dal membro del team STH Bhumika M. Lei è a capo del progetto, con oltre 10 anni di esperienza nel test del software.

Buona prova, come al solito… .. aspettando le vostre opinioni, commenti e opinioni.

Lettura consigliata

^