Qualidade. Sem Testes.

Qualidade não é apenas testar, apesar dos estereótipos. Além disso, é da responsabilidade da QA de realizar os testes?

Trabalhamos esse tema durante a nossa última mesa redonda “Qualidade. Sem testes.”. Este artigo resume os principais pontos que compartilhamos.

A qualidade do software ainda é frequentemente encontrada apenas associada aos testes. Desafios reais de percepção de valor, comunicação e colaboração estão no cerne desta questão.

Agradeço aos participantes por sua presença e contribuição:

Arnaud Dutrillaux, Senior Quality Engineer na La Javaness
Benjamin Butel, Coach Agile na Klaxoon
Christophe Moustier, Especialista em Qualidade e Teste na Inetum, Autor
Farah Chabchoub, Head of QA na Livestorm & Speaker
Iman Benlekehal, Especialista em Qualidade de Software
Olivier Dennemont, Head of QA na Manomano

Junte-se à QE Unit para aceder a mais conteúdos exclusivos da comunidade.

A qualidade começa (cresce e termina) com a cultura

“Testes? Tem que ver com o QA”, uma frase que ouvimos regularmente, sem necessariamente haver disputa. Esse mito é amplamente difundido e aceito na indústria de software. Códigos, crenças e práticas compartilhadas que são a base de uma cultura. Os atores atuam de acordo com sua cultura, para definir, construir e manter software.

Alcançar a qualidade, portanto, requer uma evolução da cultura da organização.

Como algumas tribos que desenvolveram códigos completamente diferentes, algumas organizações valorizam a qualidade de maneiras diferentes. Spotify é um bom exemplo que resultou em uma abordagem de produto bem-sucedida, escalável e sustentável. Benjamin traçou um paralelo entre o nível de qualidade e nossa escolha de produtos reais: baixo, médio ou alto padrão.

“Temos de confirmar a qualidade que quer a gestão; um produto descartável de baixo custo, um barato por 2 anos ou melhor?”
Benjamin Butel

Para outras culturas, de startups ao Fortune 100, a qualidade é muitas vezes um modelo de baixo custo; desenvolvemos novamente a cada 2 anos, mantendo e acumulando dívida técnica até a próxima parede. Frequentemente associa-se QA com testes no fim da linha depois dos desenvolvimentos realizados, sem contacto com o negócio, e ainda menos com o cliente.

Esta segmentação do QA é um dos principais problemas para uma qualidade mais transversal. Olivier partilhou connosco a sua experiência pessoal, onde o contacto direto com os utilizadores do produto – e em particular o feedback deles – o alertou sobre a qualidade.

“A proximidade com os utilizadores me sensibilizou sobre a qualidade do produto desde muito cedo.”
Olivier Dennemont

Essa proximidade nos lembra que software não é apenas código; é uma solução que deve ser útil para alguém. Essa empatia é necessária, podemos facilmente perder de vista o cliente imerso em nossas questões tecnológicas.

Voltando à cultura, os códigos e palavras estabelecidos são poderosos e reveladores. A equipe de QA é materializada por um silo organizacional no organograma? O líder da equipe tem um título de “Líder de Testes”? Os membros da equipe falam sobre testes, qualidade ou valor ?

São todas variáveis que influenciam a percepção da qualidade da organização. A qualidade é, portanto, estruturante, começando por nós mesmos; Estamos falando do negócio? Estamos em contato com o cliente? Trabalhamos para diminuir as prioridades estratégicas em os eixos da qualidade?

O trabalho começa por nós mesmos, antes de ampliar nosso impacto no resto da organização. As mudanças culturais demoram tempo e, por isso, devem ser iniciadas o quanto antes.

O primeiro passo é construir uma visão compartilhada por meio da colaboração.

Co-construir um objetivo corporativo comum, apoiado na qualidade

A colaboração de diferentes atores ao nível de uma empresa será sustentada pela sua cultura e pelos seus objetivos comuns. Sem esta estrela, as forças locais terão vantagem em detrimento do desempenho geral do sistema.

Garantir a qualidade deve, portanto, ser um objetivo comum e unificador; uma pista, não é a qualidade de software como tal. Vamos dar um passo atrás antes de falar sobre Shift-left, Shift-right, DevOps, microsserviços ou Holistic Testing.

