Destaque

A atualização de segurança KB5063878, disponibilizada pela Microsoft como parte do Windows 11 24H2, trouxe um bug crítico que pode tornar SSDs (e até HDDs, em casos isolados) inacessíveis após a transferência contínua de grandes volumes de dados. Quando o problema ocorre, o sistema operacional deixa de reconhecer o dispositivo e, após reiniciar o computador, as partições podem aparecer como RAW, inacessíveis ao usuário. Os relatos indicam que o bug se manifesta quando se tenta gravar mais de 50 GB de dados contínuos em unidades que já estão com mais de 60% de ocupação. O responsável por testes, identificado como Nekorusukii, avaliou 21 SSDs de diversas marcas (incluindo Samsung, WD, Seagate e Crucial) e constatou que vários deles ficaram inacessíveis. A unidade WD Blue SA510 2 TB SATA foi a única que sofreu danos permanentes e não voltou a funcionar, mesmo após reboot. Embora inicialmente se pensasse que o problema estava restrito a SSDs com controladoras Phison, o bug aparentemente atinge modelos com outros controladores também. A Microsoft confirmou estar ciente dos relatos e afirmou que está investigando o caso junto com parceiros de mercado, como a Phison. Como medida preventiva até que haja um patch oficial, especialistas recomendam que os usuários evitem realizar transferências de arquivos muito grandes, especialmente em unidades já bastante utilizadas, e mantenham seus backups atualizados. O artigo original via TecMundo e PCWorld pode ser lido aqui e aqui. 

No final do passado mês de julho, um erro de software nos sistemas de radar da National Air Traffic Services (NATS), no centro de controlo de Swanwick, Hampshire, levou ao encerramento temporário do espaço aéreo sobre a Inglaterra e País de Gales, provocando uma suspensão geral dos voos por cerca de 20 a 60 minutos. Apesar da rápida resolução técnica — com a NATS a ativar um sistema secundário em cerca de 20 minutos — os efeitos desse apagão seguiram-se durante horas, com congestionamentos de aeronaves e tripulações desalinhadas para retomar as operações normais. Mais de 150 voos foram cancelados, e estima-se que tenha afetado mais de meio milhão de passageiros. A Secretária de Estado dos Transportes, Heidi Alexander, convocou o CEO da NATS, Martin Rolfe, para explicar o sucedido e garantir medidas preventivas para o futuro. A Ryanair exigiu a demissão de Rolfe, afirmando que falhas anteriores — incluindo uma em agosto de 2023 que afetou cerca de 700 mil passageiros — não serviram de lição. Especialistas e opositores políticos pedem uma investigação governamental independente sobre a resiliência da infraestrutura de controlo aéreo do país. Embora os sistemas de emergência tenham garantido que não houve nenhum ataque cibernético, nem risco para a segurança dos voos, o incidente deu visibilidade às fragilidades latentes nos sistemas centrais de controle de tráfego e reforçou a urgência de modernização e planos de contingência mais robustos.   O artigo original via The Telegraph pode ser lido aqui. 

