Não há mais Quality Assurance na Manomano & OpenClassrooms

“Paramos com a Quality Assurance”.

Foi essa transformação que o Olivier Dennemont e o Vincent Dauce conseguiram nas empresas Manomano e OpenClassrooms, dois grandes players digitais. A palavra “QA” e sua percepção desapareceram dessas organizações.

A Quality Assurance deu lugar ao modelo organizacional de Quality Assistance. Trata-se de abordar a qualidade do software o mais cedo possível, de forma transversal e contínua na cadeia de valor do software.

Nesta entrevista, partilhamos as suas experiências de respectivas transformações, explorando a sua definição, gestão da mudança e resultados obtidos. As referências citadas estão disponíveis ao final do artigo.

Siga a QE Unit para aceder a mais conteúdos exclusivos da comunidade.

Podem começar por apresentar-se?

Vincent : Sou o diretor de qualidade da OpenClassrooms. Também estou preparando uma palestra sobre este assunto para o Paris Test Conf. Esta é a abordagem que adotamos com nossa equipe de qualidade. Também faço parte da comunidade do Ministry of Testing Paris, que geralmente interage com outras comunidades na França.

Olivier : Sou QA Manager na Manomano. Eu gerencio a equipe “Qraft” que representa o jogo de palavras em Qualidade e Craftsmanship. Cheguei há dois anos e meio no controle de qualidade para redefinir a estratégia. Tenho experiência como gerente de engenharia, principalmente em aplicativos móveis.

Que definição dão para a Quality Assistance?

Olivier : A Quality Assistance contrasta claramente com a Quality Assurance. Nós também associamos a noção de ser o fiador do software que entra em produção em muitos contextos.

Na Manomano este modelo não funciona. O nosso contexto é o de uma empresa em hipercrescimento, com uma arquitetura cada vez mais complexa e distribuída para atender aos desafios da organização. Ter pessoas verificando se “a qualidade é boa” ou “se não há bugs” no final da cadeia não funciona.

Encontrei o modelo de Quality Assistance na Atlassian enquanto procurava desenvolver uma alternativa. Com o tempo, aprendi a entender e a iterar na implementação do modelo. Ele responde a uma questão concreta da escalabilidade das práticas de qualidade. Ensinamos todos a trabalhar melhor em vez de otimizar um silo.

“Vindo da engenharia, estou convencido de que o software deve ser produzido bem muito mais cedo. Atuar na segunda fase não é a prioridade. ”
Olivier Dennemont

Vincent : Concordo com o Olivier em muitos pontos. A grande diferença é que essa abordagem envolve muitas pessoas. Têm que conseguir uma mudança real de mentalidade para diferentes atores: o desenvolvedor, designer, gerente de produto, etc. É uma verdadeira mudança organizacional.

O objetivo principal é acelerar a entrega por meio da colaboração. Dizemos que colaboramos, é verdade. No entanto, muitas vezes encontramos silos que dispensam batatas quentes, sem realmente haver uma troca transversal.

Por que iniciaram um processo de Quality Assistance?

Vincent : Em julho de 2020, mudamos a forma como gerenciamos nossos roteiros. Tínhamos lançado uma pesquisa conjunta durante as várias retrospectivas. Durante este exercício, obtivemos o dobro de feedback sobre a organização da qualidade, as suas dificuldades e a sua inserção no roadmap. Esse foi o ponto de partida.

Estávamos saindo de longe. A QA era “responsável” por atrasos nas entregas de produção. Os atalhos foram então adotados para serem executados rapidamente, mas à custa da qualidade. Muitas vezes ouvimos “é o controle de qualidade que bloqueia”. E ainda, 40-95% das tarefas atribuídas ao controle de qualidade na verdade continham as causas raiz upstream.

Portanto, decidimos abordar a organização para essas questões de desempenho estrutural.

Olivier : Acumulamos sintomas semelhantes. Muitas vezes, o controle de qualidade era considerado responsável por problemas de entrega de software. Um atalho muito questionável foi criado entre os problemas de qualidade encontrados pela falta de testes pela equipe de QA. Também precisávamos impedir erros e bugs recorrentes.

A percepção do controle de qualidade é contraditória com as próprias razões da existência de bugs. Eles existem por causa de falhas na arquitetura, no código ou mal-entendidos; não por falta de testes. Mais testes ou testes diferentes podem ajudar na detecção. Mas o que nos interessa são as causas profundas.

