Riguardo al controllo qualità / test, un test sui limiti può non essere realistico? (Vedi l'immagine per chiarimenti)

Mi piacerebbe affrontarlo da un punto di vista non convenzionale.

Il ruolo di Q & A è quello di trovare ciò che non si sta comportando rispetto a ciò che è stato richiesto. Ciò implica che un analista di Q & A deve essere consapevole dei requisiti tanto quanto lo sviluppatore o anche di più.

Uno degli aspetti chiave dei requisiti è come un software deve comportarsi sotto i limiti. Se questo non è definito, non è il ruolo del Q & A a definirlo, ma a chiedere chiarimenti agli esperti del dominio (se questo è un confine di dominio) o agli esperti tecnici (se questo è un limite tecnico) su come il software si prevede che si comporti in questi casi e aiuta il team a capire cosa sta succedendo e a costruire un prodotto migliore.

Non è il ruolo del Q & A trovare un presunto bug, segnalarlo e, diciamo, dimenticarlo ("Ho fatto il mio lavoro, ho trovato il bug, mi sento bene con me stesso, maledetto voi sviluppatori fate il vostro funziona bene! ").

Fai parte di una squadra. Stai contribuendo alla creazione di un prodotto e, molto spesso, sei l'ultimo uomo in piedi tra un rilascio e un utente. Capire come deve comportarsi il tuo prodotto è solo una parte del tuo lavoro. L'altra parte del tuo lavoro è aiutare tutti nel team a capire anche quello.

Riguardo al tuo caso concreto: qual è il tipo di informazioni che ci si aspetta in quel campo? È un commento? Una domanda ? Una stringa BASE64 da utilizzare come chiave pubblica RSA ?

A seconda del tipo di informazioni che dovresti avere lì, puoi definire che si tratta di un bug (per una chiave pubblica RSA, che non ti permette di copiarlo) o meno (se si tratta di un campo di commento solo per gli anglofoni , non è ragionevole pensarlo come un bug). Ma in entrambi i casi , dovresti spingere le persone in giro per aggiungere la definizione del comportamento ai requisiti formali.

Il rifiuto per un "test non realistico" non mi sembra appropriato. Il test al contorno è un modo perfettamente legittimo per progettare i casi di test per trovare i problemi, e mi aspetto che i tecnici del controllo qualità testino regolarmente i limiti.

Il modo in cui viene trattato questo problema dipende dalle tue esigenze. Se hai bisogno di poter visualizzare tutti i caratteri / testo inseriti nel campo di testo, il software non soddisfa i requisiti. Tuttavia, poiché questa è una condizione rara, è probabile che si tratti di un problema a bassa priorità. In alternativa, il problema potrebbe essere nei requisiti stessi e in che modo il sistema è documentato come comportante.

Non mi aspetto che il tuo problema venga rifiutato, ma semplicemente la priorità è molto bassa.

Prima cosa da considerare:

• l'immissione di più di 163 caratteri causa problemi gravi come un buffer overflow? Quindi è chiaramente un bug (e spero che il project manager remoto venga licenziato).

Ma ipotizziamo che non sia il caso:

• a cosa serve il campo di testo specifico? Parole singole come un nome utente? Quindi probabilmente è un limite accettabile e nessun bug. Intere frasi con potenzialmente più di 163 caratteri? Quindi è un bug. Non lo sai in anticipo perché è usato per scopi diversi? Quindi dovrebbe essere trattato come un bug, poiché ci si dovrebbe aspettare casi di utilizzo in cui 163 caratteri non sono sufficienti. Brevi note, dove un limite artificiale ha un senso? Quindi il limite dovrebbe essere da qualche parte nelle specifiche, anzi.

Anche se non ci sono limiti espliciti menzionati nelle specifiche, per la maggior parte dei casi reali, puoi dedurre un limite ragionevole dal controllo del significato del campo di testo.

Infine, supponiamo che il limite di 163 sia abbastanza alto per il caso d'uso previsto, quindi vorrei ancora chiedere:

• è il limite trasparente per l'utente?

La pagina / modulo proibisce l'inserimento di più di 163 caratteri immediatamente quando l'utente tenta di digitare il numero di carattere 164, o accetta 2000 caratteri e taglia fuori qualcosa oltre il 163 in seguito o (peggio) segretamente? Se questo è il caso, allora non chiamerei questo problema un bug, ma "comportamento non ergonomico" o "non user friendly". La tua squadra dovrebbe avere una politica su come affrontare tali problemi (probabilmente avranno una priorità inferiore rispetto ai bug "reali", ma se il tuo team vuole produrre software di alta qualità, ti consiglio di non assegnare la priorità più bassa possibile).

Il test va bene. Nessun test dovrebbe essere rifiutato. L'unica domanda è se è un pass o un fallimento.

Ora correggimi se ho torto ma dici che questo test fallisce, non perché la nota non è memorizzata e visualizzata, ma perché il testo a capo non rompe parole molto lunghe?

Dovrei chiedere se le specifiche per la funzione definiscono il tipo di word wrapping che dovrebbe essere usato? In caso contrario, passa il test.