Você sabe o que faz com que você queira ir para o trabalho, mesmo quando o trabalho não está tão divertido assim? Sabe o que te mantém forte quando todos os testes estão falhando e as pessoas ao teu redor ficam o tempo todo perguntando o que está acontecendo de errado?
Eu não sabia. Ou pelo menos não tinha consciência.
Mas a vida como consultor nos ensina muitas coisas sobre pessoas, suas interações com os membros da equipe, e a forma como decisões são tomadas e aplicadas.
Prestei atenção no meu próprio modo de agir e no que me fazia feliz ao longo do dia, mesmo quando o dia não era dos melhores. Isso me ajudou a criar uma lista de princípios que eu utilizo como guia, e sempre que algo não está bem eu me pergunto o quanto eu estou me esforçando para aplicar esses princípios ao meu dia. Experimente e me conte se funcionou pra você também.
Princípio # 0 | Tenha a mente aberta
Preso a um aplicativo legado? Até mesmo a pior tecnologia já teve seu momento de glória.
É difícil concordar com tudo o que se passa com times que trabalham em aplicações legadas. Mas as pessoas vão trabalhar para fazer o seu melhor, e é isso que devemos ter em mente. Técnicas, ferramentas, plataformas, linguagens e metodologias são escolhidas com as melhores intenções. Antes de abandonar uma tecnologia entenda o contexto das escolhas anteriores e veja se é possível melhorar a forma como são utilizadas, dado o contexto atual.
Princípio # 1 | Pense no futuro
Prepare-se para o futuro. Testes são a mais valiosa documentação de um sistema.
Aprenda a escrever testes. Aprenda a entendê-los também. Compartilhe o seu conhecimento e ajude outros membros da equipe. Reveja os testes e elimine aqueles que não são mais úteis. Modifique testes sempre que necessário - eles não são imutáveis e existem para te ajudar, não pra te dar mais trabalho.
Princípio # 2 | Pense grande
Projete seus testes pensando em mais do que os critérios de aceitação.
Ao projetar um teste, entenda as ações dos usuários do sistema e construa testes robustos ao invés de simples scripts focados em estórias de usuários. E, sempre que você se deparar com um teste, pergunte a si mesmo: "o que este teste vai me dizer daqui a cinco meses?", "Esse teste está testando um nível apropriado? Deveria ser unitário, de serviço ou via interface gráfica?".
Princípio # 3 | Pense com sabedoria
Não automatize tudo só porque você pode e porque a ferramenta é legal, ou porque o seu gerente pediu.
É difícil não colocar as mãos naquele novo framework que todo mundo está falando. A questão é: precisa mesmo automatizar tanto assim? Escreva testes demais e você vai acabar com muitas horas de trabalho extra apenas para mantê-los passando. A dica é (clichê, mas sempre boa) pense antes de automatizar. Decisões técnicas cabem a você.
Princípio # 4 | Mantenha a calma
Quebrar build não é uma coisa ruim.
Desde que você saiba por que quebrou. Se você não sabe, preste atenção nos princípios # 1, # 2 e # 3. Pergunte-se: "nossa pipeline de build é realmente uma pipeline?" Ou "tenho como saber quais alterações de código estão envolvidas nessa falha?".
Princípio # 5 | Seja gentil
Trate o seu código de automação de teste com todo o respeito dado ao seu código de aplicação.
Não existe essa história de código de teste e código de desenvolvimento. Testes e aplicação podem ter focos diferentes, mas têm o mesmo objetivo final - entregar valor para o cliente. E enquanto o seu sistema existir, esse código também existirá.
Esses são meus princípios para poder contribuir consistentemente no trabalho como um QA. Você já pensou nos seus? Pense e me diga o que você descobriu! É incrível como um pedaço de papel e alguns minutos de introspecção podem ajudar a transformar um dia ruim em uma grande oportunidade de consultoria.
*Outra dica de leitura - o artigo Agile Tester 3.0. Esse artigo descreve uma visão com a qual simpatizo, e diz respeito aos perfis de atuação de um QA. Após ler os 6 princípios, reflita sobre em qual dimensão cada um deles se enquadra. Vale a pena!
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.