BT

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

Contribuir

Tópicos

Escolha a região

Início Artigos Painel Virtual: QAs Técnicos: Evolução ou Revolução?

Painel Virtual: QAs Técnicos: Evolução ou Revolução?

Favoritos

Convidamos quatro especialistas das comunidades de desenvolvimento e testes para um painel sobre QAs Técnicos. Nele, são discutidas questões atuais da comunidade de testes, tendências e a polêmica do "testador que programa" e mais. Os painelistas convidados foram: Jorge Diz (Maps S.A.); Bruno Abreu (Sofist), e Camilo Ribeiro e Guilherme Motta (ambos da ThoughtWorks).

InfoQ Brasil: Aponta-se para uma transformação na área de Qualidade e Testes, em que é maximizada a importância de QAs técnicos. Você concorda com esta corrente? O QA técnico seria uma evolução do analista de testes tradicional?

Jorge Diz: Tenho a visão também de que faz falta um viés mais técnico a muitos especialistas em qualidade. Isso não tem a ver apenas com poder codificar em uma linguagem de programação: o perfil do especialista em qualidade precisa ser o de buscar conhecimento técnico nas áreas que se mostram relevantes no contexto em que atua. "Isso é técnico" parece ser a desculpa padrão quando há preguiça em se aprofundar. É óbvio que não é necessário se especializar em tudo, mas é muito bom adotar a postura de correr atrás de conhecimentos sobre o que afeta mais a qualidade no contexto em que o profissional atua. Em alguns casos, pode ser entender protocolos de rede ou infraestrutura de segurança. Em outros, pode ser necessária uma imersão no ramo de negócio do cliente.

Camilo Ribeiro: Acredito que o desenvolvimento ágil de software mudou a forma como trabalhamos, desde a forma como lidamos com o cliente até a forma como os times se organizam.

De forma indireta, essas mudanças tendem para o fim dos papéis e departamentos restritos a um tipo de atividade e para a popularização de um time multidisciplinar, auto-organizado e focado em resultados. Nesse novo contexto, qualquer um no time pode ser um desenvolvedor ou QA, de acordo com o momento do projeto. Claro que outros fatores, como as preferências dos profissionais e as habilidades não técnicas influenciam na carreira das pessoas, e é comum se optar por trabalhar mais como QA, desenvolvedor ou Analista de Negócios, por exemplo. E claro, não existe problema em uma pessoa direcionar sua carreira focando em atividades de QA.

A questão é que, hoje em dia, a forma de manter a saúde de um projeto é muito mais focada em prevenir defeitos do que em encontrá-los, o que acaba indo contra antigos modelos de testes de software, baseados principalmente em grandes documentos e planos, na execução manual de testes e na resistência a mudanças. As principais formas de prevenir esses defeitos não são os testes exploratórios tardios ou a documentação extensa, ou ferramentas de controle, como na década passada. A prevenção é suportada por tecnologias como integração continua e BDD (Behavior-Driven Development) e por técnicas e metodologias como Agile e continuous delivery. Não vejo esse QA técnico como uma evolução do analista de testes tradicional - e sim como uma adaptação deste profissional para trabalhar em projetos ágeis e em ambientes colaborativos ou que ofereçam esses desafios tecnológicos, como startups.

Acredito que, caso o QA, além de especialista em testes, tenha uma formação técnica sólida em desenvolvimento e infraestrutura, ele/ela pode se mostrar muito mais produtivo e eficiente do que um QA sem o mesmo conhecimento.

Bruno Abreu: Já observo esse comportamento em grandes empresas nos EUA há alguns anos, na qual temos QAs trabalhando com foco em aumentar a produtividade das equipes de desenvolvimento e de testes. Enxergo o QA técnico como grande diferencial para as empresas; as empresas que possuem gente com esse perfil estão na frente.

Sobre ser uma evolução, penso que o QA técnico já existia antes - só que ninguém dava importância para o trabalho dele. Logo, ele não aparecia. Quando começaram a falar de automatizar testes, processos etc., aqueles com forte embasamento em programação e que trabalhavam na área de qualidade se destacaram naturalmente.

Acredito fortemente que as empresas investirão cada vez mais em aumento da produtividade e redução de custos. E para escalar, os QA técnicos serão fundamentais. Para quem não é QA técnico, é uma evolução possível; mas novamente, para mim este profissional já existia, mas não era reconhecido.

