BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Agile e a morte do departamento de QA

Agile e a morte do departamento de QA

Favoritos

A Revolução Industrial começou há cerca de 250 anos, quando as máquinas começaram a assumir o trabalho humano nas fábricas, campos e minas. É verdade que isso levou a um grande crescimento econômico; mas as máquinas substituíram o trabalhador mediano, que não conseguiu encontrar outro emprego ou aprender novas habilidades.

A semelhança com a atual situação dos testes de QA (Garantia de Qualidade) é grande. Basta olhar para a explosão de empresas especializadas em testes, como a Mercury Interactive, durante a década de 1990. Os testes de QA, assim como os departamentos de QA, foram os grandes salvadores durante o grande boom da internet na década de 1990 - quando os softwares estavam sendo produzidos a uma taxa exponencial e precisavam funcionar no momento de seu lançamento.

No entanto, à medida que a economia desaceleravam e que o orçamento diminuía, que o desenvolvimento ágil se tornava mais difundido, que a demanda por software crescia e os testes automatizados começavam a entrar em cena, o trabalho manual tornava-se mais obsoleto ao longo do tempo. E, como na Revolução Industrial, os testes manuais de QA estão ameaçados. Muitos analistas de QA estão migrando da área de Qualidade de Software para posições de verificação da qualidade através de programação e testes de desenvolvimento. A equipe de QA está mudando e integrando uma equipe multifuncional. As áreas de QA e desenvolvimento estão se unificando. As paredes estão caindo.

Vamos dar um passo atrás e examinar como as coisas costumavam funcionar. O modelo Cascata de desenvolvimento era a escolha da maioria das equipes de desenvolvimento desde a década de 50. Essa metodologia permitia que os desenvolvedores, primeiramente, focassem seus esforços na modelagem; e depois na escrita do código-fonte, o qual posteriormente era repassado à área de QA para a realização de testes; e por fim, recebiam este código de volta com o levantamento de bugs a serem corrigidos.

Como os desenvolvedores estão sempre sob pressão e nunca dentro do prazo, começaram a contar mais e mais com a equipe de QA para verificação do código. Isso criou um círculo vicioso. Mais testadores eram contratados, os desenvolvedores acabavam dependendo destes cada vez mais e passavam a testar cada vez menos o seu código. O problema se agravou, ao ponto de os desenvolvedores pararem de testar seu código totalmente.

Isso foi ineficaz tanto para os testadores quanto para os desenvolvedores, retardando o tempo de lançamento do produto ao mercado. Os produtos resultantes falhavam em alcançar os clientes dentro dos prazos.

Enquanto isso, em Fevereiro de 2001, quando a bolha das empresas de internet estava explodindo, o Manifesto Ágil foi publicado e novas formas de pensamento dos desenvolvedores começaram a emergir. Os métodos ágeis deram vida nova ao mundo do desenvolvedor, em que se requeria adaptação a cada mudança. E rapidamente, entregar software funcionando se tornou o foco das equipes de desenvolvimento. O Agile foca nos testes dos desenvolvedores, em vez de nos testes de QA. Como o Agile continua a se tornar cada vez mais difundido e eficaz, a área de QA se torna menos necessária e mais obsoleta.

Mais QA, mais problemas

O desenvolvimento de software corporativo é um empreendimento caro e muito complexo. Por isso, é muito comum descobrir que os objetivos do plano original não são alcançados e a gestão precisa decidir como responder a essa situação. Há três caminhos que uma companhia pode seguir para gerenciar o tempo de lançamento do produto ao mercado.

  1. Aumentar o orçamento - Nem sempre é possível colocar mais dinheiro em um projeto, mas, pode ser possível finalizar o projeto no prazo estimado, levando em consideração a lei dos rendimentos decrescentes. Também é necessário ter em mente que os caminhos críticos do projeto podem gerar acréscimos redundantes nos custos, e que esse não é um cenário desejado pela gestão.
  1. Economizar em funcionalidades - Nem desenvolvedores nem gestores desejam entregar aos clientes menos do que estão pagando. Definitivamente, essa não é uma opção para muitas empresas.
  2. Diminuir a qualidade - Embora defeitos sejam parte da vida, a qualidade do software é provavelmente o aspecto mais importante de qualquer produto. Mas a qualidade também é a primeira coisa a ser descartada.

O resultado é uma sensação de desequilíbrio. Os desenvolvedores ficam sob pressão (ou se tornam preguiçosos) e criam códigos com baixa qualidade. Enquanto isso, a gestão está cortando a área de QA. Há uma falha fundamental aqui; esse é o ponto onde os fundamentos ágeis podem entrar em jogo.

Qualidade em Agile

Com a popularidade do Agile em alta, desenvolvedores e gestores precisam estar aptos a encontrar o caminho para obter software de alta qualidade. Mas como em qualquer grande empresa, eram, e ainda são, as questões entre os dois lados que precisam ser trabalhadas. Contudo, uma coisa com que todos podemos concordar é que ambos querem produzir software no menor tempo possível e, no caso dos gestores, com o menor investimento possível.

