Nosso último evento foi dedicado a tornar as equipas responsáveis ​​pela qualidade do software.

Gostaria de agradecer aos seguintes participantes por sua presença e contribuição:

• Ahmed Hafni, Gerente de Pólo de Testes na KP2i
• Anass El Bekali, CEO QSI Conseil, Presidente na CMTL
• Arnaud Dutrillaux, Líder de QA na Synthesio
• Benjamin Butel, apaixonado por testes, engenharia de software em Test na Klaxoon, organizador do Ministry of Testing Rennes
• Christian Sayegh, Consultant and Automation Specialist na CloudNetCare,
• Hugo Casanova, QA Lead na AOS
• Johann Gaggero, Head of Omnichannel QA na LVMH
• Sophie Tual, QA Engineering na PayLead
• Grace Kongo, Test Analyst na Q -leap

Neste evento, abordamos as seguintes questões:

• Qual o posicionamento da qualidade de software na empresa?
• Qualidade de software, para quem e para que utilidade?
• Como identificar o valor da qualidade do software?
• Qual(is) organização(ões) para transversalizar a qualidade do software?

Qual o posicionamento para a qualidade de software na empresa?

Muitas vezes considerada uma função de suporte secundária, a qualidade do software é frequentemente encontrada posicionada entre o negócio e o IT.

Mais precisamente em reporting de uma dessas funções.

Essas opções lembram amargamente os CIOs a reportar ao CFO ou COO, refletindo o nível de interesse na função.

No vosso contexto, a qualidade está no board de diretores?

Algumas empresas deram esse passo e podem ter adquirido um relevante “Head of Product, Acceleration & Quality”.

Qualidade geralmente é a segunda prioridade da engenharia de software.

Christian Sayegh

Identificamos vários fatores que contribuem para esse posicionamento secundário.

A proposta de valor da qualidade do software muitas vezes não está ligada a indicadores e questões que a gestão valoriza.

Para outros, terceirizar a qualidade é uma escolha mais ou menos deliberada para livrar-se da sua responsabilidade.

Estruturalmente, a qualidade é transversal em suas atividades, dificultando seu posicionamento entre negócios, IT e suporte.

Portanto, encontramos silos e particionamento ainda fortemente presentes.

Separações que também podem distanciar as equipas de seu cliente real. 

Qualidade de software, para quem e para que utilidade?

O Arnaud deu-nos um elemento de resposta com esta citação.

“Quality is value to some person.”

Jerry Weinberg

Esta noção de percepção de valor para um ator é fundamental.

Adiciona uma dimensão humana, perspectivas e interesses a serem levados em consideração além de um aspecto estático do produto.

Veja o exemplo de uma equipa de teste isolada. Tenderá a otimizar o valor de qualidade local de sua percepção, otimizando a cobertura de uma matriz de teste, por exemplo.

Mas, em última análise, qual é o valor dessa qualidade para o cliente final? 

Provavelmente muito pouco.

Por outro lado, uma interface minimalista rapidamente entregue com um mínimo de testes de aceitação poderia ser muito útil para um cliente.

Também será de valor para a administração que deseja acelerar a entrega de soluções digitais para seus clientes e seu desempenho.

Devemos, portanto, focar nossa abordagem em fornecer valor aos vários participantes do ecossistema.

Como identificar o valor da qualidade do software?

É necessário compreender o ponto de vista da qualidade dos clientes.

Empatia, escuta ativa e capacidade de reformulação são fundamentais para identificar as questões, palavras e interesses dos stakeholders.

Articular o valor da qualidade geralmente requer o confronto com a realidade da experiência do cliente e dos processos de negócios.

O Johann compartilhou a co-localização das equipas de QA o mais perto possível do cliente, desde a fábrica, loja, ou armazém.

O suporte ao cliente também é uma excelente fonte de informação sobre a percepção de qualidade que qualquer organização deve ter em visibilidade.

