Que tipo de engenheiro de QA você é? Quality Assurance, ou Quality Assistance?

Na Atlassian é utilizada uma abordagem de Quality Assistance para QA, a fim de otimizar o processo de liberação para qualidade e velocidade. A Quality Assistance, inicialmente inventada por Cem Kaner, baseia-se na idéia de que um engenheiro de QA é um facilitador para a alta qualidade do produto, ao invés do indivíduo realizar os testes. Ajuda os desenvolvedores a criar qualidade em seus recursos desde o início, reduzindo os ciclos de trabalho e retrabalho que um engenheiro de qualidade e uma equipe de desenvolvimento tradicionais passarão.



Em um modelo de Quality Assurance, os objetivos de um membro da equipe de QA são bastante claros: testar o trabalho dos desenvolvedores antes de ser lançado, detectar bugs, comunicar descobertas e defender problemas para serem corrigidos. Com um modelo de Quality Assistance, há diferentes objetivos a serem focados, incluindo treinamento, ferramentas e ambientes para os desenvolvedores testarem, ajudando a simplificar e aprimorar práticas de desenvolvimento de software e prevendo problemas antes que eles se tornem problemas.

Em uma equipe de auto-eficiência cada membro da equipe pode ser invocado para fazer um ótimo trabalho em testes e os engenheiros de QA estarão focados na resolução dos grandes problemas. Esses objetivos exigem um conjunto específico de habilidades, que precisam ser praticadas para serem eficazes. Aqui estão 6 habilidades principais para começar a desenvolver:


1. Influência

Um pouco de influencia pelo caminho, para tornar Quality Assistance um modelo de trabalho. Você precisara convencer sua equipe a assumir a responsabilidade pela qualidade. Inclua o tempo de teste nas estimativas para o trabalho da story do desenvolvedor. Acabe com a expectativa de que outros vão pegar os erros.

Como praticar: 
Tornar-se um influenciador pode levar tempo - você tem que ganhar o respeito da equipe antes de sugerir mudanças. Certifique-se de que, o que você esta falando é valioso (ou seja, não dê sua opinião a sua equipe sem antes ter os fatos). Colete métricas, exemplos e evidências para ajudar nas tomadas de decisões. Aceite que você pode estar errado, e confiar com base na opinião dos outros para tomar boas decisões.



2. Experiência em Testes

Os desenvolvedores são especialistas em codificação, mas podem não ter muita experiência em testes. Uma vez que os desenvolvedores vão fazer os testes (e lembre-se, ganhe confiança em primeiro lugar), evite pedir-lhes para fazer tarefas desnecessárias.

Como praticar: 
Um testador qualificado é capaz de identificar rapidamente os riscos de uma determinada story ou feature. Isso vem de uma compreensão da implementação de recursos, e muitas vezes o desenvolvedor é a melhor fonte de informações. Você pode se tornar mais eficaz pedindo ao desenvolvedor para explicar os detalhes de implementação e fazendo perguntas sobre como ele iria lidar com vários cenários.

O teste exploratório é uma técnica valiosa, e é preciso prática. Um problema potencial com o modelo de Quality Assistance é que, ao fazer menos testes, o engenheiro de controle de qualidade se torna realmente enferrujado, então pode ser necessário encontrar maneiras de neutralizá-lo.



3. Habilidades de ensino

Os desenvolvedores podem testar bem, desde que sejam ensinados bem. Você pode treiná-los em habilidades específicas de teste, abraçar uma mentalidade de controle de qualidade e aumentar seu conhecimento de produto para torná-los melhores testadores.

Como praticar: 
Pense em como você aprendeu a testar e passe essa sua experiência. Crie workshops e sessões de prática para seus desenvolvedores. Estar disposto a dar conselhos e a responder perguntas quando eles tiverem dúvidas.



4. Inspiração

Se suas atividades de teste são tediosas, repetitivas e de baixo valor, então você está fazendo isso errado. Os desenvolvedores devem aprender a ver o teste como uma atividade valiosa, desafiadora e divertida - e estar aberto à mudanças de processo.

Como praticar: 
Por que você acha divertido testar? É o desafio do código, ou da pessoa que o desenvolveu? É a emoção de encontrar um caso obscuro, ou proteger seus clientes contra bugs desagradáveis?

Compartilhe suas motivações com a equipe. Certifique-se de que eles não vejam os testes como estúpidos, clicando aleatoriamente numa interface de usuário na esperança de tropeçar em alguns bugs. Se os desenvolvedores caírem nessa armadilha eles irão sentir que a atividade é um desperdício de tempo e vão executá-la mal.



5. Facilitação

A equipe precisa estar se comunicando bem e se ajudando, para obter padrões de alta qualidade. Você pode fazer isso acontecer definindo a barra de qualidade, organizando sessões de testes e garantindo que os desenvolvedores tenham as ferramentas certas, os dados corretos e os ambientes de que precisam para realizar seus testes de forma eficiente.

Como praticar: 
Configurar sessões de teste, onde você pede aos desenvolvedores para encontrar problemas com um recurso específico. Torne divertido e competitivo, trabalhe com os desenvolvedores para fazê-los pensar como um testador experiente faria.

Envolva todos nas conversas sobre se os bugs valem a pena ou não, e o raciocínio por trás deles. Deixe claro que você não é um perfeccionista que exige que cada questão trivial seja corrigida, chegue a um acordo coma equipe.



6. Identificar problemas

Enquanto os desenvolvedores realizam testes, você estará olhando para os problemas e criando oportunidades para melhorar a qualidade da equipe, eficiência e independência. Torne-se brilhante nas mudanças que você acha que são mais importantes para sua equipe, liderar sua implementação, e ser sincero na sua avaliação - para melhor ou pior.

Como praticar: 
As equipes devem ter feedbacks regulares, principalmete a cada sprint. Se sua equipe não fizer isso, então comece. Isso dá a você um fórum para levantar e discutir os problemas de uma equipe e é uma oportunidade ideal para iniciar a experimentação melhorias. Às vezes, os desenvolvedores estão relutantes em mudar, então esteja disposto a experimentar mudanças como experimentos e a abandonar a mudança se ela não fornecer os benefícios esperados. 

Nos vemos no próximo post! (grande sorriso)


Gostou do post? Compartilhe e siga nossas Redes Sociais 



Posts