Lasciate che vi racconti la mia storia. Potrebbe aiutare qualcuno che considera di avere o iniziare una carriera di QA.
Ho avuto esattamente 10 anni di esperienza nel QA. Ho iniziato come ingegnere di QA e sono finito come direttore di QA in quei 10 anni, il mio stipendio è più che raddoppiato lungo la strada. Sono stato fortunato perché il mio stipendio iniziale era alto. Era circa il 5% del percentile, e quando sono diventato un direttore veterano, il mio stipendio era nel 2% del percentile per il direttore del QA ed era sopra la media dello stipendio del direttore di ingegneria. Sembra una carriera di grande successo.
Ho ottenuto la mia laurea e MS in Informatica. Ho ottenuto la mia laurea da un'università sovrintendente e la MS da un'università che è tra le prime 10 scuole di ingegneria negli Stati Uniti. Durante gli anni del college, ho lavorato come sviluppatore freelance. Il QA di circa 10 anni fa era poco diverso dal QA di oggi. L'industria era per lo più concentrata sul QC (controllo qualità - pensate agli ispettori di fabbrica) e MS ha appena iniziato ad assumere un sacco di SDET. Google aveva un gruppo QA tradizionale - non il gruppo di produzione ingegneristica che prevale oggi. Ai miei occhi, il QA sembrava un mercato di nicchia. C'erano così tanti sviluppatori - io, per esempio, ero uno e circondato da loro. Ma non molti QA e sembrava che la domanda fosse alta mentre l'offerta si trascinava molto indietro. Questo è anche il periodo in cui Kent Beck ha proposto TDD. Sembrava tutto molto roseo.
Così mi sono promosso come ingegnere QA fuori dalla scuola. Il QA era in aumento e non c'erano molte persone con una laurea in CS in MS che volevano essere un ingegnere QA. (Tutti volevano essere sviluppatori) Mi sono trovato un lavoro come ingegnere del QA in una joint-venture ben finanziata. Sono stato anche pagato molto bene. Come primo lavoro fuori dalla scuola di specializzazione, stavo ottenendo circa 20k in più rispetto alle persone che avevano fatto test manuali per anni. Erano chiamati "analisti QA" e io ero un "ingegnere QA", gli analisti QA venivano promossi a ingegneri QA. L'automazione era una nuova parola d'ordine nell'industria del software. Il gruppo QA a cui appartenevo ha iniziato a guardare gli strumenti di automazione. Mentre ero alla scuola di specializzazione, ho scritto del codice JAVA per automatizzare i test noiosi dell'applicazione che il mio team di progetto aveva sviluppato. Non sapevo che quella fosse automazione, ma mi sono reso conto che'è quello che ho fatto nel mio primo lavoro. Ho iniziato a codificare alcuni script di test automatizzati. Nessuno poteva farlo nel mio gruppo. Sono stato promosso a capo del QA l'anno successivo.
Poi sono diventato la "persona tecnica" del gruppo. Il lavoro successivo che ho avuto è stato un manager QA hands-on. Il mio team è composto da ex-sviluppatori; uno di loro è stato convertito da sviluppatore a ingegnere di QA perché il suo ex-capo che lo voleva davvero nel suo team lo ha convinto. E ha convinto quest'altra ragazza della stessa scuola a convertirsi. L'automazione per il nostro team è stata facile. Abbiamo solo creato un framework di test che può accomodare le variazioni nei test e l'abbiamo fatto a pezzi. Poi, è iniziato l'hype Agile.
Essere ingegneri QA che sono stati sviluppatori nella vita passata ha un grande vantaggio. Contribuire alla qualità dei prodotti software spediti non significa solo trovare i difetti. In regime Agile, era ancora più ovvio. Non c'era posto per i test manuali. Il software è diventato sempre meno un pezzo d'arte ma sempre più una merce da vendere.
Mi sono trasferito in una grande azienda non tecnologica quando è arrivato il momento. La tecnologia non era il loro core business in questa azienda, ma volevano far crescere il team tecnico per sostenere il business. C'erano circa 40-50 persone nell'intero team tecnico quando sono entrato, e sono diventate circa 180 quando ho lasciato l'azienda 3 anni dopo. 30 di loro erano nel mio team. Sono diventato direttore nel giro di un anno da quando ho iniziato. Era circa il 20% di test manuali e l'80% di test automatici. Avevo un team di sviluppo dedicato alla costruzione di strumenti (che erano sviluppatori puri) nel mio dipartimento. Tutti nel mio team erano SDET e tutto il giorno creavano codici di test.
Poi mi sono annoiato molto molto. Mi sono trasferito in un'azienda startup pensando che potesse cambiare le cose. Non ha funzionato. Niente mi ha simulato intellettualmente. E poi mi sono anche stufato delle persone che pensano che il QA sia una cosa facile che chiunque può fare. O che la QA non sia qualcosa di essenziale per il business. È bene averlo, ma quando i soldi sono pochi, forse è una delle prime cose che può essere "licenziata" per risparmiare. Ci sono molte persone, specialmente nel mondo delle start up, che pensano che gli sviluppatori possano fare i test mentre i tester non possono fare il coding. Allora perché non assumiamo più sviluppatori per prendere due piccioni con una fava? Perché spendere soldi per il QA? Essendo il capo del QA per molto tempo, so quanto sia efficiente per il business avere un buon team di QA, posso anche quantificarlo. E questo è il motivo per cui le aziende di successo hanno un gruppo che si concentra sulla qualità - potrebbero non essere chiamati "QA" però, ha qualche sfumatura che non risuona con gli sviluppatori di alto livello che potrebbero trovare "QA" attraente. Ma ci sono persone che hanno solo paura di spendere soldi per il QA quando pensano di poter spendere quei soldi per gli sviluppatori - indipendentemente da quanto male possano essere gli sviluppatori. Ho visto molte occasioni in cui gli ingegneri del QA hanno dovuto dire agli sviluppatori esattamente quali linee di codice devono essere cambiate in cosa per risolvere certi difetti che hanno trovato. Ma bene, alcune persone che non hanno mai codificato professionalmente o alcuni dirigenti che non hanno mai visto un team di QA lavorare bene hanno questo pregiudizio verso il QA che il QA è uguale a spreco di denaro.
Se iniziate una carriera come QA come ingegnere, dovrete combattere le battaglie che ho combattuto io senza sosta. E se sei bravo, ti distinguerai facilmente - infatti, ci sono così tante persone "QA" che non dovrebbero fare QA. La deviazione standard è enorme nel QA e abbassa la media dello stipendio e la qualità delle risorse in modo significativo - lo stesso vale per gli sviluppatori, ci sono ancora più sviluppatori che non dovrebbero creare alcun codice.
Come nota a margine, però, se non sei tecnico, non sai codificare, ma vuoi essere nel mondo tecnologico, sarà più facile per te ottenere un lavoro come tester manuale QA che come sviluppatore. Ma il tester manuale QA è un lavoro che sta morendo. L'automazione sta prevalendo ed è davvero solo questione di tempo per sostituire il test manuale con l'automazione. Non sarò sorpreso se "QA" diventa obsoleto nel prossimo futuro. Immagino che anche gli sviluppatori diventeranno obsoleti, ma il QA se ne andrà prima. Ti consiglierei di considerare il Product Management; QA e Product management condividono molte caratteristiche simili e non c'è bisogno di codificare per fare il PM; ma nessuno ha bisogno di molti PM. 1 per squadra. Quindi è limitato, ma l'ingresso è facile. Ma una volta che la codifica diventa così comune, il PM avrebbe bisogno di codificare - ma non preoccupatevi: a quel punto, codificare sarà come usare excel.
Ho lasciato il mio lavoro come direttore di QA e sto riflettendo su me stesso per capire cosa voglio davvero fare dopo. Ho avuto una buona carriera e non mi pento di aver fatto il percorso che ho fatto. Spero che la mia storia - o un lungo libro di memorie - aiuti qualcuno che considera il QA come una carriera.