Destaque

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. 

Todos os anos, dezenas de automóveis pesados e ligeiros são sinalizados por problemas de segurança tão graves que exigem uma reparação imediata para corrigir um defeito conhecido. O número de recalls, ou recolha dos mesmos, bem como o número de veículos afectados, tem vindo a aumentar nas últimas décadas – só em 2023, foram recolhidos mais de 30 milhões de veículos. Segundo as estatísticas norte-americanas, cada vez mais as recolhas de segurança revelam a necessidade de corrigir um problema eletrónico: As avarias relacionadas com o software são agora responsáveis por mais de 1 em cada 5 recolhas de automóveis, de acordo com uma análise divulgada no início deste ano, relativa a uma década de dados de recolha da Administração Nacional de Segurança do Tráfego Rodoviário, pelo escritório de advocacia DeMayo Law. Uma estimativa separada da Envorso, uma empresa de consultoria americana especializada em estratégia de software para o sector automóvel, destacou um impacto ainda mais dramático: O número total de veículos afectados por recolhas relacionadas com erros de software saltou de quase 15% de todos os veículos recolhidos em 2023, para quase 42% de todos os veículos recolhidos até agora este ano. Por outras palavras, mais de 12 milhões de veículos foram recolhidos devido a problemas de software até ao final de outubro. No início deste ano, a Stellantis fez uma recolha de mais de um milhão de veículos nos EUA devido a um problema de software, que impedia que as câmaras de visão traseira de funcionarem corretamente. Uma investigação da Detroit Free Press, publicada no início deste ano, revelou ainda que milhões de automóveis usados e envelhecidos, que circulam atualmente nas estradas dos EUA não estão a ser reparados, apesar dos defeitos perigosos identificados pelos fabricantes de automóveis e pelo governo federal. A investigação concluiu, também, que os fabricantes destes automóveis estão a fazer poucos progressos na reparação dos seus modelos mais antigos com problemas de segurança, colocando um grupo crescente e vulnerável de condutores em risco desnecessário.    A continuação do artigo original via Detroir Free Press pode ser lida aqui. 

Na Alemanha, um erro de software afetou as eleições estaduais na Saxónia, levando a um cálculo errado dos novos lugares do parlamento. A administração eleitoral do Estado esclareceu agora a situação. A falha de software no cálculo da distribuição de lugares no novo parlamento estadual da Saxónia foi corrigida, e este erro não teve qualquer efeito no resultado provisório das eleições, segundo a administração eleitoral estatal. De acordo com os resultados preliminares, a CDU obteve um resultado de 31,9%; com o AfD logo atrás com 30,6% e o BSW alcançou 11,8% desde o início. O SPD ficou com 7,3% e os Verdes com 5,1%. O Partido da Esquerda caiu para 4,5% e o FDP para 0,9%. A decisão sobre a distribuição dos lugares no 8º Parlamento do Estado da Saxónia será tomada pela comissão eleitoral estatal após o resultado final oficial, que ainda está pendente, acrescentou a administração. No entanto, devido ao novo cálculo após o acidente, o AfD muito provavelmente não terá a chamada “minoria de bloqueio” no estado. O partido iniciou uma investigação – “Se houver alguma irregularidade, vamos tomar medidas legais”, disse Jörg Urban, o líder do grupo parlamentar e estadual da AfD na Saxónia, exigindo uma análise precisa do erro. Uma “minoria de bloqueio” significa que um partido tem mais de um terço dos mandatos no parlamento estadual. Neste caso, pode impedir certas leis estaduais que são aprovadas com uma maioria de dois terços de todos os deputados. Na Saxónia, tal como noutros Estados federados, os juízes constitucionais e o presidente do Tribunal de Contas, por exemplo, são eleitos por uma maioria de dois terços dos deputados. Isto significa que certos cargos não poderiam ser preenchidos sem a aprovação da AfD, que também poderia ter impedido que o parlamento estadual se dissolvesse. O artigo originais via Diesachen pode ser lido aqui. 

Recentemente, a Volvo anunciou a recolha de mais de 72 mil veículos elétricos devido a um erro de software. Segundo o comunicado da gigante sueca, estes veículos modelo EX30 podem acidentalmente apresentar um “ecrã de teste” no monitor central, obscurecendo as estatísticas de condução normais apresentadas, incluindo o velocímetro e as funcionalidades de info-entretenimento. A causa exacta do problema ainda não foi revelada. O bug foi detetado pela primeira vez durante o mês passado, quando a Volvo anunciou uma recolha de 1.255 veículos, especificamente na Austrália. “Devido a um erro de software, o ecrã da unidade de informação e lazer pode entrar num modo de teste durante o arranque do veículo. Isto pode impedir que informações importantes, como a velocidade do veículo, sejam exibidas”, lê-se no recall australiano. “A não apresentação de informações importantes pode aumentar potencialmente o risco de ferimentos ou morte dos ocupantes do veículo e de outros utentes da estrada.” De facto, o que torna este erro especialmente problemático é que, ao contrário de quase todos os outros carros, todas as estatísticas e informações destes modelos Volvo, como a velocidade, estão localizadas apenas no ecrã central. Por esse motivo, quando ocorre um erro desta natureza no ecrã de teste, os condutores ficam sem saber exatamente a que velocidade circulam. Felizmente para os proprietários do EX30, não será necessário levar os seus veículos à oficina ou aos concessionários para que o erro seja corrigido. Uma atualização, denominada versão 1.3.1, está agora disponível para que qualquer utilizador a possa descarregar e instalar. Esta não é a primeira vez que a Volvo se depara com problemas de software nos seus automóveis mais recentes. De acordo com as declarações públicas da Volvo, o EX90 topo de gama sofreu um atraso de meio ano apenas para se concentrar no desenvolvimento de software. Os riscos são elevados quando se trata de software e de potenciais problemas, especialmente quando componentes importantes de um veículo dependem diretamente do software para funcionarem corretamente.   O artigo originais via TheRegister pode ser lido aqui. 

A Food and Drug Administration (FDA) dos Estados Unidos da América anunciou recentemente um recall (retirada do mercado) do mais alto nível de gravidade, para uma aplicação móvel ligada a uma bomba de insulina. A aplicação, o t:connect Mobile App iOS v2.7 da Tandem Diabetes Care, foi retirada devido a um bug que afetou a sua comunicação com a bomba de insulina t:slim X2. Este erro de software detectado pode colocar os pacientes com diabetes, que dependem da aplicação para controlar os seus níveis de insulina, em grave risco de saúde. A FDA aconselhou os pacientes a parar de usar a versão afetada da aplicação por enquanto, e voltar a usar a interface de utilizador integrado da bomba de insulina, até que o problema seja resolvido. A empresa Tandem Diabetes Care já está resolver o problema e espera-se que em breve disponibilize uma atualização corrigida do software. Os utilizadores, entretanto, foram encorajados a acompanhar atentamente os seus níveis de glicose e a consultar os seus profissionais de saúde sobre a gestão da sua insulina. Na análise ao problema em questão, observou-se que esta aplicação – destinada a ser sincronizada com a bomba de insulina t:slim X2 – pára e reinicia abruptamente, o que  pode levar ao rápido esgotamento da bateria da bomba e os utilizadores podem não aceder ou controlar a mesmo através da aplicação. Nestas situações, podem ocorrer interrupções na administração de insulina, o que coloca graves problemas de saúde para os pacientes dependentes da bomba.   O artigo originais via BaselineMag pode ser lido aqui.