BT

Agile e a morte do departamento de QA

Postado por Eli Lopian , traduzido por Paulo Vitor Rendeiro em 25 Fev 2013 |

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.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Minha opinião sobre o artigo by Luiza Nunes

O assunto é bem polêmico e interessante, porém discordo em alguns pontos.
Trabalho como QA em projetos ágeis, e não sinto que minha função está "morrendo" ao levar em consideração que os desenvolvedores também escrevem testes e se preocupam com a qualidade do software. São pontos distintos que devem ser levados em consideração. Práticas ágeis como o TDD fazem com que os desenvolvedores estejam preocupados em escrever testes de unidade para a aplicação, e, conforme a regra, os mesmos devem falhar antes de serem refatorados para então passarem. Isso de fato melhora e muito a qualidade e a visibilidade do código. Consequentemente, os QAs recebem o software com menos propensão a falhas. No entanto, isso não significa que a aplicação já está completamente testada. Enquanto os desenvolvedores são responsáveis mais por escreverem testes unitários, os QAs, por sua vez, tem como função executar outros tipos de testes na aplicação, como aqueles mais voltados à experiência do usuário com o produto desenvolvido. Isso envolve testes funcionais, testes de integração, a escrita de cenários automatizados que verificam o comportamento do sistema sob a visão das regras de negócios, e também os testes para verificar requisitos não-funcionais, como segurança e performance. Concordo com a parte de que os QAs precisam ser multi-funcionais, pois é preciso ter conhecimento técnico para continuarmos exercendo nossa função.
Portanto, minha opinião é que o QA, sob o ponto de vista ágil, tem a mesma importância que as demais funções de um time, e exerce um papel importante para o negócio no geral - a qualidade não é assim tão facilmente descartada quando se envolve tempo, dinheiro e satisfação de um usuário. Em alguns casos, é mais racional diminuir o escopo do projeto do que sacrificar a qualidade.

Minha opinião como eterno aprendiz do assunto... by Elias Nogueira

Um dos únicos posts que parece não fazer jus de estar no InfoQ...

O autor parece ter conhecimento nenhum sobre o que é e o que faz um "Departamento de QA"

O autor mesmo utiliza alguns termos que não deveriam ser utilizados quando falamos em qualidade no geral como, por exemplo, "Fazer passar os testes unitários".
Nós não "fazemos passar o teste unitário", nós desenvolvemos testes para garantir o comportamento esperado por uma entidade (requisito, user story, stakeholder, etc...)

Outra "gafe" que o autor comete é a utilização do termo "Manter código testado é a única forma de manter o código funcionando". Ela não é a unica forma, senão a chamariamos de "bala de prata". Ela é uma das formas para manter um código funcionando.

Da pra notar também que o mesmo autor que escreve sobre QA parece nunca ter trabalhado em tal área ou entender da real dinámica de uma área de QA. Também não deve ter lido o livro "Agile Testing" da Lisa Crispin e Janet Gregory, que é a biblia sobre o assunto e fala justamente, em termos práticos o que o autor quer expressar, e não consegue em "E agora, pra onde vamos?"

Eu fortemente, como um dos comentários colocados no post original em ingles (inclusive há muitos pontos importantes lá), recomendo que muitos pontos deste post sejam desconsiderados por uma visão limitada do autor.

Re: Minha opinião como eterno aprendiz do assunto... by Leonardo Galvao

Obrigado pelo retorno sobre o artigo, Elias. Realmente há vários pontos questionáveis no artigo. Há deduções um pouco simplistas e os chamados "Non sequiturs", além de reducionismo excessivo. Por outro lado, sendo um artigo assinado, o autor tem certa liberdade para emitir as opiniões dele.

Já em notícias, que são de nossa total responsabilidade, trabalhamos forte para evitar distorções. Mas em artigos, a "rédea" é menos curta e é comum que a opinião do autor não se alinhe com a opinião do InfoQ Brasil. Vamos deixar ele se expressar e corrigir nos comentários!

QA só sabe fazer testes funcionais? by Eduardo Souza

Eli Lopian,

O modelo FURPS (acrônimo que representa um modelo para a classificação de atributos de qualidade de software) avalia os seguintes atributos em um software:
Functionality - Feature set, Capabilities, Generality, Security
Usability - Human factors, Aesthetics, Consistency, Documentation
Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure
Performance - Speed, Efficiency, Resource consumption, Throughput, Response time
Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability

Me explica como os seus testes unitários avaliariam estes aspectos em um software, por favor.

Re: QA só sabe fazer testes funcionais? by Paulo Vitor Rendeiro

