Testar com poucos (ou nenhuns) Requisitos

Muitos testers são surpreendidos quando lhes pedem para testar aplicações informáticas sem que existam requisitos claros. Será possível não cair em pânico e sair desta situação de forma segura quando não se tem muita experiência? Muito dificilmente um tester recebe um documento completo e preciso de especificações funcionais. Em muitos casos estão definidos prazos de entregas iniciais, surgem mudanças repentinas de requisitos ou tarefas urgentes, faltam recursos humanos, e existem outros obstáculos que podem complicar o processo de testes. E mais frequentemente também surgem desentendimentos entre especialistas de diferentes áreas que podem ser resolvidos graças à intervenção do tester. Para ultrapassar estas situações, existem algumas dicas que podem ajudar os testers com menor experiência.

Primeiramente é necessário encontrar respostas claras para algumas questões genéricas:

• Vamos fazer testes unitários e/ou de sistema?
• Vamos fazer testes funcionais, de performance ou de regressão?
• Trata-se de um produto novo ou é um projecto de manutenção?
• Como é que os programadores entendem o sistema?
• Que outra documentação existe além de especificação funcional?
• Existe algum analista/especialista de negócio, ou um utilizador final disponível?
• Há componentes funcionais previamente definidas?
• Quais são as áreas de risco?
• Qual o nível de experiência da equipa de testes?
• Vão ser feitos testes manuais e/ou automáticos?

As respostas às questões anteriores revelarão possíveis formas de pôr em prática o processo de testes.

Quanto ao aspecto organizacional dos testes podemos considerar os seguintes aspectos:

• Identificar os pontos fortes da equipa de testes.
• Obter informações sobre as componentes técnicas desenvolvidas.
• Combinar ou separar módulos consoante o tipo de testes.
• Distribuir os módulos a testar de acordo com as competências e conhecimentos dos testers.
• Encorajar a comunicação constante entre a equipa de testes e programadores e analistas.
• Escolher uma abordagem de testes clara e objectiva, que não seja passível de diferentes leituras, para evitar erros de interpretação.
• Documentar os passos básicos nos detalhes do processo de teste, se houver pouco tempo disponível.

Com estes princípios em mente, podemos ainda tentar algumas abordagens alternativas para os testes. Podemos realizar testes exploratórios, em que testamos a aplicação de acordo com o nosso próprio método. E podemos fazer testes de aceitação (ou com utilizadores) envolvendo um utilizador desconhecido para perceber como são entendidos os requisitos e as funcionalidades básicas, e compreender a forma como os utilizadores interagem com a nova aplicação. Também se pode pedir aos utilizadores que escrevam pequenas histórias (descrições do negócio) que podem servir de base para o desenho de mais testes.

Em resumo, podemos dizer que, quaisquer que sejam as condições para testar software, devemos sempre pensar cuidadosamente e definir objectivos claros antes de começar.

----------------------
Traduzido e adaptado de: Testing In The Dark: How To Come Out Into The Light (Blog Hunteress)

Outros links sobre este assunto:

• Software Testing without Requirements: Survival Guide
• How To Test With Little To No Requirements
• Testing Without Requirements
• Testing Without Requirements or Specifications 
• Testing Without Requirements

It’s time to take software testing seriously

 

Image found here.

Serão os testers "programadores falhados"?

O desenvolvimento de software é um processo de certa forma sinuoso, que envolve a intervenção de diferentes pessoas. A interacção entre diferentes pessoas não promove apenas a aprendizagem colectiva como também ajuda a desenvolver as competências técnicas dos colaboradores. No entanto, uma maior interacção entre colaboradores também aumenta as hipóteses de conflito, algo comum em ambientes de trabalho. Developers e testers são duas classes de colaboradores cuja interacção pode levar a conflitos infindáveis devido a várias razões, tais como a diferenciação das funções profissionais, a experiência profissional e os atributos intelectuais.

