DM #30 – Testar é melhor do que remendar

Tempo de leitura: 2 minutos

Todo mundo sabe que testar é melhor do que remendar. Você também sabe.

Mas então, por que somos tão relaxados na hora de testar nossos projetos? Por que entregamos sem testar direito quando o prazo tá apertado?

Nesse episódio do Desenvolver Mindset você vai entender melhor a importância dos testes com pontos de vista diferentes daqueles que está acostumado. Vou te mostrar que bons testes podem fazer a diferença nas mais diversas situações da vida, e não apenas em projetos de TI.

Depois de ouvir, deixa um comentário aí embaixo pra me dizer o que achou.

E se esse episódio fez você repensar sua atitude sobre os testes, compartilhe com seus amigos do trabalho e nas redes sociais, assim você me ajuda a ajudar mais gente!

Abraço!!

Principais insights desse episódio

Essa seção é uma transcrição dos insights mais importantes deste episódio, pra quem está sem tempo (ou sem saco) de ouvir tudo.

Eu não sei porque diabos, mas a gente aprende na nossa carreira que testar é a última parte do processo, e que acaba não tendo muita importância.

Talvez porque o teste tá muito próximo da entrega (no método tradicional o teste é a última etapa), a gente acaba sendo pressionado pelos prazos e entrega sem testar mesmo.

É muito louco isso, porque a gente não vê esse problema como um problema.

Quando isso acontece na vida real, fora do seu trabalho com sistemas, parece que é estúpido e bizarro. Por exemplo, você tá fazendo o segundo andar de uma casa e a construção desaba. A primeira coisa que vão perguntar é “mas você não olhou se tava firme ou não?”. Se você responder “não, não testei”, o cara vai olhar pra sua cara e falar “meu, você é idiota?”.

Fora da área de TI é uma aberração você não testar. Quando a gente tá programando, entregando projeto, é normal. “Ah, testa mais ou menos aí, acho que funciona, não tem problema…”.

Não é um problema a gente errar. O problema é o momento que a gente escolhe pra ver que tá errado.

Uma frase que eu gosto muito é “fail fast, fail often” – falhar rápido e falhar frequentemente, pra poder obter feedback daquilo que você fez e fazer as correções o mais rápido possível.

É melhor errar no começo do que errar no final.

  • Tatiana Cristina de Araujo

    Parabéns André, gostei muito das suas colocações durante o vídeo. Confesso que quando encontrava uma falha no início dos testes e relatava, brochava demais porque a importância era a entrega e não o remendo que fariam após implantação mesmo notificando. Triste que todos os projetos da empresa que trabalhei eram nessa base, deixa subir mesmo relatando os bugs e depois quando feder partimos para o remendo cagando outras partes, o que acaba gerando mais gastos.

    • Obrigado Tatiana, fico feliz que tenha gostado! Sei como é essa sensação, mas não desanime. Fazendo a sua parte, uma hora o seu trabalho se destaca da média, e nenhuma empresa consegue ficar indiferente quando bons resultados aparecem. É disso que precisamos, gente que tem coragem de fazer a diferença e ficar acima da média! Abraço!!