O que é o Quality Engineering? Essa questão levanta outras como o por quê, o quê, o como. Cobrimos essas questões nessa partilha aprofundada do Quality Engineering com o João Proença.

Decidimos fazer uma interview com o João para esclarecer a implementação do Quality Engineering na indústria. Nesta entrevista, compartilhamos sua perspectiva advinda de mais de 10 anos de experiência em qualidade. 

Nós nos concentramos em compartilhar casos do mundo real para materializar como o Quality Engineering pode viver nas organizações. O conteúdo mencionado está disponível nas referências no final do artigo. Estaremos felizes em continuar a discussão nos comentários.

Junta-se a QE Unit para aceder a conteúdos exclusivos e regulares da comunidade.

Sobre João Proença

João Proença é natural de Lisboa, Portugal, e é Principal Quality Engineer em I&D da OutSystems, uma empresa que fornece uma das principais plataformas de desenvolvimento de low-code a nível mundial.

Ele assumiu várias funções ao longo de sua carreira nos últimos 14 anos, incluindo garantia de qualidade, desenvolvimento, suporte ao cliente e marketing. Encontrar soluções inovadoras para problemas complexos é o que mais o motiva, por isso ele está sempre impaciente para falar sobre como os profissionais estão superando os desafios dos testes em todo o mundo. 

Fora de TI, João é apaixonado por composição musical, cinema e futebol. Pode o seguir no twitter sobre todos esses tópicos usando no @jrosaproenca.

Antoine: Podes começar por te apresentar?

Ao longo dos anos, fiz uma variedade de coisas, a música foi uma delas em algum momento 🙂 Comecei minha carreira como pesquisadora em renderização 3D quando terminei a faculdade. Foi interessante, eu estava fazendo renderizações específicas para encontrar novas maneiras alternativas de modelizar itens. Depois de um tempo, descobri que queria ter mais impacto no mundo real com o que estava fazendo na pesquisa. Decidi fazer outra coisa.

Mudei-me para Outsystems, tornando-me um Quality Engineering na altura. Naquela época, era como um trabalho regular de quality assurance. Eu estava dentro de uma equipe ágil lidando com atividades de teste manual e de automação. Fiquei neste posição por cerca de 5 anos com uma experiência mais ampla do que QA: Eu desenvolvia software desde o desenvolvimento até a correção de bugs. Após esse período, eu não queria voltar apenas para a área da qualidade.

Investi mais tempo em desenvolvimento, mas também trabalhei na equipe de suporte ao cliente. Foi uma experiência enriquecedora, ter que pegar no telefone, atender clientes, felizes ou às vezes até irritados. Eu tive que decidir o que escalar dentro da empresa para resolver problemas específicos. Dado o tamanho da empresa, era uma posição exigente devido à complexidade e variedade de suporte para lidar com a primeira linha.

Antoine: Para onde evoluiste depois dessa experiência enriquecedora de suporte?

Fui então convidado a me juntar à equipe de Cloud Operations recém-criada quando a Outsystems lançou sua oferta Cloud relacionada. Fui nomeado para liderar a equipe de operações. Ao mesmo tempo, também estava trabalhando em meu projeto de álbum de música paralela, lidando com várias atividades de marketing. Comecei a me interessar mais por essa área e ganhei a oportunidade de trabalhar em uma equipe de marketing de produto em outra empresa. Trabalhei lá por um tempo, sendo o engenheiro a produzir conteúdos para esta empresa de software. Depois de algum tempo, percebi que minha vocação era de ser focado na engenharia.

Eu estava de volta à Outsystems com a proposta de ingressar no domínio Qualidade. Hesitei porque não queria entrar só naquela área novamente. Eles me disseram: “Agora temos uma visão completamente diferente da Qualidade”. Eles ainda não tinham um nome, mas realmente tinham uma perspectiva diferente. Aceitei e sou Quality Engineer desde 2017, com muitas experiências diferentes desde então.

Antoine: Um percurso interessante com diversas experiências, desde engenharia, suporte, operações, música e marketing. Para compartilhar com a audiência, podes partilhar mais detalhes sobre a empresa?

A Outsystems fornece uma plataforma de software low-code para o desenvolvimento rápido de diferentes produtos, desde experiências na web até experiências móveis. Ao longo dos anos, encontrou o seu mercado e acelerou o seu crescimento a nível mundial a partir de Portugal. É um dos maiores unicórnios da área de tecnologia, com hipercrescimento e desafios de escala.