Se há algo que se deseja em qualquer carro, é uma forma de parar. É ainda mais importante do que a potência, o estilo ou qualquer tipo de gadget chamativo. Ter um pedal de travão que não funciona não é bom, e é por isso que a Volvo está a alertar os condutores de determinados veículos híbridos plug-in e elétricos para que parem de conduzir até baixarem a última atualização de software. De acordo com o relatório de recall, este bug na programação do módulo de controlo do travão faz parte da versão 3.5.14 do software e só aparece em determinadas condições e em modelos conectados à tomada. Os clientes afetados podem sofrer uma perda temporária da funcionalidade de travagem após numa situação de descida por pelo menos 1 minuto e 40 segundos com o modo de condução «B» para veículos PHEV e o modo «One Pedal Drive» para veículos BEV sem aplicar o pedal do travão ou (até certo ponto) o pedal do acelerador. Se a situação ocorrer, pressionar o pedal do travão pode remover completamente a funcionalidade de travagem. Embora muitos condutores de híbridos plug-in provavelmente não conduzam sempre no modo de condução «B», as pessoas que vivem em áreas montanhosas podem fazê-lo, tal como alguns condutores de veículos elétricos a bateria utilizam religiosamente o modo de um pedal. Foi assim que o defeito foi descoberto, e a NHTSA (Agência Nacional de Segurança do Tráfego em Auto-Estradas) chegou a publicar um vídeo de uma DashCam que mostra este modo de falha dos travões a ocorrer. Há algo de inquietante em saber que uma atualização de software pode interferir no desempenho dos travões, porque, embora deva funcionar bem, e se não funcionar? A solução é parar de conduzir o veículo e descarregar a última atualização de software over-the-air assim que estiver disponível. Se um carro afetado precisar ser movido, certifique-se de que o modo «B» em híbridos plug-in e a condução com um pedal em veículos elétricos a bateria não estejam selecionados. O artigo original via The Autopian pode ser lido aqui. 

Nos Estados Unidos da América, um erro de software levou a uma confusão generalizada entre milhões de residentes do condado de Los Angeles que receberam uma mensagem de aviso de evacuação pouco depois da eclosão do incêndio de Kenneth em Woodland Hills, de acordo com um relatório divulgado pelo gabinete do deputado norte-americano Robert Garcia. A mensagem de texto foi enviada para os telemóveis dos residentes a 9 de janeiro, pouco depois de o incêndio de Kenneth ter começado, durante uma forte tempestade de vento que, dois dias antes, tinha provocado os devastadores incêndios de Palisades e Eaton, que destruíram milhares de casas. A mensagem destinava-se apenas aos residentes de Calabasas e Agoura Hills, uma vez que o incêndio se estava a propagar para oeste na sua direção. Vinte minutos depois, o condado enviou outro alerta corrigindo o erro e esclarecendo que o aviso era apenas para a área de evacuação do incêndio de Kenneth, diz o relatório – “O falso alerta do incêndio de Kenneth foi uma chamada de atenção”, disse Garcia numa declaração. “Mostrou as consequências das falhas de software, da redação vaga das mensagens e da falta de normas federais. Temos de modernizar os nossos sistemas de alerta de emergência para garantir que os avisos são exactos, oportunos e direcionados. A confiança do público está em jogo”. As mensagens erradas foram enviadas porque um elemento preciso da área de avaliação não tinha sido carregado no sistema federal de alerta e aviso ao público. A Genasys Inc., que supervisiona os alertas, não notificou o condado de que o elemento estava em falta, pelo que o alerta foi enviado a cerca de 10 milhões de pessoas em vez dos bairros visados, segundo o relatório. A empresa disse acreditar que o erro se deveu a uma possível interrupção da rede, mas não entrou em pormenores, diz o relatório. Através do mesmo relatório, consta que desde então, a Genasys acrescentou salvaguardas para corrigir o problema, incluindo um aviso ao utilizador quando o elemento está em falta. O artigo original via EastBayTimes pode ser lido aqui. 

Em novembro do ano passado foi descoberto um bug na aplicação Modefer, que gere cerca de 1.500 pacientes por mês do Serviço Nacional de Saúde (NHS) do Reino Unido. A falha do software deixou os dados dos pacientes vulneráveis a ataques de hackers, refere a BBC e segundo o engenheiro de software que a descobriu, esta existe pelo menos há seis anos. A Modefer diz que não tem provas de que a vulnerabilidade exista há tanto tempo e avança que os dados dos pacientes não foram comprometidos. Dias depois da descoberta o bug foi corrigido, garante a empresa. Um porta-voz do NHS disse que estava a anotar as preocupações levantadas sobre a Medefer e irá tomar as ações necessárias. Foi explicado que o sistema da Medefer permite aos pacientes fazer marcações virtuais com os médicos, que têm acesso aos dados clínicos associados. O engenheiro que descobriu a vulnerabilidade disse que as APIs utilizadas da Medefer não estavam devidamente seguras, podendo ser acedidas por terceiros mal-intencionados e ter aceso a informações dos pacientes. O engenheiro acusa ainda a Medefer de não tomar as providencias adequadas assim que se soube da vulnerabilidade. “Trabalhei em organizações onde se algo assim acontecesse, todo o sistema seria desligado imediatamente”- acrescenta que deveria ter sido chamado um especialista de cibersegurança externo para investigar o problema, algo que a Medefer não fez. Por outro lado, a empresa diz que uma agência de segurança externa analisou o problema e que os dados estão em segurança. A confirmação foi adiantada pelo fundador da empresa, Bahman Nedjat-Shokouhi, referindo que a correção foi lançada em 48 horas após descoberta a vulnerabilidade. E aponta ainda que é falsa a alegação de que o bug deu acesso a quantidades elevadas de dados dos pacientes. “Levamos os nossos deveres com os pacientes e a NHS muito seriamente. Temos auditorias externas de segurança regulares aos nossos sistemas, em várias ocasiões anualmente”. Pelo facto da Medefer lidar com dados altamente sensíveis dos pacientes, como é o caso da informação médica, especialistas em cibersegurança que analisaram o caso apresentado pelo engenheiro de software, apontam que os dados da NHS não estavam seguros como deveriam e que deveriam ter sido chamados imediatamente técnicos de cibersegurança externos para aferir a verdadeira dimensão do problema.   O artigo original via Sapo24 pode ser lido aqui. 

John Cheeks, residente em Washington DC, comprou um bilhete da lotaria Powerball a 6 de janeiro de 2023. O sorteio aconteceu no dia seguinte, mas não o viu em direto. Contudo, quando foi ao site, eram os seus números que estavam lá. E não havia dúvida, já que a sua chave incluía uma combinação de aniversários de família e outros números com significado pessoal, conta o The Guardian.“Fiquei um pouco excitado, mas não gritei, não berrei. Apenas telefonei educadamente a um amigo. Tirei uma fotografia, como ele recomendou, e pronto. Fui dormir”, explicou. Contudo, aquilo que parecia um sonho viria a transformar-se num pesadelo. Quando Cheeks se dirigiu ao Office of Lottery and Gaming (OLG) para resgatar o seu prémio, foi informado de que tal não seria possível — e um funcionário no local disse-lhe mesmo para deitar fora o boletim, porque não iria receber prémio nenhum.“O pedido de prémio do requerente foi recusado, porque o bilhete não foi validado como vencedor pelo sistema de jogo do OLG, tal como exigido pelos regulamentos do OLG”, podia ler-se numa carta enviada posteriormente. Mas John Cheeks decidiu guardar as provas que tinha e, de seguida, processar a Powerball. Já em tribunal, surgiu a justificação para o facto de aquela chave, afinal, não ser a vencedora da lotaria. Aparentemente, estariam a ser feitos testes de qualidade no site, pelo que foram publicados acidentalmente números de teste da Powerball, em vez de num ambiente de desenvolvimento que imitava a página oficial, mas que não era visível para o público. Richard Evans, advogado do queixoso, diz que a justificação não mostra como fazer andar o processo. “Eles disseram que um dos seus contratantes cometeu um erro. Ainda não vi provas que sustentem isso. Mesmo que tenha sido cometido um erro, a questão é: o que é que se faz em relação a isso?”, questionou. Além disso, deixou um exemplo de uma outra situação em que foram publicados números por engano, em novembro do ano passado. Nesse caso, os vencedores temporários — as pessoas que tinham os números em questão — puderam ficar com os seus prémios, que variavam entre 4 e 200 dólares. Resta agora saber o que acontece com os 340 milhões. O artigo original via Sapo24 pode ser lido aqui. 

