Erro de software provoca aviso de Tsunami no Alaska

Várias pessoas na cidade de Stika, no Alaska, acreditaram que um tsunami estava iminente quando receberam aviso que omitia a frase “Isto é um teste”. Os exercícios e simulações costumam ocorrer em muitas cidades costeiras do Alaska, mas desta vez, um erro de software terá levado a população a acreditar que se tratava de um evento real.

Segundo a rádio KWAC, um erro de software terá estado na origem da confusão. Joel Curtis, do Serviço Nacional de Meteorologia, esclareceu que a mensagem que foi transmitida usou o template de aviso real que substituiu a mensagem usada em exercícios e simulações.

Após esta simulação de tsunami, a polícia de Sitka apressou-se a esclarecer os residentes que a mensagem de alerta de tsunami foi apenas um teste.

-------------------
FONTES:
Software error leads to Tsunami warning scare in Alaska (FoxNews)
Tsunami warning test too real? (KWAC)

FAA ordena correcção imediata ao software do Boeing 747-8

A Federal Aviation Administration (FAA) (agência federal americana para a aviação) ordenou a correcção imediata da mais recente versão do software do Boeing 747-8, declarando que foi detectado um problema que pode provocar a perda de potência durante a manobra de aterragem e causar a queda do avião. Esta é a 4ª directiva da FAA sobre este tipo de aparelho.

Por seu lado, a Boeing já veio esclarecer que o problema agora detectado nunca afectou qualquer avião em pleno voo, acrescentando que a possibilidade de ocorrência de problemas é “extremamente remota”. Entretanto, as companhias que possuem este tipo de aparelho foram aconselhadas a actualizar o respectivo software.

O Boeing 747-8 é a mais recente versão do avião conhecido como “Jumbo“. Actualmente existem dezenas deste tipo de aparelho no activo em diversas companhias aéreas.

-------------------------
FONTE: FAA tells Boeing to fix 747-8 software to avoid crash (Reuters)

Testes de Regressão: Manuais ou Automáticos?

A questão que surge em cada fase do desenvolvimento é que os testes de regressão após cada iteração levam muito tempo, e muitas vezes a funcionalidade que está a ser validada não sofreu alterações. Consequentemente, a possibilidade de existirem defeitos é muito baixa. Como resultado natural, chegamos a uma ideia de automatizar todos os cenários de regressão e em detrimento dos testes manuais de regressão. As vantagens são evidentes:

• os testes automatizados são mais rápidos do que os manuais ;
• os testes automatizados podem ser realizados em qualquer momento;
• os testes automatizados são muito precisos;
• a automatização pode ser utilizada em quase todos os processos de teste;
• pode-se criar relatórios com base nos resultados da automatização.

Mas, infelizmente, a automatização dos testes de regressão tem muitas armadilhas que raramente são discutidas.

Antes de começar a automatizar testes de regressão é necessário resolver algumas questões: 

• Que funcionalidade deve ser coberta pelos testes;
• Definir a arquitectura dos testes automáticos;
• Escolher uma ferramenta para automatizar de testes de regressão.

Vamos ver situações reais na prática. Na fase de mudança de testes manuais para testes automatizados, tive um projecto onde eu tinha que testar o registo de dois tipos de contas para um site em 43 domínios, consoante país. Era um autêntico inferno. O cliente não se preocupava com a qualidade da informação apresentada. Os requisitos eram os seguintes:

• as contas são criadas sem erros fatais ;
• os dados introduzidos coincidem com os valores que são exibidos nas configurações após a criação.

Depois de duas execuções percebi que era demais. Na altura, só conseguia ver que o número de campos de registo é diferente em alguns países e também tinha alguma experiência em programação em C#. Havia a possibilidade de automatizar os testes regressão e não hesitei. Pedi a um amigo familiarizado com automatização para descrever e mostrar como se escrevem testes. Depois de muitas perguntas, tentativas e erros, nasceu um teste simples de navegação. Descobri locators e web drivers Selenium - e eis que, todos os domínios utilizavam os mesmos locators. Pouco mais tinha para fazer: executar última regressão manual da minha vida em todos os domínios e preencher a tabela com os correspondentes campos e domínios. Outra sessão de regressão manual - um longo processo para fechar o círculo - e tudo parecia terminado.

Gozei cada uma das regressões seguintes. Pude assistir a algumas séries de TV enquanto executava a regressão. E, por sinal, cada uma demorava apenas o tempo de um episódio. Enquanto eu costumava gastar cerca de 4 a 5 horas em testes de registos nos 43 domínios, os testes de regressão automatizados demoravam 40 a 45 minutos.

Considerando isto, podemos chegar à conclusão nº1: para ver as vantagens da automatização de testes, devemos começar com os testes mais frequentes, que geralmente são positivos, e que devem ser executados após cada release.