Depois que a bolha da internet explodiu e a economia voltou a crescer, as companhias sabiam que precisariam desenvolver software bom sem grandes custos. É aqui que as coisas se tornaram preocupantes. Como os custos da área de QA poderiam ser justificados?

Felizmente, o desenvolvimento ágil prega que os desenvolvedores testem o seu próprio código. Fazer os testes unitários passarem garante que cada parte do código avaliado pelos testes resolve o problema em questão. Isso requer esforço da equipe para trabalhar de maneira integrada. Os gerentes de produto determinam o produto a ser desenvolvido, de forma que as necessidades de seus clientes sejam atendidas. Os desenvolvedores e testadores trabalham juntos para escrever as especificações dos testes. Os desenvolvedores escrevem os testes unitários para garantirem cada parte do código produzido. Manter código bem testado é a única forma de entregar software funcionando, que é o conceito mais importante do desenvolvimento ágil. Se escrito de forma correta, um teste unitário, validado, garante que um código-fonte se comporte da forma que o desenvolvedor pretendia.

Embora a área de QA ainda tenha o seu valor, efetuando testes de cenários alternativos, os desenvolvedores reconhecem a necessidade de assumir a responsabilidade por seu código. Um dos pilares do desenvolvimento ágil é o software funcionando. O XP (eXtreme Programming) inclui o desenvolvimento orientado a testes (TDD) como atribuições dos desenvolvedores. Os testes unitários têm como objetivo a verificação de partes do código, visando um todo melhor através dos benefícios do feedback instantâneo e contínuo, que permite que bugs sejam corrigidos de forma rápida e barata. Sem uma boa cobertura de testes unitários, é muito difícil se manter ágil, pois a arquitetura muda continuamente, e essas mudanças no software irão, em algum momento, conduzir a novos bugs. E sem o conhecimento desses bugs gerados, o desenvolvimento chega ao ponto em que nada funciona.

Testes unitários: possível substituto do QA

Os testes unitários são uma forma de testar um pedaço específico de código para garantir seu funcionamento adequadamente. Já foi demonstrado que, através de testes unitários, podemos verificar mais de 90% do código produzido. E diferentemente das ferramentas manuais dos analistas de QA, os testes unitários, se corretamente implementados e automaticamente executados, podem evoluir juntamente com os demais artefatos do software, testando o código-fonte em tempo real.

Não digo que testes unitários são a resposta para todos os problemas de qualidade em desenvolvimento de software. Como uma plataforma para testes de código, os testes unitários se justificam, pois custam menos, e ajudam a entregar mais rapidamente um software de qualidade. Quando se fala em fazer software de qualidade, os testes unitários automatizados e o TDD são as práticas mais importantes. Essa práticas permitem que os desenvolvedores adaptem seus códigos para novas funcionalidades e outras alterações em tempo real.

Os testes de QA podem ter sido os salvadores durante a bolha da internet, no final dos anos 90. Mas as empresas logo perceberam a inabilidade das equipes de QA em se ajustarem frente às mudanças na arquitetura do software. Um departamento de QA é responsável por buscar os erros que posteriormente serão passados aos desenvolvedores para ajustes. Por outro lado, os testes unitários, juntamente com o desenvolvimento ágil, prometem entregar software funcionando no momento em que sai das mãos do desenvolvedor.

E agora, para onde vamos?

No título deste artigo, deixo a entender que a área de QA está morta. Entretanto, ainda podemos observar departamentos e profissionais de QA em empresas de desenvolvimento de software. A questão é, por quanto tempo essa situação persistirá? Particularmente, sinto que é apenas questão de tempo até acontecer uma mudança dramática na direção dos departamentos de desenvolvimento de testes. Isso significa que os desenvolvedores ficarão encarregados de testarem seus próprios códigos e não poderão mais contar com uma área de QA.

Sim, ainda vão existir muitos profissionais de QA trabalhando. Acredito que veremos essas pessoas atuando como parte da equipe de desenvolvimento, ao invés de subordinados a outro departamento. O Agile requer comunicação multifuncional, assim como a queda de silos, que não são econômicos nem eficazes. Além dos custos dessa separação serem muito altos, a velocidade é outro problema de um departamento de QA tradicional. Existe apenas um caminho lógico a ser seguido: testes dos desenvolvedores. Não significa que a área de QA está morta, mas terá que se redefinir e se modernizar, não pode continuar como está. O departamento de QA terá que se mesclar com a equipe de desenvolvimento, colaborando na automação de testes unitários ou, por outra perspectiva, fundir-se à gestão de produtos, a fim de definir um produto que atenda às necessidades de seus clientes.

Conforme vamos em direção à era da responsabilidade do desenvolvedor, veremos desenvolvedores produzirem software mais limpo, funcionando da forma como deveria e com menos defeitos. Agora está nas mãos das empresas identificar onde podem economizar dinheiro e ao mesmo tempo produzir software de qualidade.


Sobre o autor

Eli Lopian é fundador e Presidente do Typemock. Antes de fundar a empresa, teve 17 anos de experiência em pesquisa e desenvolvimento, em organizações como AMDOCS e DEC, onde era responsável por otimizar o processo de desenvolvimento e liderar a transformação dos ambientes de desenvolvimento para suportar processos e ferramentas eficientes.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT