A Mesa Redonda da Quality Engineering Unit reuniu-se para discutir da transição do Quality Assurance (QA) para o Quality Engineering (QE),

A área do Software Quality Engineering tem como objetivo incluir a qualidade na transversalidade das equipas, processos e tecnologias na construção do produto.

No entanto, o facto de ter a palavra “engenheira” no nome, não significa que se resume apenas a implementar um conjunto de ferramentas e tecnologias.

Partilhamos os seguintes temas:

• Quais temas para uma transição do QA para o QE?
• Que boas práticas podem ser utilizadas, e quais os critérios a ter em atenção?
• Como definir as suas prioridades?

Agradeço cada participante para a sua participação e contribuição :

• João Proença, Principal Quality Engineer na Outsystems e International Speaker
• Diogo Rede, Engineering Lead & Test Engineer na Farfetch
• Luis Bastião Silva, CTO na BMD Software
• Filipa Nogueira, Engineering Team Lead na La Redoute
• André Macedo, Solution Architect na Sky Technology Center

Contextualização do evento

Em aquecimento, partilhamos com o João Proença o que é o Quality Engineering, tem mais conteúdos neste episódio.

Iniciamos o evento por identificar os temas de interesse nessa matriz de priorização.

O Luís Bastião Silva deu início a nossa conversa sobre a transversalidade dos riscos.

A sensibilização ao risco é fundamental

É familiarizado com a regra de não fazer release do produto à 6a-feira?

Muitas experiências relatam um fim de semana complicado quando esta regra não foi seguida.

Esta regra é de bom senso num ecossistema complexo que não esteja ainda no nível de qualidade esperado.

Voltando à pergunta, toda a equipa tem essa sensibilização aos riscos?

A sensibilização do risco é fundamental, e deve ser transversal entre todas as equipas, e deve ir muito mais além do que apenas as equipas de operações.

Luís Bastião Silva

É neste ponto que tocamos com o Luis, partilhando muitas vezes riscos diferentes entre equipas, acabando por resultar em problemas reais nas operações.

Uma matriz transversal de risco vem neste contexto ajudar a definir e partilhar os riscos envolvidos no processo de desenvolvimento.

A questão dos riscos deve vir a ser um reflexo da equipa ao longo do tempo.

Pontos que pode refletir no seu contexto, e que debatemos a seguir :

• Tem consciência pessoal dos vários riscos na cadeia de valor?
• Existe uma formalização desses riscos, com priorização?
• Como pode definir, partilhar e animar a sua utilização com a equipa?

Com o poder de deploy até a produção, vem a responsabilidade

Quem é responsável por instalar o software em produção na sua organização?

Por motivos históricos, mais que técnicos, encontramos muitas vezes as operações com esse papel.

A problemática não tem a ver com a equipa que faz, mas quem está na primeira linha a seguir no protocolo.

Aí também, os developers podem faltar, deixando esse trabalho a equipas de operações e de suporte de primeira linha.

Ser responsabilizado end-to-end para um produto é fundamental para a sua qualidade.

Diogo Rede

Muitos bons argumentos organizacionais e de eficácia de processos entram nesses modelos, tal como separation of concerns, shared services.

Em contrapartida, criam outras problemáticas, como um product owner ou um developer que não tem feedback direto da utilização real do seu produto, e por essa razão não entende o impacto das alterações efectuadas.

Partilhamos a necessidade, que consideramos fundamental, da equipa ter um feedback loop de utilização do produto em produção, bem como requisitos e comentários dos utilizadores finais, e também da parte mais técnica.

Para conseguir esta integração das várias equipas num processo de qualidade integrado, poderá ser necessário rever processos na organização, e muitas vezes podemos encontrar soluções que mantêm vantagens dos modelos e que permitam esse feedback loop.

O que pode questionar no seu contexto :

• Quem está hoje responsável por executar o deploy, e fazer o seu seguimento?
• Existem ainda razões válidas para que o developer não tenha acesso à produção?
• Quais os mecanismos de feedback loop automáticos que posso implementar?

