Em fevereiro de 2013, um artigo foi traduzido e publicado na InfoQ a respeito da “morte” das áreas de QA (Quality Assurance – Garantia de Qualidade) e de testes com o advento das práticas do Desenvolvimento Ágil. Segundo o autor, o TDD e os testes unitários, por exemplo, substituem o trabalho dos analistas de teste.
Espere aí… como?! Aí que ele se engana, meu amigo…
Antes de iniciar o artigo, gostaria de fazer um grande agradecimento à minha namorada, Beatriz Makiyama, por todo o apoio, motivação e confiança no meu trabalho aqui no blog!
Bom, os leitores que me acompanham sabem que sou um grande adepto ao Desenvolvimento Ágil em virtude da quantidade de artigos já publicados sobre este tema. No entanto, eu acho que esse fanatismo, algumas vezes, chega a ser prejudicial para um agilista e também para a imagem da metodologia. Vários profissionais que estudam e empregam o Desenvolvimento ágil formulam uma mentalidade que se resume em acreditar que essa metodologia é a solução para todos os problemas do desenvolvimento de software. Uma dessas crenças, por exemplo, é considerar que os pilares do eXtreme Programming, como o TDD (Test-Driven Development), é um mero substituto do trabalho dos analistas de teste.
Embora eu seja um entusiasta pelo XP, não afirmo, em nenhuma ocasião, que testes unitários são a muralha de concreto que impedem a ocorrência de bugs no software em sua totalidade.
A verdade é que, ao meu ver, os testes realizados pelos desenvolvedores e analistas de teste são essencialmente diferentes.
Por um lado, os desenvolvedores criam classes de testes, capazes de testar a funcionalidade em âmbito técnico, evitando exceções, ausência de validações e garantindo a padronização relacionada à arquitetura do código. Através dos testes unitários, além de avaliar os cenários mais evidentes da funcionalidade implementada, também é possível evitar que futuras refatorações ou modificações nesse código impactem no que já está funcional. Perfeito.
Agora, por outro lado, consideremos os analistas de teste. É correto afirmar que o trabalho deles se restringe ao que foi descrito no parágrafo anterior? Claro que não! A função destes analistas não é verificar se uma condição IF está correta ou se os objetos estão sendo liberados da memória. É um nível mais alto e específico. O trabalho dos analistas de teste envolve o comportamento tanto sob a perspectiva de requisitos funcionais, como as regras de negócio, quanto da usabilidade, desempenho, segurança e de qualquer outro requisito não-funcional que esteja relacionado com a experiência do usuário ao utilizar a aplicação. Para isso, eles criam cenários automatizados e executam testes de regressão, testes de integração, testes funcionais e testes de “caixa” (preta, branca e cinza) para analisar os resultados e validar os requisitos. Esses são os pontos ausentes nos testes unitários, ou melhor, são essas as características que esses testes não possuem para explorar todo o contexto de uma funcionalidade. Um teste unitário, por exemplo, não irá identificar que uma determinada tela da aplicação passou a demorar 20 segundos para ser exibida para o usuário em comparação com 5 segundos antes da implementação. Um analista de teste, por sua vez, registraria essa falha de desempenho, evitando que o artefato fosse liberado para o ambiente de produção e, portanto, impedindo que um novo incidente fosse aberto pelo cliente no dia seguinte.
Já trabalhei em uma equipe que escrevia testes unitários (bem eficientes, diga-se de passagem) e, mesmo assim, erros eram encontrados nas evoluções ou correções recém-implementadas. Pergunto: o motivo é que os testes unitários eram ineficazes? Não! É pelo simples fato de que os testes unitários não eram suficientes o bastante para cobrir todos os cenários possíveis de operações que o usuário do sistema pode reproduzir. Como solução, os gestores da empresa criaram um departamento de testes e, a curto prazo, já observaram a redução de falhas em produção.
A realidade é clara: testes unitários não simulam o raciocínio do usuário em cada operação do sistema enquanto consideram os detalhes das regras de negócio e os parâmetros de aceitação dos requisitos.
Vamos ser realistas. Os analistas de teste continuam exercendo um papel importante e primordial no ciclo de vida do software, mesmo após a ascensão das metodologias ágeis. A área de testes está evidentemente associada à qualidade do software e, consequentemente, à satisfação do usuário. Em uma análise mais conclusiva, o retorno garantido do investimento de tempo e dinheiro no projeto se torna visível em função do trabalho destes profissionais.
A minha opinião é que, de fato, a área de testes sofreu uma mudança com a abordagem do Desenvolvimento Ágil nas empresas, porém, essa mudança é uma evolução, e não uma extenuação como destacado no artigo.
Bom, apesar da minha defesa, vale realçar que, assim como acontece com os desenvolvedores, as técnicas e ferramentas dos analistas de teste também são atualizadas, logo, cabe a estes profissionais acompanharem este avanço para desempenhar um trabalho eficiente e aprimorar a produtividade da equipe.
Bom, muita coisa mudou de 2013 para 2015. De lá pra cá, talvez o autor do artigo tenha mudado de opinião, rsrs.
Abraço, pessoal!
5 Comentários
Chega até ser uma ignorância achar que o papel do teste deveria sumir com a aplicação das metodologias ágeis. Fica evidente pelo seu artigo a importância deste profissional no ciclo do desenvolvimento e pode ter certeza de quem abrir mão, vai ter que refazer muita coisa.
Olá, Gustavo.
Compartilho do mesmo pensamento. A área de testes ganhou notoriedade nos últimos anos devido à importância que ela exerce no ciclo de vida do software, portanto, é fato que essa área é essencial para a garantia da qualidade do produto, independente da metodologia empregada.
Obrigado pelo comentário!
Concordo com vc André, além do mais o desenvolvedor vai estar sempre mais focado na entrega do codigo e não no desenvolvimento de um test unitário ou que seja um teste de sistema refinado, isso sempre ficará a carga do Analista de Testes.
Além de que o desenvolvedor não terá interesse em aprender novas ferramentas que proporcionem a automação dos testes.
Estou fazendo um estudo para um tese de mestrado e um dos focos é a pesquisa sobre problemas ocorridos na utilizaçao de testes ageis (TDD e regressão, etc).
Caso vcs tenham algum relato ou artigo, agradeço se puder compartilhar.
TDD está mais associado ao design do software (a forma como você desenvolver a funcionalidade) do que o teste (qualidade) em si.
Acho que, talvez, o papel do testador que não saiba criar um teste automatizado possa estar em risco. O que não significa que efetivamente está fadado ao desaparecimento.
É sempre bom lembrar o quanto nós, agilistas, gostamos que os testadores estejam presentem no time, e se não for possível, fazer com que participem do planejamento para já saberem quais testes deverão criar.
Mas parabéns pelo post.
Douglas Lima, obrigado pelo comentário! Eu tenho alguns materiais sobre testes ágeis! Envie um e-mail para “[email protected]” para que eu os envie para você, ok?
Edmilson, é sempre bom ter a opinião de um bom agilista em um artigo como esse. Eu realmente deveria ter destacado a importância da habilidade dem criar testes automatizados. Na verdade, eu acho que esse é um dos fatores que diferencia o “Testador” do “Analista de Teste”.
Na empresa em que trabalho, devido aos parâmetros do Scaled Agile Framework (SAFe), os analistas de testes devem obrigatoriamente comparecer às cerimônias de planejamento da Release e da Sprint para definirem estimativas, nas quais já contemplam o esforço de implementação dos testes automatizados.
Obrigado pelo comentário, Edmilson!