Para esta história da Quality Engineering Unit, dou as boas-vindas ao Jean-Baptiste Crouigneau, Fundador e Diretor da Prodigeo, a software quality and testing expert based in Morocco.

É consultor, treinador e auditor em todas as atividades de teste, com predileção por aspectos de gerenciamento de teste, melhoria de processo e automação de testes.

Jean-Baptiste é membro fundador do CMTL (Comitê de Teste de Software Marroquino) e também ativo no ISTQB (atualmente membro do Grupo de Trabalho de Exames) e na TMMi Foundation.

Compartilhamos um projeto para definir uma estratégia de teste em um projeto de alto risco, monitorado pela direção geral e com uma data de lançamento fixa para o público.

O projeto acabou por conter objetivos indiretos e longe de serem só de teste, daí o título “A História de uma agenda oculta”.

Foi necessária uma forte capacidade de adaptação para equilibrar os desafios deste projeto, complementada por elementos esclarecedores!

Compartilhamos aqui seu feedback sobre os seguintes pontos:

• Siga pistas para sentir o contexto da intervenção

• Identifique os objectivos directos e indirectos do projeto

• Entenda as reais expectativas dos interlocutores

• Saber como se manter firme em suas convicções e valores

• Adapte certas entregáveis para que sejam de maior valor

Boa audição, leitura ou visualização conforme a sua conveniência, fique a vontade em comentar.

Junte-se a QE Unit para ter acesso a conteúdo exclusivo e regular pela newsletter.

Antoine: Pode começar por apresentar-se?

Sou principalmente um especialista em teste de software em três tipos de actividades.

Primeiro, faço formações para partilhar experiências, especialmente na componente ISTQB, que é bastante conhecida hoje em dia, no que diz respeito a testes. Mas também trabalho com  a engenharia de requisitos.

Em segundo lugar, ainda na área de testes, realizo auditorias com o modelo TMMI, menos conhecido mas semelhante ao CMMI para o desenvolvimento de software.

Além disso, também faço projetos no terreno na área de testes, para diversos clientes.

É por isso que tenho muitas anedotas e histórias que acumularam-se ao longo do tempo.

Escolhi uma dessas aventuras para conversarmos juntos hoje.

O contexto do projeto

Antoine: Pode nos contar um pouco mais sobre essa história?

Há cerca de quatro anos, eu estava trabalhando em um banco com sede no Marrocos, onde estou atualmente a viver.

Para contextualizar o projeto, nos Marrocos como em muitos países, foram lançadas ofertas de bancos islâmicos.

Foi um processo que demorou muito tempo para acontecer e, uma vez estruturado, tornou-se uma corrida entre os bancos.

O banco em questão era marroquino e pretendia criar um novo banco, completamente separado do existente.

Uma solicitação tardia para um projeto estratégico

Fomos chamados para descrever a estratégia de teste. Como de costume de última hora.

Jean-Baptiste Crouigneau

Antoine: Então não houve orçamento ou mesmo tarefas alocadas para o teste?

Não exatamente, havia coisas já planeadas, mas os desenvolvimentos já estavam iniciados e bem avançados, com uma datas fixas impostas pela administração.

Basicamente, o cronograma não era muito realista, faltavam 9 meses para o lançamento oficial do projeto.

Antoine: Qual era o perímetro de implementação, todo o back office, baseado em um ERP?

Sim, era um âmbito completo, baseado em um ERP libanês especializado, que fornecia uma boa base.

Ainda assim, houve muito trabalho devido a desenvolvimentos específicos e ao esforço de integração necessário.

Assim, passamos a atender os diversos interlocutores do projeto, que reiteraram suas altas expectativas apesar das fortes limitações.

Ao nível da equipe de teste, não havia nenhuma!

Havia quatro líderes de áreas de negócios, mas eles não eram testadores e tinham muito que fazer fora dos testes.

O planeamento e a disponibilidade de pessoas eram, portanto, duas fortes restrições.

Adicionamos a isso três fases de testes que eram já planeadas, sem que ainda pudéssemos analisar o projeto.

Fortes restrições forçam um exercício de priorização

Dadas essas restrições, concluí que iria estimar a carga, dividir pelo número de dias que nos restavam e ver o que poderia ser oferecido.

Antoine: Em vista das limitações de tempo e recursos, isso implicou de priorizar um perímetro?

Sim, completamente.

Recuperamos requisitos formalizados de alto nível, entre 500 e 600!

Fiz uma pequena regra de três na fase de teste dividida entre conceção, implementação e execução.

Identificamos entre 500 e 600 requisitos, para mais de 1.500 testes “só”

Jean-Baptiste Crouigneau

Também presumimos que conseguiríamos dez testadores para nos ajudar na implementação.

Em média, com 3 a 4 testes por requisito, podíamos realizar cerca de 1.500 testes.

A primeira versão da estratégia é recebida com frieza

Ao apresentá-lo à equipe do projeto, foi um primeiro choque para eles, havia requisitos não negociáveis.

Portanto, realizamos uma abordagem liderada pelos riscos.

A empresa atribuiu um valor e um risco a cada requisito, para ter uma visão das possibilidades de otimização.

Após essa primeira análise, quase 100% dos requisitos estavam em um nível crítico, portanto, nenhuma verdadeira priorização!

Várias revisões são necessárias em um curto espaço de tempo

Tentamos com várias iterações de ter uma priorização real, priorizando os requisitos entre eles.

Nesse momento, o gerente do projeto voltou a falar conosco, escalando a data de entrega da estratégia de teste, que deve estar pronta em três dias.

De nossa parte, queríamos ser realistas e compartilhar a realidade, não um plano que não poderíamos seguir.

Então não tínhamos muita escolha: apresentar algo muito pobre para a data marcada ou pedir tempo adicional.

