Agile Testers TechTalks | Test War Stories - Andreia Gaita @ Tech Lead do GitHub. Saiba mais aqui

Como antecipar em uma estória Bugs



  • Caros,

    Como vcs fazem para antecipar bugs?
    Trabalham mais próximo do PO?

    Abraços!



  • Olá deyvisrf,

    Na equipe que eu trabalho, nós tentamos sempre ter os QAs participando das reuniões de definição de requisitos pois assim ele já poderá pensar nos cenários de testes e possíveis cenários críticos.

    Espero ter ajudado! :)



  • Ola @deyvisrf tudo bem?
    Na empresa que trabalho, os nossos times são multidisciplinares, portanto estamos perto dos devs, POs, UX… Falo um pouco sobre isto é um post em um blog:
    http://chatbotsbrasil.take.net/como-trabalhar-em-equipes-multidisciplinares/

    Para facilitar procuramos ajudar, na parte dos critérios de aceite, para lembrar sempre dos cenários de exceção e principalmente a experiência dos usuários. Buscamos sempre ler as histórias, antes de serem desenvolvidas, para ver se não está faltando algo. E tentamos alertar para os devs o que pode dar mais erro.
    Espero ter contribuído! :)



  • Bom Dia @deyvisrf
    Na empresa que trabalho temos reuniões onde lemos e discutimos as historias já nessa reunião e possível diminuir os bugs, pois cada ponto levantado seja por Dev ou QA e anotado e discutido. Durante todo desenvolvimento o QA tem livre acesso aos Dev e vise versa onde eles conversam e discutem sobre o projeto, para que o minimo de bug seja encontrado nos testes.
    Da uma olhada no blog do @André-Dutra que e muito bom…eu recomendo.



  • Olá @deyvisrf tudo bem? para antecipar os bugs eu costumo deixar a equipe sempre juntos (dev, suporte e teste) algumas reuniões com o cliente eu costumo levar alguém de de QA, outra coisa que faço é a definição de Ready, antes de terminar o Sprint, as próximas estórias já estão com refinamento e com critério de aceite, assim a equipe de QA já consegue antecipar bugs. Outra coisa que faço é, quando o PO está próxima, ele acaba ficando junto com o pessoal de QA.



  • O trabalho de caça a bugs deve ser feito pelo time, em tempo de desenvolvimento. Não existe bala de prata para este problema. Mesmo tendo excelentes profissionais no time, se a postura não estiver bem preparada, provavelmente o produto não terá boa qualidade.
    Encontrar bugs antes é algo que vai se conquistando conforme o time conhece melhor o produto, tecnologias utilizadas etc.
    A ideia aqui é: Prevenir bugs é melhor do que encontrar bugs.

    Na minha opinião, uma das melhores alternativas é iniciar o teste antes. Por exemplo, se vc sai da reunião de planejamento (ou refinamento, enfim…) com o critério de aceite bem definido e inicia o desenvolvimento da automação destes testes enquanto o programador inicia o desenv. da tarefa, diminui-se muito o esforço de teste manual, deixando o testador com tempo pra fazer testes em cenários alternativos, usabilidade etc. Além de se criar uma aplicação mais test-friendly.

    Às vezes temos que tomar cuidado com esta postura, pois podemos gastar muito tempo ‘procurando bugs’ e pouco tempo ‘validando se a aplicação resolve o problema do usuário’. Tudo deve variar de acordo com o risco envolvido no produto que você trabalha.

    Nem sempre um produto isento de bugs é um produto de qualidade.

    Recomendo a leitura neste livro: https://leanpub.com/AgileTesting/read
    Também tem este material bacana do Elias Nogueira: http://eliasnogueira.com/evento-workshop-de-agile-testing-mindset/



  • Na empresa onde trabalho começamos o detalhamento de testes praticamente junto com o desenvolvimento e com isso conseguimos antecipar uma quantidade grande de Bugs e ou compatibilidades não previstas do ponto de vista do desenvolvedor e ou especificador.