ProdOps Quality Engineer

Papéis e Funções

Publicação da série sobre as diversas funções e posições em uma equipe de ProdOps, juntamente com as adaptações que o ProdOps faz no fluxo e na estrutura organizacional:

Literatura preliminar

Hierarquia de Cargos e Papéis
Expansão do Squad com Times Fixos e Times Virtuais

Especialidades ProdOps

ProdOps Tracker
ProdOps Specialist
ProdOps Quality Engineer
ProdDevOps Engineer
ProdOps Reliability Engineer
ProdOps Manager
Tech Product Manager

[ESTE TEXTO CONTINUA EM REVISÃO E DEVE RECEBER ATUALIZAÇÃO FREQUENTES NOS PRÓXIMOS MESES ATÉ UMA VERSÃO RELEASE CANDIDATE]

Introdução

Assim como a identificação da juventude e a velhice, a qualidade não se resume a um único indicador. Apesar de existirem padrões, como na avaliação da idade, a qualidade exige uma análise mais profunda para determinar seu nível e ideal.

Embora indicadores como quantidade de bugs, tempo excessivo para mudanças e lentidão na recuperação de incidentes revelem baixa qualidade, o ProdOps vai além das aplicações. Ele abrange a avaliação de processos, componentes e até mesmo da equipe, buscando identificar as causas raízes dos problemas e implementar soluções eficazes.

Engenheiro de Qualidade ProdOps

O ProdOps defende a evolução contínua e a qualidade não é um destino, mas sim uma jornada. O ProdOps promove o aprimoramento constante, buscando identificar oportunidades de melhoria e implementar as melhores práticas da literatura do setor por meio de Planos de Confiabilidade eficientes e focados no momento ideal.

O Engenheiro de Qualidade ProdOps (PQE) é um especialista em ProdOps responsável por identificar e priorizar o Toil que causa deficiências. Seu papel é essencial para melhorar a maturidade do produto, desenvolvendo um plano de eliminação desse Toil e acompanhando sua implementação.

Carreira

O PQE deve ser um especialista em ProdOps com uma profunda compreensão da jornada de qualidade defendida no Framework. Ele deve ter a capacidade de codificar os testes necessários e instrumentar o ecossistema que fiscaliza e valida tanto a trajetória das peças quanto a experiência do time. Além disso, o profissional também é responsável pela configuração dos Quality Gates acordados.

Cultura Shift-Left

A cultura de antecipar os testes consolidou-se no início do movimento ágil, principalmente oriundo do Extreme Programming, Larry Smith publicou em 2001 um artigo que cunhou o termo Shift-Left testing.

Para entender conceitualmente este termo, devemos lembrar que, anteriormente, os testes eram relegados ao final do processo. Eles eram a última etapa e frequentemente abandonados devido aos atrasos frequentes nos projetos. Por isso “Mover para a esquerda”, trazer para o início do processo.

A justificativa para mover os testes para o início do processo — agora ampliado para a qualidade em geral — é garantir a completude e a correção das funcionalidades, ao mesmo tempo que reduz os custos envolvidos. Desde o final dos anos 70, diversas literaturas relatam que pelo menos metade do esforço do time era dedicado à validação durante ou após a construção. Antigamente, isso era conhecido como UAT (User Acceptance Tests), uma fase que envolvia testes manuais realizados pelo próprio cliente, o que encarecia o projeto.

Ao longo do tempo, a cultura de qualidade foi se desenvolvendo para além dos testes, incorporando processos completos que garantem a confiabilidade do fluxo com critérios de excelência em todas as atividades realizadas, independentemente do papel de quem as executa.

O especialista em ProdOps coloca a observabilidade em primeiro lugar. Isso significa que identificar todos os pontos de melhoria na maturidade da qualidade é crucial para o plano de confiabilidade.

A instrumentação da entrega, tanto nas fases de integração quanto no Deployment, requer medidas de qualidade e níveis de maturidade. O especialista em qualidade contribui significativamente para garantir essa confiabilidade.

Diferença entre o ProdDevOps e o PQE

Enquanto o ProdDevOps está focado na jornada de experiência e automação do time, preparando ambientes e configurações, o PQE foca nos Quality Gates e transição do negócio para o código.

O PQE garantirá a identificação de Checklist específico de cada momento de validação em todos os ciclos desde o planejamento até o Software em produção e apoiará na construção e execução das automatizações necessárias ao sucesso de uma boa maturidade em qualidade.

Responsabilidades

O PQE tem um papel importante em todas as fases e ciclos, o planejamento depende de um refinamento adequado entre o desdobramento das necessidades do produto e o entendimento técnico de sua construção.

Planning é a Jornada Protagonista