Guilherme Motta: Existe um movimento em que se aproximam as funções e papéis dos membros da equipe que desenvolvem software. Ao mesmo tempo que os QAs precisam possuir conhecimentos básicos referentes à programação, muitos desenvolvedores precisam aprender que o TDD não é uma prática realizada somente "para o teste" e sim para o design do software que está atendendo a um problema ou objetivo. Acredito em times que possuem um papel, o de engenheiro de software (ou qualquer outra denominação deste papel); acredito em times em que as pessoas possuem suas áreas de expertise (QA, Dev, Ops, PM/IM etc.) mas podem desempenhar múltiplas funções em determinados momentos do projeto.

Não vejo como uma evolução, mas sim como um complemento. Na área de qualidade, temos dificuldade em definir quem é QA, quem é analista de testes e quem desempenha outro papel. Vejo o QA como um profissional responsável por todo o processo de garantia da qualidade do software. Ou seja, além de possuir a responsabilidade de testar e escrever testes automatizados, esses profissionais também devem analisar e avaliar o processo de desenvolvimento como um todo e propor melhorias. Já o analista de testes, visualizo-os como profissionais mais focados nos testes e não tanto no processo.

InfoQ Brasil: Em relação a garantia da qualidade de software, um QA técnico supera um "desenvolvedor que testa"? Caso positivo, em quais aspectos?

Jorge Diz: Acho que isso tem muito a ver com o perfil de cada profissional. Há certos traços de personalidade que favorecem a atuação na área de qualidade: é preciso ser crítico, não ter medo de melindrar os outros e ser um pouco paranóico em relação a riscos.

Esperar que a maioria dos desenvolvedores tenha esses mesmos traços não é realista: por natureza, o desenvolvedor é fascinado por ver algo funcionando, e não por achar furos em algo que supostamente funciona. Uma pessoa que não fique acanhada em dizer que o imperador está nu, e conseguir mostrar isso aos outros falando a mesma língua, é muito valioso em projetos de software.

Camilo Ribeiro: Atualmente muitos projetos não veem mais tanta diferença entre os profissionais de QA e desenvolvimento. Todos se preocupam, de forma bem parecida, com a qualidade do que será desenvolvido. E muitas vezes a figura do QA é um papel que um par de membros do time usa a cada iteração, ou qualquer outro período de tempo que a equipe use para se organizar.

Mas os profissionais de testes, de forma geral, são mais vinculados a aspectos de negócio e mais centrados no usuário do que os desenvolvedores. Estes muitas vezes não veem tanto valor em testes "sem sentido" que usualmente criamos; além disso, também se preocupam mais com os riscos do projeto do que os desenvolvedores.

No dia a dia, o testador consegue enxergar de um outro ângulo. Diferentemente do desenvolvedor que foca na implementação, os QAs focam no negócio. Eu diria, que no ponto de vista de testes, o desenvolvedor se preocupa muito com os testes estruturais (comportamento interno), enquanto um QA dá mais atenção para os testes funcionais (comportamento externo).

Bruno Abreu: Vejo papéis diferentes: as duas funções se complementam. Vejo o QA técnico como uma pessoa que viabiliza os testes do desenvolvedor, buscando aumento de produtividade. O desenvolvedor deve criar os seus testes unitários e deve ser 100% comprometido com a qualidade do que cria. O QA técnico, como não possui tanto conhecimento em testes e qualidade, é o profissional que vai ajudá-lo a fazer um bom trabalho com os testes unitários. Além disso, vai ser responsável pelos testes de integração, enquanto o desenvolvedor está focado em criar e evoluir funcionalidades.

Não vejo uma relação em que um supera o outro, mas uma relação em que os dois se complementam. São responsabilidades diferentes; pense que o desenvolvedor planta e evolui a sua árvore, se comprometendo a cuidar muito bem dela, enquanto o QA técnico cuida da floresta da forma mais eficiente possível, criando mecanismos que garantam que a floresta está em plena harmonia.

Guilherme Motta: O mindset de um desenvolvedor que testa e de um QA (sendo ele técnico ou não) são diferentes. Um fator crítico para os testes é que tenhamos pessoas diferentes, independente de cargo, para realizar tarefas de teste, verificação e validação do que produto entregue. Quando quem desenvolve acaba testando ou em situações em que o QA está desenvolvendo em conjunto ao desenvolvedor e os mesmos testam o software, potencializa o risco de ocorrerem erros e eventuais problemas na aplicação. Idealmente, o QA e o desenvolvedor possuem o mesmo objetivo: manter a qualidade em um nível que seja condizente com a aplicação que está sendo desenvolvida.

