Definire e testare i requisiti dettagliati dell'interfaccia utente

Question

Definire e testare i requisiti dettagliati dell'interfaccia utente

#1 da (1 voti)
#2 da (0 voti)

3

Sono in procinto di progettare e realizzare una piccola app web. Durante l'implementazione di un primo prototipo ho scoperto che faccio molte ipotesi non scritte sul comportamento dell'interfaccia. Ad esempio:

When the user selects a product in the product browser, the product inspector quickly slides out the left side displaying the product data. If the inspector is already opened, the data is only updated. The header background color changes with a radial animation.

In questo momento sono solo io nel progetto, quindi definisco questi requisiti impliciti al volo. Ma dopo ogni cambiamento che potrebbe rompere qualcosa, devo richiamarli tutti per testarli. Ovviamente dovrei scriverli da qualche parte. Conosco i test unitari, conosco scenari e personaggi, diagrammi del caso d'uso; questo sembra essere qualcosa di diverso e non so come farlo correttamente.

Quindi, qual è il solito modo di definire, documentare e anche garantire tali requisiti? Dove li metto? Come li struttura? Come posso testarli in modo efficace? Dovrei spedirli con il codice sorgente o metterli nel progetto Wiki?

Inoltre, è probabile che questi requisiti cambino di frequente, soprattutto dal momento che utilizzo un approccio di prototipazione rapida. Non voglio passare molto tempo a disegnare diagrammi, ecc. Ma semplicemente scaricarli in un file di testo senza alcuna struttura sembra essere una perdita di tempo, non appena devo testare una parte specifica dell'applicazione. / p>

testing requirements qa ui

posta Lucius 23.08.2015 - 23:43

fonte

2 risposte

0

L'IDE Selenium consente di esaminare uno scenario e aggiungere asserzioni per verificare che funzioni come previsto. che puoi quindi salvare come file che puoi riprodurre in un secondo momento. Ha alcune limitazioni.

l'estensione funziona solo con Firefox.
controllare i cambiamenti visivi potrebbe essere difficile. (sembra che tu possa controllare le proprietà del css)

risposta data 01.09.2015 - 04:06

fonte

Leggi altre domande sui tag testing requirements qa ui

Quali strumenti usano gli sviluppatori PHP? [duplicare] Sostituzione delle stringhe di connessione e delle impostazioni dell'app durante la compilazione di TFS

score 1 · Accepted Answer

Certo, la prototipazione rapida può portare a frequenti modifiche alle tue API per un certo periodo di tempo, ma prevedo che i cambiamenti alla fine matureranno e si stabilizzeranno dopo che i requisiti verranno sistemati e puoi essenzialmente fare un 'API freeze'.

Se stai apportando delle modifiche a annulla le modifiche precedenti, potresti andare avanti e allontanarti da Non hai bisogno di esso . Il punto qui è sapere quando e come è necessario interrompere i cambiamenti dei requisiti.

Con ciò, penso che il testing delle unità sia sicuramente un potenziale punto di partenza per convalidare qualsiasi nuova modifica pensi che applichi con ciò che funziona attualmente. Tuttavia, non codificare i test di unità deboli che sono incompleti o che eseguono solo i casi di test più superficiali (ad esempio, assicurandosi che gli argomenti fail-fast per null funzionino, senza passare attraverso la logica effettiva). Prova a unità di test per casi limite più significativi, che tendono ad essere la tua prima linea di difesa quando torni al tavolo da disegno. Sarà ancora più utile se puoi scrivere i tuoi test unitari in uno stile BDD che dia una buona definizione del contratto di una classe .

Dovresti anche provare a documentare il tuo design / codice API dal punto di vista di un utente finale, o come tabula rasa sviluppatore. Collegandoti al primo punto, una volta che ritieni di aver raggiunto un punto sufficientemente maturo della progettazione dell'API, inizia a documentare da zero il codice base. Assicurati di aggiornare le parti in cui i tuoi "requisiti impliciti" originali sono cambiati. Questi possono essere inclusi nella pagina wiki del tuo progetto. Se stai anche posizionando la documentazione del tuo progetto sotto il controllo della versione, ad es. inserendoli su GitHub, avrai anche una cronologia delle versioni funzionante per scoprire come si sono evoluti la documentazione e la tua base di codice.