Destaque

Há cerca de 40 anos, um erro de software foi o principal responsável pela morte de pacientes que utilizavam o Therac-25, uma máquina de radioterapia desenvolvida para o tratamento de cancro. O equipamento tinha dois modos de operação: feixe de eletrões, usado para tratar tecidos superficiais como a pele; e feixe de raios-X de alta energia, destinado a atingir tumores mais profundos. Diferente de versões anteriores, o Therac-25 foi projetado com controlos via software, deixando de lado várias proteções físicas de segurança. O problema em questão, residia numa falha de programação que envolvia uma condição de corrida: quando o operador inseria comandos muito rapidamente, a lógica do software podia ignorar etapas de verificação e libertar radiação de forma completamente descontrolada. Como a máquina levava alguns segundos para alternar de modo, essa rapidez na operação criava uma falha perigosa, resultando assim numa projeção de doses até 100 vezes mais fortes do que o recomendado, levando a queimaduras internas graves e, em vários casos, à morte. Entre 1985 e 1987 foram documentados seis incidentes, três deles fatais. Alguns destes pacientes receberam quantidades massivas de radiação numa questão de segundos, e acabariam por falecer dias depois. O caso ficou famoso por mostrar como falhas invisíveis no software podem ter consequências devastadoras quando os sistemas críticos não contam com redundâncias físicas. O desastre do Therac-25 serviu como marco na história da engenharia de software e na área de dispositivos médicos, levando também a mudanças importantes nas exigências de testes, documentação e validação formal de programas usados em contextos de segurança crítica. O artigo original via Tom’s Hardware aqui. 

Nos Estados Unidos, a Toyota anunciou um recall que afetou mais de meio milhão de veículos. A Administração Nacional de Segurança Rodoviária (NHTSA) identificou uma falha no visor do painel de instrumentos, que pode deixar de mostrar informações essenciais, como velocidade do veículo, estado do sistema de travagem e avisos de pressão dos pneus – um defeito que representa um risco elevado de acidentes. O recall inclui vários modelos: Venza, Highlander, Lexus, Tacoma e GR Corolla. O problema decorre de um erro de software durante o arranque do veículo, que impede o painel de instrumentos de exibir corretamente as notificações críticas. Fundada em 1937, a Toyota Motor Corp é uma das maiores fabricantes de automóveis do mundo, com 11,0 milhões de unidades vendidas no varejo no ano fiscal de 2025, incluindo 10,3 milhões das marcas Toyota e Lexus. A empresa opera no setor de bens de consumo cíclicos, especificamente na indústria de veículos e peças. A capitalização de mercado da Toyota é de aproximadamente US$ 262,48 bilhões, refletindo sua presença substancial no mercado automotivo global. O desempenho financeiro da Toyota é caracterizado por um crescimento robusto da receita e métricas sólidas de rentabilidade. A receita da empresa nos últimos doze meses (TTM) é de US$ 328,37 bilhões, com uma taxa de crescimento da receita de 17,1% em três anos. Apesar de uma recente queda de 16,5% nos lucros em relação ao ano passado, a Toyota manteve uma margem operacional saudável de 9,6% e uma margem líquida de 8,82%. No balanço patrimonial, a Toyota apresenta um índice de liquidez corrente de 1,27 e um índice de endividamento de 1,07, indicando uma abordagem equilibrada em relação ao endividamento. No entanto, o Altman Z-Score de 1,77 coloca a empresa na zona de risco, sugerindo um risco potencial de instabilidade financeira nos próximos dois anos. As tendências de receita da Toyota são apoiadas pela sua linha diversificada de produtos e investimentos estratégicos em tecnologia e inovação. A expansão da margem operacional da empresa é um indicador positivo de eficiência operacional, refletindo a sua capacidade de gerir custos de forma eficaz enquanto impulsiona o crescimento. O posicionamento competitivo da Toyota é reforçado pela sua significativa quota de mercado no Japão e nos EUA, bem como pelos seus investimentos em tecnologias emergentes e parcerias com empresas como a Uber Technologies e a Joby Aviation. Avaliação e sentimento do mercado Em termos de avaliação, o rácio P/E da Toyota situa-se em 9,27, o que está abaixo da média do setor, indicando uma potencial subvalorização. O rácio P/S da empresa de 0,81 e o rácio P/B de 1,08 reforçam ainda mais esta perspetiva. As recomendações dos analistas sugerem um preço-alvo de 230,47 dólares, refletindo uma perspetiva positiva sobre o desempenho futuro da Toyota. Indicadores técnicos, como o RSI de 60,95 e as médias móveis, indicam um ambiente de negociação estável, com o preço das ações próximo da sua máxima de 52 semanas. A participação institucional é relativamente baixa, de 1,75%, sem nenhuma atividade significativa de insider trading relatada no último ano. As notas de saúde financeira da Toyota destacam áreas de preocupação, particularmente o Altman Z-Score e o ROIC da empresa de 4,39%, que está abaixo do custo médio ponderado de capital, indicando potenciais ineficiências na alocação de capital. Os riscos específicos do setor incluem mudanças regulatórias e disrupções tecnológicas na indústria automóvel. O beta da Toyota de 0,75 sugere uma volatilidade menor em comparação com o mercado em geral, proporcionando alguma estabilidade em meio a esses desafios.   O artigo original via Guru Focus aqui. 

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.