Um bug de software que viajou até Marte

Um bug potencialmente perigoso foi encontrado numa componente de software com 20 anos de idade e considerada tão eficaz que tem sido usado em smartphones, automóveis, aviões e no veículo que viajou até ao planeta Marte, a Mars Rover Curiosity.

Em 1994, Markus Oberhumer criou um algoritmo de compressão de dados (Lempel-Ziv-Oberhumer, LZO) que se mostrou tão rápido a descomprimir informações que passou a ser usado em todo o mundo. Para isto contribuiu o facto de Oberhumer ter publicado o software com licença Open Source.

Na semana passada, Oberhumer lançou a versão 2.07 da LZO, e avisou que as versões anteriores eram passíveis de buffer overrun. Isto significa que é possível criar um conjunto de dados comprimidos que executaria um pedaço de código malicioso quando o software tentasse descompactá-lo.

A falha só se manifesta em circunstâncias muito específicas, levando Oberhumer a sugerir que as "implicações práticas são limitadas". Mas a natureza do código e a popularidade do software levam a crer que a correcção do problema em todo o mundo será um enorme esforço.

-------------------------------------------------------
Notícia completa em inglês: Software bug found on Mars Curiosity rover

10 Regras Básicas sobre Automatização de Testes

Testar software é uma tarefa difícil e automatizar testes de software é o sonho de todos os testers, analistas e programadores. No entanto, a automatização é um processo que tem de ser bem compreendido, que exige muita prática, e no qual devemos seguir alguns conceitos básicos. Vamos descrever alguns desses conceitos básicos e mostrar que a automatização pode ser fácil se for feita correctamente.

Regra 1: Ler e aprender conceitos básicos

Os programadores mais qualificados necessitam de rever os seus conhecimentos ao longo do tempo; aprender é uma necessidade. A automatização não é mais que que uma mera avaliação dos passos a executar por um programa, escrevendo instruções detalhadas.

Regra 2: Estar preparado para enfrentar a automatização no projecto

A prática é a única forma de obter conhecimento válido. Seleccione uma qualquer ferramenta de testes open source disponível, instale-a e aprenda a usá-la no seu tempo livre. Qualquer uma serve. O importante é praticar, compreender e ganhar experiência para estar pronto para enfrentar um projecto real quando for necessário.

Regra 3: Os conceitos básicos são os mesmos, basta explorá-los

Além das diferentes particularidades, todas as linguagens de programação funcionam basicamente com os mesmos conceitos como variáveis, parâmetros, funções, diferentes tipos de dados, ciclos, declarações condicionais, arrays, etc. Depois de os compreender e recordar, qualquer pessoa deve ser capaz de aplicar esse conhecimento em qualquer linguagem de programação. Reserve algum tempo, cerca de duas semanas, para compreender as bases da programação.

Regra 4: Não desistir quando o primeiro programa falhar

Os russos têm um provérbio maravilhoso: a primeira panqueca é uma confusão. Isso significa que é muito provável que a primeira tentativa de qualquer coisa irá falhar, mas todas as seguintes terão melhor resultado, e com isso podemos ganhar experiência no processo. Não importa o quanto sabemos da teoria; provavelmente, a primeira execução prática será decepcionante. Por isso, temos que continuar.

Regra 5: Olhar para o código como um processo, não como magia

Sempre que um principiante olha para o código, este parece incrivelmente complexo. No entanto, depois de produzir algum código eficaz, conseguiremos reconhecer os padrões e procedimentos, tornando a leitura do código muito mais fácil. Depois podemos ver as instruções do programa, claras como água, e perceber a sua lógica.

Regra 6: Explorar a ferramenta

A melhor maneira de conhecer uma ferramenta é explorar as suas funcionalidades uma a uma. De forma sistemática, devemos seleccionar cada uma das opções e subopções de menu e inspeccionar as respectivas funcionalidades. Se existir uma barra com botões, estes devem conter as funcionalidades mais comuns. A maioria dos itens costuma ter nomes auto-explicativos.

Regra 7: Procurar Ajuda

Sempre que nos sentimos num impasse devemos procurar algum texto explicativo na secção de ajuda. Geralmente esta contém boas explicações e instruções sobre cada funcionalidade da ferramenta. Leia-a atentamente para conseguir dominar a ferramenta.

Regra 8: Praticar muito

Devemos encarar os testes de software com um processo de validação. Isto permite concluir se o código é funcional ou não. Os testes automatizados devem permitir concluir a mesma coisa, e apresentando resultados claros (sim/não; o teste passou ou falhou) em vez de resultados em bruto que necessitam de interpretação.

Regra 9: Melhorar o nosso Trabalho

Todas as coisas bem-feitas podem ser feitas ainda melhor. Investir na revisão e melhoramento dos nossos projectos é um caminho para melhorar as nossas competências e levar-nos a novos desafios.