A razão mais evidente é a parcialidade histórica em relação aos testers apelidados de cidadãos de segunda e programadores falhados. “Os testers são os licenciados em ciências computacionais que não sabem programar”, este hábito de considerar os testers como colaboradores inferiores é a causa de todo o problema. No entanto, estas considerações pertencem a uma corrente de pensamento ortodoxa e são como estereótipos, sem evidências práticas e suporte factual. Com tanto desenvolvimento e progresso no mundo do QA, a realidade é que os testers têm agora um papel mais exigente e desafiador no processo de desenvolvimento.

Após discutir com developers e testers, descobri que os “developers” foram postos num pedestal e glorificados por si mesmos e pelas chefias. Eles acreditam que o código que desenham está isento de bugs e daí se depreende um problema de ego.

Tomemo-lo desta forma: os developers são os médicos que trazem o bébé (software) à vida, e que os testers são as pessoas que dizem “que bebé tão feio”. Mas não é exactamente isso que os testers tentam fazer. Os testers estão lá para ajudar no parto do bébé e a ajudar para que ele cresça forte. No fim de contas, Desenvolvimento e Testes são dois lados da mesma moeda. Ambos se complementam e é nesse aspecto que ambos os lados necessitam de pôr o ego de lado e colaborar.

Testar é como o retrovisor para o desenvolvimento para que este não se distraia. Visto que os testers são responsáveis pela qualidade do software, estes certificam-se que o software é entregue em boa forma tanto para o utilizador final como para a empresa.

Ao longo dos anos, o papel do profissional dos testes/QA evoluiu para um patamar separado mas igual; os testers têm apenas um conjunto de competências diferentes embora valiosas. É necessária a evolução na cultura de muitas organizações para trabalhar com e tirar partido desta nova ordem demográfica. Para além disso, os testers também deveriam trabalhar não só na identificação de bugs, mas também na correcção de bugs menores. Apenas enviar de voltar os relatórios de bugs para o developer após correr os ciclos de testes e pedir-lhe para corrigir os bugs e repetir o mesmo processo só vai intensificar e agravar a situação.

Assim sendo, é imperativo para ambos trabalharem colectivamente num projecto com união, e não limitarem-se a atirar trabalho para cima do outro.

------------------------------------
Traduzido e adaptado por Pedro Sesinando de: Are Testers failed programmers?
 

What is the software testing job?

Mitos sobre Testes de Software

Mito nº 1: Testar é muito caro.

Realidade: Há um ditado que diz: pagar menos para testes durante o desenvolvimento de software ou pagar mais pela manutenção/correcção mais tarde. Antecipar os testes permite economizar tempo e custos em muitos aspectos. No entanto, reduzir custos sem testar pode provocar o desenho incorrecto de uma aplicação de software, tornando-a inútil.

Mito nº 2 : Testar é uma tarefa que consome muito tempo.

Realidade: Durante o ciclo de vida do desenvolvimento de software, a fase de testes raramente é um processo demorado. No entanto, diagnosticar e corrigir erros detectados durante os testes é um processo demorado, mas também muito produtivo.

Mito nº 3: Os testes só podem começar depois do produto estar totalmente desenvolvido.

Realidade: É verdade que os testes dependem do código fonte, mas a revisão de requisitos e desenho de casos de teste não depende do código desenvolvido. Num modelo de desenvolvimento iterativo ou incremental podemos reduzir a dependência em relação à conclusão do desenvolvimento de software.

Mito nº 4: Os testes exaustivos são possíveis.

Realidade: Isto torna-se um problema quando um cliente ou um tester acredita que é possível testar todos os pormenores de uma aplicação. É possível que todas as funcionalidades e opções tenham sido validades pela equipa de testes (ou do cliente), Mas nunca é possível realizar um teste exaustivo. Podem existir cenários que nunca são executados pela equipa de testes (ou o cliente) durante o desenvolvimento da aplicação e que surgem assim que a aplicação entra em produção.

Mito nº 5: Se o software foi testado, então não pode ter bugs.

Realidade: Este é um dos mitos mais comuns entre clientes e gestores de projecto. Ninguém pode afirmar com absoluta certeza que uma aplicação de software está 100% livre de bugs, mesmo que tenha sido testada por um tester com capacidades magníficas.

Mito nº 6: Os bugs que subsistem são culpa dos Testers.