Isso continuou durante várias releases até que a empresa decidiu oficialmente automatizar a maioria das funcionalidades. E como o cliente não era muito conhecedor em testes de automatização decidimos automatizar toda e qualquer coisa que caísse no âmbito do meu conhecimento de automatização de testes.

Como resultado, cobrimos quase todo o sistema com testes automáticos. Tudo estaria bem, mas depois de qualquer correcção alguns testes começavam a falhar. Na maioria dos casos, isso acontecia porque tínhamos grandes scripts que tinham muitos passos:

·         Num primeiro passo do teste o sistema era colocado num determinado estado; quando o erro surgia no segundo passo, já não tinha sentido executar os restantes passos;

·         Cenários longos contêm muito código e acções como estas; como resultado, repetir os primeiros passos podia fazer com que muitos testes falhassem.

·         Devido à repetição do código, os testes automáticos validam o mesmo ponto muitas vezes, o que provoca um aumento desnecessário da duração dos testes.

Com base nisso, podemos chegar à conclusão nº 2: cenários demasiado longos devem ser executados manualmente, pois consome-se muito tempo a escrevê-los e estes podem falhar devido a pequenos bugs ou erros de menor importância.

Vamos considerar uma outra situação muito interessante. O cliente pediu testes automáticos, como é habitual, e solicitou que apresentássemos alguns exemplos. Ele aprovou a ideia, e alguns dias depois adicionamos automatização de testes ao planeamento. Mas os nossos programadores atrasaram-se e, os testers tiveram que escrever testes automáticos com base numa versão provisória. Dois dias depois os programadores concluíram o trabalho, mas mais da metade dos testes automáticos falhou.

Conclusão nº 3: nunca começar a escrever testes automatizados, sem que exista uma versão estável.

Há pouco tempo atrás, tivemos uma situação engraçada. Tínhamos recebido um pedido de testes automáticos a um site e tudo tinha de ser feito rapidamente. Tudo correu melhor do que nunca. Algumas semanas depois, o cliente enviou uma carta reclamando que os testes não funcionaram. Percebemos que ele tinha iniciado um redesenho do site e todos os testes tinham falhado. Isto ensinou-me a fazer testes estáveis.

Portanto, a conclusão n º 4 é: quando for possível, usar os locators de modo que os elementos possam ser encontrados após pequenas mudanças.

Assim, as vantagens de testes manuais vêem-se claramente: não dependem de nada e podem ser feitos em qualquer momento. Prescindir dos testes manuais não vai trazer nada de bom. Testes manuais e automáticos estão inter-relacionados e complementam-se; cada um tem vantagens e desvantagens. Antes de pensar em automatizar cenários de regressão devemos avaliar o tempo a escrever os dois tipos de testes e o apoio destes. E lembre-se que os especialistas em testes manuais geralmente ganham menos do que aqueles que têm competências em automatização de testes.

Como sempre, é tudo uma questão de dinheiro. Se a automatização de cenários de teste de regressão economiza dinheiro sem perder a qualidade do produto, então pode-se alargar o leque de cenários automatizados, elevando a qualidade do produto e reduzindo custos. O ponto de equilíbrio é uma decisão de cada um de nós e depende da experiência e das preferências pessoais.

--------------------------------

Traduzido e adaptado de: Regression Testing: Manual Or Automated? (With Examples)

Day in the life of a Software Development Engineer in Test at Microsoft Ireland

Tipos de Testers

Traduzido e adaptado por João Fialho.

Comportamento: Mede qualidade, fala de qualidade, impõe qualidade, pune aqueles que não têm qualidade
"Inimigos" favoritos: Gestores de Projecto, Programadores e por vezes outros Testers
Frase preferida: Qualidade, Qualidade e Qualidade
Notas: Apenas focados em qualidade. Perfeccionista. Designados por polícias da qualidade. Exigem qualidade em todas as fases dos projectos. Este perfil vive, respire e dorme a pensar em qualidade.

Comportamento: Quando encontra um erro entra em pânico, esbraceja, grita e deita lágrimas de horror
"Inimigos" favoritos: Developers
Frase preferida: “Não dá, não dá, não dá! Não funciona!”
Notas: Atitude exagerada quando encontra algum bug, seja um bug com pouca ou muita criticidade.

Comportamento: Ri-se, brinca, atira piadas e diverte-se com o seu trabalho
"Inimigos" favoritos: Test Team Leaders
Frase preferida: “Sabes o que era capaz de ser giro?”
Notas: Trabalha para fazer um bom trabalho mas também para se divertir com aquilo que está a fazer. Após horas de trabalho, este perfil consegue manter a boa disposição e mandar uma boa piada.
Cria dados de teste engraçados.
A sua maneira de ser, pode transparecer para outras áreas alguma falta de rigor ou de qualidade.

