Camilo Falcão Ribeiro é um analista e arquiteto de teste com mais de quatro anos de experiência em testes de software e processos. Ele participou de mais de 40 projetos de software e projetos de implantação do CMMi em todos os níveis. Ribeiro é graduado em Sistemas para Internet e pós-graduando em Engenharia de Software.

2. Camilo Falcão Ribeiro Analista/Arquiteto de Teste e Engenheiro de Processos na Squadra Tecnologia; Mais de quatro anos atuando em Teste de Software e Processos; Participação em mais de 40 projetos de Software; Participação em projetos de implantação do CMMi (todos os níveis); Graduado em Sistemas para Internet pela Faculdade Pitágoras; Pós graduando em Engenharia de Software pelo DCC/UFMG; Certificado como especialista em Teste de Software pelo ISTQB e ALATS; Membro do comitê de inovação em Teste de Software ALATS; Mantedor do blog técnico www.bugbang.com.br ; Especialista em implementação e customização da ferramenta TestLink.

3. Defeitos estão por toda parte! . . .

4. Custo do Defeito Custo relativo para corrigir um defeito. Adaptado de (BOEHM, 1981). Distribuição do retrabalho pelas atividades de desenvolvimento de software. Adaptado de (WHEELER et al., 1996).

5. Soluções para cada tipo de Defeito! Teste Exploratório Teste Manual Inspeção Auditoria de Qualidade Teste de Unidade Análise Estática -Não tem relação com o Slide sobre os tipos de defeitos (joaninhas) Teste de Regressão . . .

6. Teste de Software “ Teste de software é o processo de executar um determinado software com a intenção de encontrar defeitos.” Glenford J. Myers, The Art of Software Testing, 1979 “ Teste de Software é o processo formal de avaliar um sistema ou componente de um sistema por meios manuais ou automáticos para verificar se ele satisfaz os requisitos especificados ou identificar diferenças entre os resultados esperados e obtidos.” [IEEE729 1983][NOGUEIRA2009] “ Processo que consiste em todas as atividades do ciclo de vida, tanto estáticas quanto dinâmicas, voltadas para o planejamento, preparação e avaliação de produtos de software e produtos de trabalho relacionados a fim de determinar se eles satisfazem os requisitos especificados e demonstrar que estão aptos para sua finalidade e para a detecção de defeitos. “ Testing”, [Glossário ISTQB, v. 1.3br, 01 de jul. 2007]

7. Teste de Software Teste de Software

8. Níveis, Tipos e Técnicas Créditos: Ricardo Antunes Técnica Nível Dimensões da Qualidade Funcionalidade Confiabilidade Usabilidade Desempenho Suportabilidade Tipos de Teste (alguns exemplos) Caixa Branca Teste de Unidade Teste de Integração Segurança Integridade Carga Configuração Caixa Cinza Teste de Sistema Funcional Regressão Usabilidade Caixa Preta Teste de Aceitação Volume Maturidade Estresse Instalação Como Testar Quando Testar O que Testar

9. Transparência do Teste Requisitos / Negócios (Abstração) Teste de caixa branca Teste baseado na análise da estrutura interna de um componente ou sistema. (Glossário ISTQB) Teste de caixa preta Teste, funcional ou não funcional, sem referência à estrutura interna do componente ou do sistema. (Glossário ISTQB)

10. Testar é muito mais que automatizar Necessidades Características / Requisitos Casos de Uso Cenários de Teste Casos de Teste (Incluindo Dados) Scripts de Teste [ZIELCZYNSKI 2006]

11. Teste de Aceite Teste de Sistema Teste de Integração Teste de Unidade Modelos “V” De Desenvolvimento Requisitos Análise Desenho Implementação

12. Teste de Aceite Teste de Sistema Teste de Integração Teste de Unidade Diferentes níveis, diferentes abordagens Para cada momento do ciclo de vida de um determinado produto de software, devemos ter diferentes abordagens, o que inclui as técnicas, as ferramentas e as pessoas certas.

13. Teste de Unidade Teste de unidade (unit test) é o processo que inclui o planejamento, a execução, a aquisição de dados de teste e as medições de cobertura em relação aos requisitos, usando de dados mais simples para exercitar as unidades de forma a realizar comparações entre o comportamento real (software sob teste) e o comportamento esperado (requisitos definidos). [IEEE Standards Board]

14. Teste de Unidade Mesma Classe ou Unidade

15. Teste de Unidade com JUnit Requisito Classe de Teste Bibliotecas (Junit) Implementa Especifica Dados (DB, XML) Gera e Testa Classe Java Acessa Acessa Cobertura de Código Defeitos Estimativas Exemplo: Uma Introdução a TDD com JUnit

16. Teste de Integração Teste de integração (Integration testing) Teste realizado com a finalidade de expor defeitos nas interfaces e nas interações entre componentes ou sistemas integrados. (ISQTQB Glossário)