A qualidade deve estar o mais próximo possível do negócio, até o contato com o cliente.

Johann Gaggero

Define visões clientes de ponta a ponta via personas também permite concentrar toda uma equipa no mesmo prismo.

Os meios de comunicação também devem refletir a linguagem comercial do cliente final e dos interlocutores internos.

Finalmente, por que agir de forma diferente das equipas do negócio?

Essa capacidade de adaptação, quase como um camaleão, permite que mergulhe e seja integrado pelas equipas de negócios.

Articular o valor da qualidade do software, portanto, requer uma pró-atividade inicial.

Como articular a proposta de valor da qualidade do software?

Identificar os contornos do valor é o primeiro passo.

O Arnaud lembrou que a qualidade do software não trata apenas de testes, um elemento que muitas vezes é importante de lembrar aos não iniciados.

Do ponto de vista da proteção, a redução de riscos é frequentemente citada, mas a qualidade do software não está apenas efetuada a posteriori, no final da cadeia.

A qualidade é um componente chave para fornecer estabilidade, confiança e reduzir os ciclos de iteração.

Não é essa aceleração controlada que muitas organizações procuram alcançar?

A qualidade pode, portanto, ser defendida pela capacidade de acelerar as capacidades de aprendizagem, entrega e capacidade de resposta da organização.

Por que não aplicar a engenharia de requisitos aos seus processos de engenharia da qualidade, além de apenas o produto?

Como identificar os requisitos de uma abordagem de Quality Engineering?

Os requisitos devem permitir de traduzir as necessidades da organização em uma abordagem de qualidade mais global.

A categorização em necessidades funcionais e não funcionais também é relevante.

Os requisitos funcionais devem permitir responder aos casos de uso para os vários atores identificados: product owner, product analyst, software engineer, …

Por exemplo, os serviços exigidos por um desenvolvedor devem estar disponíveis em self-service numa plataforma de desenvolvimento.

Quanto aos requisitos não funcionais, embora numerosos, o seu alinhamento em termos de definição, prioridade e planejamento são mais do que necessários.

A aceleração e a estabilidade são expectativas comuns, mesmo que raramente explicadas e medidas nos processos.

A portabilidade pode, por exemplo, ser valorizada pela organização, o que pode exigir o uso de abstrações e separações explícitas dos sistemas.

A escalabilidade merece um workshop de definição por causa de suas várias interpretações e possíveis percepções, na rapidez de instalação ou de paralelização.

A segurança também deve ser esclarecida a fim de valorizar e identificar a possível redução de risco.

Este tópico merece vários artigos, a mensagem sendo de capitalizar na engenharia de requisitos.

Qual(is) organização(ões) para transversalizar a qualidade do software?

A arquitetura da organização da qualidade é um assunto real.

Tal como acontece com um projeto, os objetivos e desafios devem ser definidos.

As etapas anteriores devem ter permitindo a identificação do valor da qualidade do software.

O desenho organizacional está fortemente ligado às interações que promoverá ou, pelo contrário, prejudicará.

Como acontece com muitos assuntos, julgo que a resposta está no equilíbrio.

A implantação de modelos em feature-teams ao extremo tenderá a criar silos paralelos, propícios à duplicação de trabalho e conflitos a médio prazo.

Pelo contrário, uma equipa fechada verticalmente em modo de shared services pode tender a otimizar os seus próprios fluxos de processos, distanciando-se das necessidades dos clientes finais.

Os modelos de SaFE e de agilidade em escala possuem elementos de resposta nos quais podemos nos inspirar: coach ágil, enabler, equipas transversais alinhadas com OKRs de negócios, comunidades transversais internas.

Em todos os casos, a qualidade deve ser incluída desde o design, o mais cedo possível.

O posicionamento e a organização da qualidade devem, portanto, ter sido pensados, formulados e implementados.

Se os modelos existem, por que ainda é tão difícil implementá-los?