Lembro-me do dia em que a empresa tinha menos de 100 funcionários. No momento, estamos variando entre 1.500 e 2.000. Já vi diferentes etapas e níveis de complexidade dependendo do tamanho da equipe. No momento, estamos expandindo; é difícil saber quantos somos precisamente em um determinado ponto.

Antoine: O Quality Engineering não tem uma definição tão comum. Eu queria aprofundar esse tema com a tua experiência profissional e o que compartilhas em conferências. Antes de começar, podes partilhar quais são as tuas principais prioridades enquanto Principal Quality Engineer?

Um grande desafio vem diretamente do crescimento acelerado da empresa. Precisamos permitir que a prática da Qualidade seja escalonada com a expansão da equipe. Isso significa que muitas novas equipes têm de alinhar-se com nossa cultura, práticas e padrões de qualidade compartilhados. Queremos evitar silos de qualidade que carecem de compartilhamento em toda a organização. Uma das principais prioridades é ter equipes compartilhando um entendimento comum de como devem lidar com a qualidade.

Eu trabalho com uma equipe específica e estou a transitar para uma função mais transversal, supervisionando várias equipes. Essas equipes podem ou não ter Quality Engineers integrados. Estou estimulando equipes a se comunicarem, conscientizarem os engenheiros da qualidade sobre diferentes práticas e oportunidades, ou mesmo levar assuntos mais amplos do que os de uma única equipe. É uma função mais estratégica que exige que eu esteja mais ciente das tendências da indústria para garantir que a qualidade seja incorporada a essas várias equipes.

Antoine: As dimensões que compartilhas demonstram um bom nível de maturidade da qualidade, também atrelado ao objetivo do negócio de dimensionar e manter a qualidade do produto. Para resumir, sua função é tornar a Qualidade um facilitador em nível local dentro de cada equipe e, ao mesmo tempo, garantir que ela contribua para um valor global em toda a empresa?

Sim, exatamente. Um aspecto concreto é direcionar os Quality Engineers para que trabalhem mais de perto com equipes específicas. Muito pode ser feito pelos aspectos humanos ao invés dos técnicos. Eu treino muito outros engenheiros na maneira como eles abordam a qualidade, interagem com outras equipes e tentam resolver problemas específicos.

Os Quality Engineers são verdadeiros facilitadores e capacitadores. Eles não são os únicos realizando atividades de qualidade; esse não é o nosso objetivo. Saber como capacitar equipes na gestão de risco ou estratégia de teste é, por exemplo, mais valioso. Às vezes, a forma como animamos um workshop específico muda o jogo, é o tipo de ações geradas.  

Antoine: Vamos agora esquecer por um tempo o contexto específico da Outsystems. Como definiria o Quality Engineering em uma frase? O que é Quality Engineering na sua perspectiva?

Eu tentaria dar minha melhor definição, onde minha experiência ainda influencia como vou definir O Quality Engineering. Venho de uma “escola de testes” baseada em: a abordagem de toda a equipe para a qualidade, os princípios de teste modernos que Brent Jensen e Alan Page começaram. Quando me tornei Quality Engineer em 2017 na Outsystems, fiz isso trabalhando com o novo Head of QA, João Neto, que veio da Microsoft, onde se originaram esses princípios modernos. Ele trabalhou para trazer essa escola de pensamento para nossa organização. 

Eu poderia construir sobre um desses materiais, mas posso contar uma história primeiro. Em 2018, fui para o Agile Testing Days na Alemanha. As pessoas estavam falando sobre tópicos semelhantes, e descobri a keynote da Anne-Marie Charrett, da Austrália. Ela compartilhou que o Quality Engineering, vinda de outras áreas da engenharia, agora está entrando no mundo do software. O Quality Engineering é para mim chegando agora, ligado a outras tendências como DevOps e Agilidade.

“O Quality Engineering abrange uma perspectiva holística muito mais ampla.”

João Proença

O Quality Assurance tende a focar mais na validação e verificação, pré e pós-implementação; às vezes muito localizado no ciclo de vida do software. O Quality Engineering traz uma visão mais holística da Qualidade, a ser construída em primeiro lugar por diferentes equipes em diferentes etapas. Um visual útil é o de Dan Ashby: existe o esquema infinito do DevOps onde o teste e a qualidade acontecem em cada etapa. Esta visão de qualidade também se baseia nas práticas existentes de qualidade e teste.

Antoine: Na tua opinião, quais são as principais práticas do Quality Engineering? Quais são as mais diferenciadoras e valiosas ?

