Wednesday, April 1, 2015

A área de testes perdeu a força com o Desenvolvimento Ágil? - Profissionais TI





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… 



 
"http://s.profissionaisti.com.br/wp-content/uploads/2014/02/certificacao-testes-software-ctfl.jpg"

alt="certificacao-testes-software-ctfl" width="580" height=

"300">



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 
"Meus artigos no PTI" href=

"http://www.profissionaisti.com.br/author/andre-celestino/">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

"http://www.profissionaisti.com.br/2009/11/tdd-desenvolvimento-orientado-a-testes/">

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

"Bug no software! De quem é a culpa? - Parte 1" href=

"http://www.profissionaisti.com.br/2014/03/bug-no-software-de-quem-e-a-culpa-parte-1/">

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

"Regra de negócio: um desafio para o desenvolvedor" href=

"http://www.profissionaisti.com.br/2012/12/regra-de-negocio-um-desafio-para-o-desenvolvedor/">

regras de negócio, quanto da usabilidade, desempenho,

segurança e de qualquer outro 

"A importância dos requisitos não-funcionais" href=

"http://www.profissionaisti.com.br/2013/02/a-importancia-dos-requisitos-nao-funcionais/">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!




0 comments:

Post a Comment