Regra 10: Automatização nem sempre é necessária

Apesar de ser muito útil, a automatização não é nada mais do que um instrumento de testes. Nem sempre os projectos necessitam de automatizar os seus testes. Devemos escolher a melhor forma de testar (manual ou automático) de acordo com as necessidades de cada projecto.

Conclusão:

Essas regras não são obrigatórias, mas são simples e óbvias. Seguindo-as podemos melhorar as nossas competências e evoluir como testers.

-----------------------------------------------------
Traduzido e adaptado de: 10 Basic Rules For Beginners In Automation Testing

GTAC 2011: Opening Keynote Address - Test is Dead

A vida bipolar de um software tester

Isto é uma chatice. Estive todo o dia a fazer testes e ainda não encontrei um único problema.

Não, espera...

Isto é bom, certo? O objectivo é termos software limpo. Tudo bem, porreiro, vamos a isto! Parece que vamos conseguir pôr isto em produção amanhã de manhã... Só mais um teste ... Porra!!! Encontrei um bug! Odeio encontrar bugs na recta final! Isto é uma treta.

Não, espera...

Isto é bom, certo? É melhor apanhar os bugs hoje em QA do que amanhã em produção . É para isso que me pagam. Ui… aqui está outro bug! E mais outro! Cá vamos nós... Acabei de encontrar a mãe de todos os bugs. Isto é incrível!

Não, espera...

Isto é mau, certo? Ou fazemos um esforço e trabalhamos até mais tarde ou adiamos a entrada em produção de amanhã. Devia ter encontrado estes problemas mais cedo, teria sido muito mais fácil… Que porcaria!

Mas o que é isto? Estão a rejeitar os meus bugs??? A sério??? Que humilhação! Odeio quando os meus bugs são rejeitados!

Não, espera... Isto é bom, certo? É porreiro que os meus bugs sejam rejeitados. Menos confusão. Agora não tenho que testar tudo novamente.

Não, espera... Eu quero testar tudo outra vez.

Não, espera... talvez não queira.

Ahhhhhhh!

-----------------------------------------
Texto original em ingles: The Bipolar Life of a Software Tester

Bug no Software interrompe contagem de votos electrónicos na Bélgica

Um bug numa aplicação de votação electrónica levou à suspensão da divulgação de resultados eleitorais na Bélgica, anunciou hoje o Ministério do Interior Belga. No Domingo realizaram-se eleições europeias, federais e regionais e registaram-se problemas nas contagens de votos feitos em aparelhos antigos existentes em 20 dos 209 cantões belgas.

O bug no software provocou resultados incoerentes quando tentou somar os resultados os votos preferenciais dessas máquinas. A aplicação soma os resultados de diferentes formas mas deve obter sempre o mesmo resultado. Mas desta vez não foi isso que aconteceu. E, consequentemente, a contagem de votos foi imediatamente interrompida.

Este bug surgiu apesar do software ter sido especialmente desenvolvido para actos eleitorais e ter sido "testado milhares de vezes", tendo mesmo sido certificada pela PriceWaterhouseCoopers, declarou Peter Grouwels, o porta-voz do Ministério do Interior.

A meio da noite a empresa Stesud que criou o software apresentou uma solução para o problema e as contagens de votos foram retomadas.

As máquinas problemáticas (PC’s x86 da era DOS) são de dois tipos e têm sido usadas na Flandres (região flamenga). Desde 2012, alguns cantões passaram a usar um sistema de voto electrónico baseado em Linux, desenvolvido pela empresa venezuelana Smartmatic. Na Valónia (região francófona) 80% dos municípios usam o sistema tradicional com caneta e papel.

Kommer Kleijn, porta-voz da VoorEVA.be, uma organização belga que rejeita o sistema de voto electrónico porque "priva os eleitores de verificar eficazmente as eleições em que participam" descreveu os problemas como "uma catástrofe".

"Eles afirmam que a gravação dos votos foi feita na perfeição; mas quem pode confirmar isso? Nós não podemos", disse Kleijn. "Não há nenhuma maneira de provar que o bug só estava presente na aplicação usada para somar os votos e não em outras partes do sistema de votação", acrescentou.

Não é a primeira vez votando com este sistema dá problemas. "Sempre que este sistema foi utilizado, houve problemas comparáveis a este" lembrou Kleijn.

Segundo um estudo realizado por sete universidades belgas, em 2003, na cidade de Schaarbeek, por exemplo, as máquinas de voto contaram 4096 votos a mais do que eleitores registados. E, em Liège, em 2006, alguns candidatos obtiveram um resultado parcial superior ao seu resultado final, disse Kleijn.