InfoQ Brasil: Na sua opinião, um profissional de QA deve programar? Deve implementar os testes funcionais?

Jorge Diz: Acho que há vários nichos em que um QA pode atuar sem precisar programar, mas esses nichos estão se tornando mais raros, menos interessantes e pior remunerados. As equipes de projeto são cada vez menores, e alguém que não programa fica limitado para exercer seu trabalho de maneira eficaz. De fato, não se trata apenas de programar, mas sim de conseguir apoiar as outras pessoas da equipe em tarefas relacionadas à qualidade, como por exemplo participar de decisões de arquitetura para favorecer a testabilidade de componentes.

Não gosto muito da expressão "testes funcionais". Em geral, é empregada como sinônimo de testes através da interface com o usuário. Vejo um esforço exagerado em definir esses testes, enquanto aquilo que a aplicação faz por baixo dos panos, aquilo que seria mais apropriadamente descrito como teste funcional, não é feito adequadamente. Seja qual for o significado atribuído a "testes funcionais", o especialista em qualidade precisa fazer sua parte na implementação deles. Não é saudável que o faça sozinho, e sim procurando a parceria de quem entende muito bem do negócio.

Camilo Ribeiro: Depende principalmente do ambiente em que o analista de testes ou QA está inserido. Em um projeto ágil por exemplo, onde um analista de testes recebe um conjunto de histórias de usuário que serão detalhados, desenvolvidos e testados em um período bem curto, mas que devem ser mantidos ao longo de todo o projeto, é essencial que esse profissional saiba programar para manter os testes automatizados e evitar o retrabalho nas próximas iterações.

Já um profissional que trabalhe em um ambiente tradicional, onde existe uma fase de testes no final do projeto, e muitas vezes ele tem uma visão superficial dos requisitos do projeto e um tempo curto para testar o projeto, pode ser que para esse caso, ele não precise desse conhecimento, afinal, ele vai testar o projeto, entregar e iniciar um novo projeto na fábrica.

Entretanto, existem outras razões para que um QA aprenda a programar, entre elas, estão a facilidade em encontrar problemas uma vez que você sabe como o sistema sob testes funciona, o vocabulário, ajuda a entender os problemas do projeto e a questionar tecnicamente os desenvolvedores e outros envolvidos.

Resumindo, eu não acho que todo QA deve saber programar, mas definitivamente precisamos de mais QAs técnicos, pois nossa comunidade é muito carente de inovação em testes de software.

Bruno Abreu: Se tem formação na área de computação, certamente o QA deve programar, pois afinal de contas ele aprendeu a programar e a criar algoritmos. Sou mais tolerante em relação a profissionais que não são de computação - logo não vejo que eles "devam" programar. Se souberem programar, certamente estarão na frente dos que não sabem.

Uma vez que a pessoa sabe programar, nada mais justo do que ela automatizar testes funcionais utilizando uma linguagem de programação de sua preferência.

Guilherme Motta: Um profissional de garantia da qualidade deve sim ser capaz de programar, ler código e corrigir pequenos defeitos. Testes automatizados também envolvem, claro, atividades de programação. A responsabilidade de implementar os testes funcionais deve ser do time como um todo, independentemente de função, cargo ou papel no time. A expertise do QA deve ser em testes mas é preciso que entenda conceitos relacionados ao domínio do negócio, programação etc.

InfoQ Brasil: O movimento DevOps e a integração contínua são uma alternativa aos QAs?

Jorge Diz: O movimento DevOps está sofrendo de maneira acelerada do que se costuma chamar "difusão semântica": virou uma descrição de cargo, sinônimo de analista de suporte. O conceito de DevOps, como originalmente proposto, tem a ver com tratar a infraestrutura como componentes de software. Em deploys e no provisionamento de serviços em máquinas virtuais, em alguma infraestrutura de nuvem, isto chega a ser literal.

Acho muito promissora a aplicação dos conceitos de DevOps, como deployment contínuo, à qualidade. Grande parte dos problemas, dos custos e dos riscos de qualquer aplicação acontece em produção. Não faz sentido dizer que uma solução está estável quando foi executada apenas em ambiente de desenvolvimento ou, com sorte, em um ambiente de homologação razoavelmente similar.