Realidade: Não é correcto culpar os testers pelos erros que subsistem na aplicação após a execução dos testes. Esses bugs devem-se na maioria das vezes a prazos, custos, mudanças de requisitos e diversos constrangimentos. No entanto, a estratégia de testes também pode não ser a mais eficaz e haver erros que a equipa de testes não detecta.

Mito nº 7: Os Testers são os únicos responsáveis pela qualidade do produto.

Realidade: É uma atitude muito comum pensar que apenas os testers (ou a equipa de testes) são responsáveis pela qualidade do produto. As responsabilidades dos testers incluem a detecção de bugs para as outras equipas do projecto, e seguidamente são essas equipas que decidem se efectuam correcções ou se dão o software como concluído. 

Mito nº 8: Automatização de testes deve ser usada sempre que possível e permite reduzir o tempo.

Realidade: É verdade que a automatização de testes reduz o tempo de teste, mas não é possível iniciar a automação de teste em qualquer momento durante o desenvolvimento de software. A automatização de testes deve ser iniciada quando o software foi testado manualmente e apresenta alguma estabilidade. No entanto, a automatização de testes não pode ser utilizada se os requisitos estiverem sempre a mudar.

Mito nº 9: Qualquer pessoa pode testar software.

Realidade: Muita gente fora do mundo da TI pensa (e acredita!) que qualquer pessoa pode testar software e que testar não é um trabalho criativo. No entanto, os testers sabem muito bem que isso é um mito. Pensar cenários alternativos e tentar crashar o software com o objectivo de explorar possíveis erros não é possível para a pessoa que o desenvolveu.

Mito nº 10: A tarefa do tester é apenas detectar bugs.

Realidade: Detectar bugs no software é a tarefa dos testers, mas ao mesmo tempo eles são especialistas no domínio do software específico. Os programadores são responsáveis por componentes específicas ou áreas que lhes são atribuídas, mas os testers têm de compreender o funcionamento global do software, quais as suas dependências e quais os impactos de um módulo sobre outros.
--------------------------------
Traduzido e adaptado de: Software Testing Myths (TutorialsPoint) 
Ver também: Software Testing Myths (OJAS)

Um tester não é o lobo mau...

... é apenas alguém que contribui para que o software tenha mais qualidade.

Testes de Sistema: Onde, Quando e Como?

Quando usamos a expressão “Testes de Sistema” estamos a referir-nos aos testes a que sujeitamos um sistema de software ou uma aplicação como um todo. Os Testes de Sistema são realizados sobre a totalidade da aplicação para validar o seu comportamento global face aos requisitos do negócio e dos utilizadores finais. Os Testes de Sistema são classificados como “caixa preta”; por esse motivo, a informação relativa à arquitectura, desenho e código da aplicação não é relevante para este tipo de testes.

Geralmente, ao testar software um tester tende a distinguir os bugs detectados nos interfaces dos detectados nas componentes. Mas durante os Testes de Sistema, o foco da atenção é o desenho e o comportamento do software, assim como as expectativas do cliente. Por esse motivo há quem designe este tipo de testes como “testes globais” no ciclo de desenvolvimento de software.

Quando surgem os Testes de Sistema?

Quando todas as componentes estiverem desenvolvidas e instaladas, o sistema é testado na sua totalidade de forma a garantir que responde a todos os requisitos de negócio, funcionais e não-funcionais. Alguns dos Testes de Sistema podem ter por base testes unitários e testes de integração, mas são executados num ambiente semelhante ao ambiente de produção. Na maioria dos casos, existe uma equipa à parte que se dedica à execução dos testes de sistema

Porquê realizar Testes de Sistema:

• Esta é a primeira ocasião em que o sistema é testado como um todo.
• Pretende-se confirmar que se cumprem os requisitos de negócios, técnicos, funcionais e não funcionais do software. Assim confirma-se globalmente que a aplicação corresponde às expectativas de todos os intervenientes.
• Os testes de sistema são efectuados num ambiente muito semelhante ao ambiente de produção, onde a versão final será instalada.

Critérios para iniciar os Testes de Sistema:

1. Testes unitários estão concluídos;
2. Testes de integração estão concluídos;
3. Foi terminado o desenvolvimento de software;
4. Está preparado um ambiente de testes de sistema que simula com exactidão o ambiente de produção.

Teste de Sistema em sete etapas:

1. Desenvolver um plano de testes de sistema;
2. Desenvolver casos de teste do sistema;
3. Escolher ou criar dados para serem usados nos testes;
4. Se necessário, preceder à automatização dos testes de sistema;
5. Executar os casos de teste
6. Corrigir os erros detectados e executar testes de regressão;
7. Se necessário, realizar o ciclo de testes de software, se possível num ambiente diferente.

O conteúdo de um Plano de Testes de Sistema pode variar de empresa para empresa ou de projecto para projecto. Este Plano baseia-se na estratégia de testes e do plano de projecto. É importante ter presente que um Plano de Testes de Sistema deve incluir:

• Definição do âmbito;
• Objectivos e propósitos;
• Identificação das principais áreas (ou das áreas críticas);
• Definição dos entregáveis;
• Plano de Testes de Sistema;
• Calendário;
• Critérios de aceitação e conclusão;
• Atrasos e alterações de critérios de testes;
• Caracterização do ambiente de testes;
• Definição do processo de aceitação;
• Participantes e plano de formação;
• Funções e responsabilidades;
• Dicionário.

Como criar casos de Teste de Sistema: 
Os casos de Teste de Sistema são escritos da mesma forma que os casos de teste funcionais. Mas há dois aspectos a ter em conta quando escrevemos casos de Teste de Sistema:

1. Os CT’s de Sistema devem incluir use cases e cenários
2. Os CT’s de Sistema devem responder a todos os requisitos, sejam técnicos, de interface, funcionais, não-funcionais, de performance e outros.

Segundo a Wikipedia, existem dezenas de diferentes tipos de testes que podem ser realizados durante os Teste de Sistema. Entre eles encontramos: testes de Interface com utilizador, testes de usabilidade, testes de performance, testes de compatibilidade, testes de tratamento de erros, testes de carga, testes de stress, testes de ajuda ao utilizador, testes de segurança, testes de escalabilidade, testes de capacidade, testes exploratórios, testes de regressão, testes de fiabilidade, testes de recuperação, testes de instalação, testes de potência, teste de manutenção, testes Ad-hoc, testes de falha e recuperação e os testes de acessibilidade.

Cada Caso de Teste de Sistema deve ter:

• Um identificador único;
• Uma classificação interna do projecto;
• Um nome de Tester que será responsável pela sua execução;
• Identificação do(s) requisito(s) associado(s) ou breve descrição da funcionalidade a ser testada;
• Passos a seguir na execução do Teste;
• Resultado previsto para cada passo que é executado;
• Dados de entrada;
• Resultado final do Caso de Teste (Sucesso/ Falha);
• Revisão do teste.

-------------------------------------------
Traduzido e adaptado de: How To Accomplish System Testing?

Onde é que os Testers podem ir buscar informação?

Com frequência, os testers sentem necessidade de recolher diversas informações que possam completar (ou substituir) as especificações de um projecto. Existem diferentes fontes de informação nas diversas fases de um projecto. Vejamos a que fontes podemos recorrer.

Então, quais as fontes podem ser usadas antes que sejam feitas alterações no código?

1. Especificação. Os testes podem-se basear numa especificação, um ficheiro de texto com uma descrição do que precisa ser testado e os resultados que o sistema deve produzir.
2. Gestor de Projecto. Regra geral, um gestor de projecto define as tarefas dos analistas/programadores. É altamente desejável que essas tarefas sejam replicadas para os testers. Isto permite poupar tempo.
3. Aplicações semelhantes. Podemos usar os produtos dos principais fabricantes de software como padrões. Por exemplo, podemos assumir algumas funcionalidades do interface do MS Office como padrão para as aplicações que correm em ambiente Windows.
4. Conhecer e compreender os use-cases.Compreender e seleccionar as funcionalidades principais e secundárias: Perceber quais as funcionalidades mais importantes para o cliente, ajuda-nos a definir correctamente as prioridades dos teste.Comportamento esperado da aplicação: Saber para que tipo de utilizadores foi criada a aplicação, permite-nos desenhar um interface mais adequado, ou, pelo contrário, identificar as desvantagens da utilização da aplicação.

