Se eu já tinha dificuldade de explicar o que eu fazia como engenheiro de software, agora trabalhando na área de testes a coisa ficou ainda pior. Vou tentar simplificar isto descrendo um dia típico de um engenheiro de testes, doravante chamado SDET, na Microsoft.

As atividades são bem diversas e dificilmente trabalhamos com apenas uma funcionlidade e sempre algum fantasma do passado vem nos assombrar em forma de bugs de releases passados. Portanto, ser multitask é uma característica básica de um SDET.

O dia de João começa com os resultados dos testes executados no final de semana. Os testes, de uma de suas funcionalidades, que falharam são analisados. João encontra um defeito e o descreve no item tracking (TFS ou algo similar) com um repro step detalhado e o cenário que este bug acontece e o impacto que ele causa, o que facilita depois a priorização do mesmo. Dois testes falharam por erros no próprio teste, um test issue, que João também adiciona ao item tracking para que sejam consertados o mais rápido possível.

Ainda antes do almoço João vai a uma reunião sobre uma nova funcionalidade. Após ter lido a especificação, ele discute com o time suas dúvidas, sugestões e preocupações sobre como e o que testar para garantir a qualidade da nova funcionalidade.

De volta do almoço João escreve a primeira versão da especificação de testes para esta nova funcionalidade. Neste documento ele descreve as estratégias de teste a serem utilizadas, os testes que serão realizados e suas prioridades. Além de ser um momento de reflexão sobre o que e como testar, este documento servirá para que colegas de time, desenvolvedores, PMs e outros testers, revisem suas idéias e sugiram melhorias e proponham alternativas.

No meio desta atividade João é interrompido pelo email de um colega pedindo sua ajuda em uma ferramenta de testes. João conhece muito bem esta ferramenta e ajuda regularmente seus colegas, ele acabou virando uma referência no time quando o assunto é esta ferramenta.

A terça-feira começou mal, um defeito de alta prioridade chegou ao time de sustained engineering e eles precisam da ajuda de João para testar o conserto, devido o seu conhecimento da funcionalidade. João prepara o ambiente necessário, reproduz o problema, aplica o conserto. Após alguns testes manuais ele tem certeza de que o conserto é bom, implementa um testcase que reproduz o problema e conserta outros três testcases que foram impactados pelo conserto.

A tarde João dedica ao desenvolvimento de testes para uma outra funcionalidade. Tanto automatizando a execução de testes via UI como acessando diretamente a camada de negócios. Em um certo momento, João identifica que a API funcional, que abstrai detalhes da API de testes em uma linguagem mais própria do negócio, não tem a função que ele precisa. Ele implementa esta nova função e avisa ao time. No final do dia, João envia os testcases prontos para revisão e aguarda a resposta no dia seguinte para colocar este código no controle de versão.

Acabei precisando de dois dias... E eles ficaram bem cheios. Lógico que na verdade o dia-a-dia não é tão movimentado assim, mas eu quis incluir todas as atividades que um SDET normalmente pode executar.