Testes de Software

...

terça-feira, 20 de outubro de 2009

O processo de Testes de Software (Parte 2')

Artigo de Alexandre Bartie


Continuação...








Definição de Cenários Possíveis (Duração, Esforço, Custo e Qualidade):

  • Levantar Lista de Projetos em Andamento e a serem Iniciados;
  • Avaliar a disponibilidade de recursos internos para alocação no Projeto;
  • Identificar Cenários Diversos (Terceirização, Redução de Escopo, Repriorização de Projetos);
  • Definir Cronograma-Macro para cada cenário identificado;
  • Definir Riscos para cada cenário identificado e Planos de Ação Esperados;
  • Estabelecer Propostas e Aguardar aprovação da Diretoria;

Aprovação do Planejamento:

  • Obter o Aceite das Propostas de Cenários Aprovados pela Diretoria;
  • Obter o Aceite de uma das Propostas pelo Cliente;
  • Divulgar do Cenário Aprovado do Projeto aos colaboradores e terceiros;
  • Obter a Assinatura do CONTRATO-MESTE e elaborar os ANEXOS; (no caso de terceirização)
  • Alocar Espaço Físico dos Terceiros; (no caso de terceirização)
  • Comunicar a Finalização da Etapa de Planejamento dos Testes; (externo)

Definição das Responsabilidades

Neste diagrama, está a representação dos papéis e responsabilidades para cada grupo de atividades envolvido na etapa de "Planejamento dos Testes".

Mapeamento dos Artefatos

Nesta representação gráfica, estão destacados os "artefatos de entrada" exigidos como premissa para que cada macro-atividade possa ser realizada. Também são destacados os "artefatos de saída" produzidos como resultado da atividade.

Etapa 2: Especificação dos Testes

Esta etapa é caracterizada pela identificação dos casos de testes que deverão ser construídos e modificados em função das mudanças solicitadas pelo Cliente, bem como pelo próprio aperfeiçoamento do processo de testes (ampliação da cobertura).

Dinâmica das Macro-Atividades

Este diagrama representa a seqüência das "macro-atividades" a serem executadas na etapa de "Especificação dos Testes".

Detalhamento das Macro-Atividades

Esta lista representa o conjunto de atividades que deverão ser executadas para que cada macro-atividade seja considerada finalizada, funcionando como um "check-list" de execução da etapa de "Especificação dos Testes".

Estudo dos Requisitos:

  • Estudar os requisitos funcionais e não funcionais solicitadas pelo Cliente (novos requisitos);
  • Estudar as modificações de requisitos solicitados pelo Cliente (mudanças de requisitos);
  • Revisar os artefatos e identificar "inconsistências" dos requisitos;
  • Estabelecer o Aceite dos Documentos fornecidos e "feedback" da qualidade dos mesmos;
  • Estudar as lições aprendidas da Etapa "Especificação de Testes";

Especificar as Adaptações da Arquitetura dos Testes:

  • Especificar as adequações nas atuais ferramentas empregadas;
  • Especificar as novas ferramentas exigidas pelo projeto;
  • Especificar as modificações estruturais na organização do ambiente;
  • Especificar as adequações na automação da preparação do ambiente (script de teste);
  • Especificar as adequações na automação da execução dos testes (script de teste);
  • Especificar as adequações na automação da análise dos resultados (script de teste);

Identificação dos Casos de Testes

  • Identificar cada solicitação de mudança requisitada pelo Cliente;
  • Identificar todos os Casos de Uso envolvidos em cada solicitação;
  • Identificar Casos de Uso não cobertos adequadamente por Casos de Testes; (legado)
  • Identificar todos o Fluxos do Caso de Uso (Básico, Alternativo e Exceção);
  • Identificar os casos de testes que garantam cada Fluxo do Caso de Uso;

Refinamento dos Casos de Testes:

  • Estabelecer dinâmica com os Analistas de Testes que possuem conhecimento horizontal;
  • Apresentação de um quadro-geral do impacto das mudanças nos respectivos aplicativos;
  • Cada Analista de Testes apresenta seus casos de testes por aplicativo;
  • O grupo de Analistas de Testes criticam e sugerem melhorias nos casos de testes;
  • O grupo de Analista de Testes avaliam o nível de cobertura alcançado;
  • Novas reuniões serão realizadas até que seja alcançado o patamar ideal de casos de testes;


Vagas para Analista de Testes

Vaga: Analista de Testes (URGENTE) RJ,SP e Hortolândia

Experiência minima de 2 anos em Test case creation, Test case execution,Teste de Metodologia.
Desejável ferramentas Rational, AIX e linguagem XML.

Local do Projeto:RJ,SP e Hortolândia
Nivel de Inglês: Avançado (para conversação)
Tempo de Projeto: Indeterminado

Interessados encaminhar CV com pretensão salarial para:

Dayana Samora
Analista de RH
Consultoria Decision Group
E-mail: 
dayana.reiss@hotmail.com

quinta-feira, 15 de outubro de 2009

Material gratuito de Curso de Introdução a Testes de software

São 02 aulas, 235 slides.


Além de acesso livre, é permitido também fazer download de todo o material. Aproveitem!


Clique em "leia mais" e inicie os estudos.


terça-feira, 13 de outubro de 2009

Palestra ALATS SP - FIAP Teste de Software

Nesta apresentação, Elias Nogueira, esclarece pontos como:

- O que é Teste de Software
- Onde o Teste de Software Influencia no Desenvolvimento da aplicação
- carreira em Teste de Software
- Profissionais em teste de Software
- Cargos e Salários da Área de Teste de Software
- Areaes dentro da area de Teste de Software
- Sobre a ALATS

Material interessante. Clique em "leia mais" para acessar a palestra completa

domingo, 11 de outubro de 2009

Ferramentas de Testes de Software Opensource - Software free

Este site é muito frequentado por Analista de testes de todo o mundo. 


Nele, encontramos absolutamente TODAS as ferramentas de software livre de Testes de Software automatizados.


Com as ferramentas é possível criar roteiros de testes automatizados, testes de carga, volume, testes de stress, de concorrência, entre uma infinidade de automações. 


Obs: para acessar o site e iniciar baixar as ferramentas, clique em "leia mais"

quinta-feira, 8 de outubro de 2009

Material de Testes de Software - Metodologia e Melhoria do Processo de Testes




Uma Metodologia para Teste de Software no Contexto da Melhoria de Processo




Esta monografia escrita por Adalberto Crespo, contém pontos interessantes tais como:


- Proceso de Testes


- Diagrama demonstrando o relacionamento entre os documentos de testes de software


- Norma IEEE 829


- Tipos de Testes


- Entre outros


Está disponível na web, vale muito a pena dar uma lida. Não é extenso: apenas 15 páginas.


Obs: clique em "leia mais" para acessar e fazer o download do trabalho.


quarta-feira, 7 de outubro de 2009

Quantidade de testes x custo dos testes


Estou criando tópicos para tirar dúvidas de leitores que, vez ou outra me escrevem. Este primeiro tópico irá abordar não exatamente uma dúvida, mas um ponto de discordância de um colega de fórum.




---------------------------------------------------------------
Se você deseja particiar de um tópico destes, envie sua dúvida para: fernando.palma@gmail.com
Se você deseja acrescentar algo, use os comentários


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




?Repito, qualidade não é negociável. Se nao funciona voce nao entrega, se funciona mais ou menos voce nao entrega. Se funciona mas contem pequenos bugs suportaveis voce conserta-os e entrega.?




YvGa,


O nível de qualidade de um serviço ou produto é variável e negociável, depende do que este serviço/produto irá atender.




Entendo que o conceito de desenvolvimento ágil, tais como metodos XP e SCRUM, vão de encontro a esta afirmativa. Entretanto, a depender do cenário, objetivo e metodologia utilizada, a qualidade é uma variável mensurada. Vejamos um exemplo:

terça-feira, 6 de outubro de 2009

Programação Orientada a Testes

Apresentacao do Paulo Silveira, Desmistificando o TDD na prática, no 7 Aniversario do CEJUG.




Video interessante sobre programação orientada a testes. Paulo Silveira demonstra na prática como escrever testes antes do código ser produzido.

Uma ótima vídeo aula de automação de Testes de Software.



Antes de iniciar, para quem não estiver acostumado com a sigla, segue uma breve definição:


Test-Driven Development (TDD), ou Programação Orientada a Testes: É um estilo de programação dirigida pelos testes. Os testes são implementados antes de escrever qualquer código. O código então é implementado de forma a atingir os pré-requisitos estabelecidos pelos testes implementados. Para concluir a codificação, é preciso "passar" pelos testes pré-estabelecidos.











Clique em "leia mais" para assistir aos vídeos















segunda-feira, 5 de outubro de 2009

Vagas para Analista de Testes (em Protugal)




TESTER DE SOFTWARE (M/F)



Oferta de Emprego:


Com um posicionamento de referência no mercado tecnológico há mais de 16 anos, a GFI Portugal conta já com uma equipa superior a 600 pessoas, onde o sucesso depende da confiança e da capacidade de manter padrões de elevada qualidade, pelos quais somos reconhecidos.
Através de uma abordagem flexível na aplicação das Tecnologias de Informação, a GFI Portugal aposta na oferta de serviços inovadores e adaptados às diferentes realidades, procurando sempre recrutar os melhores profissionais de mercado.






Clique em "leia mais" para saber mais detalhes

domingo, 4 de outubro de 2009

O processo de Testes de Software (Parte 1)

Artigo de Alexandre Bartie







Processo de Teste de Software - Parte 01


O Processo de Testes de Software representa uma estruturação de etapas, atividades, artefatos, papéis e responsabilidades que buscam a padronização dos trabalhos e ampliar a organização e controle dos projetos de testes.

O Processo de Teste, como qualquer outro processo deve ser revisto continuamente, de forma a ampliar sua atuação e possibilitar aos profissionais uma maior visibilidade e organização dos seus trabalhos, o que resulta numa maior agilidade e controle operacional dos projetos de testes.




sábado, 3 de outubro de 2009

Material de Itrodução a Testes de Software

Material interessante aborda alguns conceitos para iniciação no tema.


Clique em "leia mais" para visualizar o material.


sexta-feira, 2 de outubro de 2009

Vagas para Analista de Testes

Divulgarei algumas vagas que encontro em anúncios, já que interessados podem estar freqüentando o blog







Analista de Testes JR.
Uma Vaga - SAO PAULO-SP, 02/10/2009
 
Cargo: ANALISTA DE TESTES
Status: Publicado
 

Consultoria multinacional de TI, com atuação em grandes clientes e sistemas de missão crítica, seleciona profissionais orientados a desempenho e foco em qualidade com o perfil Analista de Testes JUNIOR.




Desejável experiência ou conhecimentos avançados em telecomunicações e sistemas bancários.


Obs: clique em "leia mais"

Qual a diferença entre verificação e validação?

Diferença entre Verificação e Validação






Verificação


A verificação tem o objetivo de avaliar se o que foi planejado realmente foi realizado. Ou seja, se os requesitos, funcionalidades e perfoemence documentados foram implementados. 


Verificaão também pode ser realizada para especificação de sistemas, para avaliar se os requisitos estão sendo documentados como deveriam e ainda prever falhas ou inconsistências entre requisitos. 




O Custo da Não Qualidade

obs. : artigo escrito em maio de 2007


O Custo da Não Qualidade

 
Por: Fernando Palma
Maio, 2007

___________________________________________________
Entre o fim da década de cinqüenta e inicio de sessenta, começava a ser criado o conceito de testes de software. Finalmente, o exercício de testar começara a ser designado como um processo separado e não mais como uma simples revisão de código dos programadores como acontecia até então. Esta mudança provocou melhoras na qualidade dos sistemas que acataram a nova metodologia, mas não significou grande redução de custos para os projetos até então. Não significou porque essa prática isolada não era suficiente, ela dependia de outra que teve origem por volta da década de oitenta: a de testar o software desde o inicio. Hoje, está claro que a eficiência dos testes resulta na qualidade do sistema, na mesma proporção que, a boa distribuição deles resulta em menores custos. Embora pareça simples, existem muitos modelos de fabricas trabalhando como nos primórdios, e continuam sem entender o porquê dos prejuízos financeiros em seus projetos.



Assim que é implantado um processo de testes eficiente dentro de uma empresa, como avaliar o ganho que foi gerado? É possível perceber o bom desempenho, assim como realizar um cálculo do custo que foi poupado (ROI).  O propósito deste artigo, entretanto, é que seja feito exatamente contrário: uma breve avaliação dos custos gerados por não testar o software de maneira eficaz e distribuída. Os exemplos a seguir são breves estudos de caso que introduzem esta análise:




Acidente: Therac 25


O Therac 25 era uma maquina controlada por um software, utilizada para o tratamento de câncer por radioterapia. Na época, foi uma grande evolução, pois gerenciava as dosagens adequadas a seus pacientes, poupando o trabalho mecânico.
A máquina operou durante seis meses e era considerada livre de defeitos, até dar-se o início a uma sucessão de falhas. Infelizmente, a descoberta foi tardia e irreparável. Devido a uma overdose causada pelo software, ocorreram quatro mortes (duas imediatas) e um total de quinze acidentes ocorridos em locais diferentes. Os episódios ocorreram entre 1985 e 1987, muitos pacientes estão com ferimentos permanentes até hoje.
O caso é considerado um dos mais graves em toda a história envolvendo falhas de computadores, justamente porque o prejuízo causado pelos erros foi incalculável: vidas humanas.
Muitas falhas foram indicadas como razão do ocorrido, após uma perícia do software. Entre elas destacam-se: a falta de gerenciamento da qualidade, documentação não apresentava explicação para os códigos de erros gerados e ausência de técnicas de testes, em construção, para simular usos imprevistos.
Mais informações: http://pt.wikipedia.org/wiki/Therac-25



Acidente :
Ariane 5

O Arine 5 é um foguete espacial utilizado para levar satelites até suas orbitas, além de transportar outros tipos de cargas. Para seu lançamento, o veículo utiliza uma serie de softwares, entre eles, sistemas de referncia inercial e o software de controle.
Em Junho de 1996, a aeronave se auto destruiu um minuto após seu lançamento. As condições de tempo estavam favoráveis, mas houve um desvio na tragetória, seguido pela explosão do foguete. O prejuízo foi de qautrocentos milhões de dólares.
Uma comissão liderada pelo matemático francês Jacques-Louis Lions realizou uma investigação para apurar a origem do problema. Como resultado, foi encontrada uma cadeia de falhas iniciais que incidiram em uma anomalia no software controlador, exatamente no instante que este executava a conversão de dados de um número de 64 bits em ponto flutuante para um inteiro de 16 bits.
O código não estava protegido contra o tipo de exceção que foi levantada.
Mais informações: http://www.sbmac.org.br/bol/bol-2/artigos/ariane5.html




Intel
Em 1994, ouve um erro de vírgula flutuante no Pentium. A correção custou à empresa 475 milhões de dólares.
O erro teria um custo insignificante se descoberto na fase de especificação.
(Computer Science, Springer Verlag – 1995)




Motorola
A empresa PrimeCo Personal Comunications cancelou um contrato de 500 milhões de dólares com a Motorola por causa de falhas.

(Wall Street Journal – 24/02/98)


Diversos outros casos poderiam ser utilizados para ilustrar, como um erro de software que paralisou as linhas as telefônicas de quase toda a costa leste dos EUA, sondas espaciais da NASA perdidas no espaço, colapsos em sistemas de matrículas, sistemas governamentais. Mas, para resumir, nada melhor do que uma estatística demonstrada no livro de Alexandre Bartie, 2002, Garantia da Qualidade de Software, envolvendo estudos americanos:
-->Mais de 30% dos Projetos são cancelados antes de serem finalizados.
-->Mais de 70% dos Projetos falham nas entregas das funcionalidades esperadas.

-->Os custos extrapolam mais de 180% os valores originalmente previstos

-->Os prazos excedem em 200% os cronogramas originais
Obs: Trecho retirado da página 06, Elsevier Editora Ltda, 2002



Depois deste breve histórico de bugs e os dados estatísticos, fica fácil compreender a imagem a seguir, que representa um gráfico bastante conhecido entre profissionais de Qualidade:
O Custo médio de um erro (em dolar)



(para ampliar, basta clicar sob a imagem)





A ilustração acompanha o custo de um defeito, demonstrando que ele cresce em uma proporção média de dez vezes a cada etapa de desenvolvimento. Sendo assim, um erro encontrado em especificação custa dez centavos de dólar para ser corrigido. Já para o caso do mesmo erro ser esquecido e detectado em fase de implantação, o custo aproximar-se-ia de cem dólares.
Os computadores e softwares tendem a tornarem-se mais complexos, em uma velocidade exponencialmente crescente. A segurança e qualidade somente serão possíveis, caso o ritmo dos critérios de avaliação, de auditorias e testes acompanhem esta evolução. Mesmo para os pequenos sistemas, existe uma infinidade de cenários e caminhos nas regras de negócio. O fatal de tanta complexidade, ao contrário do que se imagina, está nos pequenos detalhes dos softwares. Os bugs dos caminhos improváveis, quase invisíveis. Justamente os defeitos pequenos e esquecidos, são os mais traiçoeiros e causadores de prejuízos. Mas isso já é assunto para o próximo artigo.


Fernando Palma


Referências:
Bartie Alexandre, Garantia da Qualidade de Software, São Paulo: Elsevier Editora Ltda, 2002.
paginas.fe.up.pt/~jpf/teach/TQS0506
www.lac.inpe.br/~vijay/download/ELAC2007/Vijay_Testes_De_Software_E_Avaliacao_De_Desempenho_PARTE_II.pdf
http://pt.wikipedia.org/

quinta-feira, 1 de outubro de 2009

Qual a diferença entre eficiência e eficácia?


Um colega/leitor me alertou para o fato de que eu postei um video descontraído sobre o tema, entretanto não trouxe 
uma definição para o blog. Portanto segue:




Eficácia: é atingida a medida em que se atinge o objetivo esperado. Caso um projeto, serviço, produto produzido ou plano atinja o objetivo inicial, significa que foi eficaz.