Quais as fontes que podemos usar após o desenvolvimento da aplicação?

1. Os programadores. Por vezes, os programadores têm dificuldades com a implementação de uma função. Se partilham essa informação com um tester, este será capaz de se concentrar na função “problema” e testá-la mais eficientemente
2. A própria aplicação. Quando falta alguma documentação e ninguém partilha informação, não temos outra escolha que não seja investigar a aplicação.
3. Release notes. As release notes são os comentários sobre cada versão que está a ser testada. As release notes ajudar a determinar a ordem de um teste. É lógico testar primeiramente as partes do programa que foram alteradas na versão mais recente.As release notes também nos ajudam a actualizar a documentação dos testes. Sabendo quais as partes da aplicação que foram alteradas, podemos actualizar os casos de teste de acordo com as alterações, logo após a sua conclusão.

Traduzido e adaptado de Where Can Testers Get Information?

GTAC 2011: The Latest in Google Test Tools

Software Testing as a Career

Lisboa, IBM Oriente - IBM Rational: WorkShop Técnico - IBM Rational Functional Tester & Rational Perfomance Tester

Dia 28 de Maio está agendado um workshop técnico em IBM Rational nas componentes de testes funcionais e de testes de rendimento. 

• http://www.linkedin.com/groups/28-Maio-Lisboa-IBM-Oriente-4106471.S.240227700?qid=aefeb5cc-22a0-4780-b887-37fc320ee195&trk=group_most_recent_rich-0-b-ttl&goback=%2Egmr_4106471

A capacidade está limitada a 16 pessoas com recurso a 8 computadores pessoais.

A agenda será composta por:

Rational Functional Tester:

• Introduce the participants to Rational Functional Tester
• Demonstrate how automated testing can decrease test times and increase coverage
• Use the Functional tester recorder to create new scripts and enhance existing scripts
• Use data-driven wizard to cover multiple scenarios with a single script

Rational Performance Tester:

• Record and enhance automated tests
• Manage data for dynamic tests
• Create schedules to model workloads
• Execute and monitor tests
• Analyze and report on test results

Audiencia:

• Quality&Test Managers
• Application Development Managers

Contacto para inscrição e pre-registo: Rui.Garcia.Santos@pt.ibm.com

Enviar:

• Nome
• Mail 
• Telefone directo

Software error could affect some civilian paychecks

Payroll officials at the Department of Defense say a software glitch is to blame for miscalculated retirement and Social Security deductions in some upcoming civilian paychecks.

The Defense Finance and Accounting Service reported that paychecks for the pay period ending May 4 might be off for some employees due to an error in newly installed software for its Defense Civilian Pay System, according to an email from the Civilian Human Resources Agency.

The error inserted 2012 year-to-date contribution totals for retirement programs like the Thrift Savings Plan and the Roth TSP, as well as Social Security, in place of 2013 numbers, meaning some accounts were shown to have hit their contribution limits early.

Those affected will see lower retirement contributions in paychecks arriving this week or no contributions at all. Their Social Security deduction, or OASDI, could be higher.

-----------------------------
Fonte: Stars and Stripes. Notícia completa aqui.

Cinco Dicas para apanhar bugs!

Cada tester tenta detectar o maior número possível de erros. Dessa forma contribui para proteger a empresa/instituição de prejuízos financeiros adicionais e riscos. Seguidamente descrevem-se cinco dicas que podem ajudar um tester nas suas tarefas.

1. Por vezes é útil para quebrar as regras!

Executar apenas casos de teste pré-definidos pode levar um tester a não detectar erros, deixando-o mais longe de fornecer um produto que seja 100% livre de bugs. Se um tester segue apenas os casos de teste pré-definidos, corre o risco de fechar os olhos para outros erros. O primeiro segredo é verificar a funcionalidade que estamos a testar. Será uma maneira eficaz de descobrir mais bugs porque nem todos os aspectos da funcionalidade estão geralmente cobertos por casos de teste.

2. Examinar os padrões!