17. Teste de Integração Classes ou Unidades Diferentes .

18. Modelos de Teste de Integração Teste big-bang (Big-bang test) Tipo de teste de integração no qual os elementos de um software ou de um hardware, ou ainda de ambos, são combinados todos de uma vez, ao invés de em estágios, em um componente ou sistema geral. (IEEE610) (ISQTQB Glossário ) Teste bottom-up (Bottom-up testing) Abordagem incremental do teste de integração, na qual os componentes de nível mais baixo são testados em primeiro lugar, e, então utilizados para facilitar o teste de componentes de nível mais alto. Este processo é repetido até que o componente no topo da hierarquia seja testado. (ISQTQB Glossário ) Teste top-down (Top-down testing) Abordagem incremental do teste de integração na qual o componente na parte superior da hierarquia de componentes é testado primeiro, e os componentes nos níveis mais baixos são simulados por simuladores (stubs). Os componentes testados são então utilizados para testar componentes de níveis mais baixos. Este processo é repetido até que os componentes de níveis mais baixos tenham sido testados. (ISQTQB Glossário ) Unidade Testada Software Completo Unidade Software Completo Software Completo

19. Teste de Sistema Teste de sistema (System testing) Testa um sistema integrado para verificar se ele atende aos requisitos especificados. [Hetzel] Teste de Sistema é o teste realizado em um sistema completo e integrado (software ou hardware) para avaliar a sua conformidade com os requisitos especificados. No escopo do Teste do Sistema são inseridos os testes de caixa preta, e como tal, não deve exigir nenhum conhecimento de projeto interior do código ou lógica. IEEE Standard Computer Dictionary

20. Caso de Teste CT SIS65 ID - Nome Pré condições Procedimentos Entradas e Saídas Resultados esperados Pós Condições

21. Teste de Sistema CT01 CT02 CT03 CT04 CT05 CT06 CT07 Automatizado Manual Leitura dos casos de teste Registro manual dos resultados Programação dos casos de teste em ferramenta de automação e Record and replay

22. Teste de Sistema Programador Implementa Código Testador encontra muitos problemas recorrentes Release gerada Defeitos abertos Gasto excessivos de tempo; Pessoas desmotivadas (trabalho repetitivo); Maior custo com salários e horas extras; Probabilidade de erros passarem após vários ciclos de teste; Vício do testador na ferramenta (perda de eficiência).

23. Teste de Sistema Programador conta com ferramentas de suporte e processo automatizado. Release gerada * Desenvolver testes automatizados leva cerca de 3 a 10 vezes mais tempo que executá-los manualmente. O ganho está na redução do tempo de execução.( CBT-TST110 ) Testador incansável Testa, retesta e testa de novo! Log de Erros Testador motivado mantém os scripts e tem mais tempo para analisar resultados e planejar testes.

24. Teste de Sistema Scripts de Teste Teste de Sistema automatizado Call Scripts Ponto de verificação Ponto de verificação Ponto de verificação BD (Datapool)

25. Teste de Aceite Teste de aceite (Acceptance testing) Teste formal relacionado às necessidades dos usuários e aos requisitos e processos de negócios. Este teste é realizado para estabelecer se um determinado sistema satisfaz ou não os critérios de aceite e para possibilitar aos usuários, aos clientes e às outras entidades autorizadas decidir aceitar ou não determinado sistema. (IEEE 610) (ISQTQB Glossário)

26. Testes de Aceite Cenário de Teste Caso de Teste de Negócio Caso de Teste Caso de Teste de Aceite . . . Abstração

27. Testes de Aceite Os testes de aceite são os testes executados pelo cliente, baseados nos requisitos para que ele possa aprovar o sistema e avaliar se é exatamente o que ele precisava. Logo, podemos supor que não é viável automatizar testes funcionais de aceite. Relembrando: Testes funcionais são aqueles que visam encontrar defeitos funcionais ou verificar se uma determinada funcionalidade do sistema atende corretamente aos seus requisitos.

28. Testes de Requisitos Não Funcionais Os requisitos não funcionais são medidas baseadas em comportamentos do sistema durante a execução das funcionalidades. Os testes desses requisitos são normalmente executados com ajuda de ferramentas especializadas, com grande planejamento, avaliação arquitetural, aplicando técnicas avançadas. O papel que executa essas atividades é normalmente conhecido como arquiteto ou engenheiro de Teste

29. Eficiência Recursos Algoritmo Arquitetura e Rede Outros Requisitos Não Funcionais Pesquisa Requisitos Funcionais Acessos / Usuários

