Este artigo será do interesse de quem, como nós, se depara com o problema de selecionar um especialista adequado na área de testes.
Curiosamente, com o aumento do número de empresas de TI em nossa república, apenas aumenta o número de programadores dignos, mas não de testadores. Muitas pessoas estão ansiosas para entrar nesta profissão, mas poucas entendem o seu significado.
Não posso falar por todas as empresas de TI, mas atribuímos a função de QA/QC aos 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.
Um testador de uma equipe, mesmo na fase de planejamento, deve pensar em todos os requisitos funcionais e não funcionais para aceitar uma história de usuário. Ele deve entender as características operacionais do produto tão bem quanto os programadores, e melhor ainda, e ajudar a equipe a não tomar decisões erradas ainda na fase de planejamento. O testador deve ter uma compreensão clara de como a funcionalidade implementada funcionará e quais armadilhas podem existir. Nossos testadores criam eles próprios planos de teste e casos de teste, bem como preparam todas as bancadas de teste necessárias. Testar de acordo com uma especificação pronta, como um clicker de macaco, não é nossa opção. Trabalhando dentro da equipe, ele deve ajudar a lançar um produto digno e soar o alarme a tempo se algo der errado.
O que encontramos ao procurar testadores
Na fase de estudo de muitos currículos, parecia que havia especialistas com experiência adequada para nós e não haveria problemas em escolher um testador para nossa equipe. Mas, durante reuniões pessoais, encontramos cada vez mais candidatos que estavam, na verdade, muito distantes do mundo da tecnologia da informação (por exemplo, eles não sabiam dizer os princípios de interação entre um navegador e um servidor web, os princípios básicos de segurança, relacional e não- bancos de dados relacionais, eles não tinham ideia sobre virtualização e conteinerização), mas ao mesmo tempo se avaliaram no nível de controle de qualidade sênior. Depois de realizar dezenas de entrevistas, chegamos à conclusão de que o número de especialistas adequados para nós na região é insignificante.
A seguir, contarei quais passos tomamos e quais erros cometemos para encontrar aqueles tão esperados lutadores de qualidade.
Como tentamos consertar a situação
Depois de nos esgotarmos com a contratação de especialistas prontos, começamos a focar em áreas próximas:
- Tentamos aplicar práticas de avaliação para identificar, entre as muitas pessoas que “deixam”, aquelas mesmas a partir das quais podemos desenvolver especialistas fortes.
Pedimos a um grupo de candidatos em potencial com aproximadamente o mesmo nível de conhecimento para concluir tarefas. Observando seu processo de pensamento, tentamos identificar o candidato mais promissor.
Em particular, criamos tarefas para testar a atenção, a compreensão das capacidades da tecnologia e das características do multiculturalismo:
- Realizamos encontros de testadores para ampliar os limites de compreensão da profissão entre o contingente existente.
Vou contar um pouco sobre cada um deles.
O Ufa Software QA and Testing Meetup #1 é a nossa primeira tentativa de reunir aqueles que se preocupam com a profissão e ao mesmo tempo entender se o público terá interesse no que queremos transmitir a eles. Basicamente, nossos relatórios foram sobre por onde é melhor começar se você decidiu se tornar um testador. Ajude os iniciantes a abrir os olhos e encarar os testes como um adulto. Conversamos sobre as etapas que os testadores novatos precisam seguir para ingressar na profissão. Sobre o que é qualidade e como alcançá-la em condições reais. E também, o que é teste automático e onde é mais adequado utilizá-lo.
Depois, com intervalo de 1 a 2 meses, realizamos mais dois encontros. Já havia o dobro de participantes. No “Ufa Software QA and Testing Meetup #2” nos aprofundamos na área de assunto. Eles falaram sobre sistemas de rastreamento de bugs, testes de UI/UX, abordaram Docker, Ansible e também falaram sobre possíveis conflitos entre um desenvolvedor e um testador e maneiras de resolvê-los.Nossa terceira reunião, “Ufa Software QA and Testing Meetup #3”, indiretamente relacionada ao trabalho dos testadores, mas foi útil para lembrar oportunamente os programadores de suas funções técnicas e organizacionais: teste de carga, teste e2e, Selenium em autoteste, vulnerabilidades de aplicativos da web .
Durante todo esse tempo aprendemos como criar luz e som normais nas transmissões de nossos eventos:
→
→
→ - E no final decidimos tentar realizar um hackathon para testadores
Como preparamos e conduzimos um hackathon para testadores
Para começar, tentamos entender que tipo de “besta” é essa e como costuma ser realizada. Acontece que eventos deste tipo não foram realizados muitas vezes na Federação Russa e não há onde emprestar ideias. Em segundo lugar, não queria investir imediatamente muitos recursos num evento que parecia duvidoso à primeira vista. Portanto, decidimos que faríamos mini-hackathons curtos, não para todo o ciclo de trabalho de QA, mas para etapas individuais.
Nossa principal dor de cabeça é a falta de prática entre os testadores locais na criação de mapas de testes claros. Eles não perdem tempo pesquisando histórias de usuários pré-implementação e criando critérios de aceitação que sejam claros para os desenvolvedores quanto a requisitos funcionais e não funcionais, UI/UX, segurança, cargas de trabalho e picos de carga. Portanto, decidimos, pela primeira vez, passar pela parte mais interessante e criativa do seu trabalho - análise e formação de requisitos durante a pesquisa pré-projeto.
Estimamos o número potencial de participantes e decidimos que precisávamos de pelo menos 5 backlogs para lançamentos de MVP, 5 produtos e 5 pessoas que atuariam como proprietários de produtos, decifrariam as necessidades do negócio e tomariam decisões sobre restrições.
Aqui está o que temos: .
A ideia principal era apresentar temas o mais distantes possível do trabalho diário dos participantes e dar-lhes espaço para um voo criativo de imaginação.
Que erros cometemos e o que poderíamos fazer melhor?
A utilização de práticas de avaliação, tão populares na área de contratação de vendedores e gestores de nível inferior, exigiu muito esforço, mas não nos permitiu prestar atenção suficiente a cada participante e avaliar suas habilidades. Em geral, esta opção de seleção cria uma imagem negativa da empresa, uma vez que muitas pessoas recebem feedback insuficiente e, posteriormente, criam em si e nos outros o efeito da tirania do empregador (as comunicações nas comunidades de TI são muito desenvolvidas). Como resultado, ficamos literalmente com dois potenciais candidatos com um futuro muito distante.
Meetups são uma coisa boa. É criada uma extensa base de elaboração e o nível geral dos participantes aumenta. A empresa está se tornando cada vez mais reconhecida no mercado. Mas a intensidade de trabalho de tais empresas não é pequena. Você precisa entender claramente que realizar encontros levará aproximadamente 700-800 horas de trabalho por ano.
Quanto ao hackathon de testes. Esses tipos de eventos ainda não se tornaram enfadonhos, pois, diferentemente dos hackathons para desenvolvedores, são realizados com muito menos frequência. A vantagem dessa ideia é que de forma descontraída você pode trocar uma grande quantidade de conhecimentos práticos e determinar com bastante precisão o nível de cada participante.
Depois de analisar os resultados do evento, percebemos que cometemos muitos erros:
- O erro mais imperdoável foi acreditar que 4-5 horas seriam suficientes para nós. Como resultado, apenas a introdução e familiarização com os backlogs demoraram quase 2 horas.
Trabalhar com os proprietários do produto no estágio inicial e o tempo para mergulhar na área de assunto levou o mesmo tempo. Portanto, o tempo restante claramente não foi suficiente para um desenvolvimento abrangente dos mapas de testes. - Não houve tempo e energia suficientes para um feedback detalhado de cada mapa, pois já era noite. Portanto, falhamos claramente nesta parte, mas inicialmente pretendíamos ser os mais valiosos no hackathon.
- Decidimos avaliar a qualidade do desenvolvimento por meio de uma simples votação de todos os participantes, atribuindo 3 votos para cada equipe, que poderiam dar para um trabalho da mais alta qualidade. Talvez fosse melhor organizar um júri.
O que você conseguiu?
Resolvemos parcialmente o nosso problema e agora temos 4 homens bonitos e corajosos trabalhando para nós, cobrindo a retaguarda de 4 equipes de desenvolvimento. Um conjunto significativo de potenciais candidatos fortes e mudanças tangíveis no nível da comunidade de controle de qualidade da cidade ainda não foram notados. Mas há algum progresso e isso é uma boa notícia.
Fonte: habr.com