A maioria dos testers já percebeu que os bugs podem ser muitas vezes surgir em grupos; são os chamados bugs gregários. Ao testar uma nova – mas semelhante - funcionalidade, devemos analisar as ideias e as decisões anteriores sobre testes anteriores. É também um bom conselho para anotar as suas ideias que já lhe ajudaram na detecção e correcção dos erros.

3. Cercar o Bug!

Não tenha pressa para registar o bug encontrado num qualquer relatório. Isso pode ser apenas o princípio! Um erro pode indicar que o software tem uma “ponta solta”. Enquanto o sistema estiver instável, a sua tarefa testá-lo até ao limite. Alimentando-o com um grande número de dados disparatados, despejando dados em catadupa nos seus inputs, e reduzindo os recursos do sistema, poderá rapidamente permitir detectar antecipadamente a presença de outros bugs.

4. Preste atenção ao seu pressentimento sobre erros!

Antes de se manifestarem os bugs podem anunciar a sua presença! São como insectos cujo som de fundo indica a sua proximidade crescente. Por esse motivo, devemos ter os sentidos alerta para podermos apanhá-los a qualquer momento. Dessa forma, um tester deve ler as mensagens de aviso, logs de erros, etc, que não são exibidos num ecrã por qualquer motivo, mas podem indiciar a presença de bugs.

5. Duas cabeças pensam melhor do que uma!

Apesar de um tester poder ter muitas ideias, no entanto, pode haver situações em que não conseguimos detectar o bug. Este é o momento em que devemos pedir ajuda aos nossos colegas. Testar juntos ao mesmo tempo permite gerar novas ideias sobre os testes. Outra vantagem do teste em grupo é que você trabalha mais intensamente com o sentimento de "estar a ser observado". Mas a colaboração que dura por muito tempo pode levar a visão de túnel.

Existem, portanto, alguns segredos nos ajudam enquanto caçamos bugs. Experimentem-nos e depois, vejam se conseguem detectar ainda mais bugs do que anteriormente.

--------------
Traduzido e adaptado de : 5 Tips On How To Hunt For Bugs Successfully

Testes de Regressão

GTAC 2008 Keynote Address: The Future of Testing

Os cinco livros fundamentais sobre Software Testing

​Todas as pessoas envolvidas em testes de software e Quality Assurance sabem que se pode ter as competências perfeitas; cada dia de trabalho é um momento de aprendizagem. Alguns testers gostam de ir a diferentes conferências, com o objetivo de conhecer novas experiências; outros gostam de assistir a cursos de vídeo; mas o método mais popular - diria, clássico - continua a ser a leitura. Por esse motivo sugerimos cinco livros fundamentais sobre testing.

Lessons Learned in Software Testing, por Cem Kaner, James Bach, e Bret Pettichord

Este é o melhor livro para obter conhecimentos práticos. Os autores apresentam cerca de 300 lições, que abrangem uma grande variedade de questões. Todas estas questões podem ser interessantes para um tester de qualquer nível. Este livro também pode ser uma espécie de catálogo para uma equipa de testes, pois contém uma enorme diversidade de casos práticos.

How We Test Software at Microsoft, por Alan Page, Ken Johnston, e Bj Rollison

Este é um livro útil que apresenta uma vasta gama de reflexões sobre testes de software na Microsoft, incluindo em explicações detalhadas de casos práticos. Quer seja um profissional experiente ou novato, este livro tem sempre algo de novo. Cópias deste livro em PDF encontram-se com facilidade em alguns sites.

Perfect Software: And Other Illusions about Testing, por Gerald M. Weinberg

Esta é uma visão genérica e abrangente sobre algumas das principais questões ligadas ao testing: “Porque é que temos de testar tudo?” ou “Porque é que os testes conseguem ser tão complicados?” O livro é pequeno (200 páginas) e de leitura rápida. Este livro não aborda o lado prático dos testes, mas antes o “porquê” dos testes. Ideal para principiantes.

The Art of Software Testing, por Glenford J. Myers

Este é também um livro ideal como “primeira leitura de um tester”. Algumas das situações descritas já estão desactualizadas, mas não isso não o torna menos interessante. É difícil encontrar um exemplar deste livro hoje em dia, mas na internet conseguem-se encontrar cópias em PDF.

