Como diminuir os erros antes de testar?

Brian Mackey está certo sobre o TDD ser útil - e qualquer teste unitário irá melhorar as coisas drasticamente. Como testador, posso dizer a você que um conjunto completo de testes de unidade reduz drasticamente o número de bugs, e limita os bugs funcionais restantes a algumas áreas previsíveis nas quais posso concentrar meus testes (principalmente pontos de integração interações ambientais). Isso simplifica a cobertura de teste e torna os testes mais rápidos.

Outras ideias:

• Envolva o controle de qualidade o mais rápido possível. Se você não tem pelo menos um especialista em controle de qualidade sentado em todas ou quase todas as reuniões, começando com o estágio de design, você está perdendo muito valor. Testadores seniores podem ajudar a encontrar falhas de design, apresentar pequenos recursos que acelerarão muito os testes e podem começar a planejar a estratégia de teste mais cedo quando estiverem envolvidos em reuniões de design.
• Obtenha requisitos bons e sólidos, obtenha-os cedo e faça o controle de qualidade revisá-los. Um bom especialista em controle de qualidade encontrará falhas nos requisitos que ninguém pensou em abordar. Às vezes, coisas que são pequenos detalhes para desenvolvedores são enormes bloqueadores para QA (por exemplo, as especificidades das regras de negócios; dev pode construir o framework para regras e depois adicionar as regras reais com pouco esforço, mas testes não podem ser escritos até os detalhes são conhecidos). Os piores ciclos de teste que vi foram quando o pessoal da BA não obteve requisitos claros, atrasou-os ou comunicou modificações aos requisitos verbalmente aos desenvolvedores sem notificar o QA. Além disso, a automação de testes não pode ser desenvolvida simultaneamente com o desenvolvimento de produtos sem bons requisitos antecipadamente.
• Desenvolva mais incrementalmente . Não deite todo o produto para o controle de qualidade, mas entregue as peças ao longo do ciclo de desenvolvimento à medida que elas forem concluídas para testes de componentes e testes de integração de componentes. Técnicas ágeis de desenvolvimento são ótimas para reduzir os ciclos de testes e distribuí-los de forma mais suave durante todo o projeto, para que você não tenha um grande rosnado no final.
• Se você tiver desenvolvedores ou testadores que leiam código trabalhando em QA, faça-os fazer revisões de código , bem como desenvolvedores (para que um dev e um QA revisem cada mudança de código principal). Isso ajuda o QA a aprender a base de código e o sistema, além de fornecer uma perspectiva focada na qualidade do código.
• Use mais automação no seu processo de controle de qualidade . Limite o teste manual para algumas áreas bem definidas. Testes automatizados podem ser desenvolvidos antes que o desenvolvimento do componente seja concluído, possa ser executado à noite e exija relativamente poucos recursos depois de desenvolvido. Embora você provavelmente invista mais recursos de teste na automação, muito do tempo do testador acontecerá antes do 'gargalo de teste', quando o tempo do testador for barato.
• Assegure-se de que os desenvolvedores tornem os testadores que trabalham e os que desbloqueiam uma prioridade alta durante todo o ciclo de desenvolvimento. Quando você desencoraja um testador de fazer perguntas, aprender o sistema e, geralmente, fazer o seu trabalho, você adquire dívida técnica. Os desenvolvedores podem não perceber isso porque você não paga juros sobre essa dívida até chegar à fase de teste; o custo é externalizado dos desenvolvedores.
• Automatize a configuração do ambiente de teste. É demorado e a maioria dos testadores precisa fazer isso pelo menos diariamente para acompanhar as correções de bugs. Um testador deve poder instalar o (s) produto (s) inteiro (s) com um único comando.

Use o Desenvolvimento Orientado a Testes. Dessa forma, você testa e integra continuamente a funcionalidade. No desenvolvimento baseado em CRUD, eu gosto de usar uma interface iCRUD. Isso facilita a configuração dos meus testes. Apenas crie ConcreteItemX , que implementa iCRUD e configure os 4 testes (Criar, Ler Atualizar Exclusão). Implemenente até que todos os testes passem.

Enxagúe e repita.

É bom testar mais tarde no cano. Você simplesmente não pode esperar até o final do processo para realmente começar qualquer teste real, devido ao fato de que o custo para corrigir um bug aumenta drasticamente ao longo do tempo.

A primeira coisa a fazer é descobrir onde os defeitos estão sendo injetados e onde eles estão sendo detectados. Embora você saiba que muitos estão entrando na fase de testes, você não sabe de onde eles vêm. Aplicando Técnicas de rastreamento de eficácia da remoção de defeitos pode ajudar aqui. Simplesmente crie uma matriz de fases (dado o que você disse, suas fases provavelmente seriam requisitos, design, implementação, teste e campo). Sempre que você encontrar um defeito, rastreie onde você o encontrou e de onde veio. Para cada fase, acompanhe a porcentagem de defeitos que foram identificados e removidos.

Depois de saber quais fases específicas são problemáticas, você pode introduzir alterações. Exemplos de técnicas de qualidade incluem requisitos, design e revisões de código. A análise de causa e efeito também pode ser usada para determinar por que um defeito foi injetado e o que pode ser feito para evitá-lo. Listas de verificação podem ser empregadas para garantir a repetibilidade em todos os seus processos. Há várias ferramentas de qualidade por aí, mas até você saber onde estão seus problemas e o que os está causando, fazer qualquer coisa pode ser um desperdício de recursos.

