uniinfo2010 introdução teste de software - priscila coelho blauth2

UNISINOS

UNIINFO 2010Mini-curso: Introdução ao Teste de Software

1

UNIINFO - Semana da Informática UNISINOS

– Mini-curso –

24 de maio de 2010

Priscila Coelho dos Santos Blauth ([email protected])

UNISINOS

UNIINFO 2010Mini-curso: Introdução ao Teste de Software Apresentação

Instrutora e Turma

2

UNISINOS

UNIINFO 2010Mini-curso: Introdução ao Teste de Software Apresentação

Instrutora e Turma

3

UNISINOS


4

• Nome• Empresa em que trabalha, papel/atividades• O que sabes sobre qualidade de software? E sobre testes de

software?• Qual expectativa do mini-curso?

ApresentaçãoInstrutora e Turma

UNISINOS


5

Agenda

Módulo I – Processo de Teste de SoftwareO que é teste de software, seus benefícios, vantagens e objetivos.Apresentação de conceitos básicos de qualidade de software ealternativas para garantir a qualidade do produto dentro do processo dedesenvolvimento de software

Módulo II – Técnicas e Estratégias de Teste de SoftwareVisão geral das de uma seleção principais técnicas e estratégias de testede software existentes no mercado, para contextualização.

Módulo III – Recursos para o Teste na OrganizaçãoApresentação dos recursos humanos e físicos para a inserção de umprocesso de testes na organização, tipos de ferramentas essenciais.

UNISINOS


6

Módulo I – Processo de Teste de Software

UNISINOS


7

O que é “teste de software”?

“Teste de software é oprocesso de executar oprograma com a intençãode encontrar bugs.”

Glendford Myers, 1979

UNISINOS


8


"Os testes são técnicas de controle de qualidade que avaliam diretamente oproduto que está sendo construído, atuando, basicamente, naidentificação e remoção de erros.

Devem ser conduzidos de forma sistemática, para que os mesmos sejambem sucedidos.”

PRESSMAN, 1992

“Testar o software é verificar se ele está fazendo o que deveria fazer, deacordo com os seus requisitos, e se não está fazendo o que não deveriafazer.”

Emerson Rios, 2006

UNISINOS


9

O teste prova que o software tem erros, e não que osoftware está livre deles!


Os principais objetivos do teste são:Revelar as falhas do sistema,preferencialmente antes de entrar emproduçãoAvaliar a qualidade do produto baseadoem critérios objetivos

UNISINOS


10


Porém, é impossível achar todos os bugs:Impossível testar todas as formas e alternativas de entrada de dadosImpossível testar as diversas possibilidades e condições criadas pela lógica doprogramador

Se não se pode descobrir todos os erros do sistema e não se poder afirmar que ele estará 100% correto, então...

Por que testar?

UNISINOS


11


Teste é uma abordagem de controle da qualidade – diferente dagarantia da qualidade, que preocupa-se com implementação e melhoriados processos de software em geral.

Os testes de software devem ser realizados de forma sistemática, comseu processo definido e monitorado, perfis de profissionais e feramentasadequadas.

O teste não deve ser uma atividade isolada no processo dedesenvolvimento. Ele deve ocorrer em vários pontos, trazendo maiorvalor à empresa.

UNISINOS


12

Processo de Teste de Software

O que é um processo?

Entradas Atividades Saídas

É um conjunto de atividades interligadas entre si, que recebe entradas e gerasaídas com valor agregado.

UNISINOS


13


• Um processo definido não tem o objetivo de engessar, massim de direcionar o esforço da organização para tarefas maiscomplexas;

• Para um processo ser maduro, deve ser institucionalizado,documentado, utilizado por todos e continuamentemelhorado;

• Modelos de melhoria de processo servem para guiar, e nãopara certificar.

UNISINOS


14


• Um processo serve para:• Direcionar atividades de uma equipe;• Especificar quais os artefatos devem ser elaborados e

quando;• Definir responsabilidades e papéis e dirigir as tarefas

de cada indivíduo e da equipe toda (incluindo cliente);• Definir critérios para monitoramento e medição dos

produtos de cada fase e atividades do projeto.

UNISINOS


15


• O esquema a seguir mostra uma proposta de processo de testes genérico:

Procedimentos

iniciaisEspecificação Execução Entrega

Preparação

