Atualização 2023
Este artigo foi escrito originalmente no final de 2018. Agora, em 2023, mais informações serão divulgadas. Atualização de abril de 2023 na Computer Weekly
O que sabemos agora é que houve “alguns problemas”, ou seja, bugs que afetaram diferentes grupos de clientes de diferentes maneiras. Demorou pelo menos 7 meses para resolvê-los. Só podemos estimar o número total de bugs, mas é provável que esteja na faixa de 4 a 140. Sabemos disso porque há pelo menos 4 cenários de falha relatados e o número mais provável de bugs que podem ser reparados em um sistema de produção de uso intenso é de cerca de 1 por dia, independentemente do tamanho da equipe.
Avaliação de Custo da Qualidade
Custou à TSB £ 32,7 milhões em reparação aos clientes, mais uma multa de £ 18,9 milhões e podemos estimar cerca de £ 3,2 milhões de esforço técnico e um impacto adicional na equipe de atendimento ao cliente de cerca de £ 52 milhões (permitir 1 chamada a £ 10 por cliente). Depois, há o custo de oportunidade de ter de resolver isto em vez de fazer o banco avançar. E finalmente o banco terá perdido alguns clientes por causa disso.
O custo total estimado parece ser superior a £ 100 milhões. O que nos dá um custo por defeito de cerca de £ 1 milhão por defeito não descoberto antes da entrada em operação.
Como isso poderia ter sido evitado?
Conhecer o potencial de defeito de um empreendimento de software pode informar quantos defeitos você precisa encontrar antes de estar pronto para entrar em operação. É previsível. Usando várias técnicas que giram em torno do conhecimento do tamanho funcional do software, potenciais de defeitos, áreas de risco de defeitos, taxas de descoberta de defeitos, cobertura de testes e muito mais, podemos descobrir quais tipos de testes serão necessários e quantos testes são suficientes para alcançar resultados satisfatórios. qualidade. A questão é que a situação terrível era previsível e evitável. Também é interessante observar a carreira de Carles Abarco no LinkedIn, em nenhum lugar aparece a palavra qualidade.
O que é escrutínio adequado em 2023
Só podemos adivinhar as conversas que poder ocorreram:
Executivo: “Você já fez testes suficientes?”
Tecnologia: “Sim, aqui estão as centenas de testes que fizemos e todos passaram.”
Executivo: “Bom, então você está confiante, está tudo bem para ir ao vivo?”
Tecnologia: "Claro."
O fracasso era previsível e evitável. Provavelmente levaria apenas alguns meses para encontrar e corrigir esses bugs antes da migração, sem dúvida todos gostariam de ter passado esses dois meses resolvendo esses problemas. Eu me pergunto quais medidas TSB e Sabadell estão empregando agora para garantir que este cenário não se repita?
Colin Hammond, abril de 2023
A notícia do TSB mostrando transações incorretas nas contas das pessoas é evidência de um projeto de software que deu errado devido a um trabalho de má qualidade. Por que isso acontece e como poderia ter sido evitado? A causa raiz subjacente pode vir de uma série de possibilidades. Neste artigo, exploro algumas das mais prováveis e as lições que podemos aprender com elas.
Sistemas legados sob pressão
No centro da maioria dos bancos e grandes instituições financeiras está um software que foi originalmente escrito há muito tempo e que provou ser muito confiável. Chamamos isso de sistemas legados e, à medida que exigimos diferentes formas de acessar nossos dados bancários, o código subjacente desses sistemas legados funciona de maneiras que os desenvolvedores originais nunca imaginaram ou pretendiam, o que pode levar a bugs pouco frequentes.
Manutenção de tecnologias legadas
A maioria desses sistemas antigos é escrita em tecnologias antigas, como uma linguagem chamada COBOL. A maioria dos desenvolvedores COBOL já se aposentou e há muito poucos jovens entusiasmados em aprender essas línguas mortas. Consequentemente, há uma escassez de desenvolvedores altamente qualificados para estes sistemas antigos.
Risco leva à abstração
A migração de sistemas legados para tecnologias mais recentes é difícil e arriscada. Pode levar anos para planejar e implementar. A substituição de um sistema central pode ser tão potencialmente perturbadora que a administração evita fazê-lo completamente. Uma tática para permitir que os bancos avancem oferecendo novas funções aos usuários é envolver esses sistemas antigos usando uma técnica chamada Abstração. Eles são tratados como uma “caixa negra” e não precisamos de nos preocupar com a forma como funcionam, apenas precisamos de ter confiança nas suas entradas e saídas. Esta técnica adia a eventual necessidade de substituição destes sistemas.
Arquitetura e Complexidade
À medida que novos produtos bancários são criados, cada vez mais sistemas dependentes “penduram” o legado, criando uma imagem cada vez mais complexa de como os dados se movem entre estes sistemas. Sistemas excessivamente complexos podem ser a causa de muitos bugs. Uma boa arquitetura de TI ajudará a combater ou conter essa complexidade e os riscos associados.
Código evoluído
Sistemas que já existem há muito tempo foram frequentemente modificados por muitos programadores ao longo dos anos. Às vezes, há pouca transferência de conhecimento de um desenvolvedor para outro. O novo cara não entende o que o último fez e está relutante em alterar o código existente, caso ele o quebre. Então, em vez disso, ele escreve um novo código para ficar ao lado do código antigo. Ambos os conjuntos de código provavelmente fazem a mesma coisa, mas o que acontece quando o próximo desenvolvedor aparece é que ele não tem certeza em qual código trabalhar. Essa é uma das maneiras pelas quais a complexidade pode aumentar.
Testar por si só não é suficiente para garantir a qualidade
Estudos de milhares de projetos de TI nos fornecem evidências de que os testes por si só não garantirão que todos os bugs foram encontrados. Na verdade, na melhor das hipóteses, os testes raramente encontrarão mais de 85% de bugs. Os testes precisam ser complementados por outras formas de técnicas de melhoria de qualidade que possam identificar possíveis bugs antes mesmo de você iniciar os testes. Algumas das mais eficazes são a análise estática e as revisões formais que abrangem requisitos, arquitetura, design e código.
Teste se não faz o que não deveria
Suponha que você esteja fazendo uma transação no seu aplicativo bancário, a conexão é perdida e apenas metade da instrução é enviada ao banco. Como o sistema do banco lida com meia instrução? Se esse sistema estiver conectado a um sistema legado, como o sistema legado lida com uma instrução incompleta? Sempre que fazemos uma mudança no sistema, sempre testamos se o novo sistema faz o que deveria fazer. Devemos também garantir que ele não faça o que não deveria, pois esse tipo de teste tende a ser esquecido.
Horário compactado
Sem dúvida, o trabalho realizado pelo TSB para migrar sistemas terá passado por testes extensivos. Porém, com todos esses projetos, a equipe estará sob alguma pressão de tempo para concluir seu trabalho em uma data específica. Uma escala de tempo compactada é uma das causas mais comuns de falha em projetos de TI.
Habilidades técnicas
Codificar é um trabalho criativo que exige habilidade e experiência. Por exemplo, existem muitas maneiras de codificar o mesmo resultado: um codificador pode obter um conjunto de funcionalidades em apenas uma ou duas linhas, outro pode ter que escrever cinquenta. No geral, um código mais compacto/conciso tende a ser de maior qualidade. As habilidades do desenvolvedor variam dramaticamente, compare um cantor que tem um tom perfeito com outro que não consegue nem cantar, ambos se autodenominam “cantores”. Desenvolvedores de baixa competência podem introduzir mais bugs do que correções ou funcionalidades.
Pressão empresarial por novos requisitos
A gestão está sempre sob pressão para expandir os seus negócios e, em alguns casos, pode perder de vista a importância de sistemas estáveis e precisos quando está sob pressão para fornecer novos recursos e capacidades.
Bugs não previstos, portanto o risco do negócio não foi compreendido
Ao contrário do que muitas pessoas acreditam, bugs em software podem ser previstos e medidos. Usando métricas de software padrão, é possível saber quantos bugs ainda existem em um sistema antes de colocá-lo no ar. Se os gestores forem informados de quantos defeitos pendentes ainda não foram encontrados, eles poderão não aprovar a decisão de entrar em operação. É decepcionante ver que poucas pessoas usam essas métricas. Eles estão (como o COBOL) fora de moda, mas funcionam. Eles trazem uma certeza considerável para um setor que se apaixonou pela “falha rápida” e pela “implantação rápida” com base em métricas comprovadas.
Conclusão
Existem muitas razões possíveis para os recentes problemas do TSB, e sugiro algumas delas aqui. A verdade é que substituir sistemas legados é mais do que uma responsabilidade da TI, em alguns casos é uma questão de toda a sobrevivência do negócio. Os clientes bancários podem ser tolerantes se o seu aplicativo bancário ficar indisponível por algumas horas, mas não aceitarão saldos incorretos ou transações muito atrasadas. Isto mina a confiança e, sem confiança, os clientes bancários irão para outro lugar. Colin Hammond é consultor de garantia de projetos de TI e autor do ScopeMaster, uma ferramenta para trazer certeza aos projetos de TI.