Comportamento: Encontra bugs de forma instantânea, está no lugar certo à hora certa
"Inimigos" favoritos: Gestores de Projecto, Developers e outros Testers
Frase preferida: “Eu não vou à procura de bugs, eles é que me encontram”
Notas: Assim que começam a testar uma aplicação que já foi testada, encontram bugs imediatamente.
Assim que eles mexem em alguma coisa encontram logo problemas.
Todos os testers, em algum momento ou em algum projecto, usufruem desta magia.
Poucos testers conseguem ter esta capacidade permanentemente.

Comportamento: Ao encontrar bugs dá murros na mesa, pontapés na cadeira, grita e revolta-se.
"Inimigos" favoritos: Developers e Gestores de Projeto
Frase preferida: “I'm gonna put my fist through it”
Notas: Má atitude quando encontra bugs. Pior ainda quando é obrigado a registá-lo ou a verificar que a correcção não resolveu o problema.
Detesta programadores gestores de projecto e utilizadores finais.
Dá um murro na mesa quando ouve os programadores a perguntar “Isto é realmente um bug?”.

Comportamento: Para encontrar bugs explora todos os caminhos possíveis, normalmente usa phones, toma montes de notas e efectua testes pouco usuais.
"Inimigos" favoritos: Tester com o perfil “The Checklister”
Frase preferida: “Este teste parece-me interessante”
Notas: Exploram a aplicação à procura de cenários interessantes e reagem à medida que vão sendo devolvidas informações pelo sistema, alterando os seus casos de teste originais.
A capacidade inventiva que colocam na identificação dos bugs encontrados, originam bugs dificeis de identificar e de corrigir.
Este perfil testa qualquer coisa em qualquer estado, não estando limitado a nenhuma checklist.
Atribuem pouca importância aos casos de testes pré-definidos.

Comportamento: Verifica e valida constantemente, sejam bugs, correções ou regressão.
"Inimigos" favoritos: Tester com o perfil “The Explorer”
Frase preferida: “Mas no caso de teste não diz para validarmos isso”
Notas: Perfil com dois extremos.
Por um lado temos o tester inexperiente que apenas executa tarefas pré-definidas de forma robotizada, não colocando em causa nem os testes nem a aplicação. (esta é a visão que leva as pessoas a acreditar que todos os testes podem e devem ser automatizados).
Por outro lado temos o tester que utiliza checklist’s para efectuarem validações específicas e essenciais numa determinada fase do projeto.
Utiliza checklists para armazenar informações e recolher métricas.
A sua “Praia” são os testes de regressão.

Comportamento: Ri-se bastante, conversa muito, aprecia o seu trabalho e diverte-se com ele.
"Inimigos" favoritos: Praticamente não tem “inimigos”
Frase preferida: “Vamos fumar um cigarro e falar sobre isso”
Notas: Todas as equipas devem ter um.
Não gosta de monotonia nem de rotinas.
Organizam eventos e são bons a quebrar o gelo entre as equipas.
É sem dúvida o Manager dos coffee breaks e dos jantares de equipa.
Por vezes, precisa de um abanão para não se deixar entusiamar em demasia com as actividades extra laborais.

Comportamento: Tudo é automatização e automatizável
"Inimigos" favoritos: Manual Testers
Frase preferida: “Eu não posso efectuar essa tarefa utilizando esta ferramenta?”
Notas: Vivem para automatizar e automatizam tudo.
Falam com um programador e agem como um tester.
Este perfil normalmente sabe um pouco de tudo, usando um leque alargado de ferramentas, tem habilidade natural para construir código aliada a uma compreensão orientada aos testes.
Quando está restringido a apenas uma ferramenta, perdem a chama que poderiam ter, uma vez que estão limitados à resolução de um conjunto restrito de problemas.

Comportamento: Incialmente está um pouco confuso sobre o que deve realmente fazer um Tester
"Inimigos" favoritos: Testers séniores
Frase preferida: “Não percebo nada de testes, estou apenas a dar uma ajuda”
Notas: Um Drafter é normalmente alguém de outra equipa que integra a equipa de testes.
Por vezes, as equipas de gestão inserem estes elementos em equipas de testes porque pensam que todos podem efectuar testes de software. Outras vezes são inseridos apenas para ajudar.
Alguns deles têm a tendência a continuar a desempenhar funções de tester ao longo da sua carreira e percebem que tem essa aptidão.
Normalmente a aquisição de novos testers é feita através desta experiência.
A partir do momento em que o Drafter começa a defender como requisito fundamental do seu trabalho a qualidade de um sistema, e começa a levantar questões difíceis de resolver, passa a ser assumidamente um Tester.

------------------------------------
Texto original: Tester Types ( Rob Lambert)