E viveram felizes para sempre
Muito foi escrito, discutido e argumentado sobre o trabalho conjunto de desenvolvedores e analistas de teste. Parece que sempre que estes dois grupos se encontram, resultam mais desentendimentos que acordos. Estranhamente, acontece o contrário do que precisaria acontecer, ou seja, todos trabalharem em equipe para gerar valor aos clientes.
Vamos ver como tudo começou, em que ponto estamos e o que podemos fazer para melhorar.
A Época Pré-histórica
No começo, não haviam analistas de teste, apenas desenvolvedores. Os desenvolvedores não eram tão diferentes de outros colaboradores do negócio, salvo por um fato: Representavam um custo muito alto.
Os altos custos não eram dos desenvolvedores especificamente, mas sim do longo tempo de desenvolvimento e dos recursos físicos, como computadores gigantes necessários para executar o software. Ter um analista de teste não fazia sentido econômico: O tempo computacional era tão caro que conceder uma parcela deste tempo a um analista de teste parecia um desperdício.
Sem alguém para conferir o trabalho dos desenvolvedores, os próprios desenvolvedores faziam os testes e uma vez que o tempo computacional era tão caro, tentavam garantir que o software realmente funcionasse, tomando algumas atitudes como logar, imprimir informações e "depurar" desconectados.
Nesta época, não haviam IDEs [interfaces] para ajudar na depuração e era mais barato verificar centenas de páginas impressas do que se utilizar do tempo computacional. Todos que revisavam as informações também eram parte da equipe de desenvolvimento, de forma que todos falavam a mesma língua e entendiam os problemas. Era uma equipe indo pra frente, mas de forma lenta.
Acabando com a Festa
A partir do momento que a indústria do software amadureceu e os custos computacionais diminuíram, as empresas de software começaram a se preocupar com a qualidade e seus custos. Os clientes passaram a ficar agitados, pois começavam a demandar consertos e ajustes em algo que haviam pago para ter.
Uma solução oferecida para evitar estes "bugs" pós lançamento foi a utilização de testes de aceitação: Tratavam-se de cenários que o cliente realizava no sistema, funcionando como um contrato entre a empresa de software e o cliente. O software deveria passar pelos testes de aceitação antes de ser aceito pelo cliente.
No começo, os desenvolvedores eram os contatos diretos do cliente ao executar tais testes de aceitação. As empresas de software, contudo, perceberam rapidamente que os desenvolvedores não eram muito bons no relacionamento com os clientes. Assim surgiu a ideia de uma separação física entre os clientes e a equipe de desenvolvimento.
A interação entre cliente e desenvolvedor não era a única parte que não funcionava. Uma vez que os testes de aceitação falhavam, muitas vezes, havia um sentimento crescente de que a equipe de desenvolvimento precisava de mais supervisão sobre a qualidade. Esta supervisão poderia ter sido de outros desenvolvedores, mas o desenvolvimento ainda era considerado muito caro, enquanto que os analistas de teste não precisavam saber, nos mínimos detalhes, como o software funcionava. Uma nova profissão acabava de ser criada.
Obviamente, mudanças organizacionais não acontecem por si próprias. Mudança organizacional requer suporte e coordenação gerencial. Assim, depois de alguns anos não haviam apenas desenvolvedores e analistas de teste, mas equipes inteiras dedicadas ao desenvolvimento e suas equipes pares na área de teste.
Porém, isto não é tudo. Novas profissões trazem consigo a necessidade de mais treinamentos e metodologias, que passaram a evoluir assim que mais analistas de teste desejaram melhorar suas habilidades. Empresas de treinamento e de certificação perceberam a oportunidade e criaram cursos tanto para analistas de teste quanto para desenvolvedores. À medida que o negócio das metodologias cresceu, nasceram os especialistas nas distintas áreas e, então, a divisão entre desenvolvedores e analistas de teste estava formada.
Uma pequena história
Um desenvolvedor e um analista de teste trabalhavam no mesmo projeto e levavam dois estilos de vida diferentes. Os desenvolvedores viam-se como criadores que inovavam, criando software do nada, apenas para que os analistas de testes pussem apontar o que não funcionava. Por outro lado, os analistas de testes esperavam muito até o momento em que os desenvolvedores entregassem alguma coisa que, normalmente, falhava assim que era tocada. Devido à falta de qualidade, os analistas de testes gastavam o tempo reproduzindo defeitos nos principais cenários, deixando a maior parte da aplicação sem testes por falta de tempo.
Os desenvolvedores acabaram achando que os analistas de teste eram inimigos e então se distanciaram mais, esperando que houvesse o mínimo de comunicação. Os analistas, por sua vez, viam falta de profissionalismo nos desenvolvedores, gerando desconfiança entre as equipes.
Aconteceu outro problema com os analistas de teste e os desenvolvedores: Os requisitos e os cenários de teste eram confusos. Como existiam dois departamentos falando línguas distintas, os requisitos eram interpretados de formas diferentes, criando desentendimentos que eram descobertos apenas na fase de testes. As acusações mútuas eram comuns neste ponto.
O elemento final que causava atrito entre as duas equipes era o conflito de tempo: Os analistas de teste podem trabalhar apenas se houver um produto, logo, esperavam a entrega dos desenvolvedores para começar a testar. Enquanto os analistas testavam, a equipe de desenvolvimento continuava a trabalhar em outras funcionalidades, mas parava assim que os defeitos eram reportados pelos analistas de teste. Então, os desenvolvedores acusavam os analistas de tirar-lhes o foco do que estavam fazendo.
Toda a tensão entre analistas de testes e desenvolvedores prejudicava fortemente o objetivo de negócio que visava diminuir o desperdício e entregar um produto de valor. No lugar, nasceram o retrabalho, o vai-e-volta e as acusações antes mesmo do produto "ver a luz do dia".
A Ponte Ágil
Quando o movimento ágil começou, software em funcionamento foi colocado como meta, e foi um ato inteligente: Haviam desenvolvedores, analistas de teste e gestores entre os signatários do Manifesto Ágil, e o que os unia era ter o negócio em primeiro lugar. Tudo deveria ser voltado a este propósito.
A solução era o conceito de "Time coeso" que é uma prática do Extreme Programming voltada a colocar o cliente e os desenvolvedores juntos, na mesma sala se possível. Organizações inteligentes incluíram também os analistas de teste.
Ao dividirem o mesmo espaço, os desenvolvedores e os analistas de teste começaram a fazer algo há muito tempo esquecido: Comunicar-se.
Começaram a falar sobre o que significavam os requisitos, usando a mesma língua. A barreira representada pela falta de comunicação desapareceu e ambos os lados tinham as mesmas expectativas sobre o que deveria funcionar e o que ainda não estava resolvido.
O que mais ajudou nesta aproximação das equipes foi que os defeitos encontrados eram prontamente corrigidos. O intervalo de tempo desapareceu já que ambos, desenvolvedores e analistas de teste, trabalhavam na mesma iteração.
No momento em que desenvolvedores e analistas de teste sentaram juntos para trabalhar em uma iteração, descobriram algo ainda melhor: Os testes tinham alguma influência sobre o desenvolvimento, ao encontrar erros antecipadamente no processo e ajudando a decidir o que fazer com estes erros. Os desenvolvedores também foram compensados, visto que os
"problemas" encontrados e corrigidos durante a iteração não eram considerados defeitos de verdade, apenas aqueles encontrados após o término da iteração eram assim considerados.
Transformação
A equipe ágil também teve mais alguns efeitos sociais interessantes. Os limites entre os desenvolvedores e analistas de teste não eram mais tão claros: Os desenvolvedores começaram a testar e os analistas de teste aprenderam a desenvolver e automatizar. Ninguém pode fazer tudo, mas todos aprenderam novas habilidades.
Outro efeito foi o aumento na qualidade. O Agile diz que a qualidade é responsabilidade de todos. Os desenvolvedores, então, voltaram a fazer como no começo: procurar garantir que o código funcione. Ao aumentar a qualidade, os analistas de teste agora tinham a oportunidade de poder fazer testes exploratórios e não somente os testes básicos. A qualidade foi, portanto, melhorada em pelo menos duas ordens de grandeza.
Final feliz?
O sucesso das equipes ágeis ainda está em evolução. Empresas inteligentes estão caminhando em direção à construção de equipes que compostas, não apenas de desenvolvedores e analistas de teste, mas também de outras áreas do negócio.
Estas empresas, contudo, ainda são minoria. A maior parte das organizações hoje não fez a transição para um desenvolvimento ágil colaborativo. Os desenvolvedores e os analistas de teste ainda estão separados por limites organizacionais que acredita-se fazer sentido em termos de negócio. A separação causa ressentimento tanto técnico quanto pessoal entre as duas equipes.
O Agile provou que por meio de processos e colaboração é possível romper as barreiras entre equipes opostas, mas quando uma implementação ágil bem sucedida é colocada em prática, deve envolver a junção das áreas de desenvolvimento e de testes. Sem a reorganização adequada, não será possível obter o sucesso desejado. Ou, em termos ágeis: Não será possível entregar software em funcionamento.