30. Eficiência Sumário com as médias de resposta Registradores por página Medidores por servidor Número máximo de usuários 100 Requisições por segundo 12.2 Requisições não completadas 0 Porcentagem de requisições em cachê 43.4 Tempo médio de resposta de requisições (segundos) 0.57 Avg. Content Length (bytes) 14,410 Testes por segundo 0.091 Testes com falha 0 Tempo médio de duração de cada teste (segundo) 105 Tempo médio de transações por segundo 0 Tempo médio de resposta por página (segundos) 1.50 Nome do servidor % Processamento Memória disponível (Mb) Aplic01 34.7 1,034 Aplic02 21.3 747 Banco De dados 0.25 1,332 Apresentação 69.1 627 URL (Link to More Details) Avg. Page Time (sec) Count /Pacote1/VisualizarItem.aspx 2.30 40 /Pacote2/ExibeFornecedor.aspx 1.94 250 /Default.aspx 1.33 10 /Pacote1/ConsultarItem.aspx 1.30 30 /Portal.aspx 0.77 40 / Pacote3 /pac/8/banner.swf 0.32 20

31. Arquitetura de Automação - Praxis Casos de teste.properties Arquivo com os casos de teste usados pela aplicação. Os mesmos casos de teste podem ser usados pelos testes de unidade e de sistema. Entidades de teste.properties Arquivo com as entidades utilizadas como entrada para os testes de unidade e sistema. Mensagens.properties Arquivo com as mensagens do sistema, normalmente usado para informar o resultado esperado dos casos de teste. [WILSON2009, MERCI2010] http://homepages.dcc.ufmg.br/~wilson

32. Macro Arquitetura de Automação RSDP * *RSDP – Rational Software Development Platform

33. Testadores Técnicos Automatizador de Teste O automatizador é um profissional com conhecimentos intermediários em programação e conhecimento básico de arquitetura de software. Normalmente conhece bem alguma linguagem de programação, domina Orientação a Objetos e algumas ferramentas e técnicas de programação. O automatizador de testes é o profissional responsável por escrever os testes predefinidos pelo engenheiro de testes ou arquiteto de testes. Engenheiro de Teste O engenheiro de testes é um profissional que procura se qualificar de forma a atender projetos de forma analítica e sistemática, sempre ponderando as decisões técnicas e tecnologias usadas para melhor desempenho durante todas as atividades de teste no projeto. A escolha das ferramentas de automação, a análise dos requisitos não funcionais, o conhecimento das limitações das linguagens, frameworks e bancos dados também são pontos que um bom engenheiro de testes deve observar. Arquiteto de Teste O arquiteto de Teste de Software é o profissional responsável pelo planejamento estratégico dos testes na organização. Esse planejamento vai desde aquisição de novas ferramentas, inclusão de novas atividades nos processos, arquitetura dos casos de teste, arquiteturas de reuso de testes (funcionais e não funcionais), frameworks de teste e etc.

34. Esse material foi inspecionado! Obrigado: • Fabíola Lara • Marlon Lima • Vanessa Vaz E ainda deve ter alguns bugs . . . 

35. Dúvidas?

36. Bibliografia • Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1. • BOEHM, B.W., 1981, Software Engineering Economics, Prentice Hall. • WHEELER, D.A., BRYKEZYNSKI, B., MEESON, R.N., 1996, Software Inspections: An Industry Best Practice, IEEE Computer Society. • PRESSMAN, R.S., 2001, Software Engineering: A Practitioner´s Approach, Fifth Edition, McGraw Hill. • [ISO9126] ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality • ISQTQB Glossário de termos usados no Teste de Software Versão 1.0 • Foundation Level ISTQB Syllabus, ISTQB • PÁDUA FILHO (2003), Wilson. Engenharia de Software – Fundamentos , Métodos e Padrões. 3ª Edição. LTC Editora, 2009. • RIOS, E., MOREIRA, T., SOUZA, A., CRISTALLI, R . Base de Conhecimento em Teste de Software 2ª Edição. Martins, 2007. • IEEE Standards Board, "IEEE Standard for Software Unit Testing: An American National Standard, ANSI/IEEE Std 1008-1987" in IEEE Standards: Software Engineering, Volume Two • IEEE Std 829-2008. • IEEE Std 610- • Hetzel, Bill, The Complete Guide to Software Testing, 1993, Ed.2 • CBT-TST110, Computer Based Training TST110 Principals of Software Testing for Testers; • IEEE729-1983 • NOGUEIRA, Elias. Automação de Teste - Mitos e Verdades, 4° Encontro Mensal ALATS, http://www.slideshare.net/elias.nogueira , 2009 • IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries; IEEE; New York, NY.; 1990 •MERCI2010, Praxis 3.0 – Wilson de Pádua. http://homepages.dcc.ufmg.br/~wilson/praxis/ 2010 • ZIELCZYNSKI, Peter, Traceability from Use Cases to Test Cases, http://www.ibm.com/developerworks/rational/library/04/r-3217/ IBM Rational Technical library, 2006

37. Muito Obrigado!