Artigo de opinião assinado por Adem Tural. 1. Encontrar Bugs Incentiva-nos Testar software é como uma à caça de um tesouro: É possível investigar o trabalho de programadores especializados e descobrir quaisquer falhas ou defeitos no software. É um pouco como pirataria informática, mas completamente legal. Encontrar e corrigir erros dá-me adrenalina e tenho orgulho em ajudar a criar software sólido e fiável para os utilizadores finais. Quando vejo as partes interessadas satisfeitas com os resultados do meu trabalho árduo, é muito gratificante e torna o meu trabalho ainda mais satisfatório. 2. Desafiar a Mente Como testador de software, é necessário ter uma mente afiada para analisar o trabalho dos melhores programadores. Não se trata apenas de resolver problemas, mas sim de os encontrar. Tem de ser crítico, analítico e minucioso na sua abordagem. É um desafio que requer criatividade, um olho para a qualidade e uma lógica superior. A sua mente está constantemente empenhada em resolver quebra-cabeças e desvendar os mistérios do software. E sabes que mais? Tornou-me mais concentrado e orientado para os pormenores, não só no trabalho, mas também na minha vida pessoal! 3. Melhorar as Competências Sociais através do Trabalho em Equipa O teste de software não é um trabalho para uma só pessoa, mas sim de equipa que exige uma colaboração intensa, trabalhando em estreita colaboração com especialistas funcionais e peritos técnicos que têm perspectivas e ângulos diferentes. É necessário compreender, integrar e gerir estes diferentes pontos de vista, colaborando de forma construtiva para melhorar a qualidade da solução. Neste sentido, ajudou-me a melhorar as minhas competências pessoais e a prosperar num ambiente de trabalho colaborativo. 4. Win-win: Aprender com os Colegas Uma das melhores coisas de ser um testador de software é a oportunidade que nos dá de aprender e crescer. Na OMP, estou constantemente a aprender com os meus colegas mais experientes, alguns dos quais são os melhores na sua área. Colaborando com gestores de produtos funcionais, revejo casos de teste enquanto eles partilham generosamente o seu tempo e conhecimentos, fornecendo informações valiosas sobre vários produtos e soluções. Os seus contributos ajudam-me a produzir cenários de teste de maior qualidade para o utilizador final. Os programadores ensinam-me novas competências técnicas, reconhecendo que o meu conhecimento profundo da aplicação me permite realizar testes rigorosos. Em troca, ajudo-os a melhorar a qualidade do seu código. É uma situação em que todos ganham, motivando-me constantemente a continuar a aprender e a melhorar as minhas competências. 5. Explorar Novas Tecnologias e Metodologias O teste de software é um campo dinâmico que está em constante evolução, oferecendo oportunidades interessantes para explorar novas ferramentas, tecnologias e metodologias de teste como parte do trabalho. Tenho a sorte de trabalhar com ferramentas e tecnologias de ponta, incluindo JavaScript, Python, API REST, automação de IU, Git, AzureDevOps, SQL Server, InfluxDB, Kubernetes (K8s) e tecnologias de cloud. Além disso, a nossa equipa colabora utilizando ferramentas scrum e metodologia agile. Enquanto testador de software, devemos procurar estar na vanguarda dos mais recentes desenvolvimentos da indústria, aprendendo e adaptando-se continuamente. 6. Prosperar na Diversidade Profissional Por fim, uma outra coisa que mais gosto nos testes de software é a diversidade. Desde testes de front-end a testes de API, testes de desempenho, testes de escalabilidade, testes de bases de dados e testes de ponta a ponta, estou sempre a lidar com uma variedade de tarefas em simultâneo. Analiso os requisitos quanto à sua validade e viabilidade, executo diferentes testes e participo numa série de projetos, tudo ao mesmo tempo. É como ser um gestor de projetos completo, fazendo malabarismos com várias tarefas e desafios, sem nunca ficar aborrecido   O artigo original via OMP pode ser lido aqui. 

