Serviços de qualidade e teste de software

(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 autorais


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).


Twitter

twitter.com/c_caetano


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.


Alguns clientes


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


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-000


Tópico

• Introdução


Sopa de letrinhas

• Tópico 1
– Sub tópico 1
• Sub tópico 2


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.


Manifesto Ágil


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.


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/


Metodologias ágeis

• Agile Unified Process
• Dynamic Systems Development Method
• Essential Unified Process
• Feature Driven Development
• Open Unified Process
• Extreme Programming
• Scrum
• Lean
• Etc


SCRUM

http://www.scrumalliance.org/
http://www.slideshare.net/adrianotavares/gesto-gil-de-projetos
http://www.slideshare.net/Ridlo/engenharia-de-software-100-agil-scrum-fdd-e-xp


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

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

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

Metodologias ágeis


Adoção das metodologias ágeis

State of Agile Survey - 2009
http://pm.versionone.com/StateOfAgileSurvey.html

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.



• É 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



Cultura: Nós X Eles


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)


Características do teste de software ágil

• Cultura: A qualidade é responsabilidade de todos

www.motivatedphotos.com

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


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

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.


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

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)


Testes unitários


Testes unitários: Análise de cobertura de código


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

http://improveit.com.br/xp/praticas/tdd

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


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.



• 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.


Testes de aceitação

http://www.agilemodeling.com/artifacts/userStory.htm


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


Tópico

O papel do testador em
projetos ágeis


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


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

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

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


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


Tópico

• Testes manuais em
projetos ágeis


Testes manuais em projetos ágeis

Não existe

As duas faces do teste ágil

Testes confirmatórios

Testes unitários
Testes de aceitação automatizados

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


• 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


• 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);


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;



• 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.


• 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).



• Phoenix Checklist



• 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.

Testes exploratórios: Ferramentas de apoio

• Wink (free)
– http://www.debugmode.com/wink/



• BB TestAssistant ($225)
– http://www.bbsoftware.co.uk/BBTestAssistant.aspx



• TestExplorer ($200)
– http://www.testexplorer.com/


Tópico

• Automação de testes em
projetos ágeis


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

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


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

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

Testando em camadas diferentes

• Testando camadas diferentes



• Testes em todas as camadas da arquitetura (de dentro para
fora e de fora para dentro)

Código

API

Interface gráfica


• Testes em todas as camadas da arquitetura (de dentro para
fora e de fora para dentro)


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


• 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



• Tipos de testes automatizados
– Record-Playback testing
– Picture-driven testing
– Keyword-driven testing
– Behavior-driven testing


Record-Playback testing


Picture-driven testing

http://sikuli.org/

Keyword-driven testing


Behavior-driven testing

http://github.com/heynemann/pyccuracy

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-000


Serviços de qualidade e teste de software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a Serviços de qualidade e teste de software

Semelhante a Serviços de qualidade e teste de software (20)

Mais de Qualister

Mais de Qualister (20)

Serviços de qualidade e teste de software