Quais os obstáculos para uma transversalização da qualidade?

Gerir mudanças nas organizações envolve indivíduos e dinâmicas de grupo existentes.

Os egos das várias partes interessadas, portanto, não devem ser subestimados.

Os interesses são fortes impulsionadores do comportamento, desde a motivação até o desejo de mudar, agir fora da zona de conforto.

O problema não estaria nos silos e nos diferentes egos?

Benjamin Butel

O Benjamin compartilhou conosco a postura às vezes arrogante do negócio para a engenheira, quase querendo substituir-se ao cliente final.

Neste caso, é um verdadeiro obstáculo à transversalização da responsabilidade pela qualidade, mesmo com um modelo organizacional horizontal.

É também o caso para desenvolvedores ou alguém das operações: por que ele iria a reuniões adicionais em vez de fazer confortavelmente as suas tarefas habituais?

A mudança e a sua conduta devem ser pensadas, animadas e reforçadas.

Também voltamos aos sponsors, tão diferenciadores e importantes na implementação de uma abordagem de qualidade.

Quais são os interesses dos sponsors de uma abordagem de qualidade?

Um projeto sem orçamento provavelmente tem uma baixa prioridade e alta probabilidade de fracasso.

Mesmo que irritante, essa questão da existência de orçamento solicitado pelos vendedores na fase de prospecção mostra o aprendizado deles.

A realidade é que um orçamento real deve ser divulgado pelos sponsors para uma abordagem de qualidade com impacto.

Para convencer, é preciso identificar os interesses dos patrocinadores além dos da organização.

Um projeto sem patrocinador geralmente rima com um projeto sem orçamento.

Christian Sayegh

Em alguns casos, eles estarão alinhados com os da organização.

Às vezes, eles terão uma orientação de interesses mais políticos ou pessoais, e será apropriado julgar o alinhamento com os do negócio.

A percepção de maturidade e a consciencialização da qualidade na organização são necessárias para ajustar e direcionar o seu esforço.

O Arnaud nos perguntou se a qualidade de software não permaneceria muito nos seus pontos históricos, com falta de iniciativas. 

Devemos, sim, ser pró-ativos com os sponsors, mesmo estando muitas vezes mal posicionado na organização.

Finalmente, como fazer da qualidade a responsabilidade de todos?

A qualidade do software é um conjunto de atividades, não uma responsabilidade individual.

Tornar-se o negócio de todos significa torná-lo uma prioridade para a organização, através dos vários jogos de influência, de animação, e orquestrar atividades cada vez mais maduras.

Os objetivos do processo devem ser verdadeiros contribuintes de valor, tanto para o cliente final como para os interesses dos vários intervenientes.

Adaptar os objetivos por estágio de maturidade da organização permite passar pelas etapas.

O Hugo partilhou connosco o caso de empresas que, mesmo recentes e sozinhas no seu mercado ou principal líder, integram a qualidade a um elevado nível de exigência para se manterem um passo à frente.

A arquitetura da organização, em particular das suas interações, é um elemento diferenciador para o alcance dos objetivos do sistema.

Na verdade, é muito difícil obter resultados para os quais o sistema e a organização não foram projetados.

Toda a organização deve estar envolvida e motivada pelo processo, para se sentir responsável, ativa e com impacto no seu desenvolvimento.

É também o que possibilitará a implementação de mecanismos reais de aprendizagem organizacional e estruturalmente eficientes no longo prazo.

Também nos questionamos se a qualidade deve ser um critério de valorização das empresas, ou integrada como responsabilidade social.

A qualidade deve, em qualquer caso, ser parte integrante do produto desde a sua concepção, seja ou não reforçada por mecanismos de incentivos.

Além dos interesses individuais, são necessárias uma liderança real e pró-atividade.

Devemos esperar um novo CxO de qualidade de software?

A priori não, já podemos atuar como esse líder hoje.