Eu recomendaria a leitura de Métricas e Modelos de Stephen Kan em Engenharia de Qualidade de Software . Este foi o livro usado no curso de Qualidade de Produtos e Processos de Engenharia de Software da minha universidade, e é um livro muito bom quando se trata de entender e melhorar a qualidade tanto no nível do produto quanto no nível do processo.

Onde é possível que os desenvolvedores escrevam testes de unidade, durante os estágios de desenvolvimento, eu definitivamente concordo com o conselho de P.Brian.Mackey de usar Test Driven Development.

No entanto, recentemente também obtivemos muito valor por fazer com que os usuários anotassem o que eles fariam para testar o sistema antes que o desenvolvimento seja iniciado : eles são conhecidos como Testes de aceitação do usuário .

Cada UAT começa como uma lista com marcadores curtos, descrevendo o que o usuário faz e dizendo o que acontecerá. Eles também gravarão coisas como onde encontrar arquivos de entrada de amostra.

À medida que a funcionalidade é implementada, a UAT é aprimorada com mais detalhes, então eles são uma espécie de "documento vivo". Por esse motivo, acabamos armazenando-os em páginas wiki internas simples, em vez de em qualquer sistema de gerenciamento de documentos.

Estes se revelaram valiosos em uma gama surpreendentemente ampla de situações:

1. Eles dizem aos desenvolvedores exatamente qual é o comportamento esperado, antes de escrever o código
2. Isso economiza o tempo gasto na implementação de funcionalidade incorreta, apenas para ser informado de que "não, não foi o que foi desejado - corrija-o"
3. Eles servem como uma espécie de manual de instruções durante o desenvolvimento:
   • para usuários reais, para permitir que o software seja testado durante o estágio de desenvolvimento
   • para desenvolvedores que são novos em um projeto
4. Eles fazem todos os tipos de perguntas úteis sobre o que é necessário, antes mesmo de começar o trabalho, o que nos permite decidir quais decisões precisamos tomar antes do início do desenvolvimento
5. Eles dão aos desenvolvedores uma melhor compreensão do pedaço de trabalho, anteriormente - isso torna muito mais fácil estimar que aproximadamente o tempo será necessário para cada estágio.
6. E, claro, eles também facilitam o teste do sistema.

Evidências supostamente diz que uma das as melhores coisas que você pode fazer para diminuir os erros, até mais do que os próprios testes, são a inspeção formal de código.

O artigo também aborda a eficácia de muitas outras técnicas que você pode considerar (embora TDD anterior não inclua isso - pessoalmente eu ficaria surpreso se ele superasse a revisão formal de código, mas essa é uma opinião pessoal e não suportada por qualquer coisa).

Existem alguns desafios na sua história.

As coisas que vêm à mente são um modo de desenvolvimento mais ágil (o TDD é ótimo, mas haverá uma enorme lacuna nos testes, pois você já tem um produto por aí). A integração contínua e a entrega contínua ajudarão a resolver problemas de criação e integração. Além disso, uma quantidade cada vez maior de testes de unidade permitirá que você melhore a qualidade e mantenha uma base de regressão que indique se novos recursos quebram o código existente.

A coisa mais difícil de mudar será o processo real, coisas como integração contínua exigem a implantação de um conjunto de ferramentas que é um passeio no parque em comparação com a mudança do processo.

Felicidades, Carlo

Sugiro que você exija que os desenvolvedores testem a unidade e enviem seus testes para o controle Source junto com o código. Nada vai para o Qa sem um conjunto de testes de unidade que foram certificados como executados pelo desenvolvedor. TDD é uma ótima idéia (onde você escreve os testes antes de escrever o código), mas claramente seus desenvolvedores não estavam testando o código deles, então comece por aí. Só porque você tem departamento de QA não alivia o desenvolvedor da responsabilidade de testar seu código.

A próxima revisão de código deve ser um requisito em sua empresa. Nenhum código é avaliado até ser revisado e os revisores codificados serão instruídos a não apenas revisar o código quanto à precisão técnica, mas também quanto à conformidade com os requisitos. O código de trabalho que faz a coisa errada também é um bug.

Em seguida, sente-se com os jogadores (devs e qa) dos projetos que falharam e passe pelos bugs encontrados e veja se há padrões que você pode ver. Alguns tipos de erros são comuns? Então, talvez seus desenvolvedores precisem de treinamento nesses tópicos. Esta não é uma sessão de culpa, você não se importa quem criou o bug, você está procurando melhorar o processo e o primeiro passo é coletar dados sobre o que deu errado para que você possa evitá-lo no futuro.

Em seguida, os gerentes darão uma boa olhada no nível de habilidade dos desenvolvedores que você tem. É menos caro treinar o pessoal existente para melhorar suas habilidades do que despedi-lo e contratar novas pessoas. No entanto, se você tem algumas pessoas que repetidamente cometem os mesmos erros e nunca aprendem com seus erros, pode ser hora de considerar se eles estão contribuindo para a empresa. Eu começaria com o treinamento (eu suspeito que sua cultura corporativa provavelmente não lhes deu uma chance de melhorar, eu vi desenvolvedores terem suas coisas consertadas por outra pessoa e nem sabia que isso era ruim.) E então ver se os mesmos erros continuam. Então, em cerca de 6 meses, analise o desempenho e veja se algumas pessoas não estão melhorando para o nível que você precisa ter.