La mia azienda sviluppa sistemi embedded e hanno un progetto in cui stanno sviluppando una nuova piattaforma che sarà utilizzata per fare demo per i potenziali clienti. Introducono un nuovo concetto tecnologico e vogliono averlo come base per i nuovi prodotti, in modo che possano riutilizzare la maggior parte dei blocchi di codice generati e devono semplicemente configurare alcune parti dell'architettura e aggiungere applicazioni per i clienti.
C'è un gruppo di ingegneri che lavorano su di esso, un paio di loro per ogni competenza (SW / SYS / EE / Mech) e vogliono includerci (gruppo di test di sistema) per eseguire test su ogni versione. Il mio manager vuole includere test di integrazione per il nostro approccio e io sto guidando l'iniziativa.
Voglio dimostrare che dovremmo eseguire solo test di integrazione, poiché il software sviluppato non avrà un client specificato, i requisiti di sistema saranno generati dalle competenze SYS / SW. Il test del sistema è basato su req. documenti, quindi le implementazioni di test eseguite da SW rispetto ai requisiti scritti da SW / SYS porteranno a problemi non risolti (credo che SW non metterà in atto sforzi per modificare un'implementazione che hanno deciso di fare). Inoltre, la maggior parte dei Requisiti generati da loro sarà diversa da quella generata dal potenziale cliente (nel caso in cui decidessero di darci un progetto) in modo tale da portare solo a un lavoro duplicato.
I test di integrazione (tra moduli software, non HW-SW) ci porteranno a trovare problemi sull'architettura di base per i progetti futuri che utilizzano quella piattaforma e a trovare modi migliori per interfacciare tra le applicazioni che il cliente vorrebbe sul prodotto e il nostro sw e forniti da terze parti (HAL, RTOS, Servizi, ecc.).
Ho ragione? Quali sarebbero i tuoi criteri per decidere se Integrazione o Sistema (o entrambi)?