Este artigo será de interesse para aqueles que, assim como enfrentamos o problema de selecionar um especialista adequado no campo de testes.
Curiosamente, mas com o aumento do número de empresas de TI em nossa república, apenas o número de programadores dignos, mas não testadores, está aumentando. Muitos estão ansiosos por esta profissão, mas muitos não entendem seu significado.
Não posso dizer para todas as empresas de TI, mas atribuímos a função de QA / QC a nossos especialistas em qualidade. Eles fazem parte da equipe de desenvolvimento e participam de todas as etapas do desenvolvimento, desde a pesquisa até o lançamento de uma nova versão.
O testador da equipe, mesmo no estágio de planejamento, deve considerar todos os requisitos funcionais e não funcionais para aceitar a história do usuário. Ele não deve ser pior do que os programadores, ou ainda melhor, para entender as características operacionais do produto e ajudar a equipe a não tomar as decisões erradas no estágio de planejamento. O testador deve ter uma ideia clara de como a funcionalidade implementada funcionará e quais podem ser as armadilhas. Nossos testadores elaboram planos e casos de teste, além de preparar todos os suportes necessários para o teste. Testar de acordo com a especificação finalizada como um clicker de macaco não é nossa opção. Trabalhando dentro da equipe, ele deve ajudar a lançar um produto decente e acionar o alarme a tempo, se algo der errado.
O que encontramos ao procurar testadores
Na fase de estudar muitos currículos, parecia haver especialistas com experiência adequada para nós e não haveria problemas em escolher um testador em nossa equipe. Mas, em reuniões presenciais, fomos cada vez mais confrontados com candidatos que, na realidade, estavam muito distantes do mundo da tecnologia da informação (por exemplo, eles não sabiam os princípios de interação entre navegador e servidor da Web, princípios básicos de segurança, bancos de dados relacionais e não relacionais, não tinham idéia sobre virtualização e contentorização), mas, ao mesmo tempo, se avaliavam no nível do controle de qualidade sênior. Depois de mais de uma dúzia de entrevistas, chegamos à conclusão de que o número de especialistas adequados para nós na região é insignificante.
Em seguida, vou lhe dizer quais foram as medidas que fizemos e em que medida adotamos para encontrar os lutadores há muito esperados pela qualidade.
Como tentamos consertar a situação
Tendo sofrido com o fornecimento de especialistas prontos, começamos a filmar nas áreas próximas:
- Tentamos aplicar a prática de avaliação para identificar entre o grande número de “pessoas que fogem”, aquelas de quem podemos formar fortes especialistas.
Um grupo de candidatos em potencial, com aproximadamente o mesmo nível de conhecimento, nos foi oferecido para concluir tarefas. Observando seu processo de pensamento, eles tentaram destacar o candidato mais promissor.
Em particular, criamos tarefas para verificar a atenção, entender as capacidades das tecnologias e os recursos do multiculturalismo:
- Foram realizadas reuniões para os testadores expandirem os limites da compreensão da profissão para o contingente existente.
Vou falar um pouco sobre cada um deles.
O Ufa Software QA e Testing Meetup nº 1 é nossa primeira tentativa de reunir aqueles que não são indiferentes à profissão e, ao mesmo tempo, entender se o público estará interessado no que queremos transmitir a eles. Basicamente, nossos relatórios eram sobre por onde começar, se você decidisse se tornar um testador. Ajude os iniciantes a abrir os olhos e dar uma olhada nos testes em adultos. Conversamos sobre as etapas que os testadores iniciantes precisam seguir para ingressar na profissão. Sobre o que é qualidade e como alcançá-la em condições reais. E também o que é o teste automático e onde é mais apropriado aplicá-lo.
Além disso, com um intervalo de 1-2 meses, realizamos mais duas mitaps. Já havia duas vezes mais participantes. Na Ufa Software QA e Testing Meetup # 2, nos aprofundamos na área de assunto. Conversamos sobre sistemas de rastreamento de bugs, testes de interface do usuário / UX, abordamos o Docker, Ansible e também conversamos sobre possíveis conflitos entre o desenvolvedor e o testador e como resolvê-los.
Nossa terceira metapola, “Ufa Software QA e Testing Meetup # 3”, indiretamente, dizia respeito ao trabalho dos testadores, mas foi útil para lembrar aos programadores a tempo sobre seu dever técnico e organizacional: teste de carga, teste e2e, Selenium em autoteste e vulnerabilidades de aplicativos da web.
Durante todo esse tempo, aprendemos a produzir luz e som normais nas transmissões de nossos eventos:
→ Primeiras etapas do teste - QA Software QA e Testing Meetup # 1
→ Teste de interface do usuário / UX - Qfa Software QA and Testing Meetup # 2
→ Teste de segurança, Teste de carga e Teste automático - Ufa QA and Testing Meetup # 3 - E no final, decidimos tentar um hackathon para testadores
Como o hackathon foi preparado e realizado para testadores
Para começar, eles tentaram entender que tipo de "animal" é esse e como é geralmente realizado. Como se viu, eventos desse tipo na Federação Russa foram realizados não tantas vezes e não há lugar para emprestar idéias. Em segundo lugar, eu não queria investir imediatamente, em um evento duvidoso, à primeira vista, muitos recursos. Portanto, decidimos que realizaríamos mini hackathons curtos, não durante todo o ciclo de trabalho do controle de qualidade, mas para estágios separados.
Nossa principal dor de cabeça é a falta de testadores locais na formação de mapas de teste inteligíveis. Eles não dedicam tempo à pesquisa no estágio anterior à implementação de histórias de usuários e à criação de critérios de aceitação compreensíveis para desenvolvedores em requisitos funcionais e não funcionais, UI / UX, segurança, trabalho e cargas de pico. Portanto, decidimos, pela primeira vez, passar pela parte mais interessante e criativa de seu trabalho - análise e formação de requisitos para a pesquisa pré-projeto.
Eles estimaram o número potencial de participantes e decidiram que precisamos de pelo menos 5 pedidos em atraso para lançamentos de MVP, 5 produtos e 5 pessoas que atuarão como proprietários do produto, descriptografarão as necessidades do negócio e tomarão decisões sobre restrições.
Aqui está o que temos:
pedidos em atraso para o hackathon .
A idéia principal era apresentar tópicos que estão tão distantes do trabalho diário de todos os participantes e dar-lhes espaço para a imaginação criativa.
Que erros cometemos e o que pode ser feito melhor
A aplicação de práticas de avaliação, tão populares no campo de recebimento de vendedores e gerentes de nível inferior, consumiu uma quantidade enorme de energia, mas não nos permitiu prestar atenção suficiente a cada participante e avaliar suas habilidades. Em geral, essa opção de seleção cria uma imagem negativa da empresa, pois muitas pessoas recebem feedback insuficiente e, no futuro, formam o efeito da tirania do empregador (a comunicação nas comunidades de TI é muito desenvolvida). Como resultado, temos literalmente dois candidatos em potencial com uma perspectiva muito distante.
Aqui as mitapas são uma coisa boa. Está sendo criada uma base extensiva de estudo, o nível geral de participantes está sendo aumentado. A empresa está se tornando cada vez mais reconhecível no mercado. Mas, a complexidade de tais empreendimentos não é pequena. Deve-se entender claramente que aproximadamente 700-800 horas-homem levarão para realizar reuniões em um ano.
Quanto aos testadores de hackathon. Tais eventos ainda não tiveram tempo de ficar entediados, porque, diferentemente dos hackathons para desenvolvedores, eles são realizados com muito menos frequência. A vantagem desse empreendimento é que, de maneira inequívoca, você pode trocar uma grande quantidade de conhecimento prático e determinar com bastante precisão o nível de cada participante.
Após analisar os resultados do evento, percebemos que os montes cometiam erros:
- O erro mais imperdoável foi acreditar que 4-5 horas seriam suficientes para nós. Como resultado, apenas a introdução e o conhecimento de pendências demoraram quase 2 horas.
O trabalho com os proprietários dos produtos no estágio inicial e o tempo para mergulhar na área de estudo demoraram tanto. Portanto, o tempo restante claramente não foi suficiente para um estudo abrangente dos cartões de teste. - Não havia tempo e energia suficientes para um feedback detalhado de cada cartão, já que já era noite. Portanto, essa parte foi claramente reprovada por nós e era originalmente a mais valiosa do hackathon.
- Decidimos avaliar a qualidade do estudo com um simples voto de todos os participantes, alocando 3 votos para cada equipe que eles poderiam dar para um trabalho da mais alta qualidade. Talvez fosse melhor organizar um júri.
O que você conseguiu
Resolvemos parcialmente nossa tarefa e agora temos 4 homens bonitos e corajosos que cobrem a parte traseira de 4 equipes de desenvolvimento. Um conjunto significativo de possíveis candidatos fortes e mudanças tangíveis no nível de comunidade de controle de qualidade da cidade ainda não foram notados. Mas existem alguns progressos e isso não pode deixar de se alegrar.