Test delle funzionalità non centrali [chiuso]

Question

Test delle funzionalità non centrali [chiuso]

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

0

Solo l'1% dei nostri clienti utilizza particolari funzionalità o scenari. Pensi che dovremmo spendere tanto tempo a testare queste caratteristiche e scenari mentre spendiamo sulle nostre funzionalità e scenari centrali, o dovremmo testare soprattutto il "percorso felice" per queste funzionalità?

Aggiorna

Forse avrei dovuto porre la domanda in un modo diverso. Pensi che un'azienda debba dedicare più tempo a testare le caratteristiche centrali dei suoi prodotti? Ad esempio, suppongo che il team di Windows 8 abbia testato la sequenza di avvio in modo più approfondito rispetto a quando hanno testato il driver per una scheda grafica molto rara. Il costo di un bug in una sequenza di avvio è enorme poiché nessuno sarebbe in grado di utilizzare il sistema operativo. Ma un bug in un driver di una GPU oscura farà male solo a una piccola base di clienti.

testing

posta Eugene 16.03.2014 - 20:10

fonte

3 risposte

Leggi altre domande sui tag testing

Idiomatic C API per quanto riguarda i puntatori Rilascio di un progetto open-source sotto più licenze

score 3 · Answer 1

Si riduce al costo / beneficio.

Tranne che per programmi banali, di solito non è fisicamente possibile testare tutte le permutazioni di possibili input per la correttezza del programma. (Se potessi, potresti sostituire il tuo codice con una semplice tabella di ricerca).

Dato che non puoi testare tutto, tu (o il management) devi dare la priorità. Probabilmente farei qualcosa del tipo:

priority = odds of hitting it * the pain you'll see if the failure occurs

"happy path" - 80% of your customers use these features every day. A failure here will be noticed by a lot of people, very quickly. High chance of hitting it, not sure about the pain (depends on the feature).

Catastrophic failures - low chance of hitting it, but extreme pain if hit

odd ball features - low chance of hitting it, and hopefully low pain if hit.

La tua "caratteristica dell'1%" potrebbe cadere ovunque nello schema di priorità. Se questo è il tuo più grande cliente e rappresentano 1/2 del reddito dell'azienda, il bug dell'1% potrebbe avere una priorità più alta di tutti gli altri 500 clienti combinati.

score 1 · Answer 2

Facciamo finta di aver pubblicato un'enciclopedia. Solo questo è speciale. Sono andato e ho sostituito la definizione di salsapariglia con l'immagine di una testa di scimmia.

La maggior parte dei miei utenti sarà felice di poter cercare cose popolari come scimmie e mozziconi, ma l'unica persona che aveva un disperato bisogno di sapere che cosa fosse una salsapariglia si sarebbe ritrovata un po 'sottaceti.

Quindi dipende. Stai bene con il tuo programma potenzialmente in crash sull'1% della tua base di utenti quando sbagliano qualcosa? È probabile che lo facciano? Se lo sono, potresti voler passare un po 'di tempo in quella sezione del programma.

score 0 · Answer 3

Dovresti testare tutte le funzionalità della tua applicazione. Non vuoi presentare problemi ai tuoi clienti solo perché non hai la voglia di testare a fondo come dovresti.

Detto questo, c'è uno scopo molto pratico per non testare queste caratteristiche: il tempo. Se queste sono funzionalità che non sono state toccate dal nuovo codice (direttamente o tramite codice di supporto), è altamente improbabile, ma non impossibile che vengano interrotte con una nuova compilation.

Aggiorna

Vorrei essere molto chiaro, consiglierò sempre di testare tutto in un'applicazione. La direzione potrebbe non consentirmi il tempo necessario per testare completamente. In tal caso, metterei maggiormente l'accento sulla verifica dei componenti più utilizzati del sistema.