Este artigo será de interese para aqueles que, como nós, se enfrontan ao problema de seleccionar un especialista axeitado no campo das probas.
Curiosamente, co aumento do número de empresas de TI na nosa república, só aumenta o número de programadores dignos, pero non de probadores. Moita xente está ansiosa por entrar nesta profesión, pero non moitos entenden o seu significado.
Non podo falar por todas as empresas de TI, pero asignamos o papel de QA/QC aos nosos especialistas en calidade. Forman parte do equipo de desenvolvemento e participan en todas as fases do desenvolvemento, desde a investigación ata o lanzamento dunha nova versión.
Un probador nun equipo, mesmo na fase de planificación, debe pensar en todos os requisitos funcionais e non funcionais para aceptar unha historia de usuario. Debe comprender as características operativas do produto, así como os programadores, e aínda mellor, e axudar ao equipo a non tomar decisións equivocadas mesmo na fase de planificación. O probador debe ter unha comprensión clara de como funcionará a funcionalidade implementada e cales poden haber trampas. Os nosos probadores crean eles mesmos plans de proba e casos de proba, ademais de preparar todos os bancos de proba necesarios. Probar de acordo cunha especificación preparada como un mono clicker non é a nosa opción. Traballando dentro do equipo, debe axudar a lanzar un produto digno e dar a voz de alarma a tempo se algo sae mal.
O que atopamos cando buscamos probadores
Na fase de estudo de moitos currículos, parecía que había especialistas con experiencia axeitada para nós e non habería problemas para escoller un probador para o noso equipo. Pero, durante as reunións persoais, atopámonos cada vez máis con candidatos que en realidade estaban bastante afastados do mundo da tecnoloxía da información (por exemplo, non podían dicir os principios de interacción entre un navegador e un servidor web, os conceptos básicos de seguridade, relacionais e non). bases de datos relacionais, non tiñan idea de virtualización e contenerización), pero ao mesmo tempo avalíanse a si mesmos no nivel Senior QA. Despois de realizar ducias de entrevistas, chegamos á conclusión de que o número de especialistas axeitados para nós na comarca é insignificante.
A continuación, contarei que pasos fixemos e que erros pisamos para atopar a eses tan esperados loitadores pola calidade.
Como tentamos arranxar a situación
Esgotados coa procura de especialistas preparados, comezamos a orientarnos ás áreas próximas:
- Intentamos aplicar prácticas de avaliación para identificar entre as moitas persoas "deixándoo", aquelas mesmas das que podemos desenvolver especialistas fortes.
Pedimos a un grupo de candidatos potenciais con aproximadamente o mesmo nivel de coñecemento que completasen tarefas. Observando o seu proceso de pensamento, tentamos identificar o candidato máis prometedor.
En particular, fixemos tarefas para probar a atención, a comprensión das capacidades da tecnoloxía e as características do multiculturalismo:
- Fixemos reunións para probadores para ampliar os límites de comprensión da profesión entre o continxente existente.
Vouvos falar un pouco de cada un deles.
Ufa Software QA and Testing Meetup #1 é o noso primeiro intento de reunir aos que se preocupan pola profesión e, ao mesmo tempo, entender se o público estará interesado no que queremos transmitirlles. Basicamente, os nosos informes foron sobre por onde é mellor comezar se decidiu converterse en probador. Axuda aos principiantes a abrir os ollos e mirar as probas como un adulto. Falamos dos pasos que deben dar os probadores novatos para incorporarse á profesión. Sobre o que é a calidade e como lograla en condicións reais. E tamén, que son as probas automáticas e onde é máis axeitado usalas.
Despois, cun intervalo de 1-2 meses, fixemos dúas reunións máis. Xa había o dobre de participantes. En "Ufa Software QA and Testing Meetup #2" mergullámonos máis na área temática. Falaron de sistemas de seguimento de erros, probas de UI/UX, tocaron Docker, Ansible e tamén falaron de posibles conflitos entre un programador e un probador e formas de resolvelos.A nosa terceira reunión, "Ufa Software QA and Testing Meetup #3", indirectamente relacionada co traballo dos probadores, pero foi útil para lembrar oportunamente aos programadores os seus deberes técnicos e organizativos: probas de carga, probas e2e, Selenium en probas automáticas, vulnerabilidades das aplicacións web. .
Durante todo este tempo estivemos aprendendo a crear luz e son normais nas emisións dos nosos eventos:
→
→
→ - E ao final decidimos tentar facer un hackathon para probadores
Como preparamos e realizamos un hackathon para probadores
Para comezar, tentamos comprender que tipo de "bestia" é e como se adoita levar a cabo. Como se viu, eventos deste tipo non se celebraron moitas veces na Federación Rusa e non hai onde tomar ideas prestadas. En segundo lugar, non quería investir de inmediato moitos recursos nun evento que a primeira vista parecía dubidoso. Polo tanto, decidimos que faremos mini-hackathons curtos, non para todo o ciclo de traballo de control de calidade, senón para etapas individuais.
A nosa principal dor de cabeza é a falta de práctica entre os probadores locais para crear mapas de probas claros. Non gastan tempo investigando historias de usuarios previas á implementación e creando criterios de aceptación claros para os desenvolvedores para os requisitos funcionais e non funcionais, UI/UX, seguridade, cargas de traballo e picos de carga. Por iso, decidimos, por primeira vez, pasar pola parte máis interesante e creativa do seu traballo: análise e formación de requisitos durante a investigación previa ao proxecto.
Estimamos o número potencial de participantes e decidimos que necesitábamos polo menos 5 atrasos para os lanzamentos de MVP, 5 produtos e 5 persoas que actuasen como propietarios de produtos, descifrasen as necesidades comerciais e tomaran decisións sobre restricións.
Aquí tes o que temos: .
A idea principal era elaborar temas o máis afastados posible do traballo diario dos participantes e darlles marxe para un voo creativo de imaxinación.
Que erros cometemos e que podemos facer mellor?
O uso de prácticas de avaliación, tan populares no ámbito da contratación de vendedores e xestores de nivel inferior, levou un esforzo enorme, pero non nos permitiu prestarlle a suficiente atención a cada participante e avaliar as súas capacidades. En xeral, esta opción de selección crea unha imaxe negativa da empresa, xa que moitas persoas reciben feedback insuficiente e, posteriormente, crean en si mesmos e outros o efecto da tiranía do empresario (as comunicacións nas comunidades informáticas están moi desenvolvidas). Como resultado, quedamos literalmente con dous potenciais candidatos cun futuro moi afastado.
As reunións son boas. Créase unha base extensa para a elaboración e aumenta o nivel xeral dos participantes. A empresa é cada vez máis recoñecible no mercado. Pero a intensidade laboral deste tipo de empresas non é pequena. Debes entender claramente que a celebración de reunións levará entre 700 e 800 horas persoais ao ano.
En canto ao hackathon de probas. Este tipo de eventos aínda non se volveron aburridos, xa que, a diferenza dos hackathons para desenvolvedores, celébranse con moita menos frecuencia. A vantaxe desta idea é que de forma relaxada podes intercambiar unha gran cantidade de coñecementos prácticos e determinar con bastante precisión o nivel de cada participante.
Despois de analizar os resultados do evento, decatámonos de que cometemos moitos erros:
- O erro máis imperdoable foi crer que 4-5 horas serían suficientes para nós. Como resultado, só a introdución e familiarización cos atrasos levou case 2 horas.
Traballar cos propietarios de produtos na fase inicial e o tempo para mergullarse na área temática levou a mesma cantidade de tempo. Polo tanto, o tempo restante claramente non foi suficiente para un desenvolvemento integral dos mapas de proba. - Non había tempo e enerxía suficientes para obter comentarios detallados sobre cada mapa, xa que xa era noite. Polo tanto, claramente fallamos nesta parte, pero inicialmente pretendíamos ser a máis valiosa do hackathon.
- Decidimos avaliar a calidade do desenvolvemento mediante un simple voto de todos os participantes, asignando 3 votos para cada equipo, que poderían dar para o traballo de maior calidade. Quizais sería mellor organizar un xurado.
Que conseguiches?
Resolvemos parcialmente o noso problema e agora temos 4 homes valentes e guapos traballando para nós, cubrindo a parte traseira de 4 equipos de desenvolvemento. Aínda non se notaron un grupo significativo de potenciais candidatos fortes e cambios tanxibles no nivel da comunidade de control de calidade da cidade. Pero hai algo de progreso e isto non pode menos que alegrarse.
Fonte: www.habr.com