• Save
Mini Curso Testes Ageis
Upcoming SlideShare
Loading in...5
×
 

Mini Curso Testes Ageis

on

  • 1,323 views

Mini curso de testes ágeis (agile testing)

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

Statistics

Views

Total Views
1,323
Views on SlideShare
1,319
Embed Views
4

Actions

Likes
8
Downloads
2
Comments
0

1 Embed 4

https://twitter.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mini Curso Testes Ageis Mini Curso Testes Ageis Presentation Transcript

  • (48) 4052-9536 / 9540 contato@qualister.com.br• Terceirização de profissionais• Consultoria de teste• Avaliação de usabilidade• Automação de testes• Testes de performance• Treinamentos Treinamento Testes ágeis www.qualister.com.br
  • Direitos autoraiswww.qualister.com.br
  • 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 View slide
  • Twitter twitter.com/c_caetanowww.qualister.com.br View slide
  • 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
  • Alguns clienteswww.qualister.com.br
  • 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 usabilidadewww.qualister.com.br
  • Contato• Email: contato@qualister.com.br• Telefone: (48) 4052-9540 e (48) 4052-9536• Endereço: Rua Patrício Antônio Teixeira, 317, Sala 406-A, Jardim Carandaí. Biguaçu/SC. CEP 88160-000www.qualister.com.br
  • Tópico • Introduçãowww.qualister.com.br
  • Sopa de letrinhas• Tópico 1 – Sub tópico 1 • Sub tópico 2www.qualister.com.br
  • 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
  • Manifesto Ágilwww.qualister.com.br
  • 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
  • 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
  • Metodologias ágeis• Agile Unified Process• Dynamic Systems Development Method• Essential Unified Process• Feature Driven Development• Open Unified Process• Extreme Programming• Scrum• Lean• Etcwww.qualister.com.br
  • SCRUMhttp://www.scrumalliance.org/http://www.slideshare.net/adrianotavares/gesto-gil-de-projetoshttp://www.slideshare.net/Ridlo/engenharia-de-software-100-agil-scrum-fdd-e-xp www.qualister.com.br
  • Extreme ProgrammingValores 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
  • 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
  • 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%A3owww.qualister.com.br
  • Metodologias ágeiswww.qualister.com.br
  • Adoção das metodologias ágeis State of Agile Survey - 2009 http://pm.versionone.com/StateOfAgileSurvey.htmlwww.qualister.com.br
  • 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
  • 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 testamwww.qualister.com.br
  • Características do teste de software tradicional Cultura: Nós X Eleswww.qualister.com.br
  • 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
  • Características do teste de software ágil• Cultura: A qualidade é responsabilidade de todos www.motivatedphotos.comwww.qualister.com.br
  • 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çãowww.qualister.com.br
  • 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 dominadowww.qualister.com.br
  • 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 dominadowww.qualister.com.br
  • Testes unitários• Conceitos básicos Classe Setup Exercise Mocks Método(a, b, c): d Verify Teardown http://xunitpatterns.com/Four%20Phase%20Test.htmlwww.qualister.com.br
  • 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
  • Testes unitárioswww.qualister.com.br
  • Testes unitários: Análise de cobertura de códigowww.qualister.com.br
  • 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/tddwww.qualister.com.br
  • 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
  • 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
  • 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
  • Testes de aceitação http://www.agilemodeling.com/artifacts/userStory.htmwww.qualister.com.br
  • 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 comumwww.qualister.com.br
  • Tópico O papel do testador em projetos ágeiswww.qualister.com.br
  • 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 – EtcO papel do testador não é claramente definidowww.qualister.com.br
  • 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 Practiceswww.qualister.com.br
  • 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 ágeiswww.qualister.com.br
  • 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 Respeitowww.qualister.com.br
  • 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 multifuncionalwww.qualister.com.br
  • Tópico • Testes manuais em projetos ágeiswww.qualister.com.br
  • Testes manuais em projetos ágeis Não existewww.qualister.com.br
  • 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 Marickwww.qualister.com.br
  • 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.aspxwww.qualister.com.br
  • Testes exploratórios• Lee Copeland, autor do livro “A Practitioners 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.aspxwww.qualister.com.br
  • 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.aspxwww.qualister.com.br
  • 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.aspxwww.qualister.com.br
  • 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.aspxwww.qualister.com.br
  • 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.aspxwww.qualister.com.br
  • 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.aspxwww.qualister.com.br
  • 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.aspxwww.qualister.com.br
  • 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.aspxwww.qualister.com.br
  • Testes exploratórios: Ferramentas de apoio• TestExplorer ($200) – http://www.testexplorer.com/ www.qualister.com.br
  • Tópico • Automação de testes em projetos ágeiswww.qualister.com.br
  • 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 detestes de aceitação, é um minuto em que o projeto está fora de controle” Ron Jeffries (tradução livre) http://www.extremeprogramming.org/map/loops.htmlwww.qualister.com.br
  • 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 Livrewww.qualister.com.br
  • 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 Pyramidwww.qualister.com.br
  • 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 Pyramidwww.qualister.com.br
  • Testando em camadas diferentes• Testando camadas diferenteswww.qualister.com.br
  • 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áficawww.qualister.com.br
  • Testando em camadas diferentes• Testes em todas as camadas da arquitetura (de dentro para fora e de fora para dentro)www.qualister.com.br
  • 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-testerwww.qualister.com.br
  • 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 repetitivoswww.qualister.com.br
  • Automação de testes• Tipos de testes automatizados – Record-Playback testing – Picture-driven testing – Keyword-driven testing – Behavior-driven testingwww.qualister.com.br
  • Record-Playback testingwww.qualister.com.br
  • Picture-driven testing http://sikuli.org/www.qualister.com.br
  • Keyword-driven testingwww.qualister.com.br
  • Behavior-driven testing http://github.com/heynemann/pyccuracywww.qualister.com.br
  • Dúvidas?• Contato: – Email: cristiano.caetano@qualister.com.br – Telefone: (48) 3285 5615 / 9645 5506 – Endereço: Rua Patrício Antônio Teixeira, 317, Sala 406- A, Jardim Carandaí. Biguaçu/SC. CEP 88160-000www.qualister.com.br