Questo articolo interesserà coloro che, come noi, si trovano ad affrontare il problema della selezione di uno specialista adeguato nel campo dei test.
Stranamente, con l'aumento del numero di società IT nella nostra repubblica, aumenta solo il numero di programmatori meritevoli, ma non di tester. Molte persone sono ansiose di intraprendere questa professione, ma pochi ne comprendono il significato.
Non posso parlare a nome di tutte le aziende IT, ma abbiamo assegnato il ruolo di QA/QC ai nostri specialisti della qualità. Fanno parte del team di sviluppo e partecipano a tutte le fasi dello sviluppo, dalla ricerca al rilascio di una nuova versione.
Un tester in un team, anche in fase di pianificazione, deve considerare tutti i requisiti funzionali e non funzionali per accettare una user story. Deve comprendere le caratteristiche operative del prodotto così come i programmatori, e ancor meglio, e aiutare il team a non prendere decisioni sbagliate anche in fase di pianificazione. Il tester deve avere una chiara comprensione di come funzionerà la funzionalità implementata e quali insidie potrebbero esserci. I nostri tester creano essi stessi piani di test e casi di test, oltre a preparare tutti i banchi di prova necessari. Testare secondo una specifica già pronta come un clicker scimmia non è la nostra opzione. Lavorando all'interno del team, deve contribuire a rilasciare un prodotto degno e dare l'allarme in tempo se qualcosa va storto.
Cosa abbiamo riscontrato durante la ricerca di tester
Nella fase di studio di molti curriculum, sembrava che ci fossero specialisti con l'esperienza adatta a noi e non ci sarebbero stati problemi con la scelta di un tester per il nostro team. Ma, durante gli incontri personali, incontravamo sempre più spesso candidati che in realtà erano piuttosto lontani dal mondo dell'informatica (ad esempio, non sapevano spiegare i principi di interazione tra un browser e un server web, i fondamenti della sicurezza, relazionali e non database relazionali, non avevano idea di virtualizzazione e containerizzazione), ma allo stesso tempo si valutavano a livello di QA Senior. Dopo aver condotto dozzine di interviste, siamo giunti alla conclusione che il numero di specialisti adatti a noi nella regione è trascurabile.
Successivamente, ti dirò quali passi abbiamo intrapreso e quali errori abbiamo commesso per trovare quei combattenti di qualità tanto attesi.
Come abbiamo cercato di risolvere la situazione
Dopo esserci esauriti nel reperire specialisti già pronti, abbiamo iniziato a prendere di mira le aree vicine:
- Abbiamo cercato di applicare pratiche di valutazione per identificare tra le tante persone che “lasciano tutto”, proprio quelle da cui possiamo sviluppare forti specialisti.
Abbiamo chiesto a un gruppo di potenziali candidati con approssimativamente lo stesso livello di conoscenza di completare le attività. Osservando il loro processo di pensiero, abbiamo cercato di identificare il candidato più promettente.
In particolare, abbiamo proposto compiti per testare l'attenzione, la comprensione delle capacità della tecnologia e le caratteristiche del multiculturalismo:
- Abbiamo organizzato incontri per i tester per espandere i confini della comprensione della professione tra il contingente esistente.
Ti parlerò un po 'di ciascuno di essi.
Ufa Software QA and Testing Meetup #1 è il nostro primo tentativo di riunire chi ha a cuore la professione e allo stesso tempo capire se il pubblico sarà interessato a ciò che vogliamo trasmettergli. Fondamentalmente i nostri resoconti riguardavano da dove è meglio iniziare se hai deciso di diventare tester. Aiuta i principianti ad aprire gli occhi e guardare i test come un adulto. Abbiamo parlato dei passaggi che i tester alle prime armi devono compiere per entrare nella professione. Su cos'è la qualità e come ottenerla in condizioni reali. E inoltre, cos’è il test automatico e dove è più opportuno utilizzarlo.
Poi, a distanza di 1-2 mesi, abbiamo tenuto altri due incontri. I partecipanti erano già il doppio. All'"Ufa Software QA and Testing Meetup #2" abbiamo approfondito l'argomento. Hanno parlato di sistemi di tracciamento dei bug, test UI/UX, hanno toccato Docker, Ansible e hanno anche parlato di possibili conflitti tra uno sviluppatore e un tester e di come risolverli.Il nostro terzo incontro, “Ufa Software QA and Testing Meetup #3”, si riferiva indirettamente al lavoro dei tester, ma è stato utile per ricordare tempestivamente ai programmatori i loro compiti tecnici e organizzativi: test di carico, test e2e, Selenium nell'autotest, vulnerabilità delle applicazioni web .
Per tutto questo tempo abbiamo imparato come creare luci e suoni normali nelle trasmissioni dei nostri eventi:
→
→
→ - E alla fine abbiamo deciso di provare a organizzare un hackathon per i tester
Come abbiamo preparato e condotto un hackathon per i tester
Per cominciare abbiamo cercato di capire di che tipo di “bestia” si tratta e come viene solitamente eseguita. Come si è scoperto, eventi di questo tipo non si sono svolti molte volte nella Federazione Russa e non c'è nessun posto dove prendere in prestito idee. In secondo luogo, non volevo investire subito molte risorse in un evento che a prima vista sembrava dubbio. Pertanto, abbiamo deciso di organizzare brevi mini-hackathon, non per l'intero ciclo di lavoro del QA, ma per le singole fasi.
Il nostro principale grattacapo è la mancanza di pratica tra i tester locali nel creare mappe di test chiare. Non perdono tempo nella ricerca di storie utente pre-implementazione e nella creazione di criteri di accettazione chiari agli sviluppatori per requisiti funzionali e non funzionali, UI/UX, sicurezza, carichi di lavoro e carichi di punta. Pertanto, abbiamo deciso, per la prima volta, di affrontare la parte più interessante e creativa del loro lavoro: l'analisi e la formazione dei requisiti durante la ricerca pre-progetto.
Abbiamo stimato il numero potenziale di partecipanti e abbiamo deciso che avevamo bisogno di almeno 5 arretrati per i rilasci MVP, 5 prodotti e 5 persone che agissero come proprietari dei prodotti, decifrassero le esigenze aziendali e prendessero decisioni sulle restrizioni.
Ecco cosa abbiamo ottenuto: .
L’idea principale era quella di proporre argomenti che fossero quanto più lontani possibile dal lavoro quotidiano di tutti i partecipanti e di dare loro spazio per un volo creativo con l’immaginazione.
Quali errori abbiamo commesso e cosa potremmo fare meglio?
L'uso di pratiche di valutazione, così popolari nel campo dell'assunzione di venditori e manager di livello inferiore, ha richiesto uno sforzo enorme, ma non ci ha permesso di prestare sufficiente attenzione a ciascun partecipante e di valutare le sue capacità. In generale, questa opzione di selezione crea un'immagine negativa dell'azienda, poiché molte persone ricevono feedback insufficienti e successivamente creano in se stessi e negli altri l'effetto della tirannia del datore di lavoro (le comunicazioni nelle comunità IT sono molto sviluppate). Di conseguenza, ci ritroviamo letteralmente con due potenziali candidati con un futuro molto distante.
I meetup sono una buona cosa. Si crea un'ampia base di elaborazione e il livello generale dei partecipanti aumenta. L’azienda sta diventando sempre più riconoscibile sul mercato. Ma l’intensità di lavoro di tali imprese non è piccola. Devi comprendere chiaramente che ci vorranno circa 700-800 ore di lavoro all'anno per organizzare gli incontri.
Per quanto riguarda l'hackathon di test. Questi tipi di eventi non sono ancora diventati noiosi perché, a differenza degli hackathon per sviluppatori, si svolgono molto meno frequentemente. Il vantaggio di questa idea è che in modo rilassato puoi scambiare una grande quantità di conoscenze pratiche e determinare con precisione il livello di ciascun partecipante.
Dopo aver analizzato i risultati dell'evento, ci siamo resi conto di aver commesso molti errori:
- L’errore più imperdonabile è stato credere che ci sarebbero bastate 4-5 ore. Di conseguenza, solo l'introduzione e la familiarizzazione con gli arretrati hanno richiesto quasi 2 ore.
Lavorare con i proprietari dei prodotti nella fase iniziale e il tempo per approfondire l'area tematica hanno richiesto lo stesso tempo. Quindi il tempo rimanente non era chiaramente sufficiente per uno sviluppo completo delle mappe di test. - Non c'erano abbastanza tempo ed energia per un feedback dettagliato su ciascuna mappa, poiché era già notte. Pertanto, abbiamo chiaramente fallito questa parte, ma inizialmente doveva essere la più preziosa nell'hackathon.
- Abbiamo deciso di valutare la qualità dello sviluppo tramite un semplice voto di tutti i partecipanti, assegnando 3 voti a ciascuna squadra, che avrebbero potuto dare per il lavoro di massima qualità. Forse sarebbe meglio organizzare una giuria.
Cosa hai ottenuto?
Abbiamo parzialmente risolto il nostro problema e ora abbiamo 4 uomini coraggiosi e belli che lavorano per noi, coprendo le retrovie di 4 team di sviluppo. Non sono ancora stati notati un bacino significativo di potenziali candidati forti e cambiamenti tangibili nel livello della comunità di QA della città. Ma qualche progresso c'è e questo non può che rallegrarci.
Fonte: habr.com