Como a direção geral estava em espera para o projeto, tínhamos pouca esperança de obter mais tempo.

Então, dissemos a nós mesmos que iríamos cumprir os prazos, priorizar da melhor maneira possível e usar técnicas de teste mais leves quando era aplicável.

Antoine: Então você tentou otimizar certas técnicas e atingir 80/20?

Sim, exatamente, além disso, planejamos integrar testadores com experiência na área de QA e no setor bancário.

A automação é inadvertidamente promovida pelo cliente

Voltando à nossa estratégia de teste, um dos quatro gerentes de negócios se ofereceu para automatizar os testes, para, na sua perspectiva, poupar tempo.

Para nós, essa não era a solução, dado o investimento adicional necessário para implementar a automação.

Então, pressionei para que a automação não fosse adicionada ao projeto, contra a proposta intuitiva que tinha sido feita.

Chega o dia da apresentação oficial da estratégia

Os três dias passaram e então chega o dia da apresentação da estratégia de teste.

Por isso apresentamos ao diretor do projeto, às várias equipas impactadas incluindo a equipa de desenvolvimento.

Compartilhamos que, dadas as restrições, priorizar era obrigatório.

Concretamente, identificamos os serviços que seriam necessários imediatamente após o lançamento, por exemplo, a criação de uma conta.

Existiam operações menos frequentes e desnecessárias na inicialização deveriam ser realizadas posteriormente.

Apesar do foco nos negócios, a apresentação não foi bem recebida

A nossa proposta não foi bem recebida e a apresentação correu mal, a nossa surpresa.

Podíamos ver que o gerente de projeto não estava satisfeito: “É muito leve, não podemos correr esse tipo de risco em um projeto de grande escala” etc.

Ao mesmo tempo, tínhamos exposto todo o contexto, as fórmulas de cálculo e dados utilizados.

Antoine: Você também teve que focar a priorização no valor do negócio, levando em consideração a experiência do cliente, as funções e as datas comunicadas?

Sim, totalmente, a proposta estava alinhada com o contexto de negócios.

Ficamos, portanto, um pouco desconfortáveis ​​e surpresos com esse tipo de reação.

Elementos-chave são obtidos numa discussão no corredor

Ao final da reunião, numa discussão no corredor, obtemos informações adicionais.

Entendemos indiretamente que o diretor do projeto, que nos solicitou, queria no fundo demonstrar que o projeto não poderia ser concluído a tempo!

Antoine: Então, por causa dos testes e do QA, o projeto estratégico teve que ser adiado?

Lá estava ele, ele queria que as pessoas apoiassem a sua proposta e provavelmente tinha outros elementos em favor disso.

Portanto, entendemos por que nossa proposta não era adequada, tínhamos que rever a nossa contribuição.

A entrega é adaptada para atender a necessidade real

Desenvolvi uma pequena ferramenta baseada em Excel para priorizar os testes.

Ao inserir alguns parâmetros, como o número de requisitos, testes e testadores, ele podia  obter cenários de carga e de planeamento.

A ideia era que essa ferramenta poderia ser utilizada na construção de cenários e como suporte da argumentação.

Foi uma espécie de porta de saída para nós, permitindo-nos agir um pouco no sentido que ele queria.

Antoine: Uma reviravolta superinteressante, percebemos retrospectivamente qual era o real objetivo da intervenção!

Exatamente, todos sabiam que o projeto não era realista.

Sem ter participado do projeto, o lançamento ocorreu após a data prevista.

Compreender expectativas reais é um verdadeiro desafio

Olhando para trás, reconheço que deve prestar atenção aos primeiros sinais de alerta, especialmente para entender as reais expectativas das pessoas.

Para entregar o que se espera, devemos estar muito atentos aos interlocutores diretos e indiretos que podem nos colocar em pistas mais ou menos relevantes.

Preste atenção aos primeiros sinais de alerta e às reais expectativas dos interlocutores.

Jean-Baptiste Crouigneau

Mantenha a sua linha de conduta apesar da pressão externa

O outro conselho que posso dar, pelo menos é o meu curso de ação, é permanecer firme em suas crenças e idéias.

É fácil ser influenciado e adaptar um plano para atender um pedido vindo de cima, por exemplo.

Fique firme em suas convicções e ideias.

Jean-Baptiste Crouigneau

No projeto preferimos responder de forma factual, confrontando a realidade, para permitir que as pessoas trabalhassem em boas condições, ao invés de um plano ilusório.

Não é fácil quando há pressão. No nosso caso, todos os jogadores-chave e influentes estavam sob grande pressão.

Antoine: Você quase poderia traçar um paralelo com os esportes defensivos onde você usa a força do seu oponente. Como se é melhor adaptar-se do que ir contra a maré.

Sim, é uma boa imagem, o nosso objetivo não era terminar num beco sem saída.

Saber como adaptar os resultados e encontrar uma saída

Não podíamos entregar exatamente o que era esperado, então propusemos uma alternativa permitindo que ele explorasse as possibilidades com assumpções realísticas.

Antoine: Quase queremos perguntar quais são os objetivos ocultos do projeto quando recebe uma solicitação!

Exatamente, é bastante complicado quando não se conhece bem o contexto da empresa.

Você tem que tentar sentir as coisas, seguir seus instintos, agir como um investigador.

Isso também é o que se transforma em experiência.

Antoine: Muito obrigado Jean-Baptiste. Mal posso esperar para conversar de novo, pois sei que tem mais histórias e anedotas para compartilhar!

Sim, partilho aqui os primeiros elementos de uma próxima história.

É composto por dois gestores de projetos, quer a direção geral separar-se de um deles, tendo passado por momentos e aprendizagens interessantes…

O resto no próximo episódio!