No mundo de alto risco da exploração espacial, a precisão é tudo. Uma única casa decimal mal colocada, um carácter omitido ou um pequeno erro de sintaxe podem significar a diferença entre o sucesso e o fracasso catastrófico. Um dos erros de codificação mais infames da história – a ausência de um hífen – levou à destruição da nave espacial Mariner 1 da NASA poucos momentos após o lançamento, custando à agência uns impressionantes 18,5 milhões de dólares.  A 22 de julho de 1962, a Mariner 1 da NASA estava pronta para embarcar numa missão inovadora ao planeta Vénus. A nave espacial foi concebida para transmitir dados científicos valiosos de volta à Terra, fazendo avançar a compreensão do sistema solar por parte da humanidade, no entanto, apenas 293 segundos após a descolagem, a missão terminou em desastre: O foguetão desviou-se da rota, levando o controlo em terra a iniciar a sequência de auto-destruição. O responsável? Um único hífen em falta no código do software de orientação. O hífen em falta levou a cálculos de velocidade incorrectos, causando um comportamento de voo errático que acabou por tornar a nave espacial incontrolável.  Em suma, a nave espacial Mariner 1 dependia de uma combinação de sistemas de orientação baseados em terra e a bordo, sendo que o seu software era responsável por interpretar os sinais das estações de rastreio e ajustar a trajetória do foguetão em conformidade. O hífen em falta no código perturbou as instruções matemáticas que ditavam as correcções de velocidade, resultando em cálculos errados. O erro traduziu-se em desvios de trajetória não intencionais que se tornaram cada vez mais graves, deixando a NASA sem outra opção senão abortar a missão. Este incidente continua a ser um dos erros tipográficos mais dispendiosos da história, realçando a importância crítica de uma atenção meticulosa ao pormenor na programação, particularmente em aplicações de missão crítica. No mundo do desenvolvimento de software, mesmo o mais pequeno descuido pode ter consequências de longo alcance. Isto é especialmente verdade na engenharia aeroespacial, onde a precisão é fundamental. Para os programadores e engenheiros actuais, a falha do Mariner 1 serve como um conto de advertência; sublinha a necessidade de revisões rigorosas do código, testes extensivos e redundância em sistemas de missão crítica. Atualmente, os processos de verificação de software, a deteção automatizada de erros e os testes baseados em simulações evoluíram para reduzir esses riscos, mas a lição continua a ser relevante: todos os caracteres do código são importantes. Embora o incidente do Mariner 1 esteja entre os mais famosos erros de codificação, a história está repleta de outros exemplos de pequenos erros que conduziram a resultados catastróficos: Explosão do foguetão Ariane 5 (1996): Um erro de software no sistema de referência inercial levou à auto-destruição deste foguetão da Agência Espacial Europeia, causando um prejuízo de 370 milhões de dólares. O Mars Climate Orbiter (1999): Uma falha na conversão de unidades do sistema imperial para o sistema métrico levou a que a nave espacial entrasse na atmosfera de Marte a uma altitude errada, o que resultou no fracasso da missão. O colapso da rede da AT&T em 1982: Uma única linha de código defeituoso numa atualização de software causou uma enorme falha nas telecomunicações, afectando 75 milhões de chamadas telefónicas. O desastre do Mariner 1 sublinha um princípio essencial tanto na engenharia de software como em empreendimentos tecnológicos mais vastos: o diabo está nos detalhes. Independentemente do grau de avanço da tecnologia, a necessidade fundamental de precisão e validação completa permanece inalterada. No mundo digital acelerado de hoje, onde o software governa sectores que vão das finanças aos cuidados de saúde, garantir a precisão a todos os níveis é mais importante do que nunca.   O artigo original via YourStory pode ser lido aqui. 

