O nosso último evento foi o primeiro claramente focado no tema do Quality Engineering, a partir do pivô “Do QA ao QE, por onde começar?”
Agradeço aos seguintes participantes pela presença e contribuição:
- Xavier Pigeon, especialista em estratégia e método de qualidade e TI, autor de gearsoftesting.org e fundador de TestAsYouThink
- Florian Fesseler, Head of Engineering na iObeya
- Fatima-Zahrae Abbadi, Lead QA na Odigo
- Nicolas Guyon, Expert Test & QA, CI, DevOps e Implantação ágil na Murex
Neste evento, abordamos os seguintes pontos:
- Qual a visão e percepção atual do Quality Engineering?
- Quais as primeiras ações mais relevantes para iniciar uma abordagem?
- Quais abordagens e práticas para implementar de forma transversal?
A contextualização do evento
A nossa partilha começou com uma troca em torno do Quality Engineering de forma a delimitar melhor os seus contornos.
Partilhamos também sobre o QA e o QE, antes de passar para a fase prática.
Cada participante conseguiu listar os temas selecionados a seguir.
Os desafios do Quality Engineering
Começamos por contextualizar quais desafios o Quality Engineering deve ajudar a resolver.
Os desafios encontrados são equilíbrio do comércio para a tecnologia. De forma contra-intuitiva, fora da prática pura de engenharia.
Trazer uma qualidade estrutural induz uma perspetiva transversal do sistema, daí a importância do primeiro ponto de comunicação entre os vários stakeholders.
A instabilidade das necessidades dificulta a capacidade dos atores de alinharem-se com uma visão, exigindo que a discussão se concentre em pontos mais estáveis, voltaremos a isso.
A tendência subjacente do “anywhere, anyplace, anytime” é materializada na noção do always-on, tornada mais complexa pela diversidade de modelos de implantação.
A necessidade de fornecer uma experiência de usuário útil, de qualidade e atualizada regularmente é uma das principais expectativas do QE.
Antoine Craske
Essa necessidade de iteração rápida implica uma experiência de desenvolvimento de ponta a ponta eficaz.
A capacidade de medir o valor fornecido dá peso ao processo, sem basear-se apenas em indicadores de desempenho.
Os indicadores podem ser efetivamente limitados a uma análise qualitativa das entregas.
A fundação também inclui a necessidade de focar mais amplamente no valor entregue do que no campo técnico da intervenção local.
Essa identificação continua sendo um verdadeiro desafio, que partilhamos nesta mesa redonda.
Quais são as diferenças entre QA e QE?
Em seguida, mudamos para a articulação do Quality Assurance (QA) e do Quality Engineering (QE).
Intuitivamente, as duas práticas compartilham fundamentos de gestão da qualidade, também aplicáveis ao campo do software.
Encontrei as duas definições seguinte, partilhando as respectivas perspectivas de cada domínio.
Como qualquer definição, eles têm vieses de interpretação, podem ficar superficiais e faltar a inclusão do contexto.
No entanto, julgo interessante observar as palavras ensure (garantir) e processo de desenvolvimento de software, esclarecendo a perspectiva transversal.
O QA, por sua vez, é limitado numa definição fortemente associada a um processo de controle a posteriori.
Como numa fábrica, o controle de qualidade só pode estar no final da cadeia, mas por meio da liderança e pró-atividade pode ser incluído em toda a cadeia de valor, seja QA ou QE.
Dos vários estudos recentes sobre qualidade de software, julgo que o QE é uma expansão da QA e de outras áreas.
Quais critérios de uma transição bem-sucedida?
O Nicolas lançou esta questão, observando a necessidade de identificar os objetivos de gestão por trás do desejo de qualidade.
Nós descobrimos o mal muitas vezes necessário de uma organização encontrar-se de frente para a parede antes de realmente mudar.
Mais precisamente: estar de frente para a parede e realizar que uma enésima correção por um desenvolvedor heróico não pode mais resolver o problema.
Partilhei uma experiência pessoal em que nos deparamos com essa situação. O nosso primeiro objetivo era entregar uma pequena mudança o mais rápido e estável possível.
Saber entregar uma mudança simples no mesmo dia, sem uma organização específica, é um critério de sucesso do QE.
Antoine Craske
Esta abordagem não é fácil de convencer do ponto de vista empresarial, porque no curto prazo temos a sensação de desacelerar, regredir e acumular trabalho em espera.
Isso o lembra de ler os procedimentos e práticas LEAN na Toyota ou a sigla WIP (Work In Progress)?
Este é realmente o caso ao adicionar este tijolo de pensamento sistêmico e LEAN para um Quality Engineering estruturalmente eficaz.
Os objetivos do Quality Engineering devem estar voltados para a aceleração, estabilidade e qualidade do curto ao longo prazo.
Questões que pode usar no seu contexto:
- Existem objetivos de negócios e dos clientes claramente identificados?
- A organização parece estar madura para aceitar um modelo alternativo de mensuração do valor de entrega?
- Que elementos de contexto você deve usar para argumentar a necessidade de mudança, agora?
Qual lugar para o CI/CD no QE?
Essa é uma boa pergunta, uma vez que o CI/CD costuma ser associado ao DevOps, ele permanece vinculado à qualidade por meio do padrão Quality Gates.
A nossa discussão nos levou a identificar o CI/CD como um dos blocos de construção necessários em um processo de QE.
Resta ser integrado à abordagem geral por meio de seus múltiplos impactos: culturais, organizacionais, de processo, ferramentas e manutenção.
Um CI/CD estrutural e organizacionalmente funcional é como mudar do artesanato para a pequena fábrica.
Antoine Craske
No lado cultural, o CI/CD requer em parte uma transversalidade de responsabilidade pela entrega de software, desde seu design até seu uso.
Abordado apenas sob o aspecto de ferramentas, corre o risco de perder fôlego, além de trazer mais restrições e frustrações do que o valor de negócio inicialmente identificado.
Uma abordagem CI/CD deve, portanto, ser colocada em sua transversalidade:
- Que problemas estamos tentando resolver automatizando processos?
- Como o CI/CD deve ser complementado para resolver os problemas identificados?
- Como o CI/CD se encaixa nos processos, de ponta a ponta, e com quais impactos?
DoD não se limita a User Stories
Xavier compartilhou conosco sua visão de Definition of Done (DoD), muitas vezes limitada a tarefas de desenvolvimento.
Não faltam exemplos de outras tarefas: correção de bugs, organização de um sprint ou lançamento público do produto.
Cada um dos DoDs, portanto, merece ser identificado e definido nas várias tarefas de uma equipa.
Este diagrama de tela do radar DoD exemplifica as diferentes tipologias e níveis de resultados.
Observamos os critérios de usabilidade e medição da entrega, fazendo a ligação com a necessidade de alinhar as questões do cliente no processo do Quality Engineering.
Concretamente para o seu contexto:
- Quais são as tipologias mais relevantes de entregáveis identificados?
- O DoD integra as necessidades de automação, qualidade, usabilidade?
- Como seguir e medir o seu uso real? Esses DoDs são co-definidos, compartilhados e rastreados automaticamente em uma ferramenta de gerenciamento de tarefas?
Quais caminhos para aculturar os desenvolvedores para o Teste?
Essa questão surgiu com o objetivo de disseminar a adoção de testes fora do QA.
Essa etapa parecia fundamental para nós, a fim de integrar a qualidade em todo o ciclo de desenvolvimento e entrega de software.
Mudar os seus hábitos continua sendo um desafio para os seres humanos.
É necessário partilhar as problemáticas, dar sentido e explicar como isso trará valor para a pessoa em questão.
No caso de um desenvolvedor, os testes devem, portanto, possibilitar, no mínimo, entregar mais rapidamente o código com o qual ele está satisfeito em termos de qualidade, tanto quanto o seu cliente.
Ao mesmo tempo, essas novas possibilidades devem limitar os impactos negativos sobre a situação existente e dar um real valor, em detrimento de serem postas de lado.
Um desenvolvedor deve ser capaz de acessar, usar e visualizar os diferentes tipos de teste.
Florian Fesseler
Temos a Developer Experience (DevEx) como um dos pilares do Quality Engineering, a fim de trazer valor aos atores envolvidos nos processos.
Em troca, essa noção de plataforma exige que ela seja planejada e integrada desde a concepção, num padrão de shift-left.
Mecanismos de proteção ficam necessários, longe de soluções manuais, devem ser protegidos por automação e complementados por uma gestão de acesso bem pensada.
Se a equipa estiver fazendo essa pergunta quando a entrega estiver em andamento, provavelmente é tarde demais para as iterações atuais.
Possíveis caminhos para estender os testes aos desenvolvedores:
- Quais são os objetivos esperados e como eles contribuem para o objetivo geral?
- Quais casos de uso e experiência serão fornecidos ao desenvolvedor?
- Como isso muda os hábitos existentes? Quais são as contribuições, freios e limitações?
O Quality Engineering deve fornecer uma plataforma para os diferentes atores.
O valor trazido pela inclusão da qualidade em todo o processo também se estende a outros atores do sistema.
Assim como o controle de qualidade, as equipas de operações históricas devem avançar no sentido de fornecer uma plataforma para desenvolvedores.
Um exemplo concreto é, por exemplo, fornecer um implementação gradual (canary release, A/B testing, …) ou supervisão As A Service.
Essas mudanças são amplamente discutidas no paradigma DevOps, é interessante traçar o paralelo com outros domínios.
O Quality Engineering visa a transversalidade entre os diferentes atores, inspirada no DevOps, com foco na qualidade ao nível da equipa.
Antoine Craske
Quanto às equipas de produto, elas devem ser capazes de iterar em diferentes funcionalidades para julgar o valor para os clientes.
Isso implica, por exemplo, que o desenvolvedor planejou o gerenciamento dessa ativação gradativa, e que se preocupa com ela até a produção.
Na fundação, as equipas de operações devem ter permitido o uso dessas ferramentas para o desenvolvimento.
Também esperamos que o aplicativo seja devidamente supervisionado, talvez complementado por testes em produção.
As perguntas a serem feitas:
- Quem são os atores que colaboram em torno do Produto com probabilidade de agir de acordo com sua qualidade?
- Quais informações, casos de uso e ações podem permitir que eles contribuam?
- Quais organizações, processos e ferramentas podem dar suporte às necessidades identificadas?
Como co-criar uma estratégia de teste
Uma estratégia de teste é muitas vezes definida por uma única pessoa (dica: alguém do QA), com uma falta de inclusão e de alinhamento transversal.
Continua a ser um desafio real: como envolver o gerenciamento do produto, a arquitetura, o desenvolvedor na definição da estratégia de teste?
Inspirado pelos Moving Motivators do Management 3.0, o jogo de cartas “What’s My QA” de Florian Zilliox nos oferece uma possível animação.
O exercício deve ser realmente colaborativo e divertido na sua animação para garantir uma contribuição equilibrada e com interesse.
O processo consiste na preparação de um conjunto de cartas por participante, que cada um deverá priorizar de acordo com o seu ponto de vista.
A equipa partilha as suas diferentes perspectivas e, de seguida, alinha colaborativamente as suas prioridades para a sua estratégia de teste.
Esta abordagem – se corretamente animada e executada – tem algumas vantagens:
- A inclusão dos objetivos do negócio e do cliente na estratégia de teste
- A melhoria da colaboração através da empatia criada entre os participantes
- A materialização de uma dinâmica transversal
Como priorizar o seu esforço de qualidade?
Abordamos a falta de inclusão do contexto e dos objetivos de negócios das pirâmides de teste.
Elas continuam úteis para fornecer um quadro das tipologias de testes e sua possível priorização em um determinado contexto, historicamente de QA.
O Quality Engineering visa proporcionar integração estrutural da qualidade em todo o processo de engenharia de software, começando pelo cliente.
Então, quais modelos podemos usar, tanto para QA que para o QE?
O Xavier compartilhou conosco um modelo pessoal, os Quadrantes de Teste de Software, que se sobrepõe a certos pontos da abordagem da Lisa Crispin e da Janet Grégory sobre Agile Testing.
O modelo tem a vantagem de reforçar a necessidade de equilíbrio para atender estruturalmente à qualidade.
Há um equilíbrio necessário entre a boa construção do software integrando durabilidade básica, a sua aceitação e a resposta às necessidades do negócio.
Os quatro quadrantes materializam os diferentes objetivos do produto, definindo pronto, objetivo, sucesso e feito.
Acho interessante notar que algumas práticas não se destinam a ser automatizadas, o que parece relevante dada a maturidade do ecossistema atual.
Este modelo pode apoiar o exercício colaborativo de estratégia de teste em uma abordagem ágil, garantindo os seguintes pontos:
- Tratamos os diferentes prismas de qualidade em nossa priorização?
- Temos uma definição clara para cada um dos blocos?
- Qual modelo organizacional pode nos permitir entregar os diferentes blocos?
O QE, uma abordagem de plataforma colaborativa
As nossas várias discussões levantaram pontos acionáveis para iniciar um processo de QE.
Assim como acontece com o QA, há a necessidade de alinhar os objetivos da organização e os critérios de sucesso que serão utilizados.
O desempenho da transição deve ser medido passo a passo e merece uma abordagem iterativa e incremental pela complexidade dos atores e processos envolvidos.
Como o software, uma fase de arquitetura e design são necessárias para uma base escalável e sustentável, integrando em parte o CI/CD.
O objetivo do QE é fornecer uma plataforma, que deve ser orientada para os diferentes atores, como desenvolvedores e o resto da equipa.
Por fim, a estratégia de qualidade definida em colaboração permite alinhar os vários atores, os seus objetivos e concretizar a transversalidade necessária.
Conteúdo evocado
Tela de radar de definição de Concluído
https://gearsoftesting.org/tempo-of-testing.html#content4-2b
Qual é o meu controle de qualidade – exercício colaborativo de pirâmide de testes
https://github.com/FlorianZilliox /whatsmyqa/blob/master/whatsmyqa.pdf
Tipologia de teste
https://gearsoftesting.org/test-typology.html#content4-2u
Article Quality Engineering, Accenture
https://www.accenture.com/us-en/insights/ tecnologia / qualidade-engenharia-novo
Agile Testing, Lisa Crispin e Janet Grégory
https://agiletestingfellow.com/
Moving Motivators, Management 3.0