Software senza obiettivo verificabile

Question

Software senza obiettivo verificabile

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

2

Spero che tu porti con me qui. È difficile spiegare questo problema, soprattutto senza riferimento diretto al dominio specifico.

Lavoro su un componente di un sistema più grande che esegue preelaborazioni computazionalmente costose in modo che il componente "in tempo reale" possa eseguire rapidamente le sue funzioni. Il mio prodotto crea efficacemente un set di dati di grande ricerca per il componente principale da interrogare.

Il mio prodotto calcola i risultati di un insieme finito di "scenari" (alcune centinaia di migliaia) ognuno dei quali può essere eseguito da un cliente. Il componente utilizza un algoritmo k-shortest paths e un numero di motori di regole per considerare ogni scenario e creare le ricerche, operando su dati di riferimento che rappresentano il dominio problematico.

Per gli scenari che vengono comunemente eseguiti dai nostri clienti i casi di test sono facili; i risultati attesi sono facili da ideare e affermare test di accettazione. Tuttavia, per gli scenari che non sono "popolari", i risultati attesi sono difficili da stabilire e in ogni caso i loro risultati possono essere modificati dalle modifiche ai dati di riferimento che sono praticamente impossibili da prevedere. In altre parole, le modifiche ai dati di riferimento modificano gli input sull'algoritmo del percorso più breve che a sua volta può modificare l'output.

Creare test di accettazione per questi casi impopolari è anche complicato, perché l'azienda "non sa cosa non sa", e quindi non ha una base di riferimento su cui possa essere testato.

Ogni volta che un tester torna da me con un difetto, la certezza del 99,9% è dovuta al fatto che le condizioni nei dati di riferimento sono cambiate, piuttosto che a causa di eventuali modifiche al codice. Trascorro quindi un sacco di tempo inseguendo i difetti che sono "problemi di dati". Penso che ciò che confonde la situazione è che i dati di riferimento sono fondamentali per la funzionalità del sistema, e il sistema senza una serie specifica di dati di riferimento non produrrebbe risultati che avessero alcun significato per l'azienda. Potrei creare una serie di dati di riferimento "falsi" su cui testare, ma qualsiasi affermazione contro questi dati di riferimento ingegnerizzati non sarebbe valida nel mondo reale.

Sarei molto interessato a sentire qualsiasi prospettiva su questo specialmente da coloro che hanno riscontrato problemi simili. Sono ansioso di non limitarsi a scrollare le spalle e rispondere "problema dei dati", ma arrivare alla radice del problema e capire come costruire e testare questa cosa in modo affidabile, ripetibile e prezioso.

testing design acceptance-testing

posta Matt 09.12.2013 - 20:03

fonte

3 risposte

Leggi altre domande sui tag testing design acceptance-testing

Come testare una funzione che aggiorna la password nel database? Progettazione di un elenco definito dall'utente da memorizzare in un database relazionale - Devo includere l'indice utente?

score 4 · Answer 1

Un buon approccio a questo (supponendo che la vostra azienda abbia lo stomaco adatto) sarebbe quello di modellare diverse classi di scenari dei dati dei clienti come requisiti verificabili, scrivere requisiti verificabili per quelli e quindi scrivere test per tali requisiti. Per identificare le generalizzazioni che definiscono il più comune degli scenari non comuni, in altre parole, e assicurarsi che il software li indirizzi in modo adeguato.

Questo avrebbe diversi vantaggi. La tua azienda capirebbe meglio il loro software, avrebbe gli strumenti per creare una documentazione e un servizio migliori per i clienti e forse potrebbe anche identificare modi per utilizzare il software che prima erano imprevisti.

Uno sforzo del genere dovrebbe essere guidato direttamente dal feedback dei clienti, in modo da poter giustificare lo sforzo per quegli scenari che hanno un genuino interesse del cliente. In altre parole, non solo vai alla ricerca di scenari che potrebbero essere utili.

score 2 · Answer 2

Penso che tu scaldi i dati falsi in fretta. Il punto di test è dimostrare che l'implementazione del percorso più breve di k sta trovando i percorsi più brevi, non che funzioni sull'esatto input dell'utente. Se funziona su dati falsi abbastanza buoni funzionerà su dati reali modulo eventuali errori nei dati o la vostra comprensione dei dati.

Sembra che tu abbia bisogno di due round di test, uno per il tuo algoritmo (con dati falsi pensati per esercitare ogni percorso di codice non solo quelli che il cliente capita di usare) e uno per i dati per verificarne l'integrità e la compatibilità (che dovrebbero essere trattati come errori di dati finché non vengono visualizzati diversamente).

score 1 · Answer 3

In questa situazione i dati sono davvero parte dell'algoritmo. Proprio come le modifiche al codice devono essere controllate dalla versione e testate dall'unità, e i dati che guida devono passare attraverso il controllo della versione, una sorta di verifica, e quindi le due parti dovrebbero essere testate per l'integrazione.

Sembra che le persone che modificano i dati di riferimento debbano definire quali sono le loro modifiche che si intendono raggiungere (criteri di accettazione) e quindi testare tali criteri.

Dovresti anche far parte di quel processo e parte della soluzione. Come puoi aiutarli ad avere più successo? Dal momento che non si dice nulla sulle persone che cambiano i dati di riferimento, non c'è molto da fare, ma suppongo che loro (e voi) non si vedano come persone IT. Quindi dovrai aiutarli a vedere il quadro generale, dove i loro dati e il tuo algoritmo lavorano insieme per produrre i risultati richiesti.

PS Vorrei anche aggiungere che il codice e i dati di riferimento dovrebbero essere sottoposti a test di regressione separatamente.