if (testadores = leitores de docs && apertadores de botão) assert false;

  Post interessante do Shoes sobre os testadores. Ele faz um comparativo, baseado em sua experiência, entre testadores ágeis e não ágeis.  Veja aqui!

Uma resposta

  1. O artigo é interessante mais eu acho que Phillip
    exagerou um pouquinho.

    ” O que acontecia era:

    * O pacote era aprovado. O desenvolvedor, com o sistema já em produção, olhava o plano de testes por curiosidade e via que eles não testavam absolutamente nada de relevante, ninguém garantia a qualidade do treco
    * O pacote era rejeitado. O desenvolvedor olha ao motivo da rejeição e via que o que estava sendo testado nem de perto era o que o sistema deveria fazer. O testador Não entendeu o documento, muitas reuniões explicando tudo novamente e o pacote era retestado sem modificações
    * O pacote era recebido pelo testador com total surpresa. Era uma aplicação de linha de comando e o testador esperava uma aplicação com interface web, ou o testador esperava que o sistema usasse banco de dados e ele mantinha tudo em memória, ou…
    * O testador rejeitava o pacote porque não sabia como testa-lo. O desenvolvedor não pensava no testador, o testador não pensava no desenvolvedor. ”

    Eu já trabalhei em um projeto com uma equipe de testes não ágil e isso que ele falou era difícil de ocorrer. Só se os testadores fossem muito ruins e incompetentes.
    Pelo menos do jeito que ele falou é com se isso acontecesse todo o tempo.
    Nunca trabalhei em um projeto com uma equipe de testes ágeis, mas depois disso estou desconfiando de que equipes ágeis sejam essa beleza toda que se fala por ai.
    Acho que isso depende muito mais da qualificação da equipe do que se é ágil ou não. Pode ser que um projeto ágil as coisas melhorem um pouquinho, mas acho que não é verdade essa coisa de que em projetos não ágeis as coisas são sempre mal feitas e em projetos ágeis tudo é bem feito (incluindo os testes) e funciona as mil maravilhas.

Deixe um comentário