A aplicação dos princípios “First Things First” e “Start With Why” são mais do que relevantes aqui. Iman compartilhou o termo “Shift-up and Spread” para começar nosso pensamento, apoiando o foco na empresa e em seus clientes antes de ampliar nosso prisma.

“Antes de falar sobre Shift-left ou Shift-right, a Qualidade deve identificar o valor em Shift-up.”
Iman Benlekehal

Voltamos ao “porquê” inicial da organização por meio de sua missão, visão e valores. Esta motivação de existência deve traduzir-se em objetivos internos e externos, em particular para os clientes. A repartição dos imperativos de qualidade deve derivar desta razão de ser, que é apoiada em vários níveis.

Primeiro, nossa abordagem deve envolver as várias partes interessadas em workshops colaborativos, desde os patrocinadores até a equipe operacional. Iman compartilhou conosco o objetivo principal de alinhar as prioridades de qualidade, além das percepções individuais iniciais. Farah também compartilhou suas práticas nesta entrevista: A qualidade, das operações até o conselho de administração.

Em segundo lugar, a proposição de valor de qualidade deve trazer a visão de negócios o mais próximo possível da de TI. O surgimento da digitalização de empresas é uma oportunidade a ser aproveitada na articulação do valor da qualidade. Podemos encontrar elementos de excelência na experiência do cliente, nas iterações de desenvolvimento de negócios ou na confiabilidade de nosso backbone corporativo.

Surgiram modelos de atores importantes que tiveram de abordar questões semelhantes, além do mais, em escala. A Google, por exemplo, mudou seu conceito de Site Reliability Engineering (SRE) para Customer Reliability Engineering (CRE). Essa viragem interessante mostra a transversalização das práticas e a força das palavras escolhidas.

O nosso valor é de articular uma proposta de valor de qualidade, identificando escolhas relevantes em nosso contexto. Temos um forte dever de consultoria de trazer à tona as questões invisíveis do negócio e os trade-offs que elas envolvem. Arnaud compartilhou a necessidade duma qualidade integrada, especialmente em ambientes dinâmicos.

“Acelerar os ciclos de entrega requer uma qualidade transversal e inclusiva, não há outras opções.”
Arnaud Dutrillaux

Ultimamente, a qualidade que queremos co-construir deve ser reforçada por mecanismos de reforço, ou de feedback loops. É aqui que a inclusão de patrocinadores e influenciadores é mais do que relevante para as ações de comunicação, arbitragem e defesa de qualidade, principalmente quando a pressão aumenta. Christophe mencionou a importância dos ciclos de aprendizagem duplos que detalharemos a seguir.

Os patrocinadores também são necessários para mudar a organização, um elemento estrutural da melhoria da qualidade.

Passando do Quality Assurance para o Quality Assistance

Um organograma por si só terá pouco impacto na dinâmica de uma organização e em suas atividades. As famosas reorganizações idealizadas que se revelam demoradas e sem qualquer melhoria são um exemplo disso. Os indivíduos, suas interações e objetivos estão no cerne do sistema organizacional.

Portanto, vamos voltar ao posicionamento de qualidade. Muitas vezes encontramos uma equipe de QA de silo para ser chamada de alguma forma em diferentes projetos e garantir essa famosa qualidade. Este modo de organização tenderá a consultar o QA assim que for sentida a necessidade de BDD, teste ou outro. É tarde demais para produzir qualidade, quanto mais entregar o valor da qualidade em upstream.

“A realização de atividades de teste reforça o sentimento de ownership da qualidade”
Olivier Dennemont

Portanto, só temos que fazer um modelo à la Spotify, incluindo perfis horizontais de QA, em belos slides de agilidade em escala para nossos patrocinadores. Esses modelos devem ser adaptados ao sistema como um todo: a cultura da empresa, a arquitetura organizacional e de produto. Além disso, a horizontalização da função reforça a necessidade de uma animação vertical de uma real prática, se quisermos manter um mínimo de consistência.

Infelizmente, mesmo que esses modelos influenciam a dinâmica da organização, eles não vão ao cerne do problema: fazer qualidade requer uma inclusão estrutural nos diferentes processos. Também podemos falar do conceito de criar capacidades a esse efeito.

Fazer qualidade implica capacitar outros atores além do QA sobre a qualidade, não apenas nos slides. Devemos agir na realidade mudando as interações, as posições e os tipos de atividades realizadas.

“Na Manomano, as equipes de QA não fazem mais testes para os outros; somos uma equipa de Quality Assistance”.
Olivier Dennemont