Artigo de opinião assinado por Giridhar Rajkumar. 1. Integração da IA e da Aprendizagem Automática O papel da IA e da aprendizagem automática no setor dos testes de software continua a crescer todos os anos, prevendo-se uma influência cada vez maior. A IA transformará várias actividades de teste de software, incluindo a geração de novos casos de teste, permitindo capacidades de auto-cura e criando dados de teste para reduzir o esforço manual. Melhora os testes automatizados através da criação de excertos de código, permitindo assim que os testers se concentrem nas suas tarefas principais. Além disso, a IA apoia os testadores dando prioridade aos testes críticos, detetando anomalias e identificando as causas principais das falhas do sistema, ou dos próprios testes. Isto inclui a categorização de falhas em defeitos de produto, defeitos de automação ou falhas. 2. Testes Shift-Left e Shift-Right No atual ciclo de vida acelerado de desenvolvimento de software, é essencial obter feedback sobre os testes de forma rápida e eficiente. Os métodos tradicionais de teste de software podem atrasar o ciclo de vida do desenvolvimento, fornecendo informações nas fases posteriores: O teste Shift-Left é uma abordagem para obter feedback mais rápido para ajudar os programadores a corrigir problemas/defeitos o mais rapidamente possível, ajudando a reduzir o custo e o tempo associados à correção de defeitos. Por outro lado, podem também ser melhorados pelos testes Shift-Right, que estendem os testes à produção, através de técnicas como testes A/B, lançamentos canários e implementações azuis/verdes para recolher feedback dos utilizadores. Os sistemas de monitorização ativa recolhem informações sobre o desempenho e identificam falhas para garantir que o software satisfaz os requisitos do mundo real. Depois de uma funcionalidade ser lançada, os testes de ponta a ponta, que incluem testes de interface do utilizador, também podem validá-la com êxito. 3. Testes Éticos de IA A IA está a desempenhar um papel cada vez mais importante nos testes de software, mas as práticas éticas devem orientar a sua utilização. À medida que a IA evolui, pode gerar involuntariamente resultados tendenciosos, levando a resultados injustos ou discriminatórios. E é aí que entra a IA ética. Os testes éticos de IA garantem que os sistemas cumprem as principais normas, como a equidade, a responsabilidade e a conformidade com regulamentos como o RGPD (Regulamento Geral sobre a Proteção de Dados), que protege os dados sensíveis. Isto implica testar continuamente os resultados produzidos pelos sistemas de IA para manter a segurança, a robustez e a fiabilidade. 4. Aumento da Procura de Plataformas de Testes Low-Code A procura de plataformas de teste em low-code continua a aumentar à medida que muitas organizações preferem formas mais rápidas e eficientes de fornecer software de alta qualidade. Estas plataformas permitem que os intervenientes não técnicos, como os testadores comerciais e de UAT (testes de aceitação do utilizador), criem, executem e mantenham testes automatizados com uma experiência mínima de codificação. Ao colmatar as lacunas de competências, as plataformas de low-code promovem uma colaboração perfeita entre a empresa, os programadores e os testadores. A funcionalidade simples de arrastar e largar acelera a criação de testes, reduzindo o tempo de desenvolvimento dos mesmos. Com o suporte de CI/CD, as plataformas de low-code permitem que os testes sejam executados de forma eficiente a partir de pipelines, fornecendo feedback rápido. Ajudam a simplificar as práticas Agile e DevOps, aumentando a sua precisão. Além disso, as ferramentas low-code aumentam a escalabilidade, simplificam a manutenção e aumentam a produtividade através da automatização de tarefas repetitivas, tornando os testes de software mais fiáveis.   5. Testes Focados na Cibersegurança Em 2025, os testes de cibersegurança vão aumentar entre as organizações à medida que a frequência dos ciberataques aumentam. Muitas organizações conceituadas estão cada vez mais vulneráveis a ameaças como phishing, violações de dados, ataques de negação de serviço distribuída (DDoS) e ransomware, que podem levar a perdas financeiras e interrupções operacionais. Por isso, as empresas precisam de considerar a implementação da cibersegurança nos seus ciclos de vida de desenvolvimento. Uma dessas abordagens é o DevSecOps, em que a segurança é aplicada em todas as fases das actividades de desenvolvimento. Práticas proactivas como testes de penetração, testes estáticos de segurança de aplicações (SAST), testes dinâmicos de segurança de aplicações (DAST) e modelação de ameaças podem ajudar as organizações a identificar vulnerabilidades precocemente e a mitigar os riscos de forma proactiva. As ferramentas baseadas em IA podem ajudar na monitorização em tempo real, na deteção mais rápida de ataques e na análise preditiva para se manterem à frente das ameaças em evolução.   A continuação do artigo original via Get XRay pode ser lida aqui. 