Considerando "QA" em sentido bem restrito, como uma etapa do controle de qualidade separada, depois de gerar uma versão, diria que o esforço aplicado nisso vai passar a ser menor. As empresas, cedo ou tarde, vão diversificar o investimento em qualidade, deixando de colocar todas as fichas em testes sobre um produto final.

Aliás, tratar software como um produto acabado é algo discutível.

Camilo Ribeiro: Acredito que não o DevOps não seja uma alternativa aos QAs. Em partes, o DevOps absorveu alguns pontos que pecamos como QAs - justamente pela ausência de conhecimento técnico que o modelo tradicional criava sobre os QAs.

No meu ponto de vista, o QA deve ser uma pessoa capacitada, por exemplo, para cuidar do build e dos ambientes. Estas atividades são atualmente atribuições mais comuns de um desenvolvedor, de um Ops ou de um Devops. Contudo, acredito que o DevOps é uma reação à necessidade de times multidisciplinares. E mesmo que os QAs fossem técnicos ainda precisaríamos dos Devops.

Já a integração contínua, desde sua criação, sempre foi a melhor amiga do QA, evitando um enorme esforço em testes de regressão manuais. Porém, por mais que a integração contínua substitua um QA para execução de testes funcionais e não funcionais, ainda precisamos de QAs para planejar e escrever esses testes.

O DevOps é um profissional com background forte em desenvolvimento, sólido conhecimento em infraestrutura e habilitado para executar testes funcionais e não funcionais, principalmente do ponto de vista técnico. Normalmente os DevOps possuem o mesmo conhecimento de negócio que um QA. Por esse motivo, estes profissionais não podem ser vistos como um substituto para QAs.

Acredito que um projeto pode sobreviver muito bem somente com DevOps, mas provavelmente alguns desses DevOps são mais "Dev" (focando na implementação) do que Ops/QA, outros são mais Ops (focando mais na infraestrutura) do que Dev/QA. E é claro que alguns são mais QA (focando mais nos testes e no negócio) do que Ops/Dev também.

Vejo que muitos bons QAs hoje vão migrar para uma posição de DevOps em breve, mas não vejo isso como risco para os testes de software - e sim como uma maneira de reciclar o conhecimento. Tenho certeza que o DevOps e continuous delivery serão fortes influenciadores dos testes de software de agora em diante.

Bruno Abreu: Não vejo DevOps como alternativa ao QA. Na minha opinião trata-se de um complemento. Se cada um realiza sua função na equipe de forma muito integrada, com a maior parte dos processos automatizados, é possível entregar software de alta qualidade muito rápido. Vejo uma questão cultural, onde todos devem estar muito comprometidos com qualidade e produtividade. Para mim, sempre teremos os QAs, pois senão teremos problemas de foco dentro da equipe (qual o meu papel neste processo?), o que torna o trabalho improdutivo.

Guilherme Motta: DevOps e integração contínua estão relacionados com a garantia da qualidade - mas não substituem de forma alguma o trabalho de QA. A integração contínua nos auxilia a integrar o código mais frequentemente e a verificar se problemas foram criados em outras áreas da aplicação, após cada alteração no código. O DevOps é um movimento que busca aproximar os profissionais que desenvolvem o software (QAs, Devs, Analista de Negócio etc.) com os profissionais mais focados em infraestrutura, suporte e negócios. Um ambiente em que é seguido o movimento DevOps, que possui integração continua, exige que o processo de garantia da qualidade seja o mais automatizado possível - tanto para testes quanto para deploy.

InfoQ Brasil: Que recomendações você faz a um profissional iniciante na área de testes e qualidade?

Jorge Diz: Procure trabalhar numa empresa que tenha cultura de excelência, ou onde pelo menos pessoas chave tenham consciência da necessidade de trabalhar da melhor maneira. Estar em um papel para cumprir tabela é muito desanimador. E tentar implantar práticas de qualidade quando nós mesmos não temos uma boa base fica muito difícil.

A gente aprende quando é desafiado. Ser o único QA numa equipe força você a adquirir habilidades e conhecimentos que não aprenderia em ambientes onde seu papel está preso a processos engessados desenhados por outros, como acontece nas fábricas. Tente entender a dinâmica dos projetos em que participa para encontrar os pontos onde vale a pena investir esforçoa e que tem um efeito positivo sobre a qualidade: não necessariamente estas ações envolvem a escrita ou a execução de testes.