Nós realmente precisávamos colocar nossas cabeças acima da água para aumentar nossa qualidade. Era preciso ter sucesso em criar inveja e integrar as equipes para se incluir também nas abordagens Lean, Agile ou DevOps. Também fico frequentemente surpreso com a lacuna de maturidade na engenharia de software para abordagens de qualidade.

Quais alterações e mudanças realizaram?

Olivier : Mudei o nome da equipe para “Qraft”. A mensagem forte era esclarecer que não éramos mais uma equipe de controle de qualidade.

Incorporamos nele outros perfis, como desenvolvedores. Eles ajudam outros desenvolvedores com ferramentas, colaboração, métodos. Também integramos coaches em craftsmanship para ajudar os desenvolvedores a fazer melhor na raiz. O objetivo deles é como o princípio do Uncle Bob “O controle de qualidade não deve encontrar nada”.

Para conseguir isso, reunimos as equipes de craftsmanship e de arquitetura. Transformamos os cargos de engenheiros de garantia de qualidade em consultores de qualidade. Os últimos são delegados às equipes de produto para colaborar o mais cedo possível, o mais próximo possível e continuamente na cadeia de software.

Diferentes funções são necessárias. Temos gerentes, treinadores e também embaixadores. Animar todos os atores é fundamental para a mudança.

Vincent : Mudamos muitas coisas iterativamente. A equipe de QA também foi renomeada para Quality Engineering. Eu mesmo mudei minha posição de gerente de QA para Diretor de Qualidade. Queríamos marcar a ocasião removendo o termo “QA” também associado a “Quality Assurance”.

Alinhamos a missão da equipe para esclarecer nossa intenção. Longe de fazer testes ou apenas procurar bugs, nossa missão focou em “acelerar o alcance da qualidade entregável que torne a educação acessível”. Os dois conceitos importantes são “acelerar” e “qualidade entregável”.

Comunicamos muito em toda a organização, para o produto, para a tecnologia. Organizei um lançamento transversal oficial para esclarecer aonde queríamos ir. Também promovemos a aculturação com vários conteúdos, como o vídeo de Alan Page sobre Adventures in Modern Testing. Em 2021, trouxemos uma empresa externa para nos ajudar a definir a Qualidade: partilhar percepções, critérios e objetivos.

Dividimos nossa missão em objetivos para acelerar a entrega, eliminando gargalos e garantindo a qualidade. Não há mais indicadores sobre o número de tickets verificados com um foco local. Olhamos para objetivos transversais, como o cycle-time alinhado com a nossa missão.

O empenho dos vários actores foi fundamental para obter as suas necessidades, o seu apoio e permitir uma verdadeira transformação para uma colaboração transversal.

Que resultados obtiveram? Para qual criação de valor?

Vincent : Voltamos à medida um ano após o lançamento do processo.

Várias melhorias estruturais foram observadas:

Uma melhoria no cycle-time de 34% desde o final do desenvolvimento até a disponibilidade de produção;
O desaparecimento de reclamações de “problemas de QA” durante várias retrospectivas;
Uma melhoria nos testes “úteis” criados por jogadores diferentes dos históricos no controle de qualidade.

Além disso, também lançamos uma pesquisa sobre a percepção do controle de qualidade. 60% das equipes nos consideraram essenciais, 30% muito úteis e 10% úteis. É um verdadeiro marcador de mudança na organização após um ano. Temos até um pouco de medo de ser indispensáveis.

Isso é compreensível na nossa fase de maturidade e estamos trabalhando nisso.

Olivier : Primeiro medimos o número de anomalias conhecidas e aberturas na produção. Durante o primeiro ano, acumulamos sem ver nenhuma mudança estrutural. Também era preocupante, estava quase começando a não acreditar mais.

Mas então vimos uma reversão da tendência. Nossos 800 defeitos foram reduzidos à metade.

Também saímos do círculo vicioso do broken window. Como uma política de zero bug, a presença de um único bug gerou capacidade de resposta imediatamente para lidar com ele o mais rápido possível. Anteriormente, um bug entre muitos outros era considerado normal e permanecia aberto por um tempo considerável.

O papel da equipe é, na verdade, criar e manter essa pressão constante por qualidade, sem torná-la opressora. Essa restrição deve possibilitar a liberação de energias para abordar de forma proativa a qualidade com foco na experiência do usuário e nas melhorias, ao invés do tratamento de defeitos.

