O Departamento de Garantia da Qualidade (QA) procura por erros no software. Os métodos variam de empresa para empresa, mas isso geralmente é feito por funcionários familiarizados com o software. Eles o usam de várias maneiras e tentam encontrar bugs que os desenvolvedores perderam.
O termo QA pode se referir ao processo em si, à organização e a um testador individual nessa organização. Normalmente, os testadores em uma organização de garantia de qualidade são chamados de "QA". Neste artigo, por questões de consistência, usaremos o controle de qualidade abreviado comum em vez do "testador de garantia de qualidade" mais preciso.
Empresas diferentes têm responsabilidades diferentes de controle de qualidade pela qualidade geral do produto. Às vezes, o termo "garantia de qualidade" não é totalmente aplicável a esse departamento se ele procurar apenas bugs e contar seu número.
A seguir, estão pessoas problemáticas no departamento de controle de qualidade:
Mangueira de incêndio
Um testador que relata tantos relatórios de erros tão rapidamente que a equipe de desenvolvimento nunca termina.
- Pode se transformar em alarmistas
- É perigoso em combinação com um gerente de projeto como estatísticas
- Probabilidade de correção: alta
- Perigo para o projeto: alto
O problema
Se um bug for encontrado, é importante fazer um relatório claro e atribuí-lo imediatamente ao desenvolvedor apropriado. No entanto, alguns testadores conseguem encontrar erros mais rapidamente do que a equipe de desenvolvimento os corrige. Por causa disso, a lista de bugs está em constante crescimento e todos eles nunca podem ser fechados.
À primeira vista, pode parecer que há um problema com a qualidade do produto, mas esse nem sempre é o caso. Ao contrário de um testador convencional, que trabalha com um programa de buggy, uma mangueira de incêndio gera uma avalanche de relatórios com uma ou mais propriedades características:
- Seus relatórios são mal detalhados, o que permite relatórios mais rápidos de mais erros.
- Muitos erros são duplicados de outros, pois são apenas variações de um motivo principal.
- Não há tempo para reproduzir o erro, pois basta vê-lo uma vez para escrever um relatório.
Os testadores de mangueira de incêndio geralmente aparecem sob pressão direta ou indireta da empresa:
quanto mais erros você encontrar, melhor o seu trabalho . Isso leva ao fato de que os testadores de controle de qualidade, que monitoram cuidadosamente a causa principal dos erros e os relatam de forma clara e concisa, são considerados menos produtivos do que as mangueiras de incêndio que emitem o número máximo de relatórios por unidade de tempo.
As atividades desses testadores podem causar pânico no projeto, porque parece que o produto é de baixa qualidade e o projeto está agora atrasado. Sua influência no moral pode ser imediata e dramática: a equipe de desenvolvimento ora para interromper o fluxo de relatórios de bugs.
Solução
Antes de consertar uma mangueira de incêndio, é vital identificá-la com precisão e não confundi-la com um controle de qualidade eficaz que colide com um sistema muito defeituoso. A evidência mais clara vem das reclamações dos desenvolvedores:
- A maioria dos erros são duplicados.
- Muitos bugs têm as mesmas causas óbvias, portanto, eles podem ser relatados como um bug.
- As mensagens de erro não contêm detalhes.
Para remediar a situação, a mangueira de incêndio deve ser explicada que não há incentivo para relatar um grande número de erros, e o objetivo é melhorar a qualidade do sistema e ajudar os desenvolvedores. Depois disso, a qualidade do produto deve melhorar no mesmo ritmo (ou melhor), mas sem pânico.
O promotor
O controle de qualidade, que após cada bug encontrado, acusa os desenvolvedores de não testarem seu programa.
- Pode se transformar em alarmistas
- É perigoso em combinação com um gerente de projeto como estatísticas
- Probabilidade de correção: alta
- Perigo para o projeto: baixo
O problema
Teoricamente, um desenvolvedor pode encontrar e corrigir qualquer bug antes de transferir o produto para o departamento de controle de qualidade. Portanto, alguns testadores percebem cada erro encontrado como outra prova de que os desenvolvedores não testam seu trabalho suficientemente bem. Esse argumento irrefutável permite que o promotor expresse ainda mais alto uma opinião desdenhosa sobre a equipe de desenvolvimento.
O promotor corroeu o moral da equipe. Em vez de ajudar a melhorar a qualidade do produto, ele tenta provar que a equipe de desenvolvimento não está fazendo o trabalho. Cada erro é adicionado à pilha de evidências de que os desenvolvedores confiam excessivamente no controle de qualidade, em vez de identificarem os erros por conta própria.
Infelizmente, os promotores são criados como resultado de um processo típico e bastante previsível:
- Um erro crítico foi detectado na produção.
- O testador é acusado de perder esse bug.
Isso acontece com muita frequência e, portanto, o controle de qualidade se defende naturalmente usando um argumento irrefutável.
Solução
Antes de corrigir um acusador, uma organização deve primeiro parar de culpar o controle de qualidade por erros de produção. Aqueles que fazem isso precisam ser treinados em métodos mais produtivos para melhorar a qualidade do software.
Quando a organização parou de culpar o controle de qualidade por erros na produção, você pode corrigir o acusador-testador convidando-o a mudar de idéia e de atitude.
Deve-se dizer a ele que os desenvolvedores são apenas pessoas, e todas as pessoas tendem a cometer erros. O departamento de controle de qualidade deve compensar essa propriedade humana natural dos desenvolvedores, atuando como proteção contra erros que afetam os clientes. Além disso, devido ao tedioso e tedioso processo de codificação, é muito fácil para um desenvolvedor não ver a floresta atrás das árvores: ele está tão concentrado em resolver um problema específico que se esquece de verificar coisas aparentemente óbvias.
Mudança de atitude: devemos lembrar que todos trabalhamos em equipe; os camaradas não devem se culpar por cometer erros, mas devem ajudar a corrigi-los para o bem da equipe. Para o controle de qualidade, é especialmente importante estabelecer parcerias com a equipe de desenvolvimento em prol do projeto, e o processo ininterrupto de detecção de bugs, relatórios e o ciclo de vida para corrigi-los é crucial para a qualidade do produto.
Alarmist
Controle de qualidade, que afirma que todo o produto possui um nível de qualidade inaceitável, enquanto sua opinião se baseia apenas em uma impressão superficial.
O problema
Na sua essência, diferentes recursos de aplicativos têm qualidade diferente. Alguns podem ser relativamente simples ou desenvolvidos por desenvolvedores altamente qualificados e, portanto, existem poucos ou nenhum erro. Outros são relativamente sofisticados ou desenvolvidos por desenvolvedores menos experientes - e, portanto, estão cheios de bugs. O alarmista não teve a sorte de encontrar imediatamente uma área de baixa qualidade - e
sem mais investigações, ele anunciou que todo o produto era inadequado .
Você pode falar muito sobre como os QAs cansam os desenvolvedores e desperdiçam seu tempo (consulte um testador do tipo
enganoso ), mas essa é uma situação dupla. De fato, com muita frequência, o desenvolvedor conscientemente oferece um controle de qualidade do software mal testado para obter uma recompensa pelo trabalho realizado ou afirmar que ele cumpriu o prazo. Quando o controle de qualidade começa a testar esse sistema, ele imediatamente encontra muitos erros que o desenvolvedor deveria ter visto. Portanto, é claro que ele extrapola o que viu em todo o produto e reivindica uma qualidade extremamente baixa.
Um alarmista geralmente tem alguma autoridade no departamento de controle de qualidade e sua opinião é respeitada. Quanto maior o nível de sua autoridade, mais destrutivo é o impacto no projeto. Um cenário típico é o seguinte:
- O produto é transferido para o controle de qualidade.
- Um alarmista começa a testar uma área de péssima qualidade.
- O alarmista interrompe todos os testes e informa as autoridades sobre um problema sério com a qualidade do produto.
Este é um caso clássico de jogar uma criança com água. Às vezes, o controle de qualidade faz a escolha certa, especialmente quando a equipe de desenvolvimento tem reputação de transferir software não verificado para o controle de qualidade. Mas acontece que o alarme disparou por causa de um desenvolvedor fraco, cujo código foi o primeiro a chegar a um criador de pânico.
Solução
Um testador se torna alarmista se tiver sido decepcionado repetidamente por uma equipe de desenvolvimento. Se ela sempre fornecesse software de alta qualidade, não haveria motivo para desconfiança. Mas se o testador se tornar um alarmista, será difícil para a equipe de desenvolvimento recuperar a confiança, especialmente se a equipe realmente tiver desenvolvedores um
elefante na loja de porcelana e
incompetente .
Normalmente, em grandes equipes de desenvolvimento, o código de baixa qualidade surge de desenvolvedores individuais, não de toda a equipe. Portanto, é imperativo que o trabalho de desenvolvedores menos competentes seja testado por último ou que não caia no alarmista. No entanto, isso oculta o verdadeiro problema de que há
desenvolvedores na equipe
que afetam negativamente o projeto .
Cientista
Um testador que passa a maior parte do tempo documentando erros, sem encontrar novos.
- Pode sofrer mutação nos oprimidos
- Perigoso quando combinado com um gerente de produto, como o autor da patente
- Probabilidade de correção: alta
- Perigo para o projeto: baixo
O problema
Encontrar problemas no sistema pode ser tão emocionante quanto a caça ao tesouro. E quando você encontra esse tesouro, não é menos interessante resolver o quebra-cabeça. Pode-se argumentar que um testador que considera o processo de encontrar erros dessa maneira é ideal. Mas surge um problema se ele procura documentar cuidadosamente sua fascinante jornada. Em vez de focar na questão principal, o desenvolvedor é forçado a ler uma longa história com muitos detalhes inúteis, tentando selecionar as informações relevantes.
O cientista percebe literalmente o requisito de "documentar cuidadosamente os bugs". Ele os descreve na forma de um histórico de texto, e não uma breve descrição com uma sequência clara de etapas para a reprodução. A leitura desses relatórios leva muito tempo e, no final, ainda não está claro qual é exatamente o problema. Normalmente, essa descrição inclui vários erros, enquanto se refere a uma ampla área do sistema, e não a um problema específico.
A principal reclamação dos desenvolvedores ao receber mensagens de erro dos cientistas é que a relação sinal / ruído é muito baixa. Eles passam o tempo vasculhando o fluxo da consciência, procurando detalhes específicos. Isso é uma perda de tempo para o desenvolvedor e o testador.
Solução
Um cientista de controle de qualidade é fácil de corrigir, ensinando-o a escrever os relatórios certos. Freqüentemente, a correção ocorre instantaneamente assim que explicam o que é exigido dele. A maneira mais eficaz de ensinar o estilo certo é reescrever um ou mais relatórios no formato correto, que servirá de modelo para o futuro. Como resultado, um testador entusiasmado escreverá relatórios claros e concisos de erros que não podem ser mais ideais.
Enganador
Um controle de qualidade, que geralmente relata erros incorretamente, leva o desenvolvedor da maneira errada quando ele tenta reproduzir e corrigir o problema.
- Pode se transformar em alarmistas
- É perigoso em combinação com um gerente de projeto como estatísticas
- Probabilidade de correção: alta
- Perigo para o projeto: alto
O problema
O relatório de erros deve incluir o seguinte:
- A capacidade de determinar se há realmente um erro
- Capacidade de definir etapas para reproduzir um bug
- Uma descrição completa do erro, geralmente com uma causa raiz
- Etapas claras para reproduzir um bug
Em qualquer um desses estágios, o relatório pode enganar o desenvolvedor, pelo que ele perderá tempo:
- Se não houver erro, o desenvolvedor gasta tempo procurando um problema que não existe
- Se o erro não puder ser reproduzido, o desenvolvedor gasta tempo com sua reprodução
- Se o erro não for descrito corretamente, o desenvolvedor gastará tempo procurando uma causa raiz muito específica ou muito ampla
- Se as etapas de reprodução forem imprecisas, o desenvolvedor gasta tempo tentando interpretá-las ou pode declarar nenhum erro, embora
Às vezes, um desenvolvedor fica confuso devido a um simples erro do testador. Mas um testador enganador geralmente gera esses relatórios, causando considerável descontentamento entre os desenvolvedores. Se a situação persistir, o testador acabará perdendo a confiança dos desenvolvedores e eles pararão de corrigir até os erros reais, rejeitando esses relatórios de erro.
Solução
O controle de qualidade enganoso geralmente é bom em encontrar bugs, apenas os documentando mal. Portanto, vale a pena o esforço para treiná-lo.
Um dos métodos mais eficazes é monitorar o desenvolvedor, que, com base em seu relatório, tenta identificar o problema. Simplesmente sente-se ao lado do desenvolvedor que recebeu um de seus relatórios e observe calmamente (sem interferência) como o desenvolvedor está tentando descobrir. Geralmente, isso leva a uma conversa saudável sobre a melhor forma de relatar bugs, o que beneficiará o desenvolvedor e o controle de qualidade.
Oprimido
O controle de qualidade, que é superado pelos desenvolvedores a tal ponto que é improvável relatar erros, temendo intimidação da parte deles.
O problema
Talvez não exista maior manifestação de indulgência do que a atitude típica dos desenvolvedores em relação ao controle de qualidade. Além disso, é comum ver que desenvolvedores agressivos intimidam abertamente o testador, mesmo que ele relate um erro natural em seu código. Para combater isso, um controle de qualidade bem-sucedido ao trabalhar com desenvolvedores agressivos deve ter as seguintes características:
- Já conquistou a grande confiança dos desenvolvedores, então seus erros são sempre levados a sério.
- Capaz de mostrar não menos agressividade e perseverança em uma disputa com um desenvolvedor que não reconhece o bug.
Infelizmente, muitos testadores não têm essas características; portanto, os desenvolvedores costumam se expor e acusam principalmente o controle de qualidade da detecção de um novo bug. Não importa o quão ilógico possa parecer, esta é uma imagem típica nas seguintes condições:
- O desenvolvedor tem um alto senso de importância pessoal (consulte um desenvolvedor como uma prima donna )
- O desenvolvedor acredita que sabe melhor do que o testador como o sistema funciona (consulte um desenvolvedor como um seqüestrador )
Depois que o controle de qualidade é superado com o tempo, geralmente evita o confronto com desenvolvedores hostis para reduzir o estresse. Como resultado, os erros desses desenvolvedores específicos raramente são relatados, embora possam existir. Como regra, uma situação é detectada apenas quando surgem problemas na produção e uma investigação começa por que o departamento de testes não detectou um bug. Um testador deprimido fornecerá uma das seguintes explicações:
- Ele conversou com o desenvolvedor e disse que isso não é um erro.
- Ele registrou um relatório de bug, mas o desenvolvedor o rejeitou.
- Ele encontrou um erro, mas "não achou importante o suficiente".
Um caractere passivo geralmente dificulta o reconhecimento de um controle de qualidade oprimido. A chave será analisar os desenvolvedores com quem o controle de qualidade trabalha - procurando sinais óbvios de hostilidade.
Solução
Os desenvolvedores frequentemente zombam diretamente dos testadores. Assim, eles devem ser tratados como qualquer hooligans:
- Exija que pare imediatamente de zombar do controle de qualidade e evite comportamentos agressivos.
- Treine a comunicação profissional.
- Ignore se o desenvolvedor não puder corrigir seu comportamento.
Em casos especialmente graves, o departamento de pessoal terá que intervir, principalmente se a situação degenerar em hostilidade aberta.
É triste que esta situação seja a norma e não a exceção. A única diferença é o grau de hostilidade.
Cliques aleatórios
Controle de qualidade que procura erros pelo método de clique aleatório.
O problema
A busca de bugs no sistema é realizada por dois métodos principais:
- De acordo com o plano de teste, processando metodicamente a lista de casos de teste.
- Vagando aleatoriamente pelo aplicativo na tentativa de emular as ações do usuário.
Escrever um plano de teste é uma tarefa demorada e não há garantia de que, quando o teste começar, o plano ainda será relevante após a alteração dos requisitos. Isso pode levar ao fato de que o testador abandona completamente os planos de teste e, em vez disso, apenas interage com o aplicativo na esperança de encontrar erros.
De fato, a interação acidental com o aplicativo revela erros, especialmente em um estágio inicial do desenvolvimento do produto. No entanto, à medida que o produto envelhece, encontrar erros dessa maneira será muito mais difícil, pois os erros restantes ficam ocultos em casos limítrofes. Isso leva a uma falsa sensação de segurança, como se o aplicativo não tivesse erros, embora simplesmente não tenha sido testado como deveria.
É importante lembrar que a interação aleatória com o aplicativo permanece uma metodologia aceitável, pois pode revelar situações que não estão documentadas no plano.
Mas isso é apenas uma adição ao plano de teste, não uma substituição.Solução
Um clicker aleatório pode aparecer em um dos dois casos:- Ele não foi ensinado a testar o aplicativo corretamente.
- Ele evita ativamente a elaboração de um plano de teste.
Se o problema for falta de treinamento, você precisará fornecê-lo. No entanto, nesse caso, o testador ainda pode se enquadrar na segunda categoria, sem querer fazer um plano de teste, mesmo que saiba que deve fazê-lo.Escrever um bom plano de teste requer um nível raro de organização, diligência e concentração. Como resultado, certos tipos de pessoas desfrutam desse trabalho, mas a maioria não. Se você tiver muita sorte, o clicker aleatório encontrará as características necessárias para escrever bons planos de teste, mas a probabilidade é pequena.Alegremente ousado
, -, .
O problema
Relatar corretamente um bug é um processo demorado e cognitivamente difícil, e alguns QAs não desejam se esforçar o suficiente. Como regra, estes são testadores com alguns direitos: eles acreditam que não precisam tentar selecionar palavras. Eles também costumam olhar com desdém para os desenvolvedores e não pensam que vale a pena gastar algum tempo em algum tipo de análise de erro: uma declaração geral é suficiente para que os desenvolvedores se atrevam a descobrir qual é o problema.Os relatórios de erros típicos de um testador descuidado contêm as seguintes frases:- "Não funciona."
- "Está quebrado de novo."
- "O problema seria óbvio se você realmente usasse esse recurso".
- "Não sei por que eles perderam."
- “Verifique com cuidado da próxima vez”
- "Não sei por que não podemos implementá-lo corretamente"
Obviamente, os desenvolvedores não estão muito satisfeitos com os relatórios que usam frases semelhantes em vez de etapas para reproduzir o erro. Isso raramente é feito por um analista de controle de qualidade profissional, mas geralmente é encontrado se outro funcionário da empresa que foi solicitado a procurar bugs reportar um erro. Isso geralmente acontece quando resta pouco tempo antes do lançamento e não há testadores suficientes. Como resultado dessa "ajuda", geralmente ocorre o caos, pois os relatórios são rejeitados pelos desenvolvedores, causando ainda mais controvérsia na equipe, o que aprofunda ainda mais a indignação.Solução
Em geral, os testadores profissionais devem ser responsáveis por encontrar bugs. Infelizmente, existe uma opinião no setor de que todos podem procurar bugs, mas isso não é verdade. É mais preciso dizer que qualquer pessoa pode detectar um erro, mas, como regra, apenas especialistas profissionais em controle de qualidade podem identificar erros importantes ocultos em situações limítrofes e relatá-los de forma que o desenvolvedor possa entender, reproduzir e, portanto, corrigir imediatamente esse bug.Um testador de ação descuidada acredita que tem todo o direito a esses relatórios frívolos. Se ele entrar no departamento de controle de qualidade, ele deve ser avisado para corrigir seu comportamento contraproducente. Se a busca por bugs não for de sua responsabilidade direta, ele deverá ser proibido de relatar erros até aprender a fazê-lo profissionalmente.Muitas vezes, é muito mais eficiente remover o testador descuidadamente ousado do que tentar consertá-lo. Por suas ações, ele definitivamente deixa claro que não deseja se envolver em testes, portanto, removê-lo é do interesse comum.Veja também: