L'integrazione continua è una best practice di per sé, il cui obiettivo principale è quello di assicurare che il tuo codice venga assemblato correttamente e superare i test di unità e integrazione.

CI dovrebbe succedere continuamente indipendentemente dalle modifiche (non sporadicamente solo quando si verificano cambiamenti). Questo è particolarmente importante per i progetti coinvolti nella distribuzione e nella consegna continua.

I test possono fallire in qualsiasi momento durante il processo CI. Diciamo che i contratti di terze parti API potrebbero essere stati modificati o potrebbero aver smesso di funzionare. O peggio ancora, qualcuno potrebbe aver cambiato l'RDM. Queste cose accadono più spesso di quanto pensiamo. Applicando continuamente il nostro codice per superare i test, ci aspettiamo dei problemi imprevisti prima delle versioni o delle distribuzioni.

Per quanto riguarda il tuo ruolo di tester, Q & Gli sviluppatori sono focalizzati sulla convalida delle funzionalità end-to-end e dell'esperienza degli utenti piuttosto che sul codice. Contribuiscono allo SDLC con test end-to-end manuali o automatizzati, in modo che se gli sviluppatori cambiano, rimuovano o aggiungano nuove funzionalità al progetto, ciò viene comunque realizzato con il suo scopo principale nelle premesse concordate. Test di accettazione .

Q & Gli sviluppatori sono in qualche modo un cliente molto esigente. Meno sono familiari con il codice, meglio è perché i test non saranno influenzati dai dettagli di implementazione.

I test automatizzati sono integrati nella pipeline di implementazione, contribuendo a CI e CD.

Dal punto di vista DevOps, non c'è un ruolo A o B, c'è una squadra in cui tutti fanno test, sviluppano, si occupano della qualità e dell'integrità del progetto.

Test di accettazione

Seguendo i tuoi commenti relativi a come automatizzare i test di accettazione, alla mia ultima esperienza abbiamo 3 possibili approcci

1. Test manuali

Bene, fai solo test manuali. Eseguiamo questi test in piccoli progetti. Per noi, piccolo significa 1-5 schermi. Qui, la documentazione è tua amica. Ottieni documentato il caso d'uso da eseguire e il risultato atteso. Esegui il caso d'uso nell'ordine corretto e controlla il risultato.

2. Automatizza il test: orientato agli eventi della macchina

In poche parole. Selenio. L'idea dietro Selenium è quella di imitare il browser. Ne più ne meno. Dieci anni fa era relativamente fattibile perché i browser web non erano così sofisticati come lo sono oggi. Né erano le applicazioni web. Le applicazioni web di oggi sono molto più complesse, sono piuttosto basate su eventi, più dinamiche e il rendering non è più sequenziale. Il selenio non si adatta bene in tali condizioni. Le metodologie agili non aiutano qui perché i cambiamenti avvengono più spesso e alcuni di essi potrebbero portarci a ridigitare l'intero automatismo.

3. Automatizza il test, orientato all'azione umana

Recentemente abbiamo iniziato a giocare con Computer vision e abbiamo ottenuto ottimi risultati. Non è esente da carenze ed è molto più complesso farlo funzionare. Ad esempio, dobbiamo raggiungere pixel perfetti per ogni possibile risoluzione, per ogni possibile S.O, per qualsiasi dispositivo possibile. Dobbiamo inoltre implementare un X-server per eseguire il rendering del browser Web su un server remoto quando questi test vengono eseguiti da Jenkins.

Questo articolo potrebbe interessare tu. Abbiamo implementato Skulli come motore di visione artificiale. I nostri test vengono eseguiti contro le applicazioni implementate che vengono monitorate durante l'intera fase di test da Jacoco, quindi possiamo determinare il grado di copertura del caso d'uso.

Non tutti i test dovrebbero subire modifiche come quelle che stai descrivendo. Ad esempio, i casi di test di accettazione non devono fallire se un costruttore cambia - devono cambiare solo quando cambiano i requisiti. I tester dovrebbero concentrarsi sulla scrittura di casi di test automatizzati che verificano requisiti e test che proteggono dalla regressione. Questi casi di test automatizzati dovrebbero essere eseguiti su un sistema completamente integrato il più vicino possibile alla produzione possibile.

Gli sviluppatori dovrebbero essere responsabili della scrittura di unit test per il loro codice e sono responsabili dell'aggiornamento di questi test mentre apportano modifiche.

Penso che la domanda debba essere chiarita un po ', ma qui c'è il nocciolo di una / alcune buone domande. Prendendo i tuoi punti a turno:

When we are developing a software supported by continuous integration (CI), I imagine 3 roles working together...

Non ho mai visto questo particolare mix prima di YMMV ...

My problem is that I have no experience as a tester and I don't understand how is it possible to create automatic tests that will withstand any change in the merges added by the developers.

Non tutto può essere coperto da test automatici, quindi non preoccuparti di questo. C'è anche una differenza tra test unitari e test di integrazione.

For example, in a strongly typed language such as Java, creating a new injectable dependency to a Class must screw up so many tests because the constructor of that class would be changed.

Se un piccolo cambiamento rompe molti test, questo tende a indicare vari problemi come la fragilità del codice, l'accoppiamento stretto ecc. Parla con i tuoi sviluppatori e / o architetti.

My point is: for most changes in code there must be changes in the tests, so what's the point of CI here?

Il punto di CI è che il codice fallisce rapidamente e quindi i problemi vengono identificati in anticipo. Confrontalo con le pratiche di un tempo in cui le build sono avvenute quotidianamente, settimanalmente o anche meno frequentemente e non è difficile capire quanto sia utile per gli sviluppatori. Inoltre, elimina in gran parte le puntature del dito poiché lo sviluppatore può vedere che ha rotto la build e se ne sta occupando più o meno immediatamente senza trattenere i colleghi.

Why CI if changes in code will mostly end up in changes on the tests?

Anche se è solo il codice di test che stava fallendo, vorresti comunque eseguire nuovamente la suite poiché i criteri per una build di successo saranno cambiati.

Lo scopo principale dell'IC è di prevenire i problemi di integrazione. ( Wikipedia )

es Lo sviluppatore A apporta una modifica su una parte del sistema e 1 giorni dopo lo sviluppatore B apporta una modifica su un'altra parte del sistema, lo sviluppatore B non dovrebbe apportare modifiche inconsce che interferiscono con le modifiche dello sviluppatore A.

Questo è uno dei poteri del test. Lo sviluppatore B può essere certo di non apportare modifiche accidentali alla funzione dello sviluppatore A.

Un test che fornisce consapevolezza e sicurezza che cambia, non interferisce con altre funzionalità.

D'altra parte, è anche utile per un singolo sviluppatore mantenere un'app per lunghi periodi di tempo. A meno che tu non abbia una buona memoria, non saprai mai che rimuovere http://example.com/api/v1/users endpoint, farebbe sì che 24 utenti che usano la nostra vecchia app mobile rilasciata 3 anni fa non possano accedere alla nostra applicazione.

Ma se sono attese le modifiche sull'altra funzione, allora è ok cambiare il test.

Se hai spesso bisogno di cambiare un test ogni funzione aggiuntiva, probabilmente è un allarme che crei un test scadente.