Un piano di test per il software interno deve tenere conto degli stati di errore di tutte le possibili configurazioni?
Vale a dire: ho un app.config con alcuni percorsi di file. Il piano di test dovrebbe avere dei passaggi per testare cosa succede quando quei valori sono errati?
Due scuole di pensiero su questo:
Se è probabile che causi un problema, allora sì dovrebbe.
D'altra parte, dal momento che si tratta di un'app interna, potresti non voler spendere troppi sforzi puntando ogni I e incrociando ogni T.
L'ultimo dipende dall'ambito del software. Se è solo una semplice utility che rende qualcosa di più facile da fare, allora può andare bene senza una gestione degli errori molto robusta. Se otterrà una buona quantità di utilizzo, soprattutto da parte di molte persone diverse, dovrebbe essere relativamente robusto dal momento che probabilmente gli utenti dipenderanno da esso.
Considera la possibilità di creare uno strumento che generi una configurazione casuale, ma valida, da utilizzare come parte degli script di test.
In un mondo ideale, sì.
Anche se si tratta di un'app interna, non è possibile controllarne l'utilizzo da parte degli utenti e più essa viene utilizzata, più probabilmente verrà utilizzata in modi che non avresti mai pensato.
Tuttavia, non viviamo sempre in un mondo ideale, quindi giustificare il "budget" potrebbe essere complicato - "funziona, vai avanti".
Per lo meno, consiglierei di implementare una qualche forma di registrazione in modo tale che quando sorgono problemi (se?), si inizi a ricrearli. Poiché si tratta di un'app interna, procurarsi i file di log non dovrebbe essere un problema.
Sì.
(A meno che tu non voglia che gli utenti interni ti chiamino ogni volta che c'è un errore nell'installazione)
Leggi altre domande sui tag testing