Não vejo uma receita única para todos. Posso identificar várias ações que fiz como Quality Engineer que não são tão comuns e que estão sob minhas responsabilidades. Primeiro, considere a qualidade desde a fase de design. Os riscos são muito importantes para mim. Ser orientado para o risco é considerar seriamente os riscos como a fonte de muitas coisas que faz e, particularmente, dos riscos de qualidade. Note que muitas vezes as equipes falam sobre riscos referindo-se a “riscos de projeto” que são diferentes na minha visão de “riscos de qualidade”. Os riscos do projeto colocam em risco o sucesso de um projeto específico.

Em riscos de qualidade, estamos pensando em como o produto pode dar errado, não satisfazendo as expectativas de nossos usuários. Eu vi muitas discussões sobre riscos sem uma estrutura clara para pensar sobre eles de forma completa ou sistemática. Portanto, aprendi sobre avaliação de risco por meio de risk-storming, uma prática fundamental para discutir qualidade desde o início. Eu até discuti o valor de fazer isso desde o início e continuamente com seus criadores, Beren Van Daele e Marcel Gehlen.

“O Quality Engineering trata de encontrar o ponto ideal entre entregar valor e, ao mesmo tempo, manter a capacidade de reagir.”

João Proença

Uma coisa que descobri sobre a avaliação de risco é que é fundamental fazer isso no momento certo em um projeto ou iniciativa. No início, não terá certeza do que está tentando construir e entregar aos utilizadores, portanto, os riscos que pode encontrar não são tão completos. Mais tarde, quando já estiver desenvolvendo, pode estar muito longe na implementação para poder acionar mitigação de risco de que precisa nos planos de sua equipe. Tem uma compreensão muito melhor dos riscos, mas menos margem para agir sobre eles. O ponto ideal está no equilíbrio quando começa a materializar o valor do produto sem ter muito compromisso. Alcançar esse estado requer um modelo colaborativo o mais cedo possível. Mitigar o risco envolve, com certeza, muitos testes, mas também pode envolver outras práticas, como técnicas  de testes em produção, como shadow-deployment ou a observabilidade. Essas práticas vão além dos testes e nos permitem medir os riscos e nos adaptar antecipadamente. 

Outra prática que achei muito impactante é atuar no nível de Arquitetura. Olhando para problemas específicos, o teste era inútil; colaboramos com arquitetos para resolver problemas estruturais. Permite que reafirme o porquê, o quê e o como, tornando-o mais explícito sobre os riscos e prioridades mais importantes. Já estou falando sobre muitas práticas diferentes que são realmente diferentes daquilo que um teste tradicional ou uma equipe de controle de qualidade faria.

Antoine: O Quality Engineering leva a qualidade em consideração e atua como um todo, onde as equipes de garantia da qualidade desempenham um papel fundamental. Como gerenciar o Quality Engineering? Identificas medidas específicas para usar?

Definitivamente, meu trabalho é permitir que as equipes pensem dessa forma em direção a uma qualidade integrada transversalmente. Em retrospectiva, o que temos tentado no ano passado é fazer as equipes entenderem duas coisas: o que qualidade significa para elas e o que qualidade significa para o produto. Estamos formalizando algumas métricas que eles podem usar e adaptar para avaliar seu desempenho atual e pretendido em seu próprio contexto. 

Chamamos nosso modelo de “Radar da Qualidade”, ele fornece um conjunto de processos, hábitos e princípios que podem ser avaliados. O Radar foi altamente inspirado no Guia de Transição da Cultura de Qualidade do Alan Page. O modelo contempla várias áreas como a cultura da qualidade, tipologias de teste ou mesmo manutenção. Por exemplo, temos equipes trabalhando ativamente na dívida de tecnologia e promovendo seu tratamento de forma qualificada.

Sua implementação depende do desenho do radar. O objetivo não é avaliar as equipes, mas capacitá-las a fazer sua própria avaliação e plano de ação. Uma equipe pode descobrir “Ei, somos péssimos em observabilidade, o que podemos fazer?” O radar dá a eles os primeiros passos que podem dar de acordo com o nível de maturidade. Estamos continuamente aprimorando o modelo, algumas áreas em fase de experimentação.

Antoine: Esse compartilhamento nos leva ao valor do Quality Engineering. A perspectiva do produto e da equipe os ajuda a trabalhar continuamente para preencher a lacuna de valor. Existem métricas valiosas específicas a serem consideradas?