Artigo de opinião assinado por Brooke Masters. Com a disseminação de veículos eléctricos e sistemas mais sofisticados, a gestão das actualizações de só se tornará mais importante à medida que estes se tornarem mais populares, e os sistemas de informação digital e de segurança dos veículos a gasolina se tornarem cada vez mais sofisticados. As correcções de software foram responsáveis por 15% das recolhas de veículos nos EUA no ano passado, contra 6% há cinco anos, de acordo com os dados da National Highway Traffic Safety Administration. No ano passado, a BMW foi alvo de três recolhas de software nos EUA, mais do que muitos dos seus rivais, de acordo com os registos da mesma entidade. Globalmente, a Ford registou o maior número de casos, com 19, seguida de perto pela Chrysler. A Tesla detinha a maior quota de mercado, com 50% das 16 recolhas a exigirem correcções de software. Isto não é surpreendente, dado que os automóveis eléctricos dependem muito mais do software e têm menos peças do que os motores de combustão interna. Mas os dados relativos às recolhas apenas arranham a superfície de um problema de software mais vasto: À semelhança dos fornecedores de telemóveis, os fabricantes de automóveis utilizam regularmente actualizações para melhorar as funcionalidades existentes e vender novos serviços aos clientes existentes.  A maioria dos fabricantes envia actualizações regularmente, que abrangem tudo, desde modos de iluminação interna e melhorias na utilização da bateria até alterações de segurança importantes. “Antigamente, era possível fabricar um automóvel, embrulhá-lo e vendê-lo”, afirmou Kevin Mixer, analista sénior da consultora Gartner. “O automóvel é agora uma plataforma viva… As empresas estão a aprender em tempo real.” Isto está a revelar-se mais difícil para os fabricantes de automóveis tradicionais do que para os concorrentes emergentes. No ano passado, quando a Gartner classificou os fabricantes de automóveis em função do seu desempenho digital, os sete primeiros eram todos fabricantes de veículos eléctricos chineses e norte-americanos, incluindo a Rivian, a Tesla e a Nio, enquanto os fabricantes tradicionais obtiveram uma pontuação média desanimadora de 33 em 100. Os problemas de software atrasaram os lançamentos recentes em empresas como a Volvo e a General Motors. Frustrados com o desenvolvimento interno de software, os executivos da Volkswagen assinaram uma parceria de 5 mil milhões de dólares com a Rivian no verão passado. As actualizações de software são também, por si só, oportunidades de receita. A Accenture prevê que, até à década de 2040, os serviços digitais poderão gerar até 3,5 biliões de dólares anuais para os fabricantes de automóveis, representando 40% das receitas totais, contra os actuais 3%. As possibilidades vão desde a atualização para bancos aquecidos, estacionamento automático, até permitir que os condutores comprem comida, combustível e entretenimento de alta qualidade diretamente a partir do interior do veículo. Mas esse futuro lucrativo terá de esperar até que a indústria automóvel domine a arte das actualizações de software sem falhas.  A continuação do artigo original via Financial Times pode ser lida aqui.