O documento discute técnicas e motivação para testes de software, incluindo: 1) A importância de criar um ambiente propício à qualidade e testes através de padronização, boas práticas e ferramentas; 2) Diferentes técnicas de teste como teste unitário, funcional, de estresse e integração; 3) Como métricas e revisões podem melhorar a qualidade do código. O objetivo final é demonstrar na prática exemplos desses testes.

1. Qualidade em desenvolvimento
Java para todos os gostos
Daniel Wildt – dwildt@gmail.com
FACENSA – http://www.facensa.com.br
Faculdade Cenecista Nossa Senhora dos Anjos

2. Agenda
• Motivações
• Criando um ambiente de qualidade e propício a
testes
• Técnicas de Teste
• Prática!
• Exemplos de ferramentas que podem ser
utilizadas nestes processos.
2

3. Motivações - Histórica
• Por que não testar?
• Por que aceitar erros de software como algo do
dia a dia?
• Por que não se preocupar com a causa dos
erros, somente com a conseqüência destes?
• Por que não querer trabalhar em um ambiente
em melhoria contínua e melhores técnicas de
desenvolvimento?
• Por que não querer minimizar custos de
manutenção e aumentar a produtividade da
equipe?
3

4. Motivações - Comunicação
4

5. Motivações – Cultura de Equipe
• Criar cultura de testes
• Profissionais com múltiplos papéis são realidade
em muitas empresas de desenvolvimento.
Será?
• Profissional = Gerente + DBA + Analista +
Programador.
• Testadores e Gestão de Qualidade = Pessoal
do Suporte
• Suporte = Estagiários da empresa
• Pessoa responsável por assegurar qualidade
dos produtos e processos?
5

6. Motivações – Testar é trivial
• Testar funcionalidades é sempre igual?
• Os riscos são os mesmos?
• Os requisitos são os mesmos?
• O ambiente é o mesmo?
• A qualidade esperada é a mesma?
• Como medir qualidade? Quem determina?
• Qualidade, definição do Aurélio: Propriedade,
atributo ou condição das coisas ou das pessoas,
que as distingue das outras e lhes determina a
natureza.
6