Integrar a qualidade parece óbvio. Ainda assim, quantas dessas reorganizações de agilidade de escala incluem um plano de mudança de cultura, visão compartilhada e realocação de função para uma qualidade integrada? Não a maioria, tendo em vista o ecossistema que continua associando qualidade com teste. Alguns modelos adaptativos estão surgindo, como o X-teams.

Uma consequência concreta é a evolução do papel do product manager e do engineering manager, que tem de levar em consideração uma qualidade mais global; esse é um bom assunto para o desenvolvimento organizacional. Alguns modelos defendem o desaparecimento de gestores, não é necessariamente o assunto se eles forem substituídos por coaches em craftsmanship ou a mais recente ferramenta de feedback colaborativo à moda.

Este conceito de Quality Assistance materializa com mais clareza as responsabilidades esperadas de cada equipe. Este não é o único conceito que pressiona por mais responsabilidade das equipes multifuncionais, ao mesmo tempo que lhes fornece ferramentas: podemos mencionar o engineering productivity ou a developer experience.

Além disso, a sigla QA possui outra variante disponível nas referências, a de “Question Asker”.

Permitindo a priorização da qualidade no centro dos processos

Esta seção começando com a palavra “priorizar” pode fazer perder o link com o “Question Asker”. Fazer qualidade enquanto num role de QA exigirá cada vez mais o suporte das equipes de produto e jogadores da linha de frente. Perguntas relevantes e abertas apoiarão as equipes em sua inclusão de qualidade.

Muitas vezes estimamos erroneamente nosso nível de compreensão de um assunto, questionar com toda a humildade já é uma prática de qualidade. Se também queremos impactar sem estarmos no palco, fazer perguntas com valor agregado mostrará o interesse em interagir com equipes de qualidade.

A qualidade integrada também deve ser alcançável. Entregas aceleradas, complexidade de produtos e organizações exigem um modelo escalável de inclusão de qualidade. Adicionar perfis de controle de qualidade não escala, além de ser ineficiente. A priorização deve, portanto, ser realizada pelos jogadores do produto, auxiliados pelas equipes de qualidade em sua abordagem, priorização e implementação.

“Estamos aqui para ajudar as equipes a testar em upstream, na forma como trabalham e não no produto acabado.”
Olivier Dennemont

Os recursos das empresas são limitados face aos desafios e objetivos que pretendem alcançar, essa é a realidade. A priorização é a chave e é encontrada nos conceitos de Work In Progress do LEAN. O valor de inicialmente passar por um “Shift-up & Spread” assume toda a sua importância aqui.

Para algumas equipes, o Shift-left focado em técnicas de BDD pode ser a escolha certa em seu contexto. Por outro lado, o CRE e gerenciamento do suporte serão para outra equipe. O contexto é fundamental no exercício contínuo de priorização, os modelos mais recentes e as siglas da moda passam a ser vistos em uma segunda etapa; ou para a pausa do café.

A priorização colaborativa será materializada por ações a serem realizadas, geralmente no contexto de sprints. O assunto da atribuição de tarefas pode começar, sem permanecer sob a responsabilidade do controle de qualidade.

Compondo em iterações medindo o progresso

As etapas anteriores consistem em garantir o “right product”, deixando o desafio equivalente de entregar o “product right”. É nas iterações que testaremos nosso modelo e nossas premissas, em busca da criação de valor por meio da qualidade.

As nossas iterações devem permanecer focadas no objetivo comum inicial de criar valor para a empresa. Manter a direção é um verdadeiro desafio durante os ciclos de execução, onde podemos rapidamente perder essa perspectiva. A medição é importante para verificar a adequação de nossas ações, mas quais métricas usar?

Os indicadores são relevantes quando contextualizados, como a organização e suas prioridades. Para a qualidade, mantivemos o uso de ciclos de aprendizagem duplos: o da criação de valor (“right product”) e o da melhoria do sistema que produz esse valor (“product right”).

A escolha, interpretação e comunicação dos indicadores apresentam complexidades reais de implementação. Podemos sofrer com nossos preconceitos cognitivos, não ter relevância para os negócios e ter dificuldade em demonstrar uma correlação de nossas ações. Os assuntos de Observability, Value-Stream e de Analytics devem ser investigados em todo o processo.

