Pude entrevistar o Lionel Ducrocq sobre uma experiência de projeto de automação cheia de reviravoltas.

Eu queria compartilhar com mais detalhes as práticas que identificamos em retrospecto em nosso intercâmbio.

• Fica no controle de seu repositório de teste, especificações e entradas é um ativo

• Teste rapidamente os casos de uso críticos com os requisitos não funcionais

• Antecipe os custos de automação diretos e indiretos para construir um plano realístico

• Use seus instintos como um guia complementar para gerenciamento de risco

• Compreender a origem e os contornos de uma solução permite um melhor entendimento de sua integração natural

As seções a seguir detalham os pontos com recomendações acionáveis.

Manter o controle de seu repositório de teste, especificações e entradas é fundamental em todos os momentos

Você terceiriza as funções essenciais do seu negócio?

Imagino que não e estou convencido de que o raciocínio deve ser semelhante para o seu repositório de requisitos.

O conhecimento dos testes é em grande parte um reflexo das necessidades do negócio, que evoluem e refletem o operating model da empresa.

É aí que encontramos o valor diferenciador da empresa, que pode revelar-se um verdadeiro ativo da empresa se for dominado.

Um repositório controlado é um ativo real da empresa: um reflexo dos requisitos proporcionando flexibilidade na implementação.

Antoine Craske

Em controle, garante a relevância dos casos de teste, sejam manuais ou automatizados, executados internamente ou externamente.

Na experiência do Lionel, isso permitiu-lhes pivotar rapidamente, alterando ferramentas, equipes e de parceiro.

Excepcionalmente, pode também permitir que o teste manual seja executado em caso de problema no teste automático.

Teste rapidamente os casos de uso críticos com os requisitos não funcionais

Neste caso específico, centenas de casos de teste foram identificados no âmbito da automação.

O estudo de viabilidade centrou-se em quatro testes de validação de diferentes tipologias.

No entanto, a capacidade de paralelização dos testes e sua estabilidade não foram avaliadas na primeira parte do projeto.

Testar requisitos não funcionais é fundamental num projeto de automação.

Antoine Craske

Em vista dos problemas de infraestrutura estruturais encontrados posteriormente, o teste desses requisitos não funcionais poderia ter detectado o problema de estabilidade.

Notamos que os requisitos não funcionais são fundamentais num projeto de automação.

Portanto, é necessário tornar esses requisitos explícitos no início de um projeto e definir um plano de teste adaptado.

Menos visíveis e naturalmente evocados, são facilmente colocados de lado, a um preço que pode relevar-se caro mais tarde.

Antecipe os custos de automação diretos e indiretos para construir um plano realístico

No compartilhamento de experiências, percebemos que a carga de revisão e de validação não foi prevista.

O atraso aparece e acumula-se, acentuado pelas perdas de tempos em mensagens, o contexto de trabalho remoto e as prioridades diferentes entre as equipas.

Um paralelo pode ser traçado com os projetos de desenvolvimento de TI, onde os custos indiretos para as tarefas de produção devem ser previstos.

As tarefas de automação têm sobrecargas associadas, como especificação, revisão, integração e teste.

Antoine Craske

Este é frequentemente um aspecto esquecido em projetos de automação. Encurtamos o projeto apenas para tarefas de automação.

Essa carga pode ser estimada no início do projeto, a fim de garantir um melhor respeito dos prazos de entregas, inspirada no ciclo de vida do teste (STLC).

Uma prática comum é de colocar uma carga indireta por grande categoria de complexidade dos casos de teste identificados.

Esta carga é então adaptada durante a execução do projeto face à realidade, estando sujeita a possíveis otimizações.

Muito parecido com a peer review do desenvolvimento de software, dedicar intervalos de tempo para a revisão e a validação de teste pode facilitar o feedback direto, a colaboração e o entendimento mútuo.

Use seus instintos como um guia complementar para gerenciamento de risco

Várias pessoas na equipe notaram testes estáveis ​​apenas no parceiro e na demonstração programada.

Durante o decorrer do projeto, a estabilidade do ambiente acabou por ser um fator limitador forte, que acabou por ser bloqueante.

Outros fatores entraram em jogo, como restrições de segurança e o acesso à infraestrutura.

No entanto, sentimos que seguir a nossa intuição e nossos instintos às vezes pode nos colocar no caminho certo.

A nossa intuição pode nos guiar para os caminhos certos.

Antoine Craske

Não subestimar o nosso instincto e agir cedo pode fazer a diferença. Um problema não tratado tem tendência a multiplicar-se em vez de se resolver dele próprio.

Pragmaticamente, dedicar pessoalmente uma hora por semana no seu diário para fazer uma revisão das actividades, dando um passo atrás para planear ações.

Pessoalmente, esta é uma prática que utilizo para me distanciar das questões operacionais e ter uma perspectiva sobre os objetivos e a evolução do seu contexto.

Num aspecto de colaboração e de inteligência colectiva, organizar sessões de análise de risco com a equipe do projeto a cada 2 a 3 semanas também é uma prática relevante.

Falamos de retrospectiva no mundo ágil, mas permanece menos natural em projetos tradicionais.

O gerenciamento de riscos às vezes permanece fechado para o gestor de projeto, mas merece ser aberto e compartilhado para trazer mais valor a organização.

Compreender a origem e os contornos de uma solução permite um melhor entendimento da sua integração natural

Compartilho aqui uma reflexão que li no livro The Software Architect Elevator, de Gregor Hohpe.

Na história compartilhada, percebemos que a plataforma técnica implantada internamente finalmente apresentou problemas.

Em retrospectiva, perguntamos se o produto era de fato adequado para uma instalação on-premise, provavelmente não era.

É aqui que perceber a origem de um produto, identificar o seu coração, porque foi criado, é muito útil para delimitar os seus contornos.

Compreender a origem de um produto permite definir os seus contornos e identificar os seus limites.

Antoine Craske

Neste caso específico, se a solução já era instável na primeira demonstração, era questionável avançar com a sua implantação.

Concretamente, construir uma lista de perguntas para avaliações de solução é uma prática comum.

Pessoalmente, julgo que temos que manter as coisas simples e com uma visão ampla numa primeira abordagem, evitando matrizes de decisão com 100 critérios.

As perguntas devem permitir que você execute um 80/20 identificando os pontos-chave de compreensão e de atenção.

Esta abordagem torna possível limitar algumas escolhas relevantes que serão exploradas em mais detalhes.

Um projeto de automação continua sendo um verdadeiro desafio devido à sua complexidade e transversalidade

Percebemos que um projeto de automação de teste requer organização real, gerenciamento e maior análise do contexto.

Os fundamentos do gerenciamento de projetos, gerenciamento de equipas e qualidade de software são a chave para o sucesso de um projeto de grande escala.

Espero que este artigo tenha sido útil na partilha de experiência, e também concreto e acionável para si. Sinta-se à vontade para comentar e reagir para continuar a partilha.