Os autores do "Calendário do testador " de novembro foram Olya Fazulzyanova, testadora de Kontur.Ekterna, e Olya Izyuryeva, testadora de Kontur.Filling e organizadora de um curso de testadores. As meninas falaram sobre o teste em pares, sobre as tarefas que ajudam a resolver e deram um exemplo de uso mal sucedido da prática.

Existe uma prática na metodologia XP - programação em pares. Muitas fontes escreveram sobre a massa de suas vantagens: alta qualidade do código, intercambiabilidade de desenvolvedores, etc.

Se a programação de pares é tão eficaz, por que não aplicar princípios semelhantes nos testes? Sim, isso pode ser feito, o teste de pares existe há muito tempo e se provou bem. Mas não esqueça que qualquer prática é apenas uma ferramenta para resolver qualquer problema.

A Wikipedia não possui o termo "teste de pares", mas existe uma definição para a programação de pares, que pode ser tomada como base. Então, em nossa opinião, obtemos o seguinte.

O teste de pares é uma técnica na qual o teste de uma única funcionalidade é realizado por duas pessoas no mesmo local de trabalho. Um testador ("guia") controla o computador, o segundo ("navegador") monitora continuamente o trabalho do primeiro. Além disso, durante todo o trabalho na tarefa, eles trocam idéias e as discutem.

Qualquer prática é apenas uma ferramenta. Não queremos martelar as unhas com um microscópio; portanto, sempre partimos da tarefa. Vejamos as tarefas para as quais o uso da prática do "teste de pares" é relevante.

Tarefa: Tutoria

A qualquer momento, uma nova pessoa pode vir para a equipe. Expectativas da equipe em relação a ele - uma imersão bastante rápida na equipe e nas especificidades do projeto e, é claro, desempenho de alta qualidade de seu trabalho. Para tornar as expectativas rapidamente realidade, existe um processo de orientação em muitas empresas. Mas o que acontecerá se a mentoria for implementada através do teste de pares?

Um exemplo:

Um novo testador veio ao projeto, com experiência ou não, não importa. Você, como mentor, senta-se com ele em seu computador de trabalho e começa a construir o processo da seguinte maneira: no início, você tem um papel de liderança, e o objetivo principal é apresentar o iniciante aos processos do projeto e à área de assunto. O conhecido pode ser através de uma história, apresentação ou imediatamente através de testes conjuntos de tarefas.

Você pode começar discutindo a essência do problema, encontrando respostas para as perguntas e desenvolvendo um plano de teste. Quando tudo estiver pronto para o teste, você pega o teclado e o mouse e mostra como testar, e o iniciante observa. Ninguém proíbe a alteração de papéis e tarefas nas tarefas subseqüentes. O principal é não mudar a essência - teste conjunto de tarefas em uma estação de trabalho até que você esteja confiante em seu parceiro.

Lucro:

• O iniciante se adapta mais rapidamente à equipe. Ele tem um ponto de entrada - um mentor através do qual você pode conhecer o resto da equipe. Além disso, o novato formará uma idéia da área de responsabilidade dos colegas, porque durante a busca por respostas às perguntas, você o encaminhará imediatamente para as pessoas certas.
• Um iniciante descobrirá rapidamente uma nova área de assunto.
• Se um iniciante sem experiência em testes, aprenderá na prática sobre novas técnicas de teste e avaliará sua aplicabilidade.
• Há um compartilhamento de conhecimento: sobre processos de desenvolvimento, técnicas e ferramentas de teste.
• A visão do iniciante não fica embaçada, para que ele possa trazer novos cenários não padronizados.
• O Mentor determinará rapidamente o nível de preparação de uma nova pessoa. Isso ajudará a corrigir oportunamente o vetor de desenvolvimento, selecionando tarefas para ele.
• O líder de teste e / ou o gerente de desenvolvimento não se distrai com a adaptação do iniciante. O recém-chegado está em boas mãos e definitivamente não haverá problemas com a qualidade das primeiras tarefas.

Mini saída:

A prática é adequada se o parceiro é uma pessoa sem experiência e você precisa transformá-lo rapidamente de iniciante em especialista. Há um lucro ao trabalhar com um iniciante experiente: todo mundo aprende, incluindo um mentor. Afinal, cada pessoa trabalha à sua maneira e pensa de uma maneira única, usando suas próprias práticas e ferramentas.

Tarefa: treinamento avançado