Esqueça a procura por "melhores práticas": elas não existem. Não peça templates disso ou daquilo nas listas de discussão: fique atento aos mecanismos de comunicação que podem funcionar dentro do seu contexto.

Esqueça a ideia de que precisa registrar e evidenciar tudo. Ao contrário do que dizem alguns livros, o principal objetivo doa testes não é achar o maior número possível de defeitos: é prover mecanismos de alarme para saber onde estão os problemas para que se possa agir sobre eles.

Perceba que testes podem ser sensores de um processo mas que também podem ser atuadores. Em outras palavras, não separe qualidade de processo e qualidade de produto.

Camilo Ribeiro: Estude. Não deixe de aprender coisas novas simplesmente porque alguém falou "você não precisa aprender isso". A área de testes de software é muito promissora - e ela não está morrendo, mas sim passando por uma transformação que não deve ser vista como uma ameaça, mas como grande oportunidade.

Um bom profissional de testes de software que domina desenvolvimento de software e infraestrutura, e tenha interesse por requisitos não-funcionais, já é um profissional muito diferenciado. Nos próximos anos, mais e mais empresas estarão procurando por esses profissionais para implantar modelos como Continuous Delivery e Specification by Example. Isso já acontece em vários países e já não é tão raro ver empresas brasileiras se preocupando com essas questões.

Guilherme Motta: Se você esta entrando na área de testes porque não gosta de código, procure outra profissão.

Bruno Abreu: Para aqueles que não programam, recomendo que aprendam a programar e que coloquem isso em prática. Temos que aprender a gostar disso, pois facilita nossa vida absurdamente. Já vi muita gente da área de computação que dizia saber programar e automatizar testes e processos, mas na hora crucial, não conseguiram. Quando questionados, vinham com a argumentação fraca de que trabalhavam com testes e não com programação.

E para aqueles que programam, aprofundem-se em novas tecnologias, para aumentar seus conhecimentos e seu leque de alternativas para problemas que ainda estão por vir. Ajudem a equipe de desenvolvimento a se comprometer com a qualidade; é difícil, mas vocês verão resultados. E por último, digo que vocês estão no caminho certo.

Lembrem-se de que testes são muito interessantes, principalmente se fora usada a programação como aliado. Além disso, realizar testes não se resume a clicar o dia todo em links, campos, botões etc. - a não ser que você não queira fazer a diferença na empresa em que trabalha. Leia livros técnicos, de preferência os estrangeiros: compromisso com qualidade lá fora já é realidade há muitos anos.


Sobre os participantes

  • Jorge Diz, aprendiz de tecnologia da informação, desenvolve, testa e tenta entender software há quase três décadas. Com frequência palestra em eventos técnicos e participa da organização de outros, como o TDC. É Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, ambos pela UNICAMP. Atualmente trabalha como desenvolvedor de produtos para o mercado financeiro na Maps Soluções e Serviços. Seus interesses incluem qualidade de software, dinâmica de equipes de desenvolvimento, e linguagens de domínio.
  • Camilo Ribeiro é Sênior QA Consultant na ThoughtWorks em Porto Alegre. Trabalha e estuda o mundo de desenvolvimento e teste de software desde 2005, e desde 2006 tem se dedicado aos testes de software. Acredita em QAs técnico e pratica Agile. Gosta de automatizar processos e de discutir as melhores soluções com o cliente.
  • Bruno Abreu, co-fundador da Sofist e do One Day Testing, já participou em quase uma centena de projetos dos mais variados tipos na área de testes e qualidade de software. É apaixonado pelo estudo de formas de tornar QA mais eficiente e eficaz, e acredita no trabalho de QAs se tornando cada vez menos manual e menos repetitivo. É Mestre em Ciência da Computação pela UNICAMP e Bacharel em Ciência da Computação pela UFMG. Acompanha ativamente o curso de especialização em engenharia de software da UNICAMP desde 2005, especificamente nas disciplinas de V&V e Manutenção.
  • Guilherme Motta trabalhou durante grande parte da sua carreira como consultor em diferentes companhias, com culturas e processos distintos. Nesses projetos, atuou como engenheiro e analista de testes, QA, analista de segurança, desenvolvedor, IS, além de em diversos outros papéis multifuncionais. Atualmente é Consultor Sênior da ThoughtWorks Brasil, advogando o Agile em projetos internacionais e em diversos eventos da comunidade de desenvolvimento.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

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

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

BT