Mini curso de testes ágeis (agile testing)
Quer realizar esse curso na sua empresa, entre em contato conosco: cristiano.caetano@qualister.com.br
Visite: http://www.qualister.com.br/cursos
3. Instrutor
Cristiano Caetano
Email: cristiano.caetano@qualister.com.br
Apresentações: slideshare.net/cristianocaetano
Blog: cristianocaetano.wordpress.com
É certificado CBTS pela ALATS. Diretor técnico da Qualister com mais de 10 anos de experiência, já
trabalhou na área de qualidade e teste de software para grandes empresas como Zero G, DELL e HP Invent.
É colunista na área de Teste e Qualidade de software do site linhadecodigo.com.br e autor dos livros "CVS:
Controle de Versões e Desenvolvimento Colaborativo de Software" e "Automação e Gerenciamento de
Testes: Aumentando a Produtividade com as Principais Soluções Open Source e Gratuitas". Participante ativo
da comunidade de teste de software brasileira, é o criador e mantenedor do portal TestExpert: A sua
comunidade gratuita de teste e qualidade de software (www.testexpert.com.br).
www.qualister.com.br
5. Sobre a Qualister
• Fundação: 2007.
• Sobre a Qualister: A Qualister é uma empresa nacional, constituída a partir da união
de profissionais qualificados e certificados na área de testes e qualidade de
software, com o objetivo de integrar, implementar e implantar soluções com base nas
melhores práticas do mercado e normas internacionais.
• Colaboradores: A Qualister é composta por colaboradores pós-graduados e
certificados na área de testes (CBTS, CSTE) com larga experiência na indústria de
Tecnologia da Informação.
• Área de atuação: A Qualister é uma empresa especializada em serviços de
qualidade e teste de software. Tem como linhas de atuação consultoria em
teste/qualidade de software, outsourcing (terceirização dos serviços através da
alocação de profissionais) e treinamentos.
• Localização: A Qualister está localizada em Biguaçu na Grande Florianópolis/SC e
está instalada no CITEB – Centro de Inovação Tecnologia de Biguaçu no campus da
universidade UNIVALI.
www.qualister.com.br
7. Parcerias internacionais
Soluções para automação, profilling e gestão de testes
Soluções para testes de performance
Soluções de apoio a avaliação de usabilidade
www.qualister.com.br
10. Sopa de letrinhas
• Tópico 1
– Sub tópico 1
• Sub tópico 2
www.qualister.com.br
11. Manifesto Ágil
• Manifesto ágil - http://agilemanifesto.org
– Princípios básicos
• Indivíduos e interações são mais importantes que processos e
ferramentas.
• Software funcionando é mais importante do que documentação
completa e detalhada.
• Colaboração com o cliente é mais importante do que
negociação de contratos.
• Adaptação a mudanças é mais importante do que seguir
estritamente um plano.
www.qualister.com.br
13. Declaração de interdependência
• Declaração de interdependência - http://www.pmdoi.org/
– Princípios básicos
• Aumentamos o retorno de investimento tornando o fluxo contínuo de
valor o nosso foco principal.
• Entregamos resultados confiáveis pelo envolvimento de nossos
clientes em interações freqüentes e pela propriedade compartilhada.
• Esperamos pela incerteza e a gerenciamos por meio de iterações,
antecipação e adaptação.
• Liberamos a criatividade e a inovação, reconhecendo que os
indivíduos são a melhor fonte de valor e criamos um ambiente onde eles
possam fazer a diferença.
• Melhoramos o desempenho pela avaliação de resultados do grupo e
pela responsabilidade compartilhada para a eficácia da equipe.
• Melhoramos a eficácia e confiabilidade mediante estratégias,
processos e práticas.
www.qualister.com.br
14. The chaos ten
• The Chaos Ten
1. Suporte executivo
2. Envolvimento dos usuários
3. Gerente de projeto experiente
4. Objetivos de negócio claros
5. Escopo reduzido
6. Estrutura de software padronizada
7. Requisitos estáveis
8. Metodologia formal
9. Estimativas confiáveis
10. Outros
http://www.standishgroup.com/
www.qualister.com.br
15. Metodologias ágeis
• Agile Unified Process
• Dynamic Systems Development Method
• Essential Unified Process
• Feature Driven Development
• Open Unified Process
• Extreme Programming
• Scrum
• Lean
• Etc
www.qualister.com.br
17. Extreme Programming
Valores Princípios Práticas primárias Práticas corolárias
• Comunicação • Auto-semelhança • Ambiente Informativo •Análise da Raiz do Problema
• Coragem • Benefício Mútuo • Build de Dez Minutos • Base de Código Unificada
• Feedback • Diversidade • Ciclo Semanal • Código Coletivo
• Respeito • Economia • Ciclo Trimestral • Código e Testes
• Simplicidade • Falha • Desenvolvimento Orientado a • Continuidade da Equipe
• Fluidez Testes • Contrato de Escopo
• Humanismo • Design Incremental Negociável
• Melhoria • Equipe Integral • Envolvimento do Cliente Real
• Oportunidade • Folga • Equipes que Encolhem
• Passos de Bebê • Histórias • Implantação Diária
• Qualidade • Integração Contínua • Implantação Incremental
• Redundância • Programação em Par • Pagar Por Uso
• Reflexão • Sentar-se Junto
• Responsabilidade Aceita • Trabalho Energizado
http://www.extremeprogramming.org/map/project.html
www.qualister.com.br
18. Lean
• O Sistema Toyota de Produção, também chamado de Produção enxuta e Lean Manufacturing,
surgiu no Japão, na fábrica de automóveis Toyota, logo após a Segunda Guerra Mundial. Nesta época
a indústria japonesa tinha uma produtividade muito baixa e uma enorme falta de recursos, o que
naturalmente a impedia adotar o modelo da Produção em massa.
• No Sistema Toyota de Produção, os lotes de produção são pequenos, permitindo uma maior variedade
de produtos. Exemplo: em vez de produzir um lote de 50 sedans brancos, produz-se 10 lotes com 5
veículos cada, com cores e modelos variados. Os trabalhadores são multifuncionais, ou seja,
conhecem outras tarefas além de sua própria e sabem operar mais que uma única máquina. No
Sistema Toyota de Produção a preocupação com a qualidade do produto é extrema. A base de
sustentação do Sistema Toyota de Produção é a absoluta eliminação do desperdício. Foram
desenvolvidas diversas técnicas simples mas extremamente eficientes para proporcionar os resultados
esperados, como o Kanban e o Poka-Yoke.
– Kanban é uma palavra japonesa que significa literalmente registro ou placa
visível.
– Poka-yoke (pronuncia-se pocá-ioquê) é um dispositivo destinado a evitar a
ocorrência de defeitos em processos de fabricação e/ou na utilização de
produtos.
http://pt.wikipedia.org/wiki/Sistema_Toyota_de_Produ%C3%A7%C3%A3o
www.qualister.com.br
19. Lean
• Just in time é um sistema de administração da produção que
determina que nada deve ser produzido, transportado ou comprado
antes da hora exata. Pode ser aplicado em qualquer organização, para
reduzir estoques e os custos decorrentes. O just in time é o principal
pilar do Sistema Toyota de Produção ou Produção enxuta.
• Automação descreve um recurso de projeto de máquinas para
desempenhar o princípio de "Jidoka" utilizado pelo Sistema Toyota de
Produção . Automação, ou Jidoka, pode também ser descrito como
"automação inteligente'". Este tipo de automação implementa algumas
funções supervisoras antes das funções de produção. Na Toyota isto
geralmente significa que, se uma situação anormal aparecer, a
máquina pára e o os operários pararão a linha de produção.
Automação previne produtos defeituosos, elimina superprodução e
foca a atenção na compreensão do problema e assegurar que esse
problema não se repita.
http://pt.wikipedia.org/wiki/Sistema_Toyota_de_Produ%C3%A7%C3%A3o
www.qualister.com.br
21. Adoção das metodologias ágeis
State of Agile Survey - 2009
http://pm.versionone.com/StateOfAgileSurvey.html
www.qualister.com.br
22. Características do teste de software tradicional
BOEHM, Barry. Software Engineering
Economics. Prentice Hall PTR, 1981
CRAIG, R.D., JASKIEL, S. P., “Systematic Software Testing”, Artech House Publishers, Boston, 2002.
www.qualister.com.br
23. Características do teste de software tradicional
• É uma fase separada do desenvolvimento
• É realizado por um equipe independente
• Manual
• Informal
• Superficial
• Enfoque apenas na interface gráfica
• Ocorre no final de uma liberação ou no final do projeto
• Última (ou única) peneira da qualidade
• Os programadores desenvolvem e os testadores testam
www.qualister.com.br
25. Características do teste de software ágil
• Teste faz parte do processo de desenvolvimento
• Teste usado para complementar a documentação
• Teste usado para compartilhar o conhecimento
• Testes em todas as camadas da arquitetura (de
dentro para fora e de fora para dentro)
• Os programadores testam, os testadores testam,
os usuários testam (Test-Infected)
www.qualister.com.br
26. Características do teste de software ágil
• Cultura: A qualidade é responsabilidade de todos
www.motivatedphotos.com
www.qualister.com.br
27. Qualidade e teste de software sob a perspectiva ágil
• Práticas/Princípios mais relevantes:
– Desenvolvimento orientado a testes
– Refactoring
– Testes unitários
– Programação em par
– Integração contínua
– Testes de aceitação
www.qualister.com.br
28. Desenvolvimento orientado a testes
• Um teste vale mais do que milhares de opiniões.
Você pode me dizer que o sistema funciona, mas
enquanto você não me mostrar os resultados dos
testes, eu não vou acreditar. - Scott W. Ambler
Cristiano Caetano: Test Infected: Tá tudo dominado
www.qualister.com.br
29. Refactoring
• Refactoring é uma prática que prega melhoria da estrutura e do design
interno do código sem, no entanto, modificar o seu comportamento. Por
outro lado, esta prática só tem benefício quando realizada num código
coberto por testes de unidade em virtude de que os testes de unidade
detectam os defeitos imediatamente; garantindo assim que o código
mantenha o seu comportamento externo apesar das várias
modificações na sua estrutura interna.
Cristiano Caetano: Test Infected: Tá tudo dominado
www.qualister.com.br
30. Testes unitários
• Conceitos básicos
Classe Setup
Exercise
Mocks Método(a, b, c): d
Verify
Teardown
http://xunitpatterns.com/Four%20Phase%20Test.html
www.qualister.com.br
31. Testes unitários
A melhor maneira de
não introduzir bugs é
não escrever nenhum
código. A melhor
maneira de não
encontrar problemas é
não executar nenhum
teste. Testes unitários
inexistentes não
falham.
James Lyndsay
(tradução livre)
www.qualister.com.br
34. Testes unitários: TDD
• Test Driven Development também conhecido como Test First Design
é uma prática de desenvolvimento de software em que os testes de
unidade automatizados são escritos antes do código. Por meio do
suporte de frameworks XUnit para a realização de testes de unidade, os
testes são escritos incrementalmente encorajando a criação de um
código com baixo acoplamento e alta coesão.
RED GREEN REFACTOR
Cristiano Caetano: Test Infected: Tá tudo dominado
http://improveit.com.br/xp/praticas/tdd
www.qualister.com.br
35. Programação em par
• Programação em par é uma das práticas mais conhecidas do Extreme Programming. Ela
sugere que todo e qualquer código produzido no projeto seja sempre implementado por
duas pessoas juntas, diante do mesmo computador, revezando-se no teclado
• A programação em par é uma forma eficaz de reduzir a incidência de bugs em um
sistema. Isso se deve em grande parte às visões complementares que atuam durante o
uso dessa prática. Quando dois desenvolvedores estão programando em par, um deles
está com as mãos no teclado e no mouse. O outro está sentado ao lado, olhando para a
mesma tela e preocupado em resolver o mesmo problema. Ambos estão trabalhando
juntos na solução, embora apenas um esteja com as mãos no teclado. Eles conversam o
tempo todo e trocam idéias sobre a solução
www.qualister.com.br
36. Integração contínua
• Integração Contínua (Continuous Desenvolvimento em
time não é um típico
Integration), que é um dos pilares problema de dividir
fundamentais do Extreme para conquistar. É um
Programming (XP). A proposta da problema de dividir,
conquistar e integrar
Integração Contínua é a criação de um
ambiente separado e independente Kent Beck
do ambiente de desenvolvimento, onde (tradução livre)
as modificações individuais são
unificadas ao projeto principal, o
projeto é compilado, os testes são
rodados, a documentação é gerada e
assim por diante.
www.qualister.com.br
37. Integração contínua
• Independência: As tarefas de integração são executadas sem terem que concorrer com outros
aplicativos que normalmente estão rodando num computador de desenvolvimento. Além disso, a
utilização de um ambiente independente, fomenta o descobrimento de vários problemas, como por
exemplo, problemas de dependência (arquivos, dlls, chaves de registro) que fazem o software funcionar
no computador de desenvolvimento, no entanto, provavelmente não funcionaria no computador do
cliente;
• Freqüência: Quanto mais cedo uma modificação puder ser integrada ao projeto principal e testada,
mais cedo os erros serão detectados e corrigidos. A freqüência em que as tarefas de integração serão
realizadas, sem dúvida, vão depender do software que estiver sendo desenvolvido;
• Sincronização: A sincronização das modificações freqüente e contínua serve como um termômetro
para identificar a qualidade dos esforços da equipe de desenvolvimento. Além disso, integrações bem
sucedidas, elevam a moral de todos os membros da equipe;
• Automação: Entre outros benefícios, a Integração Contínua fornece um meio de automatizar processos
manuais e repetitivos, evitando que os processos sejam esquecidos ou que algum passo importante
não seja executado;
• Simplicidade: Uma vez que todo o processo seja automatizado, qualquer operação poderá ser
realizada por meio de um clique do mouse. Ninguém mais precisará encontrar o checklist para realizar a
compilação das bibliotecas compradas no ano passado, ou lembrar como se faz para gerar o manual
nos formatos desejados, ou até mesmo lembrar como se faz para gerar a instalação do software.
www.qualister.com.br
38. Testes de aceitação
http://www.agilemodeling.com/artifacts/userStory.htm
www.qualister.com.br
39. Testes de aceitação
• Clarifica o objetivo da estória
• Estabelece uma linguagem comum
• Fornece pistas sobre problemas importantes
• Garante que não existem assunções nas entrelinhas
• Fornece a perspectiva em relação ao que deve ser testado
• Serve como critério de aceitação
• Serve com gerador de idéias para testes unitários
• Compartilha o conhecimento sobre o negócio entre os
membros da equipe por meio de uma linguagem comum
www.qualister.com.br
40. Tópico
O papel do testador em
projetos ágeis
www.qualister.com.br
41. Papel do testador em projetos ágeis
• As metodologias ágeis foram criadas sob a perspectiva do
desenvolvimento.
• As práticas de testes são todas sob a perspectiva do
desenvolvimento:
– Testes unitários
– Programação em par
– Integração continua
– Etc
O papel do testador não é claramente definido
www.qualister.com.br
42. Papel do testador em projetos ágeis
• As principais atividades desempenhadas por um
testador num projeto ágil:
– Clarificar estórias e esclarecer suposições;
– Apoiar na escrita dos testes de aceitação;
– Prover estimativas para as atividades de testes;
– Automatizar os testes funcionais;
– Planejar//Executar testes avançados (performance, segurança,
usabilidade, etc);
– Prover feedback contínuo sobre os níveis de qualidade.
XP Testing Without XP: Taking Advantage of Agile Testing Practices
www.qualister.com.br
43. Os testes ágeis são formados por técnicas redundantes
• Testadores em projetos ágeis são redundantes. Sim, isso mesmo!
Testadores são como os airbags dos automóveis. Apesar dos cintos de
segurança serem eficientes na prevenção de acidentes, os airbags
oferecem uma proteção a mais; ou uma proteção para os tipos de
acidentes em que os cintos de segurança são pouco eficientes.
• Kent Beck, no seu livro "Extreme Programming Explained Embrace
Change" [5] afirma: "Você não pode resolver os defeitos com apenas
uma prática. Os defeitos são muito complexos e cheios de facetas e
nunca serão resolvidos completamente. (...) Algumas práticas são
certamente redundantes, identificando os mesmo tipos de defeitos.
Apesar dessas redundâncias serem um desperdício, seja cauteloso ao
remover práticas redundantes que sirvam para alguma proposta. (...) O
preço da redundância é mais do que pago pela economia de evitar
a ocorrência de um desastre".
Cristiano Caetano: Testes Extremos - Entenda o papel do testador em projetos ágeis
www.qualister.com.br
44. Perfil do testador em projetos ágeis
Conhecimento em computação
Conhecimento em testes
Programação
Certificações
Banco de dados
Técnicas
Sistemas operacionais
Ferramentas
Redes
Conhecimento no negócio Habilidades interpessoais
Regras/Leis Comunicação
Processos/Workflows Visão crítica
Realidade do usuário Respeito
www.qualister.com.br
45. Desafios do testador ágil
• Papel não
reconhecido
• Tentar usar as
práticas tradicionais
de testes em projetos
ágeis
• Dificuldade em
interagir ou colaborar
com um time
multifuncional
www.qualister.com.br
46. Tópico
• Testes manuais em
projetos ágeis
www.qualister.com.br
48. As duas faces do teste ágil
Testes confirmatórios
Testes unitários
Testes de aceitação automatizados
Integração contínua
Testes exploratórios
Testes de cenários/transações de uso
Usabilidade/Performance/Segurança/Etc
Testes investigativos
Adaptado de: Agile Testing and Quality Strategies: Discipline Over Rhetoric por Scott W. Ambler
Adaptado de: Agile testing quadrants por Brian Marick
www.qualister.com.br
49. Testes exploratórios
• O teste exploratório é, na sua definição mais
básica, a criação e a execução ao mesmo
tempo de um teste. Quando se realiza um teste
exploratório, normalmente o testador não tem
informações detalhadas sobre o que vai testar e
como vai testar. O testador se baseia na sua
experiência, assim como no conhecimento que ele
vai adquirindo sobre o aplicativo durante a
execução do teste exploratório. A partir dessa
perspectiva, podemos afirmar que o teste
exploratório é uma atividade iterativa e empírica
de exploração que exige idas e vindas num
processo de investigação contínuo onde a
intuição, a criatividade e a experiência do testador
são indispensáveis para garantir a eficiência do
teste.
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
50. Testes exploratórios
• Lee Copeland, autor do livro “A Practitioner's Guide to Software Test Design”, é
um dos poucos autores que conseguiu capturar as atividades realizadas
durante o teste exploratório sob o ponto de vista de um processo empírico e
iterativo. Segundo Copeland, um possível processo que pode ser aplicado
durante a execução de um teste exploratório, pode ser definido da seguinte
forma:
– Criação de uma hipótese. Um modelo mental representando o
funcionamento supostamente correto da área do aplicativo que será
testada.
– Planejar um ou mais cenários de teste que possam comprovar se a
hipótese é verdadeira;
– Aplicar os testes e observar os resultados;
– Avaliar os resultados contra a hipótese levantada no primeiro passo;
– Repetir esse processo até que a hipótese seja comprovada (ou não);
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
51. Testes exploratórios: abordagens formais para a geração de hipóteses
• Test Oracle
– Test Oracle é uma técnica comumente empregada para auxiliar o testador a predizer
o funcionamento supostamente correto do aplicativo ou de determinada do
aplicativo. A idéia fundamental dos Test Oracles é garantir consistência por meio da
observação e comparação. Digamos, por exemplo, que um novo portal de vendas
online está sendo construído para substituir um outro mais antigo. Durante a
realização dos testes do novo portal, o portal antigo sempre será usado como
referência; ele será um Test Oracle para garantir que o comportamento do novo
portal seja consistente. Por outro lado, vamos supor que um aplicativo de
contabilidade sempre exibe um preview dos relatórios antes iniciar a impressão. O
Test Oracle nesse caso é a consistência desse comportamento em todo o aplicativo;
ou seja, poderíamos considerar um defeito caso algum relatório não exibisse o
preview antes de iniciar a impressão. Padrão genérico para a identificação de Test
Oracles sob o ponto de vista da consistência:
• Consistência com a proposta: o comportamento deve ser consistente com a sua proposta;
• Consistência com o resto do aplicativo: o comportamento deve ser consistente com o
comportamento de outras áreas do aplicativo;
• Consistência histórica: o comportamento deve ser consistente ao longo do tempo;
• Consistência com aplicativos semelhantes: o comportamento deve ser consistente com o
comportamento de aplicativos similares, concorrentes, etc;
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
52. Testes exploratórios: abordagens formais para a geração de hipóteses
• Heurísticas
– Heurística é uma boa prática utilizada intuitivamente por testadores experientes. A
heurística se baseia no bom senso e na experiência de quem a utiliza; é uma forma
de auxiliar o testador a imaginar cenários de teste rapidamente sem ter muitos
detalhes sobre o aplicativo a ser testado. Na verdade, podemos afirmar que a
heurística é uma técnica cuja principal função é auxiliar o testador a fazer
suposições com algum embasamento formal. A idéia fundamental da heurística é
evitar que as suposições sejam realizadas por meio de chutes a esmo. Do ponto de
vista prático, vamos analisar a utilização dessa técnica para identificar cenários de
teste fictícios que poderiam ser realizados numa sessão de testes exploratórios,
conforme apresentando a seguir:
• (Baseado na experiência do testador): baseado na minha experiência em outros projetos,
os aplicativos que suportam línguas internacionais normalmente não funcionam direito em
plataformas com uma língua diferente da língua nativa dos desenvolvedores.
Freqüentemente os desenvolvedores esquecem hard-coded alguma constante que varia
conforme a língua (como por exemplo “C:Arquivos de Programas” ) que provavelmente
faria o aplicativo gerar uma exceção numa plataforma diferente (como por exemplo Chinês
Simplificado). Neste caso, durante a execução dos testes exploratórios devemos executar
um conjunto de testes básicos numa plataforma de língua oriental para confirmar se não
existem defeitos críticos.
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
53. Testes exploratórios: abordagens formais para a geração de hipóteses
• Phoenix Checklist
– A Phoenix checklist é basicamente um conjunto de perguntas que podem ser aplicadas a qualquer contexto e foi
desenvolvida nos Estados Unidos pela CIA. Este checklist é normalmente empregado para ajudar os agentes da
CIA a visualizar os problemas por diversas perspectivas diferentes. No ponto de vista dos testes exploratórios,
este checklist serve para auxiliar o testador a identificar novos cenários de teste ou para identificar a causa raiz
um defeito. A Phoenix checklist é dividida em um conjunto de perguntas para identificar e explorar o problema em
que se está lidando (Figura 1) e um outro conjunto de perguntas para auxiliar a identificar um possível plano para
a resolução do problema (Figura 2).
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
54. Testes exploratórios: abordagens formais para a geração de hipóteses
• Phoenix Checklist
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
55. Testes exploratórios: abordagens formais para a geração de hipóteses
• Five Whys
– Five Whys é uma outra técnica cujo propósito é promover uma análise profunda do problema em que estamos
lidando por meio do questionamento contínuo. Nesta técnica você deverá perguntar “Por que?” cinco vezes e
prover as respostas adequadas para cada pergunta. Ao final da quinta pergunta, você deverá analisar as
respostas em busca da causa raiz do problema. Uma vez identificada a possível causa raiz, devemos criar
cenários de testes exploratórios para realizar uma investigação mais detalhada, como pode ser visto no exemplo
abaixo:
– Por que todos os testes de impressão de relatórios falharam?
• Porque os dados parecem estar inconsistentes.
– Por que os dados parecem estar inconsistentes?
• Porque muitos dos testes de cadastro e consulta de cliente também falharam.
– Por que muitos dos testes de cadastro e consulta de cliente também falharam?
• Porque esta foi a primeira vez que os dados foram importados para essa plataforma.
– Por que esta foi a primeira vez que os dados foram importados para essa plataforma?
• Porque somente agora foi contratado um programador para realizar essa tarefa.
– Por que somente agora foi contratado um programador para realizar essa tarefa?
• Por que não existia ninguém no nosso time que tivesse experiência nessa plataforma para
realizar esta tarefa.
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
56. Testes exploratórios: Ferramentas de apoio
• Wink (free)
– http://www.debugmode.com/wink/
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
57. Testes exploratórios: Ferramentas de apoio
• BB TestAssistant ($225)
– http://www.bbsoftware.co.uk/BBTestAssistant.aspx
Cristiano Caetano: Testes exploratórios de A a Z
http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx
www.qualister.com.br
59. Tópico
• Automação de testes em
projetos ágeis
www.qualister.com.br
60. Teste de software ágil: Cedo, freqüente e automatizado
“Cada minuto entre,
quando um
programador achar
que uma estória está
terminada e realmente
provar que a estória
está terminada de
verdade por meio de
testes de aceitação, é
um minuto em que o
projeto está fora de
controle”
Ron Jeffries
(tradução livre)
http://www.extremeprogramming.org/map/loops.html
www.qualister.com.br
61. Teste de software ágil: Cedo, freqüente e automatizado
Teste é mais do que uma fase separada, é uma atividade
que se integra ao desenvolvimento. Teste contínuo é a
única maneira de garantir progresso contínuo.
Wikipédia sobre Agile Testing
Tradução Livre
www.qualister.com.br
62. Pirâmide dos testes tradicionais
Testes funcionais manuais
Foco na interface gráfica
Baseado no modelo V ou Cascata
Testes automatizados
Foco na interface gráfica via
capture/playback
Testes unitários e de integracão
Poucos ou inexistentes
Baseado em: Mike Cohn - Test Automation Pyramid
www.qualister.com.br
63. Pirâmide dos testes ágeis
Testes funcionais manuais
Poucos ou nenhum
Testes automatizados
Foco em testes de API
Poucos testes baseados na
interface gráfica
Testes unitários e de integracão
Abundantes (100% de cobertura)
Criados pelos desenvolvedores
Baseado em: Mike Cohn - Test Automation Pyramid
www.qualister.com.br
64. Testando em camadas diferentes
• Testando camadas diferentes
www.qualister.com.br
65. Testando em camadas diferentes
• Testes em todas as camadas da arquitetura (de dentro para
fora e de fora para dentro)
Código
API
Interface gráfica
www.qualister.com.br
66. Testando em camadas diferentes
• Testes em todas as camadas da arquitetura (de dentro para
fora e de fora para dentro)
www.qualister.com.br
67. Automação de testes
Interface Enfoque no
negócio via
TestComplete
QTP
Gráfica Interface gráfica Selenium
- Custo +
Fitnesse
API Enfoque no
negócio via API
Concordium
Cucumber
Código Testes unitários xUnit
Adaptado de: http://www.slideshare.net/dwhelan/agile-testing-and-the-role-of-the-agile-tester
www.qualister.com.br
68. Automação de testes
• Por que é dado um grande enfoque em
automação de testes?
– A automação oferece uma rede de
segurança por meio de regressões
completas
– A automação viabiliza ciclos curtos de
entrega
– A automação oferece feedback contínuo
– A automação pode fazer parte de um ciclo de
integração contínua
– A automação libera as pessoas para
realizarem tarefas mais criativas ao invés de
terem que executar testes manuais,
enfadonhos e repetitivos
www.qualister.com.br