O parêntese do nosso último evento “Como ter sucesso no seu projeto de automação? (em transversal)” tinha bem um significado específico.
Agradeço a cada participante para a sua presença e contribuição :
- Iman Benlekehal, especialista em Software QA
- Benjamin Butel, apaixonado de teste, Software Engineer in Test na Klaxoon, organizador do Ministry of Testing Rennes
- Xavier Pigeon. Expert metodologia e estrátegia Qualidade & TI, autor do gearsoftesting.org e fundador do TestAsYouThink
- Anass El Bekali, CEO QSI Conseil, Presidente do CMTL
- Clément Vannouque, QA Lead na Decathlon
- Benoit Civel, Manager das Soluções Digitais na Auchan
- Soraya Azzaoui, Test Leader na Pictime Groupe
- Siham Amzile, Consultora QA na Henix
Neste evento, discutimos os seguintes pontos:
- Quais são as principais etapas em um processo de automação?
- Que ações devem ser tomadas para garantir a iniciativa o mais rápido possível?
- Que perguntas fazer, que práticas aplicar, em quais fases?
Contextualização do evento
Projetos de automação de testes apresentam alto índice de falhas, apresentando dificuldades reais e particularidades que tem de ser bem compreendidas.
Infelizmente, muitas vezes é delegado ao QA, a um estagiário ou resume-se a às ferramentas só.
Em aquecimento, preenchemos o círculo seguinte, apresentando as etapas tradicionais de um projeto de automação.
O objetivo era colocar as nossas ideias nas diferentes categorias, as mais centrais de acordo com a sua importância.
A partir desta base, o Clément deu início a uma partilha dum projeto actual que deu início ao fio condutor da nossa conversa.
Pelo meio das discussões, vários pontos-chave surgiram e são explicados nas seções a seguir.
Avalie a relevância dos desafios reais do projeto, fora do QA
Uma grande dificuldade é encontrada na falta geral de suporte da qualidade.
Esse ponto fez-nos convergir rapidamente em qual nível de visibilidade, entendimento e de suporte a organização tem para o processo de automação.
As equipes de produto são as principais partes interessadas neste trabalho de convicção, mas a alta administração muitas vezes não é abordada.
Pode pensar que os projetos de automação não valem a pena perguntar às pessoas na gestão, “eles têm coisas mais importantes para fazer”.
Esta é de facto uma resposta possível se o assunto for tecnicamente apresentado, pelo contrário ele deve apresentar objetivos claramente articulados para o negócio.
Duas importantes questões transversais: “Porquê” e “Para quê”.
Iman Benlekehal
Com essas duas perguntas, “Por que” e “Para quê (fazer)”, vemos o projeto numa outra dimensão.
Devemos ser capazes de articular como a automação ajudará a cumprir um ou mais objetivos de negócios.
É aqui que deve buscar e convencer um sponsor.
Identificamos exemplos recorrentes de objetivos nos quais é possível inspirar-se:
- Acelerar a entrega de funcionalidades para o cliente enquanto garantimos a experiência do utilizador.
- Melhorar a estabilidade das funcionalidades centrais do produto apesar das novas versões entregues
- Melhorar o desempenho das equipas, o moral e liberando tempo precioso gasto em tarefas repetitivas
Esses pontos permanecem exemplos que devem ser obtidos pelos stakeholders em seu contexto, a escuta ativa será fundamental nesse processo.
O exercício seguinte será de esclarecer como as entregas do projeto de automação estão alinhadas com os objetivos de negócios definidos.
E, se não conseguirmos convencer, apesar de um argumento preparado?
Confrontando os diferentes atores com a verdade “fria”
Para muitas equipas, apenas a data de entrega conta, o mais rápido possível, em detrimento de outros objetivos como a qualidade.
Vários elementos devem ser levados em consideração aqui: o ser humano é feito de hábitos, uma cultura leva tempo para evoluir, as pessoas orientadas para os resultados não mudam.
Um choque elétrico é, portanto, muitas vezes necessário neste tipo de contexto: será que a equipa percebe o custo da não qualidade e em que círculo vicioso ela se encontra?
A equipa foi confrontada com o nível de qualidade actual? É um eletrochoque necessário.
Benjamin Butel
Isso raramente é o caso com o impacto necessário.
De nossa partilha, identificamos que esse choque é necessário.
Identificamos que os argumentos mais úteis vêm dos diferentes membros da equipa e do cliente final do produto.
Por exemplo, a equipe está ciente do nível de technical debt acumulado e do atraso adicional a cada desenvolvimento? Quais são os indicadores disponíveis para mostrar a realidade actual e a sua evolução?
Medimos o impacto da não qualidade para o cliente? Citaremos o número de bugs encontrados, atrasos na entrega, danos durante a entrega.
O aspecto humano também deve ser levado em consideração, os membros da equipe provavelmente estão estressados, com um número de horas acumuladas, pela frustração das tarefas de rework.
Este banho frio é necessário para estimularmos uma nova dinâmica, cujos contornos devem ser definidos.
Propor uma abordagem ao invés de um projeto só
Identificamos que um projeto de automação tem mais mérito quando tratado como uma abordagem.
Quais diferenças?
Um projeto é uma organização frequentemente temporária que visa cumprir objetivos definidos dentro de um determinado quadro de prazos, custos e qualidade.
A realidade de um produto de software em desenvolvimento é bem diferente:
- O produto evolui, a automação dos testes exige portanto uma manutenção adequada, a IA ainda não existe para automatizar esse trabalho para nós.
- O produto é co-construído, a qualidade e a automação são, portanto, mais planejadas para serem co-construídas do que realizadas em silos a posteriori.
- Os processos de automação de teste devem estar integrados aos de criação do produto, daí a necessidade de adaptação ao longo do tempo.
Uma abordagem pode ser definida em torno de duas dessas definições:
- “Uma forma de caminhar”.
- “Um raciocínio, uma forma de pensar.”
Se dedicarmos um sprint à refatoração, não estaremos mais realmente no Agile. Perdemos a contribuição iterativa e incremental da qualidade no ciclo de entrega.
Xavier Pigeon
Concretamente para um projeto de automação, preferimos pôr em prática, uma forma de pensar e colaborar que evolua com o tempo.
Porém, devemos ter etapas definidas com objetivos específicos, para que a nossa abordagem nos leve aos resultados esperados.
Podemos traçar mais facilmente um paralelo com as abordagens de agilidade que suportam a implementação por meio de uma abordagem incremental e orientada por valor.
Chegamos ao próximo ponto: tornar o processo de qualidade e automação um assunto para a equipa.
Incluir toda a equipa na gestão de qualidade
O product owner e os desenvolvedores consideram a qualidade como um critério nas suas tarefas diárias?
Em caso afirmativo, o caminho para incluir a qualidade em upstream, ao longo do ciclo de construção e entrega está bem encaminhado.
A qualidade é uma responsabilidade transversal, não só do QA.
Iman Benlekehal
Por exemplo, discutimos a Definition of Done, onde podemos adicionar critérios de qualidade.
A prática de testes em conjunto e sessões de qualificação também foi partilhada como útil para melhorar o produto, a colaboração e o entendimento mútuo.
O pilar do sponsor transversal também foi levantado como fator de diferenciação na implementação de uma abordagem de qualidade, pelo seu peso e transversalidade na organização.
Obtendo o sponsor certo e o nível de especialização no momento certo
Um patrocinador pode fazer uma real diferença no projeto.
No entanto, ainda falta convencê-lo das contribuições do nosso projeto. É necessário falar sobre a contribuição do negócio e o valor para a organização.
Um patrocinador convicto é o que também pode dar acesso a recursos adicionais para proteger seu projeto.
O patrocinador é um elemento estruturante de um projeto de automação.
Anass El Bekali
Às vezes, você precisa saber como obter ajuda e aceitar uma perspectiva diferente.
A experiência pode fazer sentido no início de um projeto de automação para limitar o risco para a organização.
Muitas vezes, decisões dispendiosas são tomadas no início e impactam o resto do projeto.
Essa contribuição pode assumir diferentes formas, uma auditoria inicial, uma expertise pontual ao longo do projeto, uma consulta sobre um ponto específico.
O principal é ter a humildade necessária e utilizá-la no contexto em questão, e em primeiro saber defender o seu investimento.
Um projeto de automação de teste exige uma abordagem transversal
Reconhecemos a necessidade de verticalidade da direção até as equipas, e da transversalidade para o sucesso do seu projeto de automação.
Uma abordagem continua sendo mais importante para além de um projeto parece-nos a melhor abordagem para trazer valor no tempo.
Uma abordagem iterativa e incremental é uma chave para validar os incrementos de valor e adaptar os processos, ferramentas e organizações à realidade.
Algumas coisas não são fáceis de obter, mas farão a diferença, como um sponsor e um especialista.
Um eletrochoque para confrontar-se à realidade actual é muitas vezes um passo pelo qual devemos passar para estimular o suficiente.
Outros eventos estão por vir, espero que a nossa partilha tenha sido útil para si, encontre o conteúdo disponível em vários formatos áudio e vídeo.
Junta-se a QE Unit para aceder a conteúdos com antecedência, ficar a par das novidades, e mensagens reservadas a este canal.
Conteúdos mencionados
Scrum Life e Jean-Pierre Lambert