Planejamento

Retirado de “Teste de Software”, Emerson Rios, 2006

Elaboração documento que sela acordo entre partes envolvidas – externas e internas da empresa. Possui informações sobre objetivos, equipe, avaliações de riscos

UNISINOS


16


Procedimentos


Preparação

Planejamento

Elaboração/revisão do Plano de Testes, incluindo as estratégias que serão adoradas.

• O esquema a seguir mostra uma proposta de processo de testes genérico:Retirado de “Teste de Software”, Emerson Rios, 2006

UNISINOS


17


Procedimentos


Preparação

Planejamento


Preparação/manutenção do ambiente de testes, incluindo equipamentos, versões e ferramentas.


UNISINOS


18


Procedimentos


Preparação

Planejamento


Elaboração e revisão dos casos de teste, testes estáticos


UNISINOS


19


Procedimentos


Preparação

Planejamento


Execução dos testes conforme os casos de teste com registros desta execução


UNISINOS


20


Procedimentos


Preparação

Planejamento


Conclusão do processo de testes com a entrega do sistema em produção


UNISINOS


Priscila Coelho Blauth - Software Process Consultoria 21


Retirado de www.lgcnsglobal.com/Testing/Testing-Models.html

UNISINOS


22


Na especificação/elicitação de requisitos:Revisar documentação (incoerência, ambigüidades, padrões)Verificar se todas os processos de negócio foramabordadosVerificar se os requisitos estão corretos, completos, consistentes, testáveis...

UNISINOS


23


Na análise:Verificar se todos os requisitos foramabordadosVerificar inconsistência de regrasVerificar testabilidade

UNISINOS


24


Na arquitetura/projeto:Verificar possível incoerência na junção dos componentesVerificar completa comunicação entre as partes do softwareVerificar faltas/sobras na integraçãoVerificar se “bate” com regras determinadas na análise

UNISINOS


25


Na codificação:Verificar se está de acordo com o especificadoVerificar se atende aos requisitosVerificar padrões de codificação e de usabilidadeVerificar possíveis problemas de documentação

UNISINOS

UNIINFO 2010Mini-curso: Introdução ao Teste de Software Processo de Teste de

Software

“A qualidade do produto de softwaredepende da qualidade do processo paradesenvolvê-lo.” Watts Humphrey

26

UNISINOS

UNIINFO 2010Mini-curso: Introdução ao Teste de Software Processo de Teste de

Software

Identifique os defeitos do produto emelhore o seu processo!

27Fonte: www.defectmanagement.com

UNISINOS


28

Módulo II – Técnicas de Teste de Software

UNISINOS


29

Técnicas de Teste de Software

Técnicas de teste são formas sistemáticas de exercitaro produto de software com o intuito de identificar seusdefeitos

As técnicas de teste podem ser usadasindependentemente dos paradigmas ou metodologiasde desenvolivmento

UNISINOS


30

Técnicas de Teste de Software

Existem várias técnicas atualmente. A seguir serãoapresentadas as principais cujos conceitos básicosacabam gerando outras técnicas mistas

Existem 2 principais abordagens das técnicas:estrutural e funcional

UNISINOS


31

Teste de Caixa Branca

Também conhecido como glass box, white box ou caixa abertaÉ o teste estrutural do softwareTrabalha diretamente sobre o código-fonte do componente desoftwareO testador (outro desenvolvedor) tem acesso ao código fonte daaplicação e pode construir códigos para efetuar a ligação debibliotecas e componentesTécnica normalmente utilizada no teste de unidade, onde umaunidade do software (classe, método, função) é testadoTambém pode ser usada no teste de integraçãoPode ser necessária criação de drivers e stubs para apoiar naexecução do teste - mocks

Driver: exercita a unidade que se está testando – envio devalores, coleta e comparação de resultadosStub: quando é necessário substituir uma outra unidade aoqual a unidade que está sendo testada depende

UNISINOS


32

Teste de Caixa Branca

No teste estrutural pode ser combinado critérios de seleçãoNormalmente se utiliza ferramenta para auxiliar nos testesComo é avaliado o código fonte, existem ferramentas específicaspara cada linguagem

Ex.: JUnit para Java

UNISINOS


33

Teste de Caixa Preta

Também conhecido como black box

Analisa apenas funcionalidade (entrada-saída) do programa

