O que é um QA "Tradicional"?

Qualidade deveria focar em processos

Há alguns dias, vi uma publicação de uma empresa no LinkedIn cujo título, “O QA Tradicional está morrendo?” me deixou curioso.

Eis o que a publicação afirmava:

(1) A empresa alcançou milhares de test cases com uma equipe reduzida e apoio de IA.
(2) Dentre os milhares de test cases, além de testes não funcionais, havia também testes funcionais.
(3) A publicação afirmava que um SDET (Software Engineer in Test) pode substituir uma equipe "tradicional" de QAs.
(4) Em seguida, o post dizia que a abordagem do QA "evoluiu" para execução de testes manuais de alto valor agregado, análise crítica de cenários, colaboração com PMs e desenvolvedores e garantia de qualidade em fases estratégicas do desenvolvimento.
(5) Complementando a abordagem descrita em (4), a publicação destaca o papel do SDET em automação e monitoramento.
(6) Finalmente, a publicação encerra mostrando um quadro em que contrapõe o QA "tradicional" (que, segundo o autor, somente realiza testes manuais de scripts fixos e atua apenas na "fase final" do ciclo de desenvolvimento de software) ao "AI SDET", que gera test plans e automação com apoio de IA e participa em todo o SDLC. 

Em que pese a publicação ter um viés de marketing, pois estava promovendo um modelo de negócio específico do autor, muitos dos pontos acima têm sido bastante discutidos pela comunidade de Quality Assurance há algum tempo, e merecem ser destrinchados.

Começo dizendo que a visão de Quality Assurance “test-centered”, em contraposição à visão “process-centered”, é justamente a visão “tradicional” de QA. O surgimento de QA (tanto como disciplina, como como papel) - que, aliás, tive o privilégio de poder presenciar - trata justamente de “mover” o QA de um papel meramente de verificação (basicamente, realizando testes dinâmicos repetitivos em etapas finais do SDLC) para um papel central e crítico em todo o SDLC: desde o refinamento, passando pelo apoio na tradução de requisitos de negócio para requisitos de software, até a identificação de KPIs de qualidade importantes. Ah, e claro, realizando testes, manuais ou automatizados, mas com uma preocupação constante acerca de cobertura e de manutenção dos artefatos de teste (sejam estes scripts de teste manuais, sejam linhas de código).

Assim, quando se concentra a descrição do resultado de uma frente de Quality Assurance no número absoluto de testes, basicamente estamos descrevendo um processo “test-centered”, que é o ponto (1) acima, e que, esta sim, é uma visão “tradicional” (na medida em que esta palavra possa conter conotações negativas, o que é assunto para uma outra publicação).

Ainda sobre (1), o número absoluto de test cases não nos diz muita coisa. Tendo o apoio de IA ou não, é possível medir o quanto de cobertura (funcional, não-funcional, positiva e negativa) representam os milhares de testes produzidos? Pensando na máxima “don't test hard, test smart”, eu me lembro de ter acompanhado equipes com um número impressionante de cenários de teste em suas bibliotecas, mas com número elevado de bugs em produção, ao mesmo tempo em que, em oposição, já vi equipes com bibliotecas enxutas que, graças a um bom processo de QA em todo o SDLC, mantinham excelente persistência funcional e não-funcional da aplicação. Meu ponto é que um número absoluto de cenários de teste não traz muita informação (qual foi a evolução de bugs e de custo de bugs com este conjunto de testes? o que se aprendeu sobre causas-raiz? como está a estabilidade da aplicação em produção?). É preciso estabelecer correlações e métricas cruzadas para começarmos a entender se este número de cenários é adequado. É claro que a IA pode e deve ser usada para complementar o trabalho dos QAs, automatizando tarefas repetitivas e liberando-os para atividades mais estratégicas, mas é preciso cuidado, especialmente com fatores mais “subjetivos” como a correlação negócio/funcionalidade.

O uso de IA é ótimo (ponto 2 acima), mas me preocupa um pouco uma certa falta de análise crítica, especialmente no que diz respeito a cenários funcionais. Um dos grandes desafios de desenvolvimento de software (desafio antigo que persiste até hoje) é entender exatamente qual é o problema do mundo real que o software se propõe a resolver, e, como corolário, quais são os requisitos funcionais de software correspondentes. A IA é muito bem-vinda aqui como apoio, mas não substitui a interação contínua humana que precisa haver (inclusive com a participação dos QAs) entre stakeholders, POs, PMs e desenvolvedores. Neste sentido, eu poderia perguntar: os cenários funcionais desenvolvidos com o apoio de IA estão sendo continuamente verificados contra os requisitos de negócio? Ou estamos “testando” funcionalidades derivadas de regras de negócio mal compreendidas? Ou existem regras de negócio críticas que não têm cobertura nos milhares de cenários? Aliás, sobre a verificação contínua dos cenários de teste, ver meu artigo anterior, em que falo sobre meta-qualidade.

Em (3), a “substituição” de uma equipe de QAs “tradicionais” por SDETs pode ser um sofisma, dependendo do que se entende por QA tradicional e por SDET. Como disse anteriormente, se a abordagem “não-tradicional” é meramente test-centered, por favor, não façamos esta substituição! Estaremos perdendo a capacidade crítica de um bom Engenheiro de QA que se envolve em todo o SDLC (e que também codifica e automatiza) por coders. E quem testa o código dos SDETs? Novamente esbarramos na falta de ações de meta-qualidade, especialmente num volume tão grande de cenários de teste.

No ponto (4), o autor menciona que o papel do QA “evoluiu” para a participação em diversas fases do SDLC (mesmo ponto, aliás, descrito no quadro que mencionei em (6)). Ora, como disse antes, a participação de um QA em diversas fases do SDLC já é preconizada há bastante tempo, e, se tal participação é vista como “evolução", parece-me que o papel original, que supostamente evoluiu, não era de QA, mas, sim, de mero Tester. Acompanho equipes de QA realizando shift-left já há algum tempo, e vejo que tais exercícios são uma ótima maneira, isto sim, de realizar um “upskilling” em Testers. Em tempo: a realização de atividades de QA em diversas fases do SDLC já é prescrita desde os primeiros modelos CMM. O mesmo vale para ações “shift-right”, como monitoramento, descrita no ponto (5).

Aqui vamos falar bastante sobre Quality Assurance e sobre o profissional de QA. Mas já adianto: Qualidade não é só teste.

O futuro de Quality Assurance reside em equilibrar a eficiência e a escala proporcionadas pela automação (e pela IA) com a expertise crítica e o foco no cliente que são inerentes a um bom processo de QA (e a bons profissionais de QA). A qualidade percebida pelo usuário final, afinal, é a verdadeira medida do sucesso de qualquer software, independentemente de quantos testes foram executados ou de quais tecnologias foram utilizadas.