Pragmaticamente, a nossa recomendação é focar-se principalmente na medição do valor de negócio comumente buscado.

Outra recomendação é investir mais tempo realmente tentando criar valor do que tentando medir (testar?). Iman imaginou muito bem o exemplo dos exames de sangue: fazer mais exames não garante uma boa saúde.

“Fazer mais exames de sangue (ou seja, fazer testes) não garante uma boa saúde (ou seja, qualidade).”
Iman Benlekehal

A realidade não tem tudo a ver com sucesso e, embora sempre gostamos de compartilhar exemplos de vitórias atingidas, às vezes precisamos ser capazes de reconhecer um muro. Encontramos esta noção no Fail-fast, interessante pela pressão colocada para validar os pressupostos da estruturação antes de ir mais longe, combinando medição do valor e redução do risco.

Os muros fazem as empresas reagirem, mas nosso objetivo é evitar a maioria deles e reduzir seu tamanho. A comunicação é, portanto, a chave para convencer, o mais cedo possível.

Comunicar, comunicar, comunicar

O termo DevOps é tão difundido que até esquecemos o esforço colossal de comunicação que foi colocado nele. Nossa qualidade se tornará parte integrante de nossa organização, sua cultura e seus processos com uma comunicação sistemática e holística. Normalmente temos que planejar 10 vezes mais do que imaginamos.

No entanto, quantidade não rima com qualidade e, contra a intuição, comunicar-se sobre qualidade não se trata apenas de qualidade.

A comunicação ao serviço de transversalização da qualidade deve ser onipresente, sem necessariamente estar diretamente associada a ela. Os indicadores de criação de valor para a empresa são um bom exemplo, a sua mera presença já é um sucesso de qualidade por ser mais presente. Sua utilização, lembrete constante e inclusão nos mecanismos de feedback loops do sistema apoiarão sua avaliação.

É importante garantir a frequência, cobertura e inclusão dos diversos públicos de valor e qualidade em nossas ações. Precisamos saber como falar com a gerência e, na hora seguinte, com uma equipe de desenvolvimento. Uma qualidade transversal será suportada por uma comunicação transversal.

Durante os ciclos de desenvolvimento, a nossa prioridade é apresentar critérios de qualidade, por meio de nossas comunidades, interações e o papel de Questionador. O Arnaud compartilhou sua experiência onde a identificação de requisitos aumentou a conscientização da empresa. A presença de vários tópicos de qualidade é o primeiro passo para que sejam considerados. O resto do trabalho está na cultura e na capacidade de apoiar a obtenção de resultados.

As abordagens com maior impacto na organização também são por natureza transversais. Veja o exemplo de nosso SRE transformado em CRE, combina experiência do utilizador, engenharia e operações. O acréscimo de error-budget equilibrará a necessidade de aceleração e estabilidade da experiência, outro elemento de uma qualidade inclusiva.

Na realidade, uma qualidade integrada torna-se natural e transparente, provavelmente é um lado frustrante e decepcionante se estivéssemos procurando fama em vez de qualidade.

A qualidade precisa de testes, longe de se limitar a testes

Tornar a qualidade sem testar é, portanto, possível, tendo em vista que permanecem necessários; Os testes não são exclusivos da qualidade nem são o centro da questão. Na verdade, temos desafios reais para a evolução das culturas e organizações no ecossistema.

“Qualidade é, antes de mais nada, uma mudança organizacional.”
Antoine Craske

Olivier e Arnaud compartilharam conosco seus modelos de QA como uma verdadeira alavanca de qualidade para o resto da organização, não lidando diretamente com os testes. Organizações mais transversais são, portanto, mais adequadas, se abordarmos de forma colaborativa as questões de cultura, alinhamento e outros mecanismos compartilhados.

As mudanças culturais em grande escala demoram; gerações inteiras são freqüentemente necessárias para verificar mudanças estruturais. Esperamos que o nosso esforço nos permita acelerar essa transformação da qualidade e da capacidade de inovação das nossas empresas, para aquelas que sobreviverão.

Novamente, a perspectiva que adotamos faz toda a diferença. Ao nosso nível, devemos transformar nossa organização para uma qualidade integrada; em uma escala mais global, todo um ecossistema digital deve evoluir até atingir seu Tipping Point, a fim de transformar a cultura de qualidade de software de forma mais ampla.

Portanto, vamos trabalhar nessa missão comum para ter a possibilidade de vivenciar essa transição.