Olá, meu nome é Maksim Plavchenok, trabalho para a Bercut e faço testes de integração. Em setembro, minha equipe e eu superamos um marco importante: não recebemos nenhum erro como resultado de um teste de integração para o lançamento de uma nova versão de faturamento para uma operadora móvel. Fizemos isso por dois anos; Quero contar a vocês hoje como conseguimos atingir nosso objetivo.
Zero erros com base nos resultados dos testes de integração - aqui estamos falando sobre o teste de novas funcionalidades em uma aceitação comercial por parte do operador. Algumas palavras sobre como esse teste funciona.
Lançamos novas versões de nosso software de faturamento dentro do prazo, 6 vezes por ano. As datas de lançamento são conhecidas com antecedência. No momento em que este livro foi escrito, já tínhamos datas de lançamento agendadas para todo o próximo ano.
Essa especificidade está associada à corrida das operadoras de celular pelo time-to-market. O princípio principal: o assinante deve receber regularmente novos recursos de cobrança. Pagamentos através de um smartphone, salvar um número ao mudar de operadora, a capacidade de vender tráfego não utilizado - as atualizações podem ser diferentes.
"Podemos não saber exatamente o que lançaremos em um ano, mas sabemos a data exata em que a atualização será lançada." Com isso, é possível manter o ritmo de atualizações desejado.
Do lado do desenvolvimento do faturamento, cerca de 70 pessoas estão envolvidas no lançamento. São de 5 a 6 equipes, cada uma com sua especialização: análise, desenvolvimento (várias equipes), teste funcional, teste de integração.
Sim, temos uma cascata em projetos de faturamento. Mas a história atual não é sobre como mudamos radicalmente o paradigma de desenvolvimento de cascata para Agile ou vice-versa. Cada abordagem de desenvolvimento tem suas próprias vantagens e é boa nas condições certas; Eu gostaria de deixar essa discussão fora do escopo deste artigo. Hoje eu quero falar sobre o desenvolvimento evolutivo: como passamos para zero erros durante a aceitação do lançamento dentro da estrutura da abordagem de desenvolvimento existente.
Zona de desconforto
No início da história descrita, há dois anos, tínhamos o seguinte quadro:
- as equipes no final da cadeia de desenvolvimento ficaram sobrecarregadas; “É hora de dar para a próxima equipe, e a anterior acaba de começar a sua parte no trabalho”;
- o cliente pode encontrar cerca de 70 erros após nossos ciclos de teste.
Os erros que podem ser encontrados com base nos resultados dos testes de integração podem ser menores (“parte da mensagem é exibida como travessões”) ou mesmo críticos (“não há transição para outra tarifa”).
Decidimos mudar esse alinhamento: estabelecemos uma meta - zero erros na aceitação comercial da nova funcionalidade.
Depois de um ano, conseguimos reduzir o número de erros para 10-15 e, em meados de 2020, para 2-3. E em setembro conseguimos atingir a meta de zero.
Conseguimos graças a melhorias em várias áreas: ferramentas, expertise, documentação, trabalho com cliente, equipe. As melhorias variam em importância: conhecer as especificações e os processos do cliente é importante, passar para uma nova escala para avaliar a complexidade das tarefas é opcional e trabalhar com a motivação da equipe é extremamente importante. Mas as primeiras coisas primeiro.
Pontos de crescimento
A principal ferramenta de teste de integração é a bancada de testes. Nesse local, a atividade do assinante é emulada.
Estandes compartilhados
Os despejos da produção são colocados em bancadas de teste para que você possa testar em condições o mais próximo possível do combate.
O problema é que os lixões em nossos estandes e os do cliente podem ser diferentes. O operador faz um dump, passa para nós, testamos novas funcionalidades, detectamos e corrigimos bugs. Fornecemos a funcionalidade finalizada ao cliente, os colegas do outro lado começam os testes. O nosso e seus lixões podem diferir em relevância: testamos em julho, a operadora - em agosto, por exemplo.
As diferenças não são críticas, mas ainda existiam. Isso levou ao fato de que, ao testar do lado do cliente, poderiam aparecer erros que não tínhamos.
O que fizemos: concordamos que os esquemas de dados usados para o teste serão os mesmos e, em geral, teremos uma posição comum.
O atraso de despejo permanece, mas configuramos a infraestrutura na qual esse atraso é mínimo. Devido a isso, fomos capazes de reduzir o número de erros causados por diferenças entre os ambientes de teste e produção.
Verificar as configurações antes de testar
Quando damos uma nova versão do software ao operador, para teste por parte do cliente, precisamos fazer a configuração. Configure a nova funcionalidade e, possivelmente, personalize ainda mais a antiga.
Escrevemos a documentação para informá-lo sobre as configurações necessárias. Somente aqui os manuais podem transmitir informações com distorções. A documentação foi escrita por pessoas, lida por pessoas e na comunicação de pessoas há um mal-entendido.
Esta é a especificidade do nosso software: altas demandas são colocadas nas configurações em termos de flexibilidade e disponibilidade. As configurações são complexas e, sem comunicação adicional, nem sempre foi possível transmitir todas as informações necessárias apenas por meio de documentação.
Como resultado, as configurações nem sempre podiam ser realizadas corretamente, o que levava à detecção de erros durante o teste por parte do operador. Ao analisar, descobrimos que não eram erros de software, mas configurações. Esses erros desperdiçam um tempo valioso.
O que fizemos: introduzimos um procedimento de verificação das configurações por parte do cliente antes de iniciar os testes nas bancas do operador.
O procedimento é o seguinte: o cliente escolhe os cases que mostramos no estande configurado. Fazemos testes. Se houver erros, iremos corrigi-los imediatamente; caso contrário, o teste é aprovado.
Essa abordagem nos permitiu reduzir o número de erros associados a configurações incorretas durante o teste de integração.
Comunicações adicionais em torno da documentação
Verificar as configurações antes de testar, além de descrever essas configurações nos manuais, é um exemplo de comunicação adicional em torno da documentação. Houve outros.
Por exemplo, fizemos com que a cada momento houvesse sempre um especialista do nosso lado, a quem o cliente pudesse recorrer para tirar dúvidas sobre a documentação e o sistema como um todo. Algo como uma linha de suporte técnico dedicada com nossos especialistas altamente qualificados.
Nossos redatores técnicos organizaram workshops para educar os funcionários do cliente sobre a nova funcionalidade.
O processo de transferência da documentação tornou-se menos discreto, mais contínuo: novas informações, esclarecimentos, recomendações passaram a ser enviadas em partes após o “embarque” dos manuais principais; como aparece ou sob demanda.
Tudo isso permitiu informar melhor o cliente sobre a nova funcionalidade e, com isso, reduzir o número de erros nos testes de integração.
Experiência em trabalhar com sistemas de terceiros
Para desenvolver o faturamento, precisamos ser capazes de controlar o tráfego. Existem sistemas PCRF separados para isso. As chamadas são contadas em um banco de dados, SMS no mesmo local e o tráfego em outro banco de dados; e existe um software especial que sincroniza tudo isso.
Ao mesmo tempo, os sistemas PCRF são softwares proprietários de terceiros. Ou seja, uma caixa preta: enviamos dados para lá, recebemos algo em troca, mas não podemos controlar o que acontece lá dentro. Além disso, não podemos mudar nada lá.
Esse alinhamento limitou nossa capacidade de localizar e corrigir bugs relacionados ao tráfego.
O que fizemos: montamos uma base de conhecimento interna separada do PCRF. Cada incidente, cada opção de personalização, cada percepção - tudo foi registrado e compartilhado pela equipe.
Como resultado, nos tornamos bons usuários do sistema PCRF, podemos customizá-lo e entender o que ele deve fazer. Isso economiza tempo em incidentes simples. Com casos complexos, é claro, ainda pedimos ajuda aos desenvolvedores de sistema.
Mais estandes
Outro recurso para testar o faturamento das operadoras móveis é que os scripts personalizados podem ser estendidos ao longo do tempo. O script completo que queremos testar pode levar vários dias ou até semanas.
É difícil esperar vários dias ou semanas durante a fase de teste. Na realidade, para verificar esses cenários, na maioria das vezes é simplesmente hora de se descontrair no banco de dados.
Para retroceder no tempo, você precisa fechar todas as sessões, exceto a sua. Chegamos a uma situação em que, condicionalmente, 20 testadores podem se inscrever em dois bancos de teste e todos querem voltar no tempo. Essa é a fila. E a fila é a probabilidade de que na data combinada de envio do software não tenhamos tempo de verificar tudo corretamente.
O que fizemos: configurar um suporte separado para cada testador.
Isso nos permitiu remover os erros que ocorreram devido ao “atraso chegou minha vez de estande, não tive tempo”.
Virtualização
A preparação do estande não é um processo rápido. Você precisa se conectar à rede da operadora, solicitar acesso e isso não é tudo. O procedimento completo pode levar várias semanas. A luta para reduzir o tempo de preparação do estande foi um importante direcionamento para se chegar à meta de zero erros.
O que fizemos: virtualização habilitada.
Copiar máquinas virtuais com todas as configurações necessárias, software pré-instalado e automatizar esse processo ajudou a reduzir o tempo de preparação do estande para “em um dia”.
Planejamento
Os erros dos testes de integração também são o resultado de erros de cálculo no planejamento da liberação. Nós balançamos muito, na hora da data de lançamento fixada, nem tudo estava no prazo.
O que fizemos: Introduzir prazos intermediários para cada estágio de desenvolvimento. “Se você sabe a data de término, então conhece todos os intermediários” - esse princípio nos ajudou a controlar melhor a velocidade do movimento em direção à meta de liberação.
Suporte e lançamento em paralelo
No início de nossa jornada, houve uma situação em que as "dívidas" do último lançamento entraram em conflito com o próximo lançamento. Após a aceitação, os bugs chegaram do lado do cliente e todos foram corrigi-los.
Ao mesmo tempo, o cronograma de lançamento não mudou. Como resultado, no momento em que era hora de abordar o próximo lançamento, ainda podíamos continuar a trabalhar no anterior.
Foi possível mudar a situação com a separação de dois grupos da equipe: quem vai consertar os erros da aceitação e quem vai lidar com o novo lançamento no prazo.
A divisão era condicional: não necessariamente metade lá, mas metade aqui. Podemos transferir pessoas entre grupos conforme necessário. Do lado de fora, pode parecer que nada mudou: aqui está uma pessoa da equipe, durante o sprint ele resolveu bugs e novos recursos. Mas, na verdade, a seleção de grupos individuais foi uma melhoria da categoria "agora podemos respirar". O foco de cada grupo e a paralelização do trabalho entre os grupos nos ajudaram muito.
Cronologicamente, este foi um dos primeiros pontos de crescimento que formulamos na pós-morte. E aqui a minha história chega à parte sobre o instrumento principal.
Ferramenta principal
A melhoria que mais nos ajudou foram as autópsias honestas.
Alguém chama isso de retrospectiva, alguém - uma análise dos resultados; a palavra "post mortem" ficou presa em nossa equipe. Todas as melhorias descritas neste artigo foram inventadas em autópsias.
O princípio é simples: houve uma liberação, vocês precisam se reunir e discutir honestamente como tudo correu. Parece simples, mas existem armadilhas na implementação. Depois de um lançamento “malsucedido”, as pessoas da equipe ficam com o clima “não dá tempo de coçar a língua, é preciso fazer alguma coisa”. Alguém pode fazer a autópsia e permanecer em silêncio (e, portanto, não fornecer algumas das informações potencialmente úteis).
Por dois anos caminhando em direção à meta de zero erros, desenvolvemos uma série de princípios de como conduzimos autópsias.
- Monte a imagem completa
Convidamos uma lista expandida de participantes. Desenvolvedores, testadores, analistas, gerentes, executivos - todos que desejam se manifestar. Organizacionalmente, nem sempre é possível reunir todos, todos. Tudo bem, funciona assim também. A questão não é negar a participação dos colegas com a frase “aqui na nossa equipe estamos somando os resultados, vocês somam no seu”. Trabalhe com estandes, código, processos, interação - nos esforçamos para não perder de vista nenhum aspecto.
- Não se agarre a tudo de uma vez
Ok, como resultado do post-mortem, obtivemos 30 pontos de crescimento. Quanto custa para trabalhar? Talvez possamos resolver isso até a próxima vez? O formato “pick 2-3” funcionou melhor para nós. Nessa situação, há foco e os esforços das pessoas da equipe não são difundidos. É melhor fazer menos, mas completamente, do que muito, mas não trazer à mente.
- Não seja esperto com o formato
Existem muitas abordagens para a realização de autópsias. Práticas de facilitação, técnicas de design thinking e lateral thinking, técnica de Goldratt e outros especialistas respeitados. Em nossa experiência, o bom senso é o suficiente para começar. Anotamos os problemas, os agrupamos, escolhemos vários clusters, colocamos o resto de lado (veja o ponto anterior), discutimos, corrigimos o plano. Quando existe um objetivo comum, não é tão difícil encontrar uma linguagem comum.
- Levar para o trabalho
Talvez o princípio principal desta lista. Por mais promissora e convincente que seja a lista de melhorias após os resultados da autópsia, se não der certo, tudo será em vão. Nós concordamos, então vamos fazer isso. Sim, existem outros assuntos urgentes. Mas também temos um objetivo e queremos chegar mais perto dele.
A pós-morte pode ser muito dolorosa. Falar sobre o fracasso, mesmo de forma construtiva, não é fácil. Mas vale a pena lutar contra o desconforto. Tenho certeza de que, sem a autópsia, não teríamos sido capazes de propor e implementar todas as coisas que ajudaram a atingir a meta de zero erros no lançamento.
A ferramenta mais importante
A pós-morte permite que você encontre meios de atingir a meta, mas se você olhar para ela, pode ser chamada de consequência de um princípio de nível superior.
A ferramenta mais importante é o envolvimento da equipe.
Existe um lado instrumental no envolvimento. Por exemplo:
- se fizer hora extra, o chefe fica ao lado da equipe, ajudando com as mãos;
- se você animar a equipe acompanhando o progresso, poderá encontrar métricas visuais (não é difícil para o número de erros).
E ainda mais com o mesmo espírito.
O envolvimento também tem um lado difícil de formalizar - a capacidade de compartilhar sua crença no sucesso com a equipe. Afinal, minha equipe e eu não apenas olhamos o folheto com os valores da empresa, vimos lá “juntos mais fortes” e decidimos que, bingo, uma solução havia sido encontrada. Vimos exemplos de como metas desafiadoras podem ser alcançadas por meio da união de forças. Tínhamos pessoas em nossa equipe que acreditavam no sucesso e tentavam transmitir essa crença aos seus colegas. O resto é uma questão de tecnologia.
As pessoas são o mais importante.
Havia muito mais no lançamento em direção ao objetivo de zero bugs. Trabalhar na melhoria da documentação, aumentando a velocidade e a qualidade das respostas às dúvidas dos clientes são diferentes. Desta vez, tentei compartilhar apenas alguns exemplos e falar sobre os princípios básicos.
A equipe e eu ainda temos muito a fazer na luta pela qualidade do lançamento e pela otimização do tempo de lançamento no mercado. Torne o resultado reproduzível regularmente com zero erros nos testes de integração, automatize a regressão.
Ainda não se sabe como atingir esses objetivos. Mas o que sabemos com certeza agora: nós definitivamente faremos autópsias e implementaremos pontos de crescimento com base nos motivos. E vamos tentar aproveitar as oportunidades que a equipe envolvida tiver.
Espero que algo disso possa ser útil para você também.