Quando mais próximo do cliente, mais inclusão do risco haverá

Somos humanos, adaptamos o nosso comportamento com base em experiência e feedbacks muitas vezes emocionais.

Por isso, de forma a melhorar a inclusão do risco, a equipa deve estar em contacto com esses riscos.

Os riscos no software materializam-se na sua utilização: funcionalidades constantemente bloqueadas , degradadas, lentidão, perda de dados, etc.

Como obter essas informações?

Uma equipa tem de estar o mais perto possível da produção.

João Proença

Apontamos aqui um ponto de Observability do produto, uma área de grande aceleração pelos benefícios que poderá trazer.

Fica também um paralelo com o padrão do shift-right.

No entanto, até ter os nossos dashboards automaticamente feitos, otimizados e geridos com Data Science, temos de agir.

Uma prática concreta é colocar a equipa em contacto com o cliente, directamente quando for possível, indiretamente quando não for.

Tinhamos queixas de lentidão, que a equipa de produto não reconhecia. Foram passar uma semana ao lado dos utilizadores e voltaram com os pontos a melhorar.

Antoine Craske

Pode materializar-se com práticas simples como colocar utilizadores com a equipa do produto, organizar sessões com um painel de beta-tester entre outras práticas.

Também não faltam ferramentas pragmáticas de gravação de ecrãs, analytics, e de gráficos que podem focar-se em pontos particulares de utilização.

Pontos que pode acionar no seu contexto:

• Como se materializa a operação do meu produto?
• Quem são os utilizadores finais?
• Como a equipa poderia receber feedback direto das operações e dos utilizadores?

O Quality Engineering envolve uma responsabilidade e espírito de equipa 

Sente uma equipa unida face à qualidade do seu produto?

É uma das ações prioritárias a assegurar antes de iniciar alterações de processos ou de ferramentas.

A equipa deve sentir-se como uma unidade desde a concepção até a operação do software, começando a incluir transversalmente o risco, e aprendendo da sua experiência.

O Quality Ownership é a responsabilidade da equipa para a qualidade, e não de uma pessoa só.

João Proença

As evoluções de pensamento e de dinâmica da equipa são muitas vezes postas em segundo plano.

Na realidade são as fundações para permitir a uma equipa melhorar a qualidade do seu produto, encontrando eles próprios melhores mecanismos em transversal.

O Diogo Rede partilhou por exemplo casos em que a equipa acaba por mitigar o risco desde a concepção com mecanismos como feature-toggles.

Mecanismos de mitigação devem ser previstos antes de mão pela equipa.

Diogo Rede

Com maturidade, uma equipa consegue ter uma abordagem de melhoria contínua baseada nas operações do produto, em que itera sobre práticas de qualidade.

É esse o resultado que deve procurar-se mais que uma arquitectura técnica perfeita a um momento particular.

O que pode trabalhar com a sua equipa :

• Qual é o nível de transversalidade da minha equipa hoje?
• Quais interações teriam mais valor de serem iniciadas?
• Quais exemplos e casos concretos posso usar como primeiros sucessos?

Começar e mostrar valor deve ser a primeira prioridade

“Mais este pequeno detalhe e estará pronto”.

Já deve ter ouvido muitas vezes esta frase, até pela mesma pessoa durante dias, sem entregar algo funcional.

Vários fatores entramem jogo aqui, a personalidade da pessoa, a cultura da organização, os objetivos e perspectiva que foram dados ao projeto.

Puxar para um produto o mais rapidamente disponível e testável em operações é uma prioridade do Quality Engineering.

“Start small”, uma transição para o QE é um processo iterativo.

João Proença

O João partilhou a necessidade de ver o QE como um caminho incremental e iterativo, não é um projeto com uma data final.

É preciso experimentar diferentes técnicas de forma a desenvolver o que resulta melhor com o seu produto.

O foco deve manter-se no valor gerado, não numa otimização técnica em silo em que podemos facilmente cair.

