Hoje, o mundo celebra o dia do testador. Nesta ocasião, decidimos ajudá-lo a analisar o trabalho desses especialistas sob diferentes pontos de vista, para que a cooperação traga a todos os participantes o máximo benefício e o mínimo estresse.
Crédito da foto: David Goehring CC BY
1. "Verifique novamente, definitivamente não há bug"
Vamos começar com o problema fundamental. O fórum da Ars Technica tem um tópico antigo no qual um desenvolvedor fala sobre o ódio profundo dos testadores "pedantes". Ele está terrivelmente irritado porque alguns especialistas em testes passam horas procurando os menores bugs. E o que é mais desagradável, eles ainda os encontram.
O que poderia dar errado : nem todo mundo está pronto para admitir seus erros. Alguém começa uma música antiga sobre "não um bug, mas um recurso", tentando provar que tudo foi planejado. Outros pedem persistentemente que verifique o código e verifique se não há nenhum erro. O testador apenas tenta fazer bem o seu trabalho e, em vez de gratidão, é enviado para reexame.
Como ser : É simples: se o testador encontrou uma falha no seu código e você entende que ele está certo, é melhor admitir esse fato. Vocês dois têm o mesmo objetivo - lançar um produto depurado e funcional. O humor ajuda a chegar a um entendimento sobre esse assunto. Aqui está um artigo no qual os testadores reúnem um "fundo de ouro" de declarações de desenvolvedores que tentam proteger seu código. Aconselhamos que você os analise e imagine como essas frases "clássicas" soam do ponto de vista do testador.
2. “Uma semana antes do lançamento. Espero que você não tenha planejado outras coisas para os próximos dois dias. "
Às vezes, o código chega aos testadores alguns dias antes do lançamento. Então eles têm que trabalhar com pressa. Alguns especialistas em controle de qualidade acreditam que os colegas simplesmente subestimam seu trabalho. Alegadamente, eles acham que encontrar bugs é fácil e rápido, então adiam a depuração no último momento.
O que pode dar errado : em uma emergência, os testadores não apenas ficam aborrecidos, mas perdem a vigilância. A falta de tempo é um dos principais motivos pelos quais os testadores ignoram os erros.
Como ser : Existem vários modelos de desenvolvimento. Do ponto de vista do controle de qualidade, existem duas abordagens principais: cascata e Agile. No primeiro caso, os testadores recebem fragmentos de código em estágios. No segundo caso, eles testam o código em paralelo com a sua escrita.
O Agile ajuda a envolver os profissionais de controle de qualidade no projeto desde o início. Graças a isso, você não precisa testar "uma hora antes do lançamento". Além disso, essa abordagem permite não encontrar bugs, mas impedir sua ocorrência. Se seus testadores se queixam de pressão constante e perdem bugs, dê uma olhada nesta metodologia.
Foto: Tim Regan CC BY
3. “Eu rapidamente ajustei o código. Olha, por favor.
Suponha que sua equipe trabalhe em um modelo em cascata e saiba como planejar corretamente as fases de desenvolvimento. Os testadores obtêm o código e parece haver tempo suficiente para depuração. Mas os desenvolvedores têm o hábito de fazer um esforço mínimo nesse estágio. Eles recebem um relatório detalhado de erros, lêem-no superficialmente, eliminam rapidamente erros óbvios e enviam o código para o próximo ciclo de teste.
O que pode dar errado : O problema é que o código após alterações superficiais geralmente retorna com ainda mais erros. O testador passou um tempo preparando um relatório detalhado e, em resposta a ele, recebeu algum tipo de resposta. Ele tem que seguir esse caminho várias vezes apenas porque o desenvolvedor não quer gastar tempo com "pequenos bugs".
Como ser : Obviamente, não se apresse. Mas isso não é suficiente. Você precisa descobrir por que não está prestando a devida atenção ao relatório. Se isso é preguiça banal, somente você pode se ajudar. Existem outras razões. Por exemplo, você acha que os engenheiros de controle de qualidade o inundam com relatórios de bugs insignificantes. Então, você precisa esclarecer esta questão no nível de liderança - os testadores devem distraí-lo "nos detalhes". Provavelmente, a resposta será sim. Alguns gerentes de produto até pedem que os desenvolvedores adicionem especificamente pequenos bugs ao código, para que os testadores estejam sempre em guarda. É importante adotar essa abordagem e tratar os relatórios de erros com a devida atenção.
4. “Parece que eu já lidei com esse bug. Mas não me lembro exatamente "
Às vezes, uma abordagem superficial é um problema sistêmico. Em algumas equipes, os relatórios de erros são perdidos no tempo e no espaço. Ninguém está respondendo adequadamente aos relatórios, não sinalizando se o problema foi resolvido ou ainda está no limbo.
O que pode dar errado : os desenvolvedores corrigem algum tipo de bug, fazem o que acham que são “pequenas” alterações no código, esquecem de notificar os testadores sobre isso e enviam o código para o lançamento. Como resultado, o problema aparece quando é tarde demais. E o testador costuma ser o "extremo".
Como ser : O problema do caos precisa ser resolvido sistematicamente. A bagunça prejudica o desenvolvimento, então você precisa reestruturar completamente o processo de comunicação em uma equipe. Aqui vale a pena usar as dicas básicas para estabelecer comunicação entre desenvolvedores e engenheiros de controle de qualidade: para determinar a terminologia; formular claramente os requisitos; introduza uma hierarquia de prioridades para vários erros. Quanto à confusão com os bugs, existem boas dicas práticas: a) deixe que os bugs relatem tudo; b) então é importante priorizá-los; c) qualquer bug fechado implica que um teste funcional será escrito; d) o status "resolvido" é atribuído não pelo desenvolvedor, mas pelo testador. Essa abordagem garante que o problema seja realmente resolvido.
Foto: Tim Regan CC BY
5. “Por que devo testar isso? Eu não sou um testador!
Em algumas equipes, a responsabilidade pela depuração é inteiramente dos testadores. Os desenvolvedores não se preocupam em perder tempo com os testes de unidade mais óbvios. Eles têm certeza de que esse não é o trabalho deles. De maneira geral, é verdade, embora existam pontos de vista diferentes sobre o assunto (com os pontos de vista da comunidade podem ser encontrados aqui ).
O que poderia dar errado : os testadores nessa situação precisam lidar com todas as deficiências consecutivas - mesmo com os erros mais primitivos e estúpidos. Claro, isso é chato.
Como ser : muitos desenvolvedores preferem testes independentes antes de serem enviados ao departamento de controle de qualidade. Isso ajuda não apenas a aliviar os testadores, mas também a aprender a olhar para o produto do ponto de vista do crítico e do usuário. Acredita-se que isso seja útil para profissionais e tenha o melhor efeito no resultado final. Para aqueles que não querem se incomodar com cheques, existem ferramentas automáticas. Eles ajudam a encontrar os bugs mais óbvios. De qualquer forma, mesmo que a equipe tenha engenheiros de controle de qualidade, uma separação estrita entre desenvolvedores e controle de qualidade não é a melhor abordagem.
6. “Igor, hoje você trabalha em conjunto com Oleg. Você vai gostar
Os gerentes de produto não se limitam à abordagem em cascata e ao Agile. Alguns deles gostam de experimentar. Por exemplo, organize a programação em pares e as sessões de teste.
O que pode dar errado : Essa é uma maneira eficaz de detectar bugs, mas também tem desvantagens - as pessoas podem não estar entusiasmadas com as inovações. Um especialista em controle de qualidade, acostumado a trabalhar sozinho, em outro andar e em seu equipamento, pode simplesmente se sentir desconfortável ao deixar o ambiente familiar. Além disso, ele pode não ser banal com a experiência e o conhecimento de um parceiro. Como resultado, em vez de testes produtivos, os gerentes de produto recebem dois funcionários insatisfeitos.
Como ser : O principal conselho é não cortar o ombro. As práticas Agile e DevOps podem parecer atraentes, mas sem a preparação adequada, elas não funcionarão.
7. "Vou levar seu dispositivo para testes, você se importa?"
O desenvolvedor tem tempo para começar a depurar, ele pede ao testador um dispositivo de teste "literalmente por 20 minutos" e sai com ele por longas horas.
O que pode dar errado : Na maioria das vezes, o desenvolvedor não retorna o dispositivo ao seu lugar e, se o fizer, é completamente descarregado. Considerando que os testadores podem ter tarefas paralelas neste dispositivo, isso não pode deixar de irritar.
Como ser : coloque lembretes, cole adesivos, faça qualquer coisa, mas devolva as coisas dos testadores para o local e a tempo.
Foto: Dave Allen CC BY
E o principal conselho para desenvolvedores e gerentes de produto, que se sugere de todos os anteriores: respeite o trabalho e o tempo de outras pessoas e, sempre que possível, coloque-se no lugar de um testador. Afinal, se não fosse por ele, o mundo inteiro saberia sobre seus erros.