Não analisa código

Tipos de defeitos encontrados:Falhas de interface;

Funções incorretas ou ausentes;

Acesso a banco de dados;

Erros de desempenho;

Erros de inicialização e término.

Baseado na especificação e em padrões definidos

Procura verificar se todas as funcionalidades previstas foramimplementadas e se respondem como esperado

UNISINOS


34

Teste de Caixa Preta

Principais técnicas:Valor limite;

Classes de equivalência;

Tabelas de decisão;

Baseada em estados.

A aplicação das técnicas:Podem ser utilizadas isoladamente ou em conjunto;

Auxiliam na identificação de um conjunto de casos de testepotencialmente revelador de falhas.

UNISINOS


35

Teste de Caixa Branca ou Caixa Preta?

Técnicas se complementam.

A escolha depende de uma série de fatores, como:Tipo do sistema

Padrões que devem ser adotados

Requisitos contratuais

Objetivo dos testes

Documentação disponível

Conhecimentos dos testadores

Investimentos disponíveis (tempo, recursos)

Ciclo de vida de desenvolvimento

Etc.

UNISINOS


36

Teste de Desempenho

Tem como objetivo avaliar o comportamento da aplicaçãoem condições de sobrecarga (com um determinadonúmero de usuários interagindo simultaneamente com aaplicação), para identificar gargalos de hardware esoftware.

Vantagens:Melhorar a qualidade das aplicações implantandas

Identificar gargalos de software

Dimensionar corretamente o hardware das suas aplicações

Reduzir o risco de problemas no ambiente de produção

Prever o comportamento da aplicação numa condição de carga

UNISINOS


37

Teste de Desempenho

Pode-se gerar uma curva de degradação da aplicação, queé o comparativo do tempo de resposta em relação aonúmero de usuários simultâneos.

Ex.:

UNISINOS


38

Teste Baseado em Riscos

Os testes baseados em riscos são baseados nos riscos do negócio daaplicaçãoBaseia-se na premissa de que se os defeitos mais “importantes” sãoachados mais cedo quando se tem um melhor planejamento eefetividade nos esforços despendidos para testarUma boa análise de risco da aplicação permite tomar melhoresdecisões sobre a cobertura do teste, focando o esforço nosmódulos/funcionalidades mais importantes.Algumas perguntas podem ser feitas no momento do levantamento:

Que funcionalidades e atributos são críticos para o sucesso do produto?Quão grave é um problema numa funcionalidade ou atributo (paraclientes, usuários, pessoas de fora)?Em que frequência esta funcionalidade é utilizada?Podemos “sobreviver” sem isso?

UNISINOS


39

Teste de Regressão

É o re-teste do software após alguma modificação (comona correção de um defeito)

Objetivos:Verificar se o problema foi efetivamente corrigido

Verificar se outros erros não surgiram onde antes não havia

Dificuldade: saber o quanto re-testar

Dicas:Combinar casos de teste

Automatizar o que for possível

UNISINOS


40

Teste Automatizado

Servem para automatizar uma ou mais técnicas em um oumais níveis de testeNão é milagroso – deve existir estrutura na organização

“Um tolo com uma ferramenta continua sendo um tolo”

Exemplos de usos:Teste de interface de unidades e verificação de assertivasTeste de GUI (capture/replay)Teste de carga e estresseTeste de desempenho/deteccção de gargalos

Exemplos: TestComplete (Automated QA), Selenium,Mercury TestRunner, IBM Funciotnal Tester.

UNISINOS


41

Teste Exploratório

Baseia-se na experiência, “feeling” do testadorQuando aliado a outras técnicas formais ajuda a identificar testes especiaisnão identificados pelas abordagens formaisA eficiência do teste dependerá muito da experiência e habilidade dotestadorTeste exploratório é, ao mesmo tempo, o design do teste, a execução eregistro e aprendizado (do próprio software)O teste exploratório pode ser aplicado:

Executar testes quando requisitos não estão completamente documentadosExecutar testes quando existe pouco tempo disponívelExecutar testes quando não se conhece o aplicativo a ser testadoExecutar testes em ambientes pouco testados pelos testes convencionaisIdentificação dos passos para tentar reproduzir um defeito aleatórioInvestigação de efeitos colateraisInvestigação de defeitos semelhantes.

UNISINOS