A jornada de planejamento (Planning) é onde o PQE agrega mais valor, mas muitas empresas ainda não estruturam de forma adequada como o profissional pode contribuir efetivamente.

O PQE nessa fase tem duas responsabilidades básicas que podem ser trabalhadas de forma assíncronas ou por meio de cerimonias apropriadas:

Definição dos critérios de Confiabilidade

Mais do que apenas os critérios de DONE, é fundamental assegurar a qualidade da escrita das histórias. Na maioria das vezes, o Product Manager ou Analista de Requisitos não possui a profundidade necessária para escrever uma história completa.

A obra “The Art of Software Testing“, um clássico cuja primeira edição foi publicada em 1979, define um cenário bastante completo para o especialista em qualidade. Enquanto o Product Manager foca no “caminho feliz” — como atingir o resultado desejado para uma necessidade de negócio — o PQE (Engenheiro de Qualidade ProdOps) aprofunda-se principalmente no “Error Handling”. Ele cobre todas as situações que podem prejudicar o resultado e introduzir inconsistências no negócio.

O enriquecimento das User Stories nessa abordagem reduz consideravelmente o tempo necessário para refinamento e entendimento do que precisa ser feito.

Refinamento técnico das User Stories.

O PQE é o profissional adequado para refinar os artefatos funcionais com o time técnico. Além disso, ele foca na escrita técnica (Tech Writing) e conduz a garantia de “Documentação como Código” (Doc as a Code) por meio de testes de diversas modalidades, como Integração, Aceitação e Performance. O PQE consegue detalhar os passos de execução, incluindo os dados necessários, cenários, limitações técnicas e insuficiências que podem afetar a entrega, dependendo da maturidade das aplicações.

O refinamento começa com a definição dos contratos de API por meio de especificações como OpenAPI (sendo o Swagger a implementação mais comum). Em seguida, avança para soluções especializadas, como Event-Driven Data Layer, na construção do Taggeamento de soluções analíticas, como por exemplo:

Feature: Acompanhamento de Categorias com bom Ticket Medio
  Cenario: Compras acima de 100 Reais
    Dado valor no carrinho maior que "100" reais  
    Quando realizar Checkout  
    Então deveria conferir no Data Layer o evento  
    {
      event: "checkout_button",
      gtm: {
        uniqueEventId: 2,
        start: 1639524976560,
        scrollThreshold: 90,
        scrollUnits: "percent",
        scrollDirection: "vertical",
        triggers: "1_27"
      },
      value: "120"
    }
Criar uma User Story para cada evento no taggeamento e garantir que o Analytics não seja impactado negativamente por uma nova versão.

Este texto não pretende ser exaustivo em relação a todas as situações em que o PQE construirá User Stories. O objetivo é apenas evidenciar o quão abrangente e detalhado esse processo pode ser, variando conforme a natureza de cada produto.

Delivery

A estrutura clássica de construção dos testes é aprimorada por ações que conectam o planejamento à entrega, como a definição do fluxo de Pull Request e os critérios de Quality Gates nas pipelines, em colaboração com desenvolvedores e ProdDevOps.

A própria conversação, como a utilização de ferramentas como o Commitlint, garante que o fluxo de geração de Release Notes seja automatizado e siga as convenções acordadas.

A tabela a seguir define um conjunto de ações que o PQE deve ser autorizado e capacitado a realizar para garantir essa confiabilidade.

Jornada	Cohort	Ação / Atividade	Artefatos envolvidos
Planning	Refinamento prévio	Detalhamento das User Stories	User Story escrita com Gherkin
Discovery	Assessment Contínuo	Definições dos contratos	Contratos OpenAPI
Discovery	Assessment Contínuo	Definições das Interfaces	Data layer
Planning	Construção do Backlog da Iteração	Cadastro das User Stories no Backlog	Template de User Story no Issue Management
Planning	Construção do Backlog da Iteração	Critérios de validação automática do DONE da iteração	Plano de Confiabilidade com as mudanças necessárias na Pipeline de CI/CD
Dev	Build	Mapeamento da arquitetura para ambiente de validação	Desenho necessário do recorte da arquitetura para a realização dos cenários de testes
Dev	Build	Construção dos testes automatizados	Testes de Aceitação e Integração
Continuous Integration	Aprovação	Quality Gates	Faixas de tolerância para cada aplicação envolvida
Continuous Integration	Integração Síncrona	Validação local	Definição dos passos de validações da Pipeline
Continuous Integration	Integração Assíncrona	Validação remota	Definição dos passos de validações da Pipeline
Continuous Delivery	Aprovação	Validação de ambientes produtidos	Pipeline de testes de aceitação e Integração em ambientes pré-produção e produtivos
Operation	Incidente Management	Postmortem	Reajuste dos cenários com novos casos de validação