Quindi siamo abbastanza bravi a soddisfare i requisiti dei nostri clienti finali, divisione aziendale e vendite / marketing. Pianifichiamo progetti per aggiungere / migliorare le funzionalità per soddisfare tali richieste e dare priorità alle attività per rispettare le scadenze nell'ordine più redditizio.
Nel corso del tempo, il prodotto software è cresciuto, il mercato è cambiato ei clienti originali sono meno prioritari rispetto ad alcune nuove opportunità.
Quindi, i requisiti, e quindi le specifiche, sono cambiati, sebbene tutti i requisiti di tutte le parti interessate possano coesistere (non ci sono conflitti).
Abbiamo anche avuto una certa contrazione nel team di sviluppo con persone che si muovevano, fuori o dentro e così ora non c'è nessuno che fosse lì "all'inizio".
Ciò ha portato ad alcune interruzioni del servizio clienti in cui abbiamo rimosso quelli che sembravano percorsi di codice inutilizzati (la logica non era familiare a tutti) solo per trovare il cliente che aveva bisogno di quella logica per eseguire l'applicazione un paio di mesi dopo. p>
Sappiamo che potremmo inserire i Test unità per verificare che il comportamento non cambi in modo accidentale (come nel caso precedente), ma questo è un grande codice in modo che ci sia bisogno di tempo per testare l'unità di tutto.
Quali tecniche / tecnologie / best practice non manuali sono a nostra disposizione per verificare che il software (ancora) soddisfi le specifiche e i requisiti?
Ho sentito sostenitori agili / iterativi dire qualcosa come "I Test di unità sono le specifiche". C'è qualcosa che potremmo usare per sposare i test unitari ai requisiti originali?
Note
(Ho visto quest'altro post , ma meno sulla verifica e altro sui test di usabilità)
Facciamo già uno sviluppo iterativo, rilasciando ogni due settimane o meno.
La base di origine è per lo più C ++ su Unix. Requisiti e specifiche attualmente documentati in Wiki, Word, sistemi di ticketing e MS Project.