A Bélgica é um dos poucos países europeus que ainda utilizam sistemas de voto eletrónico. Na Alemanha, o Tribunal Constitucional Federal proibiu o uso de urnas electrónicas em 2009, pois os resultados das máquinas não eram verificáveis. A Holanda proibiu a prática em 2008, após um grupo de activistas ter conseguido demonstrar que os resultados dos dois tipos de urnas electrónicas em uso podiam ser adulterados.

Em França há ainda alguns municípios que usam urnas electrónicas. E na Estónia é usado um sistema de voto electrónico via Internet que foi considerado vulnerável a vários ataques por diversos especialistas que desaconselharam o seu uso nas eleições europeias.

---------------------------------------------
A LER:
Software bug disrupts e-vote count in Belgian election (PC World)
Couac informatique, la diffusion de certains résultats en suspens (Le Soir)
Enormes bugs informatiques dans le dépouillement des elections (La Libre)

Cinco sinais de um Tester pouco profissional

Recentemente, tem havido muitos debates sobre o nível de profissionalismo dos testers.

Algumas pessoas argumentam que não existem testers profissionais porque a própria profissão não é formalmente especificada ou ensinada nas universidades; outros pensam que não há profissionais nesta indústria, pois esta ainda é relativamente nova. Mas por outro lado, todos consideramos natural procurar indicadores de profissionalismo na atitude das pessoas nas suas actividades e trabalho nos esforços que fazem para evoluir e aperfeiçoarem-se.

Aqui ficam alguns sinais de pouco profissionalismo nos testers:

1. Você acha que não precisa de ler o código. Porque lidamos com desenvolvimento de software, devemos saber algo sobre a sua engenharia. Podemos não ser saber escrever o código; no entanto, se não o lermos, vamos perder uma grande quantidade de informações que contribuem para o processo de testes. O código permite analisar o produto, perceber como é que as novas correcções podem afectá-lo e gerar novos bugs.

2. Você acha correcto iniciar os testes só após a conclusão da fase de desenvolvimento. A verdade é que conseguimos testar de forma eficiente, quando somos envolvidos o mais cedo possível no projecto, tal como os outros membros da equipa. Embora os testes sejam vistos como a última etapa do projecto, é fundamental participar e acompanhar o levantamento de requisitos, a análise e a fase de planeamento para entender melhor os objectivos dos testes.

3. Você normalmente não interage com o cliente. Uma vez que o seu trabalho é garantir que o produto está de acordo com todas as necessidades do utilizador, é fundamental que um tester faça validações regulares junto do cliente e tenha uma boa compreensão das expectativas dos utilizadores em relação ao produto. Só assim se conseguem fazer testes eficazes e abrangentes.

4. Você considera desnecessária a gestão de risco. Todos os testers sabem que existem algumas componentes do software que são mais propensas a bugs e que estas componentes costumam atrasar o trabalho da equipa. Por esse motivo, faz parte das funções de um tester conhecer estas situações e informar os outros. E porque nunca conseguimos testar tudo, temos que fazer a gestão de risco, atribuindo prioridades ao nosso trabalho e decidir a ordem dos testes a executar.

5. Você não tenta aumentar o seu valor como tester. Engana-se quem pensa que fazer testes não requer conhecimentos e competências especiais que permitem desenvolver a especialização em testes. Em vez de ver os testes como um trabalho pouco sério, devemos começar a construir uma estratégia profissional como testers. Devemos identificar as qualidades mais importantes que a nossa empresa exige a cada um de nós e delinear formas para as desenvolver.

O futuro dos testes de software precisa de todos nós; se deixar de ser exigente com a sua especialização profissional, então deixarão de existir testers profissionais.

---------------------------------------------------------
Texto original em inglês: Beware! 5 Signs of Being Unprofessional Tester

Ford chama 750.000 veículos devido a problema de software

Em Detroit (EUA), a Ford Motor Co. Anunciou que está chamar para revisão mais de 750.000 veículos utilitários desportivos para correcção de um possível problema no software nas portas. Os veículos em causa foram vendidos nos Estados Unidos, Canadá e México.

A segunda construtora automóvel americana chamou 692.487 SUVs (incluindo cerca de 65.000 C-Max híbridos), construídos em 2013 e 2014, devido a um problema no software que pode atrasar o accionamento dos airbags laterais em alguns acidentes.

A Ford anunciou que até ao momento não foi reportado qualquer acidente ou problema relacionado com a falha agora detectada.

Além disso, a Ford também está chamar para revisão 692.744 SUVs construídos em 2013 e 2014 para corrigir possíveis defeitos nos puxadores das portas que poderiam impedir as portas de trancar correctamente. A empresa disse que as portas se poderiam abrir durante a condução, aumentando o risco de ferimentos.

-------------------------------------------------------
Fonte: Ford recalls over 750,000 vehicles for software, door-handle faults (Chicago Tribune)