42

Módulo III – Recursos para o Teste na Organização

UNISINOS


43

Recursos Físicos

Ambiente de testes dedicado

Sistema(s) operacional(is) adequado(s)

Banco de dados em separado

Atualizações de versões

Máquinas

Aparelhos externos – celular, automações, periféricosem geral

Ferramentas de testes

UNISINOS


44

Ferramentas

Todo o processo de software necessita de ferramentas de apoio

Para o processo de testes, existem alguns tipos de ferramentasbásicas:

Ferramenta para registro e gestão de defeitosFerramenta para documentação (plano de testes, casos detestes, casos de teste padrões)Ferramenta para controle do andamento do teste em relaçãoao seu escopo

Outras:Ferramenta para registro de execução e gerenciamento detestesFerramenta que contém o processo de teste (workflow)Ferramentas para teste automatizado e outros tipos de testesde requisitos não-funcionais

UNISINOS


45

Ferramentas

Planilhas e processadores de texto servem como ferramentasbásicasFerramenta deve fornecer mínimas possibilidades de se extrairmétricasExistem centenas de ferramentas no mercado, pagas e free, paravários tipos de utilidades (ex.: Bugzilla e Mantis – gestão dedefeitos)

Sites com indicações de ferramentas:http://www.testingfaqs.org/http://www.opensourcetesting.org/

E-book “Automação e Gerenciamento de Testes: Aumentando aProdutividade com as Principais Soluções Open Source eGratuitas”, de Cristiano Caetano.

UNISINOS


46

Equipe de Teste

Ainda não há uma “padronização” de funções usualmenteutilizada pelas empresas no Brasil

Os papéis atualmente utilizados são:Executor de Teste

Automatizador de Teste

Analista de Teste

Arquiteto de Teste

Engenheiro de Teste

Gerente de Teste

Gerente Especialista

Gerente Consultor

Consultor Especialista em QA

Em algumas empresas, a função “Testador” executa 1 ou mais

desses papéis

UNISINOS


47

Equipe de Teste

Alguns requisitos técnicos que podem ser avaliados:Conhecimentos gerais sobre as práticas e princípios deengenharia de softwareConhecimento das práticas e princípios de teste de softwareConhecimentos básicos sobre métodos e estratégias de testeConhecimentos em Planejamento, Design e Execução de testesHabilidade de redação clara e objetiva, boa comunicaçãoFacilidade de leitura e intrerpretação de textosTer bom raciocínio lógicoConhecimentos de redes de computadores, banco de dados,sistemas operacionaisConhecimentos de gestão de configuraçãoHabilidades para definir, coletar e analisar medidas de teste desoftwareConhecimentos básicos em ferramentas de automação

UNISINOS


48

Equipe de Teste

Além da questão técnica, o profissional da área detestes deve ser:

Detalhista, observador

Pró-ativo

Crítico

Bom relacionamento interpessoal com váriospapéis da equipe inclusive cliente

UNISINOS


49

Equipe de Teste

Atualmente existem 4 principais certificações em teste desoftware disponíveis no Brasil:

Internacionais:QAI (Quality Assurance Institute) - www.qaiworldwide.org

CAST – Certified Associate in Software Testing

CSTE - Certified Software Tester

ISBTQ (International Software Testing Qualifications Boarding) -www.istqb.org, no Brasil representado pelo BSTQB (BrazilianSoftware Testing Qualification Board) - www.bstqb.org.br

CTFL – Certified Tester, Foundation Level

CTAL – Certified Tester Advanced Level

Nacionais:IBQTS (Instituto Brasileiro de Qualidade em Testes de Software) -http://www.ibqts.com.br/

ALATS (Associação Latino-Americana de Teste de Software) -http://www.alats.org.br

CBTS (Certificação Brasileira de Teste de Software)

UNISINOS


50

Equipe de Teste

Modelos organizacionais:

Por projeto – parte da equipe ou por área emseparado;

Por habilidades – alocados de acordo com anecessidade do projeto;

Fábrica de teste – teste tratado como um projetoem separado, por equipe especializada.

UNISINOS


51

Considerações Finais

UNISINOS


52

Visão geral

Existem diferentes técnicas e aplicabilidades quedependem do objetivo do negócio e das características dosistema

Os testes podem ser aplicados nas diferentes fases dodesenvolvimento do software