Podemos encontrar o fato de que, para a conclusão bem-sucedida de nosso trabalho, precisamos ter conhecimento de especializações relacionadas: poder elaborar documentação, automatizar tarefas etc. Como criar competências de maneira rápida e barata? Entre em contato com um membro de sua equipe.

Um exemplo:

Você, como testador, tem uma tarefa mais apropriada para cobrir testes de unidade, mas não possui qualificações suficientes e vai ao desenvolvedor para obter ajuda. Você se senta com ele em um computador em funcionamento e começa a criar o processo da seguinte maneira: no início, o desenvolvedor deve desempenhar o papel principal, porque ele deve apresentar a você a base de código e os testes disponíveis. Em seguida, você cria scripts e começa a automatizá-los. O desenvolvedor escreve os primeiros testes, e você observa, e você já faz os próximos testes em suas próprias mãos.

Lucro:

• Você descobrirá rapidamente como o projeto funciona e quais testes já estão lá.
• Aprenda não apenas a escrever testes, mas a escrevê-los corretamente (estilo).
• O desenvolvedor expandirá suas idéias sobre cenários de teste, porque você mostrará como pensar fora da caixa.
• O desenvolvedor expandirá sua compreensão dos processos de teste, porque você o ensinará a verificar a qualidade de seu código antes de passar para o teste.
• A tarefa será coberta por autotestes em um período mais curto.
• Um gerente ou líder de equipe irá deliciar seu desejo de se desenvolver.

Mini saída:

Trabalhar em pares permite que você obtenha conhecimento em um novo campo de forma rápida e eficiente, corrigindo-os imediatamente na prática.

Tarefa: livrar-se da indispensabilidade ( fator de barramento )

Muitas vezes, existem pessoas em equipes - os únicos portadores de determinado conhecimento. Muitas vezes, um testador se torna uma pessoa assim, porque sabe tudo: cenários de usuário, como os serviços são implementados, o que precisa ser configurado para um teste e muito mais. Mas na vida existem situações que podem privar um projeto de uma fonte de conhecimento (demissão, férias, licença médica ...). Portanto, para minimizar as conseqüências, você pode jogar pelo seguro e compartilhar conhecimentos de uma cabeça para várias com antecedência. Como Através de testes de pares, é claro!

Um exemplo:

Como testador, você precisa envolver qualquer membro da equipe em suas tarefas, transferindo conhecimento sagrado. Você se senta com ele em um computador em funcionamento e começa a construir o processo da seguinte maneira: você sempre tem um papel de liderança; no início, você conta e / ou mostra as fontes de informação, atualizando, selecionando e analisando tarefas que ajudarão a consolidar o conhecimento adquirido.

Lucro:

• A pressão da responsabilidade diminui, você pode sair com segurança de férias, estágios etc.
• O trabalho em pares permitirá que você mude o contexto e dilua a rotina de um testador altamente especializado.
• O gerente é calmo, porque várias pessoas têm conhecimento e, com a saída de uma, o trabalho não surgirá.

Mini saída:

Se houver especialistas limitados, faça dupla prática para você. Aumenta a intercambiabilidade e a transferência de informações relevantes.

Tarefa: obter feedback

Se a equipe de teste é composta por várias pessoas, a prática de feedback é aplicável. O teste de pares é uma ferramenta adequada para o sistema operacional.

Um exemplo:

Você ou seu colega precisam de feedback. Você se senta com ele em um computador em funcionamento. Como você constrói o processo não é importante, o principal é trabalhar em conjunto.

Lucro:

• Você ou seu colega terão uma idéia sobre as habilidades de um parceiro.
• Você ou seu colega terão uma idéia do vetor de desenvolvimento com base no feedback.
• O feedback sobre os colegas será razoável, pois será apoiado por exemplos.

Mini saída:

As sessões emparelhadas dão aos testadores a oportunidade de observar o trabalho dos colegas, resultando em um feedback mais confiável.

Analisamos as tarefas que podem ser resolvidas pelo teste de pares.
Agora, vamos falar sobre a experiência real para ilustrar claramente as armadilhas que podem ocorrer ao usar esta prática.

Caso de vida ou não como nós

Em uma das retrospectivas da equipe de teste, os seguintes problemas foram identificados:

• trabalho desigual (o método e o tempo de teste de tarefas semelhantes dependiam muito de uma pessoa em particular);
• feedback muito vago um sobre o outro (geralmente apenas uma pessoa estava envolvida em uma tarefa e, no final de seis meses, não havia nada para escrever sobre muitos colegas, exceto que “Vasya faz seu trabalho bem, ele é responsável, responsivo e sociável”).

Tendo formulado esses problemas, nos propusemos as tarefas:

1. Troque experiências e identifique as melhores maneiras e ferramentas para testar tarefas semelhantes.
2. Crie as condições para a coleta de feedback mais detalhado.

Concordamos em usar a prática do teste de pares para resolvê-los.

Meu colega e eu embarcamos na mesma tarefa de teste.
A frente do trabalho era bastante volumosa, era necessária:

1. Entenda uma nova área de assunto.
2. Verifique as análises e descubra os cenários não contabilizados.
3. Prepare um ambiente de teste.
4. Prepare os dados do teste.
5. Faça casos de teste.
6. E teste no final :).

Tudo isso tinha que ser feito do zero.

Depois de nos sentarmos em um computador, começamos a ler análises. Concordamos em ler um parágrafo ou parte do texto e depois discutir as questões que surgiram e já lançam os primeiros casos de teste. Como a análise foi pouco desenvolvida e continha uma mistura de partes técnicas e de negócios, às vezes eram necessários de 15 a 20 minutos para discutir 10 linhas de texto. Além disso, para finalmente lidar com cada problema, foram necessários esclarecimentos do analista, desenvolvedor ou especialista em suporte técnico. Todas essas mensagens e cartas também foram escritas em pares.

A nova área de assunto era bastante complexa; portanto, a compilação de casos de teste exigia a criação de um ambiente complexo e a preparação de parte dos dados de teste. Também aqui havia muitas perguntas e esclarecimentos conjuntos.

Diante de tudo isso, decidimos desacelerar e realizar uma reunião para discutir o progresso do trabalho e o sucesso dos testes em pares.

Na reunião, percebemos que, tendo começado a aplicar a prática, esquecemos completamente o objetivo de seu uso. Toda a atenção estava concentrada apenas nos testes, ou melhor, até na preparação para isso, uma vez que não alcançou a execução dos casos de teste.

No decorrer do trabalho, não conseguimos realizar uma revisão completa um do outro, porque executamos todas as ações juntas, antes de discuti-las. Não percebemos a linha de pensamento e ação do parceiro ao executar uma nova tarefa. Também não foi possível trocar conhecimento, pois a área de assunto era nova para nós dois.

Estritamente falando, acabou por compartilhar conhecimento, mas estes eram triviais como:

• uso de novas teclas de atalho,
• usando alguns chips específicos para rastreadores de bugs,
• ...

Você pode compartilhar esse conhecimento sem recorrer a uma prática tão cara.

No final da reunião, tiramos conclusões para nós mesmos:

1. Aplicando a prática, não devemos esquecer as tarefas iniciais.
   Parece que no início tudo foi feito corretamente. Formulamos um problema, definimos tarefas, escolhemos uma ferramenta de solução, mas durante o trabalho em si, a ênfase mudou. No nosso caso, conseguimos apenas que dois testadores estavam envolvidos em uma tarefa.

   
   

2. Escolha suas tarefas de teste para que a prática seja aplicável.
   Uma tarefa nova, complexa e volumosa é pouco adequada para testes em pares:
   - é difícil treinar alguém;
   - não posso trocar experiência;
   - é difícil coletar feedback.

   
   

3. Não encoste os problemas.
   Assim que sentir que algo deu errado, fale imediatamente sobre o assunto, não espere pelo fim da tarefa ou pela retrospectiva final da equipe. Portanto, você pode entender rapidamente que a prática é aplicada incorretamente ou pode ser que ela não seja adequada para a solução do problema escolhido.

   
   

Existem muitas práticas diferentes. Qual deles usar no trabalho depende de você. Mais importante ainda, não se esqueça do motivo pelo qual você os utiliza e não use a prática por uma questão de prática.

PS Se você usou o teste de pares para outras tarefas em sua vida profissional, conte-nos sobre eles nos comentários.

Lista de artigos do calendário:
Tente uma abordagem diferente
Teste de par razoável
Feedback: como acontece
Otimizar testes
Leia um livro
Teste de análise
O testador deve pegar o erro, ler Caner e organizar a mudança.
Carregar serviço
Métricas de serviço de controle de qualidade
Teste de segurança
Conheça seu cliente
Receber lista de pendências