Automação Web

Existem vários aplicativos para efectuar scipting de modo a automatizar as acções sobre um página web. Cada um deles com vários pontes fortes e com as suas falhas. Neste post vou abordar um “utilitário” que tenho usado nos últimos tempos com bastante frequência.

O watin pode ser obtido gratuitamente por enquanto a partir daqui Watin Homepage.

Efectuando o download da aplicação criamos um projecto no Visual C# Express Edition.

1. Criar projecto no Visual C# Express Edition

Para isto basta aceder ao C# Express Edition e criar um novo projecto. Um projecto do tipo “Console Application” serve perfeitamente o propósito aqui pretendido.

2. Efectuar o import da(s) bibliotecas existentes.

Extrair as dlls obtidas a partir do download do watin efectuado e adicionar as mesmas a uma sub pasta do projecto. Após esta operação importar como referência para o projecto. Esta operação pode ser efectuada acedendo ao menu de contexto das referências do projecto e adicionar uma nova referência. Para este exemplo em concreto basta adicionar a dll watin.core.dll.

3. Criar o script de automação

A partir deste momento temos o projecto pronto para arrancarmos com a codificação.

Adicionando um

   1:  using Watin.Core;

ao parte das referências da aplicação.

De seguida, e como este post funcionará apenas como um “Hello World” do watin apenas se irá aceder á página da google e pesquisar pelo blogue.

   1:  FireFox ff = new FireFox(http://www.google.com);

   2:  ff.TextField(Find.ByName(“f”)).TypeText(“http://softwareattest.blogspot.com/”)

   3:  ff.Button(Find.ByName(“q”)).Click();

A api desta aplicação pode ser consultada a partir da página da aplicação que pode ser consultada aqui.

A medida que for experimentando mais detalhes sobre esta api, vou publicando os aspectos importantes dessa experiência(s).

Bom, até à próxima.

State Transition Testing

Os testes de caixa preta são casos de testes construídos tendo como base as especificações e funcionalidades do software. Estes testes usam as descrições externas do software, incluindo especificações, requisitos e design para elaborar casos de teste. O tester selecciona entradas válidos e inválidos e determina a saída correcta. Neste tipo de testes não existe qualquer conhecimento da estrutura interna do objecto de teste.

Se é necessário executar um número infinito de testes então é necessário transformar esta infinidade numa quantidade adequada de trabalho. As técnicas de teste de software existem para reduzir o número de testes a ser executados, enquanto fornecem uma cobertura suficiente do sistema em análise.

State Transition Testing

A maioria dos sistemas nos quais é necessário efectuar testes, possuem um número demasiado grande, ou mesmo infinito de possíveis situações de teste. Por exemplo, apesar do facto de que um telemóvel possuir um número finito de funções, a utilização destas funções podem ser combinadas num número infinito de possibilidades. Este testes são usados quando o sistema, ou uma parte do sistema pode ser descrito como um diagrama de estados. Estes testes podem ser construídos para cobrir uma sequência típica de estados, cobrir todos os estados, verificar todas as transições, uma sequência especifica de transições ou testar transições inválidas.

Sendo assim temos de pegar num sistema e transforma-lo num diagrama de estados.

Desenhar o diagrama de estados associado ao objecto em testes

Um diagrama de estados é composto por estados e transições. Cada estado é geralmente representado por um circulo, e a transição por uma seta.

Mais informação sobre a construção de diagramas de transição de estados ver: (http://en.wikipedia.org/wiki/State_transition_table)

Determinar os estados iniciais, as entradas permitidas e os resultados esperados assim como os resultados finais

Depois de desenhado o diagrama há que determinar os estados iniciais (tipicamente pontos de entrada do caso em teste) e os estados finais (tipicamente os pontos de saída).

Determinar o nível de cobertura que se pretende alcançar

Existe uma série de modos diferentes de medir a cobertura quando usando testes por transição de estados. Num desses modos, a cobertura pode ser medida pelo número de sequências de transições. Esta medição é conhecida como “(n-1) switch”. N-Switch coverage representa a percentagem de sequencias de N-transições que são avaliadas por uma suite de testes. Os níveis de cobertura mais usado é o “0-Switch coverage” que define que é testado uma transição.

Desenhar a árvore de testes

A partir de uma tabela de transição de estados podemos definir um conjunto de casos de testes mínimos. Para tal devemos começar por colocar os estados iniciais como raiz da árvore e colocar todas as transições válidas para cada um destes estados. Repetir o passo anterior e colocar as transições válidas para cada um destes novos estdos. Repetiro processo até que não existam mais transições válidas. Não devem ser repetidas transições.

Definir os testes

Para determinar qual o conjunto de testes a executar deve-se pegar em todos os caminhos possíveis na árvore. Cada um destes caminhos dá origem a um caso de teste.

Exemplo

Um exemplo prático onde esta técnica pode ser aplicada é um típico workflow da gestão de defeitos. Pegando então nesse workflow temos o seguinte: (Obs: Por motivos de simplificação dos diagramas estão omitidas na análise as transições para o próprio estado)

Tabela de Transições de estado

De seguida apresenta-se a tabela com as transições válidas no workflow definido pela imagem acima.

	Open	Fixed	ReOpen	Answer Only	Rejected	Closed
Open		X			X
Fixed			X			X
ReOpen		X			X
AnswerOnly
Rejected			X	X
Closed

A partir de uma tabela de transições de estados ou de um diagrama desenhamos então uma árvore, que nos ajudará a identificar os casos de teste necessários.

A partir desta árvore identificam-se claramente cinco casos de teste para testar o workflow de gestão de defeitos que correspondem às seguintes sequências:

• Open –> Fixed –> Closed;
• Open –> Fixed –> Reopen-> Fixed;
• Open –> Fixed –> Reopen->Rejected;
• Open –> Rejected –> Answer Only;
• Open –> Rejected –> Reopen;

Obviamente estas não correspondem a todas as possíveis combinações para a edição de um defeito. Mas é garantido que neste conjunto de casos de testes todas as transições são executadas e todos os estados estão cobertos. Muito mais poderia ser escrito sobre o tema mas penso que fica cá resumido o essencial.

 

Bom, até à próxima.

Técnicas de Desenho de Testes

As técnicas de desenho de testes são o coração dos testes. Existem inúmeras vantagens em se usar técnicas de desenho de testes, entre as quais se destacam:

• Suporte para o trabalho sistemático torna a especificação de testes mais eficiente.
• O desenho dos casos de teste pode facilmente ser repetido por outros.
• Quando utilizadas é possível determinar as coberturas associadas a uma especificação.

Durante a fase de desenho e planeamento de testes, facilmente percebemos que as combinações, variações dos dados a usar nos testes e que podem ser usados como entrada para os casos de testes podem ser infinitas. Daqui rapidamente se concluí que testar exaustivamente cada caso não é possível, é necessário então usar técnicas de teste que permitam diminuir o número de casos e cenários de teste, permitindo a maior cobertura de testes com um esforço mínimo. Na elaboração deste testes é importante compreender as várias técnicas de desenho de testes disponíveis.

Se é necessário executar um número infinito de testes então é necessário transformar esta infinidade numa quantidade adequada de trabalho. As técnicas de teste de software existem para reduzir o número de testes a ser executados, enquanto fornecem uma cobertura suficiente do sistema em análise.

A utilização de várias técnicas de testes em simultâneo num mesmo projecto ou esforço de testes têm provado ser mais eficaz de que nos concentramos apenas numa técnica.

Black Box Testing

Caixa preta e caixa-branca são os métodos mais conhecidos de desenho de testes. Os testes de caixa preta tratam o sistema como uma “caixa preta”, e por isso não usam explicitamente o conhecimento da estrutura interna.

Os testes de caixa preta são casos de testes construídos tendo como base as especificações e funcionalidades do software. Estes testes usam as descrições externas do software, incluindo especificações, requisitos e design para elaborar casos de teste. O tester selecciona entradas válidos e inválidos e determina a saída correcta. Neste tipo de testes não existe qualquer conhecimento da estrutura interna do objecto de teste.

Entre as numerosas técnicas de testes disponíveis as mais conceituadas e que melhores resultados têm produzido encontram-se as seguintes: análise funcional, equivalence partitioning, path anlysis, orthogonal array testing e state transition testing.

White Box Testing

Os testes de caixa branca são de uma natureza diferente dos testes caixa preta. No teste de caixa preta, o foco das actividades é apenas sobre a funcionalidade do sistema e não no que está acontecendo dentro do sistema.  Por outro lado os objectivos de testes de caixa branca é ter certeza de que a funcionalidade é adequada, usando para tal informação sobre o desenho e implementação destas funcionalidades para elaborar os testes. Os testes de caixa branca são essencialmente efectuados pelas equipas de desenvolvimento, geralmente a partir da criação de testes unitários.

Uma das características dos testes de caixa branca é que permitem avaliar qual a cobertura do código que estamos a analisar. Existem várias possibilidades para verificar a cobertura que pode ser medida aquando do uso de testes de caixa-branca, entre os quais se destacam: Statement coverage, Function coverage, Decision coverage  e Data-Flow Coverage.

Bom espero ter esclarecido quais as principais (pelo menos) diferenças entre Black Box e White Box Testing.

 

Bom, até à próxima.

Entre a execução manual e a automática

Automação de testes é o uso de aplicações de software, scripts e/ou outros aplicativos de modo a  controlar a execução dos testes. Estes permitem a comparação dos resultados reais com os resultados previstos. Normalmente  usa-se  a automação de testes com o objectivo de automatizar um processo manual já existente de modo a eliminar que tarefas repetitivas e aborrecidas sejam feitas por humanos. 

Testes com execuções Manuais

O Tester tem a necessidade de executar todas as etapas do teste de modo manual e informar o sistema do resultado obtido. Existem várias ferramentas para gestão de testes que incluem uma interface gráfico que permite aligeirar a tarefa de cada utilizador.

Algumas vantagens de efectuar testes manuais são:

• O teste manual é preferível para produtos com ciclos de vida curtos.
• O teste manual é preferível para os produtos que possuem interfaces gráficas que mudam constantemente.
• Requerem menos tempo e dinheiro para começar o teste manual produtivo, i.e., têm um retorno mais rápido.
• A automação não consegue substituir a intuição e o raciocínio humano.
• Com um teste automatizado não é possível mudar de rumo no meio de um teste para examinar algo que anteriormente não haviam sido considerado, ou um qualquer pormenor estranho que não faz parte do plano original.

Testes Automáticos

Existem inúmeros modos se implementar inúmeros testes automatizados. Para tal é necessário que a ferramenta de gestão de testes seja compatível com os próprios testes. Para isso, as ferramentas de gestão de testes podem propor estruturas de automação de propriedades ou APIs para interface com terceiros. De modo a que o utilizador consiga cumprir o objectivo pretendido.

Benefícios da Automação de Testes

• Fiabilidade – O teste efectua exactamente a mesma operação cada vez que é executado.
• Velocidade – Sendo o processo automático não é necessária a presença humana para a sua execução, pelo que esta pode ser desviada para outras tarefas acelerando assim o processo. Além disso ferramentas automáticas tendem a executar mais rapidamente do que humanos.
• Reutilização – O teste pode ser utilizado inúmeras vezes entre diferentes versões do software.
• Melhor Qualidade do Software – Como é possível correr mais testes com o mesmo conjunto de recurso o que irá levar a um aumento da cobertura do software e a uma consequente melhoria da qualidade do software.

Contras da Automação de Testes

Embora a automação de testes traga muitas vantagens, a mesma também possui um conjunto de desvantagens. Algumas das desvantagens são:

• È necessária bastante proficiência para se criar scripts automatizados, pois estes por norma exigem bons conhecimentos de programação assim como do domínio da aplicação.
• A correcção do script de teste é algo também bastante importante e que pode ser uma fonte de dores de cabeça. Com a automação começam a surgir problemas de termos testes falhados não porque o comportamento da aplicação está incorrecto mas porque o script foi mal codificado. Por outro lado também podemos ter situações de falsos positivos. Automatizar é na prática escrever código para ser executado que está, obviamente, sujeito a erros tal como o código desenvolvido e alvo de testes.
• Testes a interfaces gráficos podem se tornar bastante caros. Porque uma pequena mudança no interface da aplicação irá obrigar à correcção do script de teste.
• A gestão de dados de testes torna-se complexa quando se possui um modelo de dados em “constante movimento”.

Linhas de Guia para a construção de testes automatizados

Cada requisito especificado é passível de ser automatizado. Idealmente todos os testes poderiam ser automatizados. Seria muito bom ter sempre tudo automatizado, mas infelizmente a automação é processo lento e complexo e pondo, para cada caso, em cima da mesa a relação custo/benefício de automatizar um caso de teste rapidamente chegamos à conclusão que existem inúmeros testes que ficam muito mais caros se forem automatizados do que corridos manualmente. Isto porque a automação desse caso pode ser complexa ou demorada, ou porque apenas precisamos de correr o teste uma vez, ou ainda porque o interface da aplicação vai sofrer alterações na distribuição seguinte. Sendo assim deixo alguns critérios para ajudar a escolher de forma mais adequada quais os testes a automatizar.

As seguintes áreas devem ser automatizados em primeiro lugar:

• Tarefas repetitivas e redundantes que são aborrecidas e que tendem a causar erros humanos com facilidade.
• Partes mais estáveis da aplicação. Não vale a pena automatizar partes que sabemos que vão ser modificadas um pouco depois.
• Funcionalidades mais críticas. Estando estas funcionalidades automatizadas é possível correr estes testes mais vezes.

A criação de testes automatizados deve seguir, sempre que possível, o seguinte conjunto de critérios:

• Conciso – Deve ser o mais simples quanto possível e não mais simples.
• Auto-Verificação – Efectua a verificação dos seus próprios resultados de teste sem a necessidade de intervenção humana.
• Repetitivo - O teste têm de poder ser executado várias vezes.
• Robusto – Várias execuções do mesmo teste devem devolver o mesmo resultado, desde que as condições do software se mantêm as mesmas.
• Claro – Cada instrução do script deve ter um objectivo fácil de entender.
• Específico – Cada teste deve efectuar uma verificação a uma funcionalidade específica do software.
• Independente - Cada teste deve correr individualmente ou como parte de uma suite mais alargada com uma ordem de execução arbitrária.
• Sustentável - Os testes devem ser fáceis de compreender, de modificar e melhorar.
• Rastreáveis – Deve ser possível ligar cada teste aos requisito e ao código coberto.

Alguns critérios para decidir se um teste deve ou não ser automatizado:

• Quantidade de vezes que se pretende executar o teste.
• Complexidade necessário para automatizar o teste.
• Importância da função alvo de teste.

Observações:

• Se a empresa ou instituição nunca teve qualquer tipo de processo de testes até ao momento, não será recomendável partir logo para a automação. Os resultados obtidos provavelmente não iram ser os melhores o que pode levar a frustrações e a conclusões erradas de que um processo de testes não trás vantagens.

Bom, até à próxima.

Processo de Testes

Um processo de testes deve, pelo menos, incluir as seguintes actividades:

• Planeamento dos testes – O planeamento dos teste é a actividade que define e verifica missão do teste, especificando os objectivos do teste e definindo as actividades a realizar a fim cumprir a missão. O planeamento pode ser documentado num plano de testes. Neste documento é definida a abordagem utilizada assim como os critérios de saída para os testes (Conjunto de critérios que nos possibilitam saber quando parar de testar, cobertura de requisitos é muitas das vezes usadas para este efeito). Nesta fase efectua-se uma estimativa do tempo de trabalho necessário.
• Análise e Desenho - A análise e o desenho de um plano de testes é a actividade onde os objectivos gerais do teste são transformados em condições e em situações de teste reais. È aqui que se identifica o que pode ser testado é o que não pode, que se prepara o ambiente de testes, e se efectua uma análise dos requisitos e documentação existentes.
• Implementação e execução - A implementação e a execução de casos de teste são uma actividade onde os procedimentos de teste são especificados combinando as situações de teste em uma ordem particular, incluindo também a informação necessária para a execução do teste. Aqui o ambiente de testes está pronto e testes são executados. Esta é uma fase em que se faz o desenvolvimento dos casos de teste, se verifica que os ambientes de teste estão funcionais e se dá inicio à execução dos testes, efectuando o registo de situações que não correspondam ao previsto. 
• Avaliação de Critérios de saída e relatórios – Quando são iniciados um conjuntos de testes deve existir sempre pré-definido qual o critério que definirá quando deveremos parar. Estes critérios podem passar por objectivos como: A cobertura de requisitos deve ser superior a 80%. Não podem ser encontrados mais de 2 defeitos muito graves e os menos graves têm de ser inferiores a 20.
• Actividades de fecho – Depois de concluída a execução de um plano de teste é necessário passar o conhecimento adquirido para os restantes elementos da equipa. Podendo deste modo a gestão decidir ajuizadamente sobre o lançamento de uma nova versão de software ou não. E também para permitir à equipa de desenvolvimento perceber o que correu mal de modo a corrigir os problemas encontrados.

Obviamente, estas não são as únicas actividades que devem existir, mas são o conjunto de actividades que não podem deixar de existir, sob pena de se começar a perder alguma credibilidade no processo em causa.

 

Bom, até à próxima.

Princípios de Teste

Os testes têm como objectivo de encontrar erros e não as suas razões. Portanto, a actividade de teste não inclui nenhuma correcção de bugs ou implementação de funcionalidades. Um tester não deve modificar o código que está a testar, sob circunstância alguma! Isso tem que ser feito pela equipa de desenvolvimento com base nos relatórios de testes que vão sendo executados. Para qualquer tester existe um conjunto de características que se deve ter sempre em atenção, características essas indicadas a seguir.

• Testes revelam a presença de defeitos – O teste pode mostrar que um produto falha, isto é, que existem alguns defeitos, mas não consegue provar que o software não possui defeitos. Um conjunto de testes apropriados reduzem a probabilidade que defeitos escondidos subsistam no software e transitem para o cliente. Mesmo quando nenhuma falha é encontrada durante o processo de testes, isto não é uma prova que não há nenhum defeito.
• Testar exaustivamente é impossível  - Um teste exaustivo onde se avaliem todas as possibilidades, todas as entradas e suas combinações de modo a verificar o seu correcto funcionamento seria impossível. Na prática testar a totalidade do software, exigiria um número elevado de situações de teste, para o qual necessitaríamos de muito tempo o que a maioria dos projectos não dispõe. Por este motivo cada plano de testes contém apenas uma amostra das possibilidades existentes. O esforço de testar deve, consequentemente, ser controlado tendo em consideração o risco e as prioridades de cada funcionalidade.
• As actividades de teste devem começar tão cedo quanto possível - As actividades de teste devem começar o mais cedo, quanto possível, no ciclo de vida de software e devem centrar-se sobre os objectivos definidos.  Uma abordagem deste tipo contribui em muito para que se possam encontrar defeitos mais cedo no ciclo de vida do desenvolvimento. Estes devem começar logo no momento em que os requisitos estejam estáveis, de modo a identificar problemas na elaboração destes antes ainda de se efectuar o design e implementação dos mesmos. Geralmente quando se encontra um defeito numa aplicação que pode ser rastreado até um requisito, a sua correcção acaba maioritariamente por dar origem a mais problemas.
• Aglomeração de defeitos - Frequentemente, a maioria de defeitos são encontrados apenas em algumas partes do objecto de teste. Os defeitos não são distribuídos uniformemente, assim se vários defeitos são detectados no mesmo local, geralmente existem mais defeitos por perto. Estas situações geralmente acontecem quando existem algoritmos de alguma complexidade a implementar ou em áreas cuja especificação não foi clara o suficiente, ou mesmo desenvolvimentos feitos por pessoas ainda inexperientes.
• O Paradoxo do Pesticida - Quando os mesmos testes são repetidos, vezes sem conta, tendem a reduzir a sua eficácia. Os defeitos previamente não detectados não são descobertos com novas execuções do mesmo teste. Assim, a fim manter a eficácia dos testes e lutar este paradoxo situações novas de teste devem ser desenvolvidas. As partes do software que não foram testadas até aqui, ou as combinações que ainda não tenham sido utilizadas serão executadas então, e um novo conjunto de defeitos pode ser encontrado.
• Os Testes são dependentes do contexto - O teste deve ser adaptado aos riscos inerentes no uso e no ambiente da aplicação. Consequentemente, dois sistemas diferentes não devem ser testados exactamente da mesma maneira. Para cada sistema de software os critérios da saída do teste, o conjunto de testes a efectuar, o tipo de testes a efectuar ou mesmo o tempo a dispensar. Devem ser decididos individualmente, dependendo de seu ambiente de uso. Os sistemas críticos como software de gestão bancária, ou controlo do suporte de vida numa urgência hospitalar exigem diferenças na maturidade dos testes em relação a por exemplo aplicações do comércio electrónico. Geralmente aplicações criticas obrigam a um período de testes muito mais alargado e rigoroso.
• Falácia de não encontrar erros - Encontrar falhas e corrigir defeitos não garante que o sistema desenvolvido vá de encontro ao conjunto de expectativas e necessidades do utilizador. A aplicação pode efectuar o que é pedido mas ser demasiado lenta, possuir uma usabilidade fraca. Aqui a participação adiantada dos utilizadores das aplicações no processo de desenvolvimento e no uso dos protótipos desenvolvidos são medidas preventivas que ajudam a evitar este tipo de problemas. Pelo que geralmente não chega verificar apenas o que é escrito no requisito. Por exemplo ninguém está à espera que uma página web demore cinco minutos a carregar, não faz sentido. Esta situação é claramente um problema, mesmo que não exista explicitamente um requisito que o indique. Aqui os testes aos requisitos criados até poderiam estar todos bem mas existiria claramente um problema de performance.

O facto de se possuir sempre estes princípios em mente (entre muitos outros existentes), irá levar a melhorias na eficácia de uma equipa de testes.

 

Bom, até à próxima.

A importância dos testes de software

 

A tarefa de efectuar testes ao software construído foi considerado secundário durante várias décadas. Era, e em alguns casos ainda continua a ser, uma actividade vista como um castigo para o programador, uma tarefa pouco importante e desnecessária. Assumia-se muito que os programadores não falhavam e que não podiam falhar. Pelo que este foi um tema descuidado durante muitos anos.

Durante largos anos foram surgindo erros graves que causaram prejuízos para a empresa fornecedora ou utilizadora do software. Os elevados custos de manutenção e suporte, à medida que as aplicações aumentavam de complexidade, entre outros aspectos. Levaram a que se começasse a perceber a importância dos testes. Assim com o decorrer dos anos começaram a aparecer bastante documentação sobre o tema, assim com a existência de normas, como são os casos por exemplo, da IEEE 829 e da ISO/IEC 29119.

O que são testes e quais os seus objectivos

Testes  de software são uma investigação conduzida de modo a fornecer aos stakeholders informação acerca da qualidade do projecto ou do serviço em teste.

Testes de software também pode ser considerado o processo de verificar e validar se o produto ou serviço disponibilizado:

• Cumpre os requisitos de negócio e os requisitos técnicos existentes.
• Funciona de acordo com o esperado. 

Assim associado a missão de efectuar testes podem-se encontrar os seguintes objectivos.

• Encontrar defeitos.
• Para assegurar que os requisitos são compridos e se servem o propósito para que foram desenhados.
• Para ganhar confiança no software construído.
• Para garantir que questões legais e de comprimento de standards são cumpridas.

Os defeitos podem ocorrer porque os seres humanos são falíveis, porque na maioria das vezes existe uma pressão de cumprir com o projecto dentro do prazo previsto. Além de erros provocados por humanos outras circunstâncias podem gerar erros na decorrer normal de uma aplicação. Condições ambientes como radiação, campos electromagnéticos podem provocar falhas que levam a um funcionamento incorrecto do software.

Existem vários motivos que levam a que se cometam erros, entre os quais de destacam

• As pessoas não são perfeitas e como tal cometem erros.
• As pessoas estão constantemente sobre a pressão do tempo.
• Os sistemas em que se trabalha são em geral complexos, assim como os requisitos a construir.
• As tecnologias nas quais se trabalha são sempre bastante recentes e os utilizadores possuem ainda pouca experiência a trabalhar com a mesma.
• A existência de falhas nos ambientes onde é executado o software.

O software criado nem sempre funciona como deveria, ou como nós pensávamos que deveria. Com relativa facilidade encontramos resultados inesperados ou errados. Por outro lado podemos não ter a funcionalidade desejada. Quando o software falha podemos perder dinheiro, tempo, perder credibilidade no mercado ou mesmo causar lesões ou mortes.

Exemplos onde a falta de "bons" testes gerou graves problemas

Depois de passar este tempo todo a falar da importância de teste não podia de deixar de colocar alguns exemplos de desastres associados a falhas de software. Existe uma frase muito conhecida que diz

“Anything that can go wrong, will go wrong.”

O que infelizmente é bem verdade e muitos exemplos que mostram esta verdade podem ser enumerados. Os resultados algumas das vezes são catastróficos devido a falhas de software embora os que se apresentam abaixo ajudem a perceber a importância que os testes de software podem ter na ajuda à detecção deste tipo de falhas.

• Explosão do Ariane 5 – Em 1996 o veículo espacial Ariane 5 explodiu cerca de quarenta segundos após o seu lançamento. O motivo da falha foi um erro no cálculo da velocidade do foguete, especificamente um número no formato 64 bits com a velocidade horizontal do foguete foi convertido para um inteiro com sinal de 16 bits. Como o número resultante dessa conversão era superior a 32.767 (o maior inteiro possível de se representar num inteiro com sinal de 16 bits) e portanto a conversão falhou. A explosão do foguete custou à agência Espacial Europeia 10 anos de trabalho e 7 mil milhões de dólares, deitados fora em apenas quarenta segundos, além da carga do foguete, avaliada em cerca de 500 milhões de dólares.

• Therac-25 era uma máquina de radioterapia, controlada por computador, que permitia a aplicação de diversas doses de radiação nos pacientes. Entre os anos de 1985 e 1987 existiram uma série de acidentes nos quais os pacientes receberam uma overdose de radiação. Pelo menos cinco pessoas morreram devido à sobredosagem provocada pelo erro no software que controlava a máquina. Mais informação detalhada pode ser encontrada aqui.

Muitos outros casos de catástrofes provocadas por erros de software podem ser encontradas aqui.

Espero ter contribuído para que os testes sejam vistos de forma séria, e não apenas como uma perda de tempo.

Bom, até à próxima.

Hello World!

 

Qualquer blog que se preze, começa com um “Hello World”. Assim

Hello World

O objectivo deste blog é partilhar um pouco da minha experiência e opiniões sobre testes de Software. O que irá aqui ser escrito é apenas fruto da minha experiência pessoal. Vou tentar correr um pouco sobre todo o ciclo de vida dos testes.Falar sobre vários processos de desenvolvimento (waterfall, v-model, spiral), falar sobre gestão de testes, gestão de risco, automação, ferramentas de auxílio à execução e gestão de testes entre muitos outras coisas que ao decorrer do tempo me vá lembrando.

Todo o conteúdo aqui apresentado é fruto da minha experiência pessoal apenas, não será necessariamente a melhor solução, assim como também não apresentarei soluções que funcionem para todos os casos. Reservo-me ao direito de ir mudando de opinião à medida que vou aprendendo, porque infelizmente ninguém nasce ensinado e o que hoje parece correcto amanhã poderá estar completamente errado.

Bom, até à próxima.