A equipe responsável não deve estar diretamentesubordinada ao projeto

Como para o desenvolvimento de software, a atividade detestes requer um processo definido com atividades,ferramentas, papéis e responsabilidades...

UNISINOS


53

Considerações finais

O processo de teste deve ser documentadoFerramentas para controle são essenciaisOs critérios de qualidade do testador deve ser omesmo do início ao fim do projeto. A decisão decorrigir ou não um bug que pareça “bobo” no final doprojeto não cabe ao testador, deve ser deresponsabilidade da gerência;Não confie na memória – nem na sua, nem na dodesenvolvedor. Documente, cadastre todas as falhasmesmo que ele diga “Peraí que eu já corrijo isso!”. Nãoesqueça que a documentação da falha é essencial parao testador, e o reteste pode acontecer horas ou diasdepois da detecção.

UNISINOS


54

Considerações finais

Os objetivos do teste são:

Verificar as regras de negócio

Verificar padrões

Verificar usabilidade...

MAS também: não deixar o usuário fazer“bobagens”. O testador deve se colocar no lugar dousuário.

E lembre-se: NUNCA SUBESTIME UMUSUÁRIO!

UNISINOS


55

Leis de Teste (incluindo Murphy)

Se alguma coisa pode dar errado, ela daráQualquer programa não-trivial contém pelo menos 1 bugSempre haverá mais 1 bugQualquer erro pode se esconder, não antes da aplicação jáestar em produção durante 6 meses é que será descoberto opior dos bugsNada é tão fácil quanto pareceNão existe nenhum trabalho tão simples que não possa serfeito erradoTodos superam sua capacidade de incompetência, porém,nunca haverá testadores suficientes.Se construtores construíssem prédios do modo comoprogramadores constróem software, então o primeiro pica-pau destruiria uma civilização.

UNISINOS


56

OBRIGADA!

Priscila Coelho [email protected]

UNISINOS


57

ReferênciasEmerson Rios e Trayahú Moreira – Teste de Software -2ª edição. Alta Books, 2006.Cem Kaner – Improve the Power of Your Tests with Risk-Based Test Design. Conferênciade Testes Baseados em Riscos, Florida, 2008.Rajnikant Puranik – The Art of Creative Destruction. SPD, 2005.Glenford J. Myers, Tom Badgett, Todd M. Thomas, Corey Sandler – The Art of SoftwareTesting. Wiley, 1979Kleber G. Greco, Ricardo Cristalli – Referência Complementar – CBTS. 2007Alexandre Bartie – Garantia da Qualidade de Software. Campus, 2002.Taisy Silva Weber – Tolerância a falhas: conceitos e exemplos. Programa de Pós-Graduaçãoem Computação - Instituto de Informática – UFRGS.Juliana Herbert – Formação em Teste de Software. UNISINOS, 2004.Fábio Oliveira – Capacitação em Técnicas de Teste de Software. PUCRS, 2003.Cristiano Caetano – Testes Exploratórios de A a Z. Retirado dehttp://www.linhadecodigo.com.br/Artigo.aspx?id=1102.Driving Software Quality – Lisa Crispin. Revista IEEE Software – dez/2006. Volume 3número 6.IEEE Standard for Software Test Documentation - IEEE Std 829-1998. IEEE, 1998

KOOMEN, Tim et al. Tmap Next, for result-driven testing. UTN Publishers, 2006.

POL, Martin; TEUNISSEN, Ruud & VEENENDAAL, Erik. Software Testing: A Guide to theTmap® Approach. Addison-Wesley Professional, 2001.

KOOMEN, Tim & POL, Martin. Test Process Improvement: A Practical Step-by-Step Guide toStructured Testing. Addison-Wesley Professional, 1999.

UNISINOS


58

Alguns sites da área

Sites:www.testexpert.comwww.badsoftware.comwww.stickyminds.comwww.testing.comSoftware Quality Institute: http://lifelong.engr.utexas.edu/sqi/index.cfmALATS: www.alats.org.brhttp://www.testingcraft.comhttp://testinggeek.com/

Blogs:http://guts-rs.blogspot.com/http://sembugs.blogspot.comhttp://gtsw.blogspot.com/http://testbugs.blogspot.com/

uniinfo2010 introdução teste de software - priscila coelho blauth2

Documents