7. Motivações - Agile
• Manifesto Ágil (http://www.agilemanifesto.org):
• “Estamos evidenciando maneiras melhores de
desenvolver software fazendo-o nós mesmos e
ajudando outros a fazê-lo. Através desse trabalho,
passamos a valorizar:
• Interação entre pessoas MAIS QUE processos e
ferramentas;
• Software em funcionamento MAIS QUE
documentação abrangente;
• Colaboração com o cliente MAIS QUE negociação de
contratos;
• Responder a mudanças MAIS QUE seguir um plano.
• Ou seja, mesmo tendo valor os itens à direita,
valorizamos mais os itens à esquerda.”
7

8. Motivações - Agile
• Alguns princípios do manifesto:
• A medida primária de um projeto é software em
funcionamento
• Em intervalos regulares o time vai refletir sobre como
se tornar mais efetivo (+ qualidade + produtividade)
• Pessoal de negócio e desenvolvimento devem
trabalhar unidos.
• Construa projetos com profissionais motivados. Dê
aos profissionais o ambiente necessário e dê suporte
as necessidades da equipe. Principalmente, confie na
equipe para ter o trabalho realizado.
• Maior prioridade é a satisfação do cliente e a entrega
contínua de software de valor agregado.
• Mais em: http://www.agilemanifesto.org/principles.html
8

9. Motivações - Agile
• ISO 9001 - Estabelece o conjunto de ações
preventivas necessárias para garantir a
qualidade de um produto após as fases de
projeto, desenvolvimento, produção, instalação
e serviços associados
• É um Sistema para Garantia da Qualidade: Um
Sistema de Garantia da Qualidade é um
conjunto planejado de atividades, que se
adiciona ao processo natural de fornecimento
de um dado produto, com o objetivo de reduzir o
risco de falhas.
9

10. Motivações – Agile
• CONCLUSÃO: Ser ágil não significa ser displicente!
• A qualidade é uma métrica constante! É necessária!
• Características importantes:
• Foco nas necessidades do cliente (resultado!)
• Liderança (comunicação!)
• Envolvimento das pessoas (pró atividade!)
• Melhoria contínua
• Tomada de decisão baseada em análise de dados e
informações (controle!)
• Todas estas características fazem parte dos princípios
da qualidade, existente na ISO 9000:2000
10

11. Criando um ambiente de qualidade e
propício a testes
• Permitir o conhecimento coletivo
• Collective Knowledge diferente de Collective
Code Ownership (prática XP)
• Uso de uma ferramenta de WIKI
• Padronizações:
• Código – Padrões de cada linguagem
• Plano de testes
• Boas práticas de Desenvolvimento
• Orientação a Objetos
• Padrões de Projeto
11

12. Criando um ambiente de qualidade e
propício a testes
• Os profissionais devem:
• Enfrentar/criar ciclos de melhoria contínua
(PDCA – Plan/Do/Check/Act)
• Cultura “test infected”.
• Entender a importância da automação de
testes e o seu impacto na evolução de
sistemas e melhoria da qualidade.
• Equipe integrada (Business and Development)
• Permitir o uso da criatividade da equipe!
12

13. Criando um ambiente de qualidade e
propício a testes
• Atitudes:
• Todas atividades no desenvolvimento de
software são construtivas. Testar é uma
atividade destrutiva!
• Pense de forma negativa quando estiver
criando planos de teste ou explorando o
software!
• Explore funcionalidades, pense no que não
foi pensado!
• Busque as ferramentas certas para cada tipo de
teste!
13

14. Técnicas de Teste
• Qual o objetivo de testar/validar um software?
• A atividade de teste não pode indicar a
ausência de erros.
• Desenvolvedores trabalham para terminar a
tarefa e verificar a ausência de erros. A
atividade de testes deve verificar a existência
de erros.
• Um teste bem sucedido apresenta um erro
ainda não descoberto.
14

15. Técnicas de Teste
• Qual o objetivo de testar/validar um software?
• Os planos de teste e execução são entradas
para a criação de métricas que podem guiar a
medição da qualidade do software e sugerir
processos de melhoria.
• Se testa para identificar se um software
possui defeitos e identificar se o software está
de acordo com a especificação.
[KOSCIANSKI, 2006]
15

16. Técnicas de Teste
• Testes Exploratórios [Tinkham, 2003]
• Testador não possui um plano formal sobre o
que deve testar.
• A criatividade é necessária
• O testador imagina uma situação a ser
verificada e aplica testes buscando
comprovar um possível erro.
• Medição e controle necessários para manter
quando e o que se testa usando esta técnica.
16

17. Técnicas de Teste
• Caixa Branca (White Box) ou Testes de Unidade
• No caso de metodologias ágeis como
eXtreme Programming, a prática é Test
Driven Development (TDD) [Beck, 2005],
onde o teste é criado antes do código em
questão
• Nesta situação o plano de teste evolui junto
com o desenvolvimento da funcionalidade.
• Ideal ter uma ferramenta para medir
cobertura de testes, para guiar o processo de
desenvolvimento
17

18. Técnicas de Teste
• Caixa Branca (White Box) ou Testes de Unidade
• JUnit
• J2ME Unit
• Emma
• Borland
OptimizeIT
18

19. Técnicas de Teste
• Caixa Branca (White Box) ou Testes de Unidade
• JUnit
• J2ME Unit
• Emma
• Borland
OptimizeIT
19

20. Técnicas de Teste
20

21. Técnicas de Teste
• Caixa Preta (Black Box) ou Testes Funcionais
• Baseado nos requisitos funcionais do
software, baseado na expectativa do cliente
• Operador concentrado nas ações que o
software deve realizar
• Útil para encontrar problemas como
[Koscianski 2006]:
• Funções incorretas ou omitidas;
• Erros de interface;
• Erros de comportamento ou desempenho;
• Erros de iniciação e término.
21

22. Técnicas de Teste
• Caixa Preta (Black Box) ou Testes Funcionais
• Borland SilkTest
• Java
• Mainframe
• Desktop
• Mobile
• Web
• BD
• Entre
outras
opções
22

23. Técnicas de Teste
• Caixa Preta
Selenium IDE
23

24. Técnicas de Teste
• Caixa Preta
• Desktop?
• JUnit pode ser utilizado para montar testes de
caixa preta
• UISpec4J
• SwingUnit
• Mobile?
• J2MEUnit pode ser utilizado para montar testes de
caixa preta
24

25. Técnicas de Teste
• Testes de Estresse
• Verificar disponibilidade e funcionamento do
sistema em situações adversas ou situações
extremas
• Carga de usuários
• Carga de transações
• Falhas na plataforma de execução
• Exemplo:
• Como o software reage com falta de espaço
em disco? E sem comunicação com um
determinado servidor?
25

26. Técnicas de Teste
• Testes de Estresse
• SilkPerformer
• Java
• WebServices
• Web
• Desktop
• Terminal
Services
• BD
26

27. Técnicas de Teste
• Testes de Estresse
• JMeter
• Validar
serviços
27

28. Técnicas de Teste
• Auditoria/Revisão e Peer review
• Manter qualidade de artefatos requer
disciplina.
• Fazer Peer Review: Revisão de código por
outro componente da equipe.
• Objetivos de Auditoria e Métricas:
• Auditoria e Métricas ajudam sua equipe a
criar disciplina de revisão contínua.
• Próprio desenvolvedor pode controlar
qualidade, não necessário depender 100% de
um setor de SQA.
28

29. Técnicas de Teste
• Exemplo de Métrica que pode ser utilizada no
desenvolvimento:
• Complexidade Ciclomática
• Mede o número de caminhos independentes de
um módulo de programa
• Através de uma classificação, indica a
complexidade de um método
• Esta medida pode auxiliar uma equipe a indicar
que tal módulo precisa ser refatorado ou então
precisa ter sua cobertura de testes melhorada
• Medida ajuda a guiar equipe no processo de teste
29

30. Técnicas de Teste
• Auditoria/Métricas de Código Fonte e Modelos
UML (Borland Together)
30

31. Técnicas de Teste
• Testes de Integração
• Testar a integração de componentes.
• Testar dependências de sistemas
• Necessária para indicar a certeza de que os
testes criados de forma isolada não estão
ocasionando erros em outras partes do sistema.
• Impossível liberar versão sem realizar um teste
deste nível.
• Ferramentas?
• Todas que possam validar as funcionalidades
que foram criadas.
31

32. Técnicas de Teste
• E o mais importante:
Verificação
X
Validação
?
• Mais: ver CMMI – Nível 3
32

33. Técnicas de Teste
http://www.ambysoft.com/essays/floot.html
33

34. Prática!
• Prática
• Mostrar Testes Unitários
• Mostrar Cobertura
• Mostrar Testes Funcionais
• Mostrar Testes de Carga
• Mostrar Auditoria de Fonte
34

35. Referências
• Beck, Kent; Andres, Cynthia. Extreme
Programming explained: embrace change. 2ª
edição. Editora Pearson Education, 2005.
• Koscianski, André; Soares, Michel dos Santos.
Qualidade de Software, São Paulo: Novatec,
2006.
• Pressman, Roger S. Engenharia de Software.
São Paulo: Makron, 2002.
• Manifesto Ágil. Disponível na internet em
http://www.agilemanifesto.org
35

36. Referências
• Tinkha, Andy; Kaner, Cem. Exploring
Exploratory Testing. Disponível na internet em
http://www.testingeducation.org/a/explore.pdf
• Método FLOOT de Scott Ambler. Disponível na
internet em
http://www.ambysoft.com/essays/floot.html
• Complexidade Ciclomática. Disponível na
internet em
http://www.sei.cmu.edu/str/descriptions/cyclomat
ic_body.html
36

37. Links
• FACENSA
• http://www.facensa.com.br
• Grupo de Estudos Java da FACENSA
• http://fuja.dev.java.net
• Grupo de Usuários XP do RS
• http://www.xp-rs.org
• Grupo de Usuários Delphi do RS
• http://www.dug-rs.org
• Grupo de Usuários Java do RS
• http://www.rsjug.org
37

38. Links
• Borland Developer Network – Artigos e acesso as
ferramentas – BDS, JBuilder, OptimizeIT (Cobertura e
Profiler), Silk Test e Silk Performer (Caixa Preta e
Desempenho), Together (Auditoria e Métricas)
• http://bdn.borland.com
• http://www.borland.com
• http://www.codegear.com
• http://www.aquasoft.com.br
• Borland CMMI Online
http://www.borland.com/us/services/cmmi.html
38

39. Links
• JUnit – Testes Unitários
• http://www.junit.org
• JMeter – Ferramenta para Testes de Estresse
• http://jakarta.apache.org/jmeter/
• Emma – Cobertura de Testes
• http://emma.sf.net
• Selenium – Ferramenta de teste Funcional
• http://www.openqa.org/selenium/
• PMD – Ferramenta de Auditoria de Código
• http://pmd.sf.net
39

40. Links
• CheckStyle – Ferramenta de Auditoria de
Código
• http://checkstyle.sf.net
• Testes unitários para aplicações mobile
http://j2meunit.sourceforge.net/
• Testes funcionais para aplicações Desktop
http://www.uispec4j.org/
https://swingunit.dev.java.net/
40

41. Perguntas e Respostas
41

42. Obrigado !!!!
42