Aquest article serà d'interès per a aquells que, com nosaltres, s'enfronten al problema de seleccionar un especialista adequat en el camp de les proves.
Curiosament, amb l'augment del nombre d'empreses de TI a la nostra república, només augmenta el nombre de programadors dignes, però no de provadors. Molta gent té ganes d'entrar en aquesta professió, però poca gent n'entén el significat.
No puc parlar en nom de totes les empreses de TI, però hem assignat el paper de QA/QC als nostres especialistes en qualitat. Formen part de l'equip de desenvolupament i participen en totes les etapes del desenvolupament, des de la investigació fins al llançament d'una nova versió.
Un provador d'un equip, fins i tot en l'etapa de planificació, ha de pensar en tots els requisits funcionals i no funcionals per acceptar una història d'usuari. Ha d'entendre les característiques operatives del producte, així com els programadors, i encara millor, i ajudar l'equip a no prendre decisions equivocades fins i tot en l'etapa de planificació. El verificador ha de tenir una comprensió clara de com funcionarà la funcionalitat implementada i de quins inconvenients hi pot haver. Els nostres verificadors creen ells mateixos els plans de prova i els casos de prova, a més de preparar tots els bancs de proves necessaris. Provar d'acord amb una especificació ja feta com un clic de mico no és la nostra opció. Treballant dins de l'equip, ha d'ajudar a llançar un producte digne i sonar l'alarma a temps si alguna cosa va malament.
El que ens vam trobar quan buscàvem provadors
En l'etapa d'estudiar molts currículums, semblava que hi havia especialistes amb experiència adequada per a nosaltres i no hi hauria problemes per triar un tester per al nostre equip. Però, durant les reunions personals, ens vam trobar cada cop més candidats que en realitat estaven força allunyats del món de la tecnologia de la informació (per exemple, no podien explicar els principis d'interacció entre un navegador i un servidor web, els fonaments de seguretat, relacionals i no bases de dades relacionals, no tenien ni idea de la virtualització i la contenidorització), però al mateix temps s'avaluaven al nivell sènior de control de qualitat. Després de realitzar desenes d'entrevistes, vam arribar a la conclusió que el nombre d'especialistes adequats per a nosaltres a la regió és insignificant.
A continuació, us explicaré quins passos hem fet i quins errors hem trepitjat per trobar aquells lluitadors de qualitat tant esperats.
Com hem intentat arreglar la situació
Després d'haver-nos esgotat amb l'obtenció d'especialistes preparats, vam començar a orientar-nos a zones properes:
- Hem intentat aplicar pràctiques d'avaluació per identificar entre les nombroses persones "deixa't", aquelles mateixes a partir de les quals podem desenvolupar especialistes forts.
Vam demanar a un grup de candidats potencials amb aproximadament el mateix nivell de coneixements per completar tasques. Observant el seu procés de pensament, vam intentar identificar el candidat més prometedor.
En particular, vam plantejar tasques per provar l'atenció, la comprensió de les capacitats de la tecnologia i les característiques del multiculturalisme:
- Vam fer trobades per a provadors per ampliar els límits de comprensió de la professió entre el contingent existent.
Us parlaré una mica de cadascun d'ells.
Ufa Software QA and Testing Meetup #1 és el nostre primer intent de reunir els que es preocupen per la professió i alhora entendre si el públic estarà interessat en allò que els volem transmetre. Bàsicament, els nostres informes parlaven d'on és millor començar si heu decidit convertir-vos en provador. Ajuda els principiants a obrir els ulls i mirar com un adult. Hem parlat dels passos que han de seguir els testers novells per incorporar-se a la professió. Sobre què és la qualitat i com aconseguir-la en condicions reals. I també, què és la prova automàtica i on és més adequat utilitzar-la.
Després, amb un interval d'1-2 mesos, vam fer dues trobades més. Ja hi havia el doble de participants. A "Ufa Software QA and Testing Meetup #2" ens vam aprofundir en l'àrea temàtica. Van parlar sobre sistemes de seguiment d'errors, proves d'IU/UX, van tocar Docker, Ansible i també van parlar de possibles conflictes entre un desenvolupador i un provador i maneres de resoldre'ls.La nostra tercera reunió, "Ufa Software QA and Testing Meetup #3", es va relacionar indirectament amb el treball dels provadors, però va ser útil per recordar oportunament als programadors els seus deures tècnics i organitzatius: proves de càrrega, proves e2e, Selenium en prova automàtica, vulnerabilitats d'aplicacions web. .
Durant tot aquest temps hem estat aprenent a crear llum i so normals a les emissions dels nostres esdeveniments:
→
→
→ - I al final vam decidir provar de fer un hackathon per a provadors
Com vam preparar i dur a terme un hackathon per a provadors
Per començar, hem intentat entendre quin tipus de "bèstia" és això i com s'acostuma a dur a terme. Com va resultar, esdeveniments d'aquest tipus no s'han celebrat moltes vegades a la Federació de Rússia i no hi ha cap lloc on agafar idees. En segon lloc, no volia invertir immediatament molts recursos en un esdeveniment que a primera vista semblava dubtós. Per tant, vam decidir que faríem mini-hackatons curts, no per a tot el cicle de treball de QA, sinó per a etapes individuals.
El nostre principal mal de cap és la manca de pràctica entre els provadors locals per crear mapes de proves clars. No dediquen temps a investigar històries d'usuari prèvies a la implementació i a crear criteris d'acceptació clars per als desenvolupadors per a requisits funcionals i no funcionals, UI/UX, seguretat, càrregues de treball i pics de càrrega. Per tant, vam decidir, per primera vegada, passar per la part més interessant i creativa del seu treball: anàlisi i formació de requisits durant la investigació prèvia al projecte.
Vam estimar el nombre potencial de participants i vam decidir que necessitàvem almenys 5 endarreriments per a les versions de MVP, 5 productes i 5 persones que actuessin com a propietaris de productes, desxifrassin les necessitats empresarials i prenguessin decisions sobre les restriccions.
Això és el que tenim: .
La idea principal era plantejar temes el més allunyats possible de la feina diària dels participants i donar-los marge per a un vol creatiu d'imaginació.
Quins errors hem comès i què podríem fer millor?
L'ús de pràctiques d'avaluació, tan populars en l'àmbit de la contractació de venedors i directius de nivell inferior, va suposar un gran esforç, però no ens va permetre prestar prou atenció a cada participant i avaluar les seves capacitats. En general, aquesta opció de selecció crea una imatge negativa de l'empresa, ja que moltes persones reben un feedback insuficient i, posteriorment, creen en si mateixes i altres l'efecte de la tirania de l'empresari (les comunicacions a les comunitats de TI estan molt desenvolupades). Com a resultat, ens quedem literalment amb dos candidats potencials amb un futur molt llunyà.
Les trobades són una bona cosa. Es crea una àmplia base d'elaboració i augmenta el nivell general dels participants. L'empresa és cada cop més reconeguda al mercat. Però la intensitat laboral d'aquestes empreses no és petita. Heu d'entendre clarament que la celebració de reunions necessitarà aproximadament entre 700 i 800 hores de treball a l'any.
Pel que fa al hackató de proves. Aquest tipus d'esdeveniments encara no s'han avorrit, ja que, a diferència dels hackatons per a desenvolupadors, es fan amb molta menys freqüència. L'avantatge d'aquesta idea és que d'una manera relaxada es pot intercanviar una gran quantitat de coneixements pràctics i determinar amb força precisió el nivell de cada participant.
Després d'analitzar els resultats de l'esdeveniment, ens vam adonar que vam cometre molts errors:
- L'error més imperdonable va ser creure que 4-5 hores ens serien suficients. Com a resultat, només la introducció i la familiarització amb els endarreriments va trigar gairebé 2 hores.
Treballar amb els propietaris de productes en l'etapa inicial i el temps per aprofundir en l'àrea temàtica va prendre la mateixa quantitat de temps. Per tant, el temps restant no va ser suficient per a un desenvolupament integral dels mapes de proves. - No hi havia prou temps i energia per fer comentaris detallats sobre cada mapa, ja que ja era de nit. Per tant, clarament vam fallar aquesta part, però inicialment pretenia ser la més valuosa del hackathon.
- Vam decidir avaluar la qualitat del desenvolupament mitjançant un simple vot de tots els participants, assignant 3 vots per a cada equip, que podien donar per un treball de màxima qualitat. Potser seria millor organitzar un jurat.
Què has aconseguit?
Hem resolt parcialment el nostre problema i ara tenim 4 homes valents i guapos treballant per a nosaltres, que cobreixen la part posterior de 4 equips de desenvolupament. Encara no s'han notat un grup significatiu de candidats forts potencials i canvis tangibles en el nivell de la comunitat de control de qualitat de la ciutat. Però hi ha un cert progrés i això no pot menys que alegrar-se.
Font: www.habr.com