O que pode fazer no seu contexto :

• Qual é o seu produto o mais simples possível que traz valor para o negócio?
• Como pode implementá-lo o mais rapidamente possível?
• Como permitir a equipa aprender da primeira experiência para definir a próxima iteração?

Ter mais qualidade não passa primeiro por mais concepção

Será que para incluir a qualidade no processo, é preciso investir mais em concepção inicial?

É uma possibilidade e parece ter bom senso.

No entanto, contra-intuitivamente ficar numa possível solução, teoria não deve ser a primeira ação a fazer.

Gostando de refletir, é para mim um desafio de confrontar-se a realidade o mais rapidamente possível.

É preciso ter a coragem de confrontar-se com a realidade, cedo.

Antoine Craske

Este ponto toca na parte em que a equipa deve ter contacto com os clientes e a operação do seu produto cedo.

Também se aplica na implementação dos seus processos, tecnologias e ferramentas de qualidade no ciclo de vida do software.

Concretamente, como pode confrontar mais rapidamente e mais regularmente a realidade com as hipóteses, modelos e o produto que tem?

O que priorizar em testes no Quality Engineering

Iniciamos com a questão do testes end-to-end numa dinâmica de Quality Engineering.

Luís partilhou a sua experiência onde testar de ponta a ponta foi a primeira prioridade que acabou por trazer bastante valor para o negócio.

No contexto em questão, permitiu validar que as principais funcionalidades estavam estáveis no produto.

Sem necessariamente encontrar exatamente a origem do problema em questão, estavam a fornecer valor para o negócio e a equipa.

A adaptação ao contexto do negócio é chave para criar valor.

Diogo Rede

Ao longo do tempo, foram complementados com outras tipologias de testes com objetivos diferentes.

Testes unitários foram um deles, e revelaram-se úteis para melhorar o foco dos developers nos use-cases e na modularização do seu código.

Concordamos sobre o erro de querer automatizar tudo, ainda mais quando o plano de testes existe e vem dos testes manuais.

Seguimos para as pirâmides de testes, alinhados que são modelos úteis percebendo as assumpções que existem para cada tipologia de testes.

O João partilhou que a pirâmide é uma metáfora, em que a granularidade dos componentes a testar entra em jogo

Não se deve testar com e2e o que pode ser testado em layers mais abaixo.

João Proença

O balanço do custo e benefício dos testes é um fator que acaba por incluir uma perspectiva de valor para o negócio dos mesmos, forçando a formalizar.

O que importa é o risco que estamos a reduzir e com qual custo associado.

Tal como partilhamos na mesa redonda de automação de testes, a quantidade não é qualidade, até pelo contrário.

Em complemento, identificamos que executar os testes logo no início, sejam end-to-end ou não, permite validar rapidamente a incorporação da testabilidade no seu produto.

Uma transição para o QE é uma dinâmica transversal e incremental 

Voltando à nossa pergunta inicial, “Do QA ao QE, por onde começar?”, abordamos aqui vários pontos:

• Identificamos que uma responsabilidade transversal da equipa, tendo acesso às operações, se possível, do seu produto é um aspeto muito importante.
• A importância da interiorização do risco das mudanças deve ser transversal entre as várias equipas, inclusive na de desenvolvimento.
• Focar-se em entregar um produto rapidamente testável na realidade é uma das chaves para iterar, seja no software final ou nos processos de suporte.
• A questão dos testes acaba por precisar do mesmo raciocínio: qual é o valor para o negócio? Qual é o custo benefício? Qual solução é a mais adequada?
• Em implementação, o QE baseia-se em práticas existentes do QA e do DevOps na parte de automação de testes, deployment e pipeline, por exemplo.

Vemos que padrões de mercado tal como shift-left, shift-right acabam por materializar-se também no QE, tanto na parte organizacional quanto técnica. Para o seu sucesso, a sua transição para o QE é uma aventura que deve ser conduzida incrementalmente.