Existem duas idéias principais sobre medição e métricas. Métricas que não são contextualizadas para sua organização, produto ou equipes geralmente não funcionam; não há métricas únicas para usar. Isso direciona a discussão sobre quais métricas são mais importantes para as equipes em seu contexto. Uma coisa que tentamos é algo que chamamos de “Metas de qualidade do produto” para as equipes definirem suas orientações sobre a qualidade que desejam ver em suas aplicações.

As Metas de Qualidade do Produto foram em parte inspiradas no conceito de Northstars. As Northstars de Produto são a principal medida de sucesso para uma equipe de produto. Para o Facebook, foi o número de curtidas ou compartilhamentos, se bem me lembro. Isso realmente orienta a tomada de decisão. Descobrindo as principais métricas que são importantes, pode alinhar uma ação para cobrir a lacuna entre os níveis inicial e alvo. É útil especialmente quando os ativos tecnológicos de uma equipe mudam muito com o tempo; eles estão mais vinculados ao valor a ser entregue, em vez de um produto construído anteriormente que poderia mudar completamente. 

Trouxemos essa ideia do Northstars para o espaço de qualidade e estou convencido de que as equipes devem definir as métricas por elas próprias. Pode fornecer a maneira de conseguir isso, mas não as métricas em si. Eu também descobri todo um conjunto de perspectivas de métricas com nossos Quality Engineers, comunidades e até mesmo Lisa Crispin que trabalhou na Outsystems. Percebi que as pessoas concordam que as métricas mais valiosas não podem ser universais. Se realmente quer algumas métricas “padrão da indústria” que se aplicam na maioria das empresas, então pode apostar que em DORA do livro Accelerate.

Eles são considerados as métricas de DevOps agora. Na minha perspectiva, essas métricas são benéficas para todo o setor. Recomendo a qualquer pessoa que execute o exercício de medição em seu modelo de maturidade.

Antoine: As prioridades do Quality Engineering são, portanto, contextuais às prioridades da empresa, sua maturidade e organização. Existem modelos organizacionais específicos de Quality Engineering? Como isso afeta o que um Quality Engineer realmente faz?

As atividades e até mesmo as responsabilidades dos Quality Engineers dependem do tamanho, contexto e história da organização. A Outsystems tem mais de 20 anos e viu diferentes níveis de escala e desafios durante sua existência. Vimos que sua definição e como tratam a qualidade evoluem, refletindo suas mudanças de prioridade e maturidade.

Antoine: Eu sinto que é mais uma questão de mentalidade e ações que habilita, tolera e prioriza. Um CTO poderia ser o único Quality Engineer em uma start-up?

Exatamente! A natureza da empresa, do produto e da organização são elementos essenciais do contexto a serem considerados. Lembro-me de conversar com uma amiga minha, Melissa Eaden, que trabalha na Unity, onde o Alan Page agora trabalha. Do ponto de vista organizacional, eles também pressionaram as equipes a desenvolver suas métricas mais valiosas. É um excelente exemplo de como as equipes devem ser responsáveis ​​por suas métricas de qualidade e planos de ação.

As métricas podem ser perigosas, mas ao mesmo tempo fortalecedoras. Bem feitas, elas capacitam a equipe a assumir o controle de seus planos de melhoria, definindo e aprendendo com os experimentos. Este alinhamento colaborativo e compartilhado é verdadeiramente benéfico para as organizações agirem em um objetivo maior.

Antoine: Isso me faz pensar em quando as empresas devem começar a ter cargos de Quality Engineering. Da nossa partilha entendemos que deve estar presente em todas as fases de maturidade da empresa. A necessidade de cargos dedicados surge de um tamanho específico ou tipos de assuntos para abordar? Quando isso se torna um requisito e não apenas uma opção? (Uma questão subsidiária é o que acontecerá a empresas maiores que ainda não abordaram o Quality Engineering)

O Quality Engineering faz sentido na maioria dos cenários. Não se trata apenas do tamanho da empresa. Se você deseja lançar uma nova startup amanhã, provavelmente não começará com uma prática dedicada de Quality Assurance, então pensar em Quality Engineering pode ser uma boa aposta.. O importante é implementar as idéias e os princípios por trás desses domínios.

Às vezes me pego pensando que a garantia de qualidade fazia mais sentido antigamente. Foi muito difícil agir depois que o software foi implantado na produção por vários motivos. Havia limitações práticas, como a entrega de software em CDs físicos que, uma vez enviados, liberar atualizações era um problema real. A adaptação contínua do software não foi tão simples, reforçando a necessidade de uma gestão muito preventiva da qualidade e dos riscos.

