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.
Agile Transition. PMBOK knowledge areas and how values, principles and agile ...
Java para testes de qualidade
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
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
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
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
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
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