(In anticipo, non sono un esperto test o agile, sto solo cercando di spingerci a migliorare. Se mi sbaglio su qualsiasi cosa mi piacerebbe le opinioni del tuo ragazzo).
Quindi ho spinto affinché diventassimo un vero e proprio agile negozio e meno un "call ad hoc". Quindi sto provando iterativamente a migliorare il nostro processo. Ho scoperto che è stato buono costruire lentamente verso "fare bene": posso ottenere buy-in per piccoli cambiamenti o grandi cambiamenti da soli. Quindi abbiamo rallentato le iterazioni (circa un mese) che ho usato per piegare lentamente sempre di più. Il mio obiettivo personale è quello di portarci a un processo che supporta l'integrazione continua: a quel punto penso che possiamo fare cose come velocizzare le nostre iterazioni a costi molto più bassi.
Il prossimo bit che ho venduto al management su ciò che dobbiamo migliorare è il nostro test. Non abbiamo mai avuto una solida strategia di test, quindi mi piacerebbe iniziare a sviluppare le nostre capacità lì. Abbiamo già introdotto "Test Driven Development", utilizzando il framework Google Test (unit test), che ci ha portato molto lontano. Ma questi test unitari non sono sufficienti per testare il sistema nel suo complesso. Stiamo completando questo con il nostro vecchio modo di test, i test ad hoc del sistema e quelli funzionali che sono veramente specifici per il progetto, che vengono riscritti ogni volta e che non sono automatizzati. A peggiorare le cose, i nostri test funzionali e di sistema sono spesso più simili alle attività di caratterizzazione rispetto ai compiti pass-fail: i nostri strumenti di test funzionali / di sistema devono essere in grado di supportare il plotting e il crunching avanzati, il che significa che molti di essi sono in Matlab brivido .
Da quello che posso dire, un buon sistema di test automatizzato ha due parti: il Framework di test (qualcosa di simile al roboframework, ect) che capisce quali test eseguire, chiama quei test, orgamizza i risultati, ecc ... la cosa che effettivamente fa l'automazione. Questo utilizza lo strumento (i) di test, il dispositivo che esegue effettivamente il test. Potrei visualizzare questo messaggio errato, ma il Framework di test è come un enorme file batch e gli strumenti di test sono i test.
Quindi vedo due possibili modi per andare con "cosa fare dopo".
-
Implement (potrebbe scrivere da solo, anche se preferirei acquisire / modificare) un Framework di test. Lascia i nostri test di sistema ad-hoc, ma lascia che il framework prenda il controllo dell'automazione. L'obiettivo sarebbe avere un modo per colpire "Test" e fare eseguire tutti i test.
-
Scopri come utilizzare gli strumenti di test in modo più efficiente ed efficace.
Non sono sicuro di quale sia il modo migliore per andare qui o se uno dei seguenti argomenti:
- Facciamo entrambi lo sviluppo di windows e linux, anche se di solito non allo stesso tempo
- Mentre voglio concentrarmi su C ++, C con CMake, facciamo anche sviluppo C # e Matlab. La struttura ideale sosterrebbe tutti questi, anche se si tratta di strumenti diversi.
- I "tester", gli "automatori di test" e gli "sviluppatori" saranno tutti estratti dallo stesso gruppo di sviluppatori altamente competenti (per ora).
- Ho bisogno di supportare l'eseguibile e le librerie da riga di comando ora, ma vorrei supportare GUI (QT e .NET) in futuro.
L'ambito di 2 sembra ENORME, anche se fare 1 sembra come prima mettere il carrello davanti al cavallo. Ho un'immagine semi-accurata di cosa sta succedendo? Ho letto alcune cose che utilizzano Google Test come framework di test, ma non si adattano meglio alla definizione di strumento di test? Sto mordendo più di quanto possa masticare?