Capisco che "devops" sia l'applicazione dei processi di sviluppo (rilevamento dei problemi, controllo delle versioni, gestione delle release ...) alle attività operative (distribuzione, migrazione ...).
Esiste un termine equivalente per l'applicazione dei processi di sviluppo alle attività del QA (test che solo un umano può eseguire, piuttosto che un test automatizzato o un'integrazione continua)?
Termini come DevOps sono soggetti ai capricci di un entusiastico marketing e consulenza popolare e fin troppo rapidamente diventano parole chiave "must have". Ma alla base di questo concetto è un concetto semplice: l'integrazione, il testing e lo sviluppo non frequenti del "big bang" sono processi costosi e dispendiosi in termini di tempo che generano antagonismo tra i team. Inoltre, a meno che gli sviluppatori non siano responsabili della correzione dei propri bug, una cultura di "funziona sulla mia macchina" deve essere affrontata continuamente.
Quindi non farlo in questo modo. Invece, automatizzare attività altamente ripetitive ed eseguirle frequentemente, fornendoci integrazione e implementazione continue, unità e altri test automatizzati. E rendere i team di sviluppo responsabili della manutenzione. Questi approcci sono efficienti, poco costosi e riducono l'animosità tra i gruppi.
Che cos'è DevOps è "l'applicazione dei processi di sviluppo ... alle attività operative". Questa è una visione delle cose molto semplicistica, orientata allo sviluppatore. Molte delle tecniche che DevOps fornisce a un'organizzazione sono nel risolvere i problemi con il processo di sviluppo.
Ma alla tua domanda:
Is there an equivalent term for the application of development processes to QA tasks (testing that only a human can perform, rather than automated testing or continuous integration)?
Le pratiche DevOps incoraggiano precoce, frequente, integrazione e test. Questo è ottenuto tramite test automatici. Quando collaborano sviluppatori e tester, i test automatizzati possono coprire la maggior parte di ciò che tradizionalmente veniva visto come "lavoro del QA", ovvero lavorare attraverso script di test, ripetendo manualmente gli stessi test più e più volte. Invece, i tester sono lasciati liberi di eseguire test esplorativi, cioè seguendo il loro istinto nel trovare bug meno ovvi, piuttosto che attenersi a uno script.
Non c'è "DevTest" perché non è necessario. Questo è già coperto da DevOps.
DevOps non è "l'applicazione dei processi di sviluppo alle attività operative". Ci sono alcune interpretazioni diverse su cosa sia DevOps, ma lo descrivo come una mentalità o cultura in cui l'implementazione, le operazioni e la manutenzione di un sistema sono considerate in tutto lo SDLC.
L'idea di "DevTest" o "DevQA" esiste già. Si chiama Agile, come definito dal Manifesto per lo sviluppo di software agile e Dodici principi dietro il manifesto agile . Sebbene il Manifesto Agile non sia l'unico modo per abbattere i silos in un'organizzazione, è probabilmente uno dei più comuni.
Per capire questo, dovresti tornare indietro nel tempo. Nei giorni in cui i modelli basati su piani erano visti come il modo di costruire software, si avrebbero dei silos. A seconda delle organizzazioni, i silos sarebbero diversi, ma sarebbero spesso basati sulle fasi di SDLC - avresti un team di requisiti che ha trasformato le esigenze degli stakeholder in una specifica, un'architettura e un team di progettazione che ha trasformato i requisiti in un design specifica, un team di codifica che prendeva le specifiche di progettazione e le trasformava in codice, un team di test che prendeva il prodotto costruito e lo testava, quindi un team di rilascio o di operazioni che avrebbe preso il sistema e lo avrebbe implementato ed eseguito.
Ma non è stato efficiente. L'idea di "lanciare il lavoro oltre il muro" alla squadra successiva ha portato solo a ritardi nella comunicazione, rielaborazioni e altri sprechi e lentezza nel ciclo di sviluppo. I vari metodi Agile lo hanno capito e hanno cercato di abbattere i muri dello sviluppo del prodotto e hanno richiesto team interfunzionali: quasi tutti i processi agili (XP, Scrum, Disciplined Agile Delivery e così via) richiedono un team interfunzionale che contiene tutte le conoscenze e l'esperienza necessarie per fornire software di lavoro su base regolare.
Tuttavia, agli inizi di quello che sarebbe diventato il metodo Agile (la fine degli anni '80 e '90), le operazioni erano diverse da quelle attuali. I progressi nella virtualizzazione, nella containerizzazione, nell'infrastruttura come codice (e nella capacità di gestire più facilmente la configurazione dell'infrastruttura) e nel cloud computing hanno cambiato il modo in cui le attività operative potrebbero essere svolte. Questi progressi e cambiamenti hanno portato alla capacità di abbattere i silos tra l'organizzazione di sviluppo prodotto (business e prodotto, sviluppo, test, assicurazione qualità) e il team operativo.
Tornando al Manifesto Agile e ai principi che ne sono alla base, alcuni dei principi sarebbero un po 'diversi nella cultura DevOps:
Business people, developers, and operations staff must work together daily throughout the project.
Working software and the infrastructure it runs on is the primary measure of progress.
The best architectures, requirements, and designs, and infrastructures emerge from self-organizing teams.
Il modo in cui questo si manifesta dipende dall'organizzazione di sviluppo. Potrebbe trattarsi di un team operativo continuo che è coinvolto nello sviluppo continuo come forma di ruolo specialistico. Potrebbe significare che gli esperti delle operazioni vengono assegnati a ciascun team per supportare le attività del team. Potrebbe anche significare che uno o più membri dei team di sviluppo hanno un certo livello di formazione incrociata nel lavoro delle operazioni. O potrebbe essere una combinazione di questi.
Sì, ho visto il termine "Sviluppatore in prova" e simili. Significa impiegare sviluppatori per testare cose.
Questo si riduce alla scrittura di test automatizzati, in genere UI o test "funzionali" eseguiti sul prodotto finito effettivo piuttosto che su test di integrazione o unità.
Se il termine non ha acquisito tanta popolarità come devops, probabilmente perché è diventato così onnipresente.
Essere un "tester" in questi giorni significa scrivere test automatici, il che significa che sei tanto un programmatore quanto gli sviluppatori.
Non ho mai sentito parlare di "DevTest" o "DevQA". Non sono sicuro di come sarebbe.
In DevOps, dovresti sfruttare il concetto di Continuous Delivery. In quanto tale, il tuo test e il processo di QA sono integrati. Idealmente, sarai in grado di costruire, testare, distribuire le tue app in modo rapido e automatico.
Per quanto riguarda la domanda di test tra umani e automatici. Quando si effettuano test umani nella pipeline di consegna, non vedo perché il processo cambierebbe. Devi semplicemente eseguire i test manuali nella tua pipeline.
Due libri su DevOps che personalmente ho trovato utili:
The Phoenix Project, Un romanzo su IT, DevOps e Helping Your Business Vincere per Kevin Behr, George Spafford & Gene Kim
Manuale di DevOps: come creare agilità, affidabilità e sicurezza di livello mondiale nelle organizzazioni tecnologiche di Gene Kim, Patrick Debois, John Willis, Jez Humble & John Allspaw