High Performance Web Sites: Essential Knowledge for Front-End Engineers, por Steve Souders

O livro é rápido para leitura e contém uma grande diversidade de conselhos úteis e respostas. Alguns destes já são aplicados por muitas empresas. Em geral, este é um livro interessante para quem tem de fazer testes num website. E quem já leu isto tudo? Bem, para esses sugiro que comparem os conteúdos destes livros com a realidade do trabalho em que estão envolvidos. E dêem o vosso feedback!

--------------------------------------
Traduzido e adaptado de: Top 5 Software Testing Books To Read

Caminhos diferentes... objectivos comuns!

Quantifying the Value of Testing

Bugs que ficaram famosos recentemente ​

Porque a nossa actividade é detectar falhas no software, aqui fica o registo de algumas falhas que ficaram famosas em tempos recentes.

Bug na Estação Espacial Internacional

Uma equipa da NASA que pretendia testar o reabastecimento e reparação automática de satélites viu a sua missão adiada devido a um erro no software que controla o braço robotizado da Estação Espacial. O reabastecimento de reparação automático de satélites poderá prolongar a vida destes engenhos e poupar milhares de milhões de Euros aos operadores. Esta tecnologia poderá ainda ser útil na recolha de lixo espacial. A missão só foi iniciada 10 dias após a data prevista, após correcções e testes exaustivos que garantiram que o software em causa não tinha qualquer problema.

Para mais informações: Software error holds up International Space Station experiment

Falha de segurança nos iPhones

Em 15 de Fevereiro a Apple confirmou que um bug no seu software iOS permite que utilizadores não autorizados acedam a voice emails, fotos e contactos dos iPhones. A empresa afirmou estar trabalhar para corrigir o problema.

Para mais informações: Apple Software Bug Allows Unathorised Access to Locked IPhones

Erros de Software provocam interrupções em diferentes Bolsa Mundiais

Nas últimas semanas, as bolsas de valores de Mumbai, na Índia, e de Osaka, no Japão, foram afectadas por erros de software. Em Mumbai, as acções da Tata Motors (propriedade da Jaguar e da Land Rover) caíram 10% ; outras empresas também sofreram perdas significativas. Em Osaka, foi a Bolsa de Derivados que viu as transacções suspensas durante 95 minutos. O sistema teve de ser reinicializado e foi aberta uma investigação para averiguar as causas do problema. Recorde-se que ao longo dos últimos meses várias Bolsas têm sofrido problemas devido a falhas de software. Em Novembro registou-se um problema em Estocolmo que levou à suspensão de todas as transacções durante algumas horas; e em Setembro foi a Bolsa Nacional da Índia que viu as transacções interrompidas durante alguns minutos.

Para mais informações:
Software error causes unexpected drops in Mumbai stock prices
Japanese Derivatives Halted After Osaka System Crashes

Software failure grounds hundreds of flights

Why banks are likely to face more software glitches in 2013

The core of the problem is that the business software used by the institutions has become horrifically complex, according to Lev Lesokhin, strategy chief at New York-based software analysis firm Cast.

He says developers are good at building new functions, but bad at ensuring nothing goes wrong when the new software is added to the existing mix.

"Modern computer systems are so complicated you would need to perform more tests than there are stars in the sky to be 100% sure there were no problems in the system," he explains.

"Business software is becoming increasingly complex, composed of sub-systems written in different programming languages, on different machines by disparate teams.

"This means no single person, or even group of people, can ever fully understand the structure under the key business transactions in an enterprise. Testing alone is no longer a viable option to ensure dependable systems."

Mr Lesokhin adds the West's banking system is particularly exposed because it was the first to install computer systems and much of the sector was badly wounded by the credit crunch's knock-on effects.

Decades of bolt-on code has made banking systems complicated to comprehend. "Tough financial times mean a squeeze on budgets and less effort spent on modernisation and quality assurance," he says.

(...) Artigo completo aqui.

O primeiro tester que conheci...

... estava num livro do Astérix. Era o provador oficial da rainha Cleópatra.