Hoje em dia, a dinâmica é muito diferente. DevOps é um exemplo de uma mudança drástica na forma como construímos, entregamos e operamos nosso software. O  Quality Engineering faz muito sentido no software de engenharia atual e no relacionamento com nossos usuários.

Antoine: Quais pistas darias para começar a explorar mais sobre o Quality Engineering?

Eu recomendaria dar uma olhada em toda a “whole team approach to quality” e aos princípios de teste modernos. Algumas pessoas duvidam de sua implementação prática. Posso garantir que bem feito, eles funcionam. Em muitos lugares do mundo, as práticas são implementadas sem se referir diretamente a elas.

Muitas práticas emergentes em nossos campos às vezes são comentadas com “Parece bom na teoria, mas na prática, nunca vi funcionar”. Eu enfrentei um exemplo prático e recente com testes de contrato (i.e. contract testing). Fui a workshops, aprendi mais sobre isso, até auxiliei em palestras em conferências para implementá-lo. Eu encontrei muitos detratores falhando em implementá-lo. Por fim, conversei com um amigo meu, Rob Meaney, que me deu os primeiros exemplos de lugares em que isso foi de fato bem-sucedido.

Muito depende da capacidade de traduzir o conceito em prática. Requer um nível de compreensão, excelência e compromisso para torná-lo uma prioridade. É como TDD. É uma prática preciosa, mas é difícil fazer o “ TDD right” dentro de uma organização. Portanto, se as pessoas tiverem dúvidas de que a abordagem da qualidade a toda a equipa seja uma teoria, eu as contradiria.

O Quality Engineering constrói muitos destes princípios com uma perspetiva mais transversal e holística, dando-nos mais opções. 

Antoine: Fechando com uma nota pessoal, tens algum conteúdo inspirador específico, como citações, livros, mesmo fora da Quality?

Os testes modernos ou Modern Testing são benéficos para mim. Pode encontrar o podcast AB Testing com centenas de episódios em seu site e se juntar a eles no slack para se envolver com a comunidade.

Mencionei a palestra de Anne-Marie Charrett sobre Quality Engineering, “Is your quality on the road to nowhere?”. Ela também compartilha regularmente no seu blog.

Em termos de livros, recomendo fortemente a leitura de Accelerate e Leading Quality, definindo conhecimentos e perspectivas essenciais. Também vou começar a ler o projeto Unicorn que segue o projeto Phoenix, dois outros grandes títulos.

Antoine: Muito obrigado, João, por esta entrevista de Quality Engineering. Desejo-te uma jornada impactante de Quality Engineering na Outsystems e mais palestras perspicazes em conferências como as dos cognitive biaises. Pode seguir o João em @jrosaproenca.

Referências 

Livro João Proença

Brent Jensen e Alan Page, Modern Testing Principles, AB Testing Podcast  https://moderntesting.org/  

Dan Ashby, Continuous Testing in DevOps. https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/ 

Brent Jensen & Alan Page, The Quality Culture Transition Guide https://testingpodcast.com/ab-testing-episode-93-the-quality-culture-transition-guide/ 

The Quality Culture Transition Guide https://docs.google.com/spreadsheets/d/1kan20hYsdbvk7HW4si-X6Ve1fLtCeTI2H_PjiniKsxY/edit#gid=1897633328 

Lisa Crispin, a abordagem de toda a equipe na prática https://lisacrispin.com/2011/04/26/the-whole-team-approach-in-practice/ 

Janet Grégory, Holistic Testing https://janetgregory.ca/testing-from-a-holistic-point-of-view/ 

Anne-Marie Charrett, palestra “Anne-Marie Charrett: sua qualidade está no caminho para lugar nenhum?” https://www.youtube.com/watch?v=46QFPrs5dT0. Dias de testes ágeis

Anne-Marie Charrett, blog pessoal em https://www.annemariecharrett.com/ 

Beren Van Daele e Marcel Gehlen, Riskstorming

Nicole Forsgren; Jez Humble; Gene Kim (2018), Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

John Ronald Cummings, Owais Peer (2019), Qualidade de liderança: como grandes líderes entregam software de alta qualidade e aceleram o crescimento https://www.amazon.com/Leading-Quality-Leaders-Software-Accelerate/dp/1916185800 

Google, The Accelerate Report https://cloud.google.com/devops/state-of-devops 

Every Product Needs a North Star Metric https://amplitude.com/blog/product-north-star-metric