Fala, Eduardo, obrigado por nos passar suas impressões sobre o artigo. Concordo com suas colocações. Durante a tradução do artigo, em vários momentos, a análise do autor sobre as atribuições dos analistas de QA foram bem simplórias. Um exemplo disso é a parte que fala que os testes unitários poderiam ser os substitutos de QA's. Mas como já dito pelo Leonardo Galvão, tentamos preservar o ponto de vista do autor. Acredito que o ponto mais proveitoso do artigo é sobre a provável futura fusão entre as áreas de QA e desenvolvimento, o que vai de encontro a formação de equipes multifuncionais.

Opinião de um grupo de QA by Luiz Felipe Garcia de Barros

Texto está desfoque da realidade e é especulativo teste unitário não desonera área de testes há situações de erros de testes manuais que nem ferramentas de testes funcionais automatizados pegam.Não adianta especular essa inconformidade com a realidade que escreveu não conseguiu descrever a morte de QA. Que é apenas um titulo de impacto,esse ser humano não tem ciência do que escreve. "Gastar menos"... mas o resultado já sabe... aplicação inconsistente e assim que esses seres perdem contratos milionários o famoso barato que sai caro.É isso ao campião.

Minha opinião by Yan Justino

Olha aí mais um artigo no qual o Agile Software Salva TODO MUNDO! Olha adoto práticas ágeis, sobre tudo, TDD. Mas reconheço que em certas estruturas oganizacionais simplismente a coisa não rola como o sugerida aqui no artigo. Eu conheço organizações com indíces acima dos 97% de aceitação do cliente e o time não adoata Testes no processo de desenvolvimento. Este índice se dá pela garantida do setor de QA. Neste cenário de indíces tão expressívos, "forçar" o time a mudar radicalmente de estratégia seria simplesmente um tiro no pé.

Testes Unitários não são garantia de Qualidade by Fabian Silva

Qualidade não é responsabilidade de uma área ou departamento de Qualidade.

A Qualidade de um Produto de Software é obtida por um somatório de forças e colaborações, que se iniciam na visão do produto, análise de negócios, análise e especificação de requisitos, decisões arquiteturais, e que por aí seguem, a cada entrega/sprint/iteração.

A qualidade é reforçada por um modelo iterativo e incremental, com verificação contínua do Produto, modelo que hoje é abraçado pelo Agile, mas que está aí no mercado há anos - faltava mais um Buzz para advogar para si os méritos do assunto. A história se repete.

A cobertura de Testes Unitários não será, jamais, a única força a garantir a Qualidade do Software; é a atuação do time, com foco em qualidade em todas as etapas do desenvolvimento, que faz a diferença.

Mudança no QA by Avelino Ferreira

Na minha empresa nós mudamos a cara do QA. Ele não fica mais inspecionando código para ver se um IF {tem ou não as chaves;}. Se o código passa ou não pelas condições. Isso é trabalho automatizado feito por ferramentas como checkstyle e JUnit.

O nosso QA faz um serviço que ainda não pode ser automatizado. Ele verifica se a interface, ações e mensagens são as melhores interfaces, ações e mensagens que o usuário poderia ter.

Ele dá aos programadores do time (nós trabalhamos o QA como parte do time) e Product Owner um feedback relevante sobre as funcionalidades a implementar e às já implementadas.

Nossa percepção é que essa abordagem de QA é muito mais eficiente e tem contribuído muito com a qualidade final do software gerado.

Mudança no QA by Avelino Ferreira

Na minha empresa nós mudamos a cara do QA. Ele não fica mais inspecionando código para ver se um IF {tem ou não as chaves;}. Se o código passa ou não pelas condições. Isso é trabalho automatizado feito por ferramentas como checkstyle e JUnit.

O nosso QA faz um serviço que ainda não pode ser automatizado. Ele verifica se a interface, ações e mensagens são as melhores interfaces, ações e mensagens que o usuário poderia ter.

Ele dá aos programadores do time (nós trabalhamos o QA como parte do time) e Product Owner um feedback relevante sobre as funcionalidades a implementar e às já implementadas.

Nossa percepção é que essa abordagem de QA é muito mais eficiente e tem contribuído muito com a qualidade final do software gerado.

Re: Minha opinião sobre o a(rtigo)utor by Derlon Aliendres

O autor acaba se equivocando nos termos, pois o que ele chama de QA, na verdade é a fiel descrição de 'Controle de Qualidadae', a qual se limita a: descobrir "produtos" defeituosos, retorná-los a linha de produção (para um possível ajuste) ou jogá-los à area de refugo.
Enquanto Quality Assuranse trabalha em todos os aspectos (e fases, se couber) da produção afim de melhorar, não apenas o produto, mas o Processo de Produção como um todo. E isto surgiu, se bem lembramos, no próprio "Toyotismo".
A QA tem partipação muito ativa e forte no grau de maturidade do Processo de Software de um Team/Organização.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

11 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT