Strategia a lungo termine per l'implementazione di un sistema di controllo qualità?

Un buon punto di partenza è lo standard IEEE sui Piani di garanzia della qualità del software .

Ci sono molti fattori da considerare -

1. Come gestisci il processo di controllo della qualità?

2. Quali standard e convenzioni seguirà la tua squadra?

3. Quali sono le tue metriche? (Ovvero, quali articoli misurerai e in che modo misurerai e riferirai su di essi?)

4. Quali audit eseguirai per assicurarti che i test siano eseguiti, le tue metriche siano valide, ecc.?

5. Quale set di documentazione ti aspetti e come valuteresti che quei documenti sono corretti?

6. Qual è il piano di test complessivo? (Questo include definizioni di test, programmi, risorse richieste, ecc.)

7. Quali strumenti di prova, strumenti, piattaforme di test, ecc. saranno usati?

8. Come si controllano le apparecchiature di test e le piattaforme di test (inclusa la calibrazione e gestione della configurazione della piattaforma di test?

9. In che modo vengono segnalati i problemi?

10. In che modo assegni e risolvi i problemi e come gestisci e gestisci questo processo?

11. Gestione della configurazione e piani di controllo del codice sorgente.

12. Controllo dei media per articoli che pubblichi e distribuisci. Questo include qualsiasi materiale stampato, materiale distribuito via CD o DVD, o software e documentazione che rendi disponibili tramite il web.

13. Se stai utilizzando subappaltatori e fornitori, come gestisci e monitora la qualità del prodotto e del materiale con cui ti forniscono?

14. Hai intenzione di creare, mantenere e conservare i record delle tue attività.

15. Formazione richiesta per i membri del team.

16. Piano di gestione del rischio.

Probabilmente vorrai almeno un assembly di test unitario per assemblaggio nel sistema.

Si potrebbe sostenere che potrebbe valere la pena suddividere i test di business logic in più assembly di test, ad esempio "BllTests.Customer, CllTests.Product, BllTests.Basket" ecc.

La cosa peggiore che puoi fare è incollarli tutti in un'unica grande assemblea, è l'equivalente di avere l'intero progetto in un unico assieme: rende le cose molto più difficili da gestire. Il tuo feedback di prova verosimilmente proviene da un server di Continuous Integration, quindi avrai bisogno di un'accuratezza abbastanza precisa di quale test sta fallendo e quale parte del sistema ha un impatto, così puoi prendere decisioni sull'impatto dello stesso errore.

NON DEFINITIVAMENTE vuoi i test nello stesso assembly di qualsiasi codice di produzione. Se li hai inseriti tutti nel codice di produzione, dovrai distribuire un gruppo di assembly di terze parti al tuo server di produzione che non hanno alcuna utilità per il prodotto stesso e aggiungere semplicemente un altro punto di errore!

Modifica

OK, quindi abbiamo a che fare con un monolite. Ciò significa che è improbabile che si abbia l'astrazione dell'interfaccia (ad esempio tutte le classi che eseguono la logica implementando un ILogicInterface, quindi è possibile testare le interfacce invece di provare a eseguire test su classi concrete).

Questo sarà un problema, dovrai fare test senza l'approccio standard di deridere le interfacce dipendenti (usando qualcosa come Rhino Mocks).

Suggerirei che il metodo migliore per te sia iniziare in piccolo: crea un solo assemblaggio "BllTests.Customer". Quindi, lentamente, sposta la tua implementazione per ereditare le interfacce, iniziando proprio nella parte inferiore del codice (l'astrazione dell'accesso ai tuoi dati è un ottimo inizio). Quindi unitamente prova i tuoi piccoli cambiamenti (stiamo parlando di 4-5 metodi all'interno di una singola classe). Quindi scegli la successiva piccola unità di logica e ripeti. Quando hai una buona porzione di codice che eredita le interfacce: inizia a suddividere il tuo codice in assembly separati: "Bll.Implementation" e "Bll.Interfaces".

Il potenziamento progressivo è il nome del gioco, non c'è molto da fare per testare il codice spaghetti, i test unitari saranno molto fragili o non testare abbastanza percorsi attraverso il codice per renderli utili indicatori se hai un problema di codice .

Se non riesci a modificare la base di codice principale (non sempre un'opzione), beh, suggerirei comunque l'approccio di più test assembly. Prova a fare in modo che tutto il nuovo codice venga eseguito in assemblaggi separati, per evitare che il tuo monolite si ingrandisca. Ma nel frattempo, mostra come un insieme di piccoli e coerenti assembly può essere molto più facile da gestire: dare l'esempio.

Vorrei ascoltare suggerimenti sulla separazione degli assembly di test dal codice di produzione e anche sulla suddivisione degli assembly di test in componenti o problemi separati. Inoltre, un server di Continuous Integration ti aiuterà a eseguire i tuoi test unitari per ogni build e ti riferirà quando i test delle unità falliscono, in modo che la build o i test possano essere indirizzati.

Ricorda che un vero test unitario dovrebbe essere indipendente dal sistema e testare una singola funzionalità di un singolo componente.

Hai menzionato i test di sistema che testano l'integrazione di vari componenti come database, servizi Web, risorse file, ecc ... specifici per un ambiente e non necessariamente per un singolo componente. Anche questi sono importanti, ma dovrebbero essere esclusi dall'integrazione continua in quanto, quando falliscono, potrebbero non mostrare necessariamente un codice o un problema logico. Questi errori dovrebbero principalmente indicare un errore di integrazione per un particolare ambiente, (come problemi di connessione al database, o non poter comunicare con un servizio web, o file non trovato, ecc ...)