Quais freios encontraram? O que aprenderam com isso?

Olivier : Foi difícil manter o curso sem obter resultados nos primeiros meses. Tínhamos que explicar que o modelo era viável e sustentável sem poder justificá-lo em nosso contexto.

Os atores estavam muito acostumados com o ritmo confortável de executar verificações no final da cadeia. Na realidade, era impossível abordar a qualidade dessa forma. Devemos ser capazes de desafiar as escolhas de arquitetura, design e até mesmo soluções.

“A resistência à mudança foi o principal problema a ser abordado.”
Olivier Dennemont

Tínhamos que ter uma verdadeira força de afronta e assertividade para questionar certas escolhas. A pedagogia foi essencial ao fazer referências a outros setores, outras organizações como a Atlassian, vinculando-as a exemplos internos.

As falsas equações de “qualidade = teste” e “teste = qualidade” também tiveram que ser desmontadas na mente das pessoas. Isso parece óbvio, mas é preciso permitir aos atores dar um passo atrás para perceber no lugar do teste na cadeia de valor do software.

Gosto muito do trabalho de James Bach a este respeito que decorre os testes que podem ser automatizados ou não. Um dos limites do modelo pode ser alcançado quando é necessária a realização de testes que requerem a experiência de um testador real. precisa ter as habilidades certas para realizar os testes certos.

Vincent : Encontramos os freios clássicos para qualquer mudança. Atores que questionam, céticos em relação aos modelos, para criticar o modelo, para questionar os processos e propostas. Esses freios fazem parte do processo.

Seguimos com as pessoas que mais gostaram desse processo. Aos poucos, isso criou uma bola de neve no resto da organização.

“As principais questões são sobre papéis e responsabilidades numa mudança para a Quality Assistance.”
Vincent Dauce

Costumamos dizer “a qualidade é um assunto de todos”. Podemos concordar com este princípio, mas ainda temos de aplicá-lo no resto da organização. Em garantia de qualidade, o modelo era claro, mas ineficaz. Na Quality Assistance, deve haver um esforço coletivo que requer esclarecimentos que podem ser qualificados de acordo com o contexto. Às vezes, a colaboração é a resposta.

Também era necessário abordar funções e habilidades. Nossas funções existentes tiveram que evoluir para mais suporte e treinamento, em vez de contribuições operacionais únicas. Alguns evoluíram na revisão de código, TestingOps.

Ao mesmo tempo, nossa organização cresceu em um contexto de crescimento que tornou nossa tarefa difícil. Tivemos que integrar pessoas que não conheciam completamente o mundo antes e nem se envolveram no processo. O alinhamento dos atores através da clareza de responsabilidades e comunicação sustentada foram fundamentais.

Quais são as vossas próximas prioridades de Quality Assistance?

Olivier : Nosso foco é a Gestão da Qualidade, que vai além da Quality Assistance.

Eu trabalho para educar a alta administração em questões de qualidade. O objetivo é que a Qualidade seja um critério integrador das decisões estruturantes das empresas. O debate deve ser transversal e subir ao nível do conselho de gestão, para assim permitir ainda mais investimentos estruturais.

Tenho um grande esforço de comunicação para conseguir usar dados e vinculando o assunto aos desafios da empresa. É um esforço constante para aumentar essa pressão positiva pela Qualidade.

Por exemplo, as métricas focadas na experiência do usuário são muito poderosas e facilmente implantáveis em toda a organização.

Vincent : Eu trabalhei em um documento para formalizar a evolução de nossas práticas de qualidade nas salas Openclass. Na verdade, é a formalização de todo o nosso esforço e da nossa visão para alinhar os atores e nos ajudar no futuro.

A qualidade sempre foi um componente forte na OpenClassrooms. Temos perfis de qualidade atribuídos à qualidade dos cursos diretamente nas equipes de conteúdo. É um assunto cultural importante para se manter vivo na vida cotidiana.

Nossa próxima prioridade é consolidar e, em seguida, subir para o próximo nível de maturidade do modelo do Dan Buckland. Queremos avançar para a Fase 2, onde a maioria das outras equipes realizam atividades de Qualidade.

Por exemplo, abordamos a prática de testes de integração com desenvolvedores, tanto no front quanto no back end. Nosso objetivo é fornecer kits de ferramentas para torná-los autônomos em testes automatizados.