testes ageis sp

7/24/2019 Testes Ageis SP

1/151

www.qualister.com.br

Treinamento

Testes geis


2/151


Direitos autorais

Importante

proibidaacpiaereproduodequalq

uer

partedocontedodestaapresentaoincluin

do,

masnolimitadoa,textos,imagens,grficos

e

tabelas.Estaapresentaoprotegidapelas

leis

deCopyrightesopropriedadedeCristiano

Caetano eQualisterConsultoriaeTreinamento

LTDA.

Nopermitidomodificar,copiar,guarda

rem

bancodedadospblico,alugar,venderou

republicarqualquerpartedestaapresentao

,

semprviapermissoexplcitadoautor.

Quandohouverpermissodeusodestem

aterial,

obrigatriaarefernciabibliogrficaconform

e

asnormasvigentes.


3/151


Instrutor

Cristiano CaetanoEmail: [email protected]: slideshare.net/cristianocaetanoBlog: cristianocaetano.wordpress.com certificado CBTS pela ALATS. Diretor tcnico da Qualister com mais de 10 anos de experincia, j

trabalhou na rea de qualidade e teste de software para grandes empresas como Zero G, DELL e HPInvent. colunista na rea de Teste e Qualidade de software do site linhadecodigo.com.br e autor dos

livros "CVS: Controle de Verses e Desenvolvimento Colaborativo de Software" e "Automao eGerenciamento de Testes: Aumentando a Produtividade com as Principais Solues Open Source eGratuitas". Participante ativo da comunidade de teste de software brasileira, o criador e mantenedordo portal TestExpert: A sua comunidade gratuita de teste e qualidade de software(www.testexpert.com.br).


4/151


Twitter

twitter.com/c_caetano


5/151


Sobre a Qualister

Fundao: 2007.

Sobre a Qualister: A Qualister uma empresa nacional, constituda a partir da uniode profissionais qualificados e certificados na rea de testes e qualidade de software,com o objetivo de integrar, implementar e implantar solues com base nas melhoresprticas do mercado e normas internacionais.

Colaboradores: A Qualister composta por colaboradores ps-graduados ecertificados na rea de testes (CBTS, CSTE) com larga experincia na indstria de

Tecnologia da Informao. rea de atuao: A Qualister uma empresa especializada em servios de

qualidade e teste de software. Tem como linhas de atuao consultoria em teste/qualidade de software, outsourcing (terceirizao dos servios atravs da alocaode profissionais) e treinamentos.

Localizao: A Qualister est localizada em Biguau na Grande Florianpolis/SC e

est instalada no CITEB Centro de Inovao Tecnologia de Biguau no campus dauniversidade UNIVALI.


6/151


Parcerias internacionais


7/151www.qualister.com.br

Tpico

Projetos de desenvolvimentotradicionais



Desafios dos projetos de desenvolvimento tradicionais

No existe requisitos ou documentao

No existe a fase de projeto de software Carncia ou inexistncia de planejamento

Controle de mudana e de verses inadequados (ou inexistente)

Gerao de novas verses incorretas (problemas no merge, build, etc)

Os clientes no atualizam as novas verses do software com medo denovos defeitos (preferem conviver com os defeitos conhecidos)

Inexistncia de estimativas

Carncia ou inexistncia de um processo de desenvolvimento e detestes

No existe levantamento de mtricas e indicadores



Desafios dos projetos de desenvolvimento tradicionais

Desenvolvimento reativo (focado em correo ao invs de evoluo do

software) Foco na entrega (em detrimento a nveis mnimos de qualidade)

Dificuldade para que profissionais recm contratados comecem aproduzir em funo da falta de projeto, falta de documentao erequisitos (o conhecimento est na cabea de alguns)

Inexistncia de um time de testes (ou um time de testes formado porpessoas inexperientes na rea de testes)

Time de testes focado em testes superficiais (sem o uso de automaode testes, de ferramentas de gesto de testes, de gesto de defeitos,etc)



Cultura predominante no desenvolvimento de software tradicional

!" $%&

'"$(&)*+",-&.'/"."&0

!1" %2)3 %2',/)"

." ,%4&/2/)"0

!/.5&6$ (%+/&

(*,* 7%,/8'*,

/22"0

9"$(/:"&; )3

(,".)"0

!/.5&6$ 7*/+/5/)*, /22"

.%22% '*$("0



Tpico

Filosofia dedesenvolvimento gil



Sopa de letrinhas

Tpico 1

Sub tpico 1 Sub tpico 2



Manifesto gil: Valores

Indivduos e interao entre eles ao invs deprocessos e ferramentas;

Software em funcionamento ao invs dedocumentao abrangente;

Colaborao com o cliente ao invs denegociao de contratos;

Responder a mudanas ao invs de seguirestritamente um plano.

http://agilemanifesto.org/



Manifesto gil: 12 princpios fundamentais

1. Nossa maior prioridade satisfazer o cliente, atravs da entrega

contnua de software de valor.2. Aceitar mudanas de requisitos (processos geis se adquam a

mudanas, para que o cliente possa tirar vantagens competitivas)

3. Entregar software funcionando com freqncia, na escala de semanasat meses, com preferncia aos perodos mais curtos.

4.

Pessoas relacionadas negcios e desenvolvedores devem trabalharem conjunto e diariamente, durante todo o curso do projeto.

5. Construir projetos ao redor de indivduos motivados. Dando a eles oambiente e suporte necessrio, e confiar que faro seu trabalho.

6. O Mtodo mais eficiente e eficaz de transmitir informaes para um timede desenvolvimento atravs de uma conversa cara a cara.

http://agilemanifesto.org/principles.html



Manifesto gil: 12 princpios fundamentais

7. Software funcional a medida primria de progresso.

8.

Processos geis promovem um ambiente sustentvel. Ospatrocinadores, desenvolvedores e usurios, devem ser capazes demanter indefinidamente, passos constantes.

9. Contnua ateno excelncia tcnica e bom design, aumenta aagilidade.

10.

As melhores arquiteturas, requisitos e designs emergem de times auto-organizveis, motivados e confiantes.

11.Simplicidade: a arte de maximizar a quantidade de trabalho que noprecisou ser feito

12.Em intervalos regulares, o time reflete em como ficar mais efetivo,ento, se ajustam e otimizam seu comportamento de acordo.

http://agilemanifesto.org/principles.html



Tpico

Metodologias geis



Metodologias geis

Agile Unified Process

Dynamic Systems

Development Method

Essential Unified Process

Feature Driven Development

Domain Driven Development

Open Unified Process Extreme Programming

ScrumLean

Valores e Princpiosgeis



Metodologias geis

State of Agile Survey - 2011http://www.versionone.com/state_of_agile_development_survey/11/



Metodologias geis

Agility at Scale: Results from the Summer 2012 DDJ State of the IT Union Survey

www.ambysoft.com/surveys/agileTesting201211.html


21/151


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

SCRUM

http://www.slideshare.net/Ridlo/scrum-experience-o-tutorial-scrum


22/151


Extreme Programming

Valores Comunicao Coragem Feedback Respeito Simplicidade

PrincpiosAuto-semelhana Benefcio Mtuo Diversidade Economia Falha Fluidez

Humanismo Melhoria Oportunidade Passos de Beb Qualidade Redundncia Reflexo Responsabilidade Aceita

Prticas primriasAmbiente Informativo Build de Dez Minutos Ciclo Semanal Desenvolvimento Orientado aTestes Design Incremental

Equipe Integral Folga Histrias Integrao Contnua Programao em Par Sentar-se Junto Trabalho Energizado

Prticas corolriasAnlise da Raiz do Problema Cdigo ColetivoContinuidade da Equipe Contrato de EscopoNegocivel Envolvimento do Cliente Real

Implantao Diria Implantao Incremental Pagar Por Uso

http://www.extremeprogramming.org/map/project.html


23/151


Metodologias de desenvolvimento: Tradicional x gil

!"#$%&%'(#) +,%)

-.' /"0$%12#34 '*+* %)*(* +% +%2%.7":7/$%.)" +" (,"B%)" 6=*2%*+* .* %)*(* *.)%,/",; " 4&% 2C -&.'/".* =%$ 2% * '".'%(D1"+" 2/2)%$* .1" 2"-,%, .%.>&$* *:)%,*D1"; "& 2%B*; (*,)% +"

(,/.'E(/" 4&% "2 ,%4&/2/)"2 21" %2)37%/2

-.' #$#/5#12#34 (*,)% +" (,/.'E(/" +% 4&% " '".>%'/$%.)" 2"=,%" (,"=:%$* *&$%.)* * $%+/+* 4&% " 2"FG*,% 7*/ 2%.+"+%2%.7":7/+"; :%7*.+" * &$* =&2'* '".2)*.)% (", ,%8.*$%.)" %

$%:>",%2 2":&DH%2I J +%2%.7":7/$%.)" "'",,% +% -",$* /)%,*K7* %

%7":&K7*I

-.' '"%0(5#$#3 # /"'&033'34 (*,)% +" (,/.'E(/" +% 4&% "2 (,"'%22"2=%$ +%8./+"2 +%7% 2%, /$("2)"2 % %L%'&)*+"2 (*,* *22%5&,*, *

4&*:/+*+% +" (,"+&)"I ?%22"*2 21" '".2/+%,*+*2 '"$" ,%'&,2"2 +*

$%2$* -",$* 4&% %4&/(*$%.)"2 % -%,,*$%.)*2I M%2'".2/+%,* "

)*:%.)" (%22"*: % "2 -*)",%2 >&$*."2I

-.' '"%0(5#$#3 # /033'#34 (*,* $%:>", 5%,%.'/*, "2 (,"B%)"2 +%2"FG*,% *2 (%22"*2 +%7%$ 2%, ),*)*+*2 '"$" /.+/7E+&"2 % .1"

'"$" ,%'&,2"2I

-.' "6,%$#3N (,%22&(H%$ 4&% 6 ("22E7%: %2(%'/8'*, +% *.)%$1")"+"2 "2 ,%4&/2/)"2 +" 2"FG*,% * 2%, +%2%.7":7/+"; (,%B&+/'*.+" %

$&/)*2 7%O%2 /$(%+/.+" ,%*:/O*, *:)%,*DH%2 % *+*()*DH%2I P1"

7":)*+*2 (*,* %.),%5* +" 2"FG*,% %2(%'/8'*+" *" /.762 +" 2&'%22"

+" (,"B%)"I

-.' 708620%3 0 %(50"#12#34 Q+*()*$ '".2)*.)%$%.)% (", $%/" +%+%2%.7":7/$%.)" /.)%,*K7" % (*,K'/(*D1" *K7* +"2 &2&3,/"2 '"$

"=B%K7" +% *22%5&,*, * %.),%5* +" 2"FG*,% 4&% *5,%5&% 7*:", *"

':/%.)%I

-.' 9:"'&";1" 5%,*$ $&/)* 2"=,%'*,5* ." +%2%.7":7/$%.)" *2%, ,%*:/O*+" '"$ *K7/+*+%2; ,%&./H%2; *,)%-*)"2; %)' 4&%

'"$(,"$%)%$ * 7%:"'/+*+% +" +%2%.7":7/$%.)" % $&/)*2 7%O%2 "

2&'%22" +" (,"B%)"I

-.' 3%


24/151


Tpico

Testes geis


25/151


Testes geis

http://www.slideshare.net/dwhelan/agile-testing-and-the-role-of-the-agile-tester


26/151


Testes geis

O teste gil caracterizado por ser uma atividade:

desempenhada por todos os membros do time; que ocorre em todas etapas do ciclo de vida de desenvolvimento;

e que o ocorre frequentemente em ciclos contnuos;

atravs de mecanismos automatizados (quando possvel).


27/151


Cultura: A qualidade responsabilidade de todos

Testes geis

www.motivatedphotos.com


28/151


Testes geis

Nas metodologias geis, todos so responsveis pelos testes. A

qualidade do software responsabilidade de todos os membros do time.Cada membro do time contribui para a qualidade do software realizandotestes sob a sua perspectiva. Dessa forma, os testes ocorrem demaneira colaborativa e complementar, da seguinte maneira:

Os desenvolvedores testam sob a perspectiva do cdigo (mtodopor mtodo);

Os clientes testam sob a perspectiva da funcionalidade (estria porestria);

Os testadores complementam os testes dos desenvolvedores e dos

clientes, assim como, contribuem com abordagens de testes maisespecializadas


29/151


Testes geis

=030(2')2%


30/151


Testes geis

Por que dado um grande enfoque em automao de

testes?

A automao viabiliza ciclos curtos de entrega

A automao pode fazer parte de um ciclo de integrao

contnua fornecendo feedback contnuoA automao oferece uma rede de segurana por meio de

regresses completas

A automao permite a implementao do conceito DRY

(Dont Repeat Yourself) e libera as pessoas para realizaremtarefas mais criativas ao invs de terem que executar testesmanuais, enfadonhos e repetitivos


31/151


Testes geis

!"#$"# &'()*+(,*# -,(',*#

U"'" .* /.)%,-*'% 5,38'*

!"#$"# &'()*+(,*# ,'$+-,./,0+#

U"'" .* /.)%,-*'% 5,38'*

!"#$"# '(*$12*+# " 0" *($"32,)4+?"&'"2 "& /.%L/2)%.)%2

Baseado em: Mike Cohn - Test Automation Pyramid


32/151


Testes geis

!"#$"# "567+2,$82*+#

?"&'"2

!"#$"# 0" 9($"32,:4+ 0" ;*#$"-,

V"+%,*+"

!"#$"# '(*$12*+# " 0" *($"32,:4+"($2"


33/151


Testes geis

-Custo

+

Unidade e integrao entrecomponentes

Integraode sistema

UI


34/151


Testes geis

-Manuteno

+


Integraode sistema

UI


35/151


Testes geis

+Velocidad

e-


Integraode sistema

UI


36/151


Tpico

Processo e Planejamentogil


37/151


Testes geis

Processo gil

Teste gil

Teste

Tradicional

nfase no planejamento,processos e roteiros

detalhados

nfase nas pessoas


38/151


Testes geis

Planejamento de testes geis

O mnimo necessrio Guias e diretrizes

Planilhas

Checklists

MindMaps


39/151


Testes geis

Mudanas de paradigmas

Usando abordagens tradicionais o teste vira o gargalo


40/151


Testes geis

Matriz de rastreabilidade/Anlise de Impacto

Mtodo tradicional > Preditivo Mtodo gil > Reativo


41/151


Testes geis

Mtricas e indicadores

Ambiente informativo Radiatores de informao

T t i


42/151


Testes geis

Bugtracking

No usado. Tolerncia Zero. Defeitos no corrigidos = Dbito Tcnico

T i


43/151


Tpico

O Testador gil

O T t d il


44/151


O Testador gil

Desenvolvedor Usurio

Testador


O T t d il


45/151


O Testador gil


Qual o meu papel e as minhas responsabilidades?

Como eu posso atuar mais prximo do desenvolvedor?

O que devo fazer manualmente ou automaticamente?

Eu tenho que programar?

Como posso testar em ciclos curtos de desenvolvimento?

Como posso testar em um ambiente onde a mudana constante? Como posso testar sem requisitos detalhados?

P fil d t t d j t i


46/151


Perfil do testador em projetos geis

>'(?0&%'(?0&%


47/151


Atividades realizadas por um testador gil

Planejamento do Sprint Apoiar no levantamento das estrias

Apoiar na elaborao dos testes de aceitao Planejar o escopo do que vai ser testado

Prover estimativas para as tarefas de testes

Estabelecer a definio de pronto(DoD Definition of Done)

Durante o sprint Automatizar os testes de aceitao e funcionais

Programao em par

Teste em par Executar testes exploratrios

Executar testes no funcionais (Performance, Segurana, Usabilidade, etc)

Evidenciar os problemas

Assegurar que as estrias/tarefas esto prontas

Reunio diria Prover feedback sobre os nveis de qualidade e status das tarefas de testes

Reviso do Sprint Apoiar na demonstrao do produto

Retrospectiva do Sprint Fornecer indicadores bsicos de qualidade

http://www.slideshare.net/gustavoqz/participao-do-time-de-teste-em-projetos-scrum-2066606

Tpico


48/151


Tpico

Estratgia de Teste gil

Estratgia de testes geis


49/151



Testes geis x Testes tradicionais

Os objetivos so os mesmos Para confirmar se o software faz o que ele deve fazer

Para confirmar se o software no faz o que ele no deveria fazer

Para aferir o atendimento a um atributo de qualidade (implcito eexplcito)

Encontrar defeitos

A diferena a abordagem (mais leve, mais rpida, mais cedo)



50/151



Quadrantes do teste gil



51/151



]*/L"

!E7%:

Q:)"

!E7%:



52/151



V*.&)%./

=/:/+*+%

?",)*=/:/+*+%]*/L"

!E7%:

Q:)"

!E7%:



53/151





54/151



Tpico


55/151


Tpico

Integrao Contnua

Integrao contnua


56/151


Integrao contnua

Integrao Contnua (Continuous

Integration), que um dos pilaresfundamentais do ExtremeProgramming (XP). A proposta daIntegrao Contnua a criao de umambiente separado e independentedo ambiente de desenvolvimento, ondeas modificaes individuais sounificadas ao projeto principal, oprojeto compilado, os testes so

rodados, a documentao gerada eassim por diante.

Desenvolvimento emtime no um tpico

problema de dividirpara conquistar. umproblema de dividir,conquistar e integrar

Kent Beck(traduo livre)

Integrao contnua


57/151


Integrao contnua

Independncia:As tarefas de integrao so executadas sem terem que concorrer com outrosaplicativos que normalmente esto rodando num computador de desenvolvimento. Alm disso, a

utilizao de um ambiente independente, fomenta o descobrimento de vrios problemas, como porexemplo, problemas de dependncia (arquivos, dlls, chaves de registro) que fazem o software funcionarno computador de desenvolvimento, no entanto, provavelmente no funcionaria no computador docliente;

Freqncia: Quanto mais cedo uma modificao puder ser integrada ao projeto principal e testada,mais cedo os erros sero detectados e corrigidos. A freqncia em que as tarefas de integrao sero

realizadas, sem dvida, vo depender do software que estiver sendo desenvolvido;

Sincronizao:A sincronizao das modificaes freqente e contnua serve como um termmetropara identificar a qualidade dos esforos da equipe de desenvolvimento. Alm disso, integraes bemsucedidas, elevam a moral de todos os membros da equipe;

Automao: Entre outros benefcios, a Integrao Contnua fornece um meio de automatizar processos

manuais e repetitivos, evitando que os processos sejam esquecidos ou que algum passo importanteno seja executado;

Simplicidade: Uma vez que todo o processo seja automatizado, qualquer operao poder serrealizada por meio de um clique do mouse. Ningum mais precisar encontrar o checklist para realizara compilao das bibliotecas compradas no ano passado, ou lembrar como se faz para gerar o manualnos formatos desejados, ou at mesmo lembrar como se faz para gerar a instalao do software.

Integrao contnua


58/151


Integrao contnua

Integrao contnua


59/151


Integrao contnua

Integrao contnua


60/151


Integrao contnua

TeamCity: http://www.jetbrains.com/teamcity/

Hudson: http://hudson-ci.org/ Bamboo: http://www.atlassian.com/software/bamboo/overview

Jenkins: http://jenkins-ci.org/

CruiseControl: http://cruisecontrol.sourceforge.net/

Mais ferramentas em: http://en.wikipedia.org/wiki/Continuous_integration

Tpico


61/151


Tpico

Programao em Par

Programao em Par


62/151


Programao em Par

Programao em Par/Continuous Peer Review

Programao em par uma das prticas mais conhecidas do ExtremeProgramming. Ela sugere que todo e qualquer cdigo produzido no projetoseja sempre implementado por duas pessoas juntas, diante do mesmocomputador, revezando-se no teclado.

A programao em par uma forma eficaz de reduzir a incidncia de bugsem um sistema. Isso se deve em grande parte s vises complementaresque atuam durante o uso dessa prtica. Quando dois desenvolvedoresesto programando em par, um deles est com as mos no teclado e nomouse. O outro est sentado ao lado, olhando para a mesma tela e

preocupado em resolver o mesmo problema. Ambos esto trabalhandojuntos na soluo, embora apenas um esteja com as mos no teclado.Eles conversam o tempo todo e trocam idias sobre a soluo.

Tpico


63/151


Tpico

Teste de Unidade

Teste de Unidade


64/151


Teste de Unidade

Os desenvolvedores testam sob a perspectiva do cdigo (mtodo pormtodo); Enquanto nas metodologias tradicionais o desenvolvedor apenas escreve

cdigo, nas metodologias geis o desenvolvedor tambm responsvelpelos testes. No entanto, os testes do desenvolvedor tem o objetivo deprevenir e detectar defeitos na perspectiva do cdigo.

Ou seja, o desenvolvedor deve garantir a qualidade de cada unidade docdigo individualmente. Unidade, neste contexto, deve ser entendida comoo menor trecho de cdigo de um software que pode ser testado, podendoser uma funo ou procedimento em linguagens de programaoprocedurais ou mtodos de classes em linguagens orientadas a objetos.

Teste de Unidade


65/151


Teste de Unidade

Benefcios:

Testes unitrios fornece feedback imediato aodesenvolvedor quando ele comete um erro

Testes unitrios fornece um rede de segurana queidentifica regresses

Testes unitrios ajudam na identificao e isolamento dedefeitos

Testes unitrios em conjunto com profilers de coberturafornece uma visualizao das reas do software cobertas

por testes

Testes unitrios fornece um exemplo executvel de comofunciona o cdigo

Teste de Unidade


66/151


Teste de Unidade

Estilos de teste de unidade:

TAD (Test After Development)

TDD (Test Driven Development)

Teste de Unidade


67/151



onversor de temperatura

Conversor dever converter graus Celcius paragraus Fahrenheit de acordo com a seguinte

frmula:

C = (F !32) / 1,8F = C "1,8 + 32

Teste de Unidade


68/151



@Test

public void testConverter30GrausCelciusParaFahrenheit() {

Conversor c = new Conversor();

assertEquals(c.celciusToFahrenheit(30), 86, 00);

}

Teste de Unidade


69/151


TDD (Test Driven Development)

Alta coeso

Baixo acomplamento

Menor complexidade

Maior testabilidade

Tpico


70/151


p

Teste de Integraoentre Componentes

Teste de Integrao entre Componentes


71/151


g p

Integrao Bottom-Up (Caixa Branca)

Unidades Componentes

Sub-sistemas

API / WEB Services

Hardware Banco de dados

Teste de Integrao entre Componentes


72/151


g p

Integrao Bottom-Up (Caixa Branca)

9"$(".%.)% Q

9"$(".%.)% ]

M,/7%,

P)&=V"'[

Tpico


73/151


p

Anlise esttica decdigo

Anlise Esttica de Cdigo


74/151


Objetivos da anlise esttica de cdigo/Profilling

Avaliao da conformidade com padres de codificao Avaliao da conformidade com boas prticas de codificao

Avaliao de potenciais problemas de dead lock/race condition/exceptions

Avaliao de potenciais problemas de desempenho

Avaliao de vulnerabilidades de segurana

Avaliao da complexidade ciclomtica Vazamento de memria/recursos

Loops infinitos

Uso de dados/variveis no inicializados

Cdigo morto (no usado por nada)

Problemas de portabilidade para outras plataformas Entre outros



75/151


xxxx



76/151




77/151




78/151




79/151


CheckStyle: http://checkstyle.sourceforge.net/

Sonar: http://www.sonarsource.org/ Clover: http://www.atlassian.com/software/clover/overview

PMD: http://pmd.sourceforge.net/

FindBugs: http://findbugs.sourceforge.net/

Coverity: http://www.coverity.com/

Klockwork: http://www.klocwork.com/ Jdepend: http://clarkware.com/software/JDepend.html

Emma: http://emma.sourceforge.net/

Tpico


80/151


Testes de Aceitao/Story Tests

Teste de Aceitao/Story Tests


81/151




82/151


A estria no suficiente para descrever a necessidade do usurio

Mtodo 3C proposto por Ron Jeffries Card Conversation

Confirmation

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

http://xprogramming.com/articles/expcardconversationconfirmation/


83/151



84/151



85/151


U/L)&,%

9C+/5" +% 2&(",)%


86/151


O BDD uma tcnica de desenvolvimento de

software, onde os programadores desenvolvem osoftware guiados por comportamentos (testes deaceitao)

Os comportamentos so descritos em umalinguagem natural similar a linguagem do negcioe deve ser facilmente entendida pelo cliente e

demais membros do time.



87/151


Um comportamento descrito por uma estria e por testes deaceitao conforme o modelo propoposto por Dan North



88/151


9%.3,/"2 +%&2"


89/151


Vrias ferramentas auxiliam o programador a transformar

os comportamentos em verificaes automatizadas

Abordagens comuns:

Behavior-Driven

Data-Driven Keyword-Driven



90/151


Vrias ferramentas auxiliam o programador a transformar os comportamentosem verificaes automatizadas

9C+/5"

Q?_

_.)%,-*'%

5,38'*


91/151

www.qualister.com.br http://blog.dannorth.net/introducing-bdd/

http://jbehave.org/

jBehave

Behavior-Driven



92/151


W%2)%2 +% *'%/)*D1"

%$ :/.5&*5%$.*)&,*: .* 8:"2"8*

]MM

9"+/5" +% 2&(",)%

!"#$%&4&%

%.'*(2&:* */$(:%$%.)*D1" +*

*D1" +%2',/)* %$

:/.5&*5%$ .*)&,*:

9C+/5"YQ?_ +" 2/2)%$*

2%.+" %L%,'/)*+" (*,*

7*:/+*, &$ '"$(",)*$%.)"

C

D

E



93/151

www.qualister.com.br http://jbehave.org/



94/151


http://fitnesse.org/

http://www.spinsp.org.br/apresentacao/57_fitnesse.pdf

Fitnesse

Data-driven (tabela de deciso)



95/151


http://fitnesse.org/

http://www.spinsp.org.br/apresentacao/57_fitnesse.pdf



96/151


http://code.google.com/p/robotframework/

Robot Framework

Keyword-Driven (palavras-chave)



97/151



Robot Framework




98/151



Robot Framework




99/151



Robot Framework




100/151


https://github.com/robotframework/RIDE

Robot Framework




101/151


http://github.com/heynemann/pyccuracy

https://github.com/heynemann/pyccuracy/wiki/Actions-Reference

Pyccuracy

Keyword-Driven (palavras-chave)Cenrio 1 - Pesquisa passagem mais barata

Dado que

Eu navego para "www.empresaaerea.com"

Quando

Eu preencho a caixa de texto "origem" com "Florianpolis"

Eu preencho a caixa de texto "destino" com "Porto Alegre"

()

E eu clico no boto "Pesquisar"

Ento

Eu espero por 5 segundos

(...)

Tpico


102/151


Testes de Integraode Sistema

Teste de Integrao de Sistema


103/151


Integrao Top-Down (Caixa Preta)

Cenrios de uso End-to-End

Transaes de negcio

Workflows



104/151




105/151


Integrao Top-Down (Caixa Preta)

TestComplete QuickTest Pro

Rational Functional Tester

Selenium

Tpico


106/151


Testes No Funcionais



107/151


Qualidade do produto (NBR ISO/IEC 9126)

http://pt.wikipedia.org/wiki/ISO/IEC_9126



108/151


Qualidade do produto (NBR ISO/IEC 9126)

http://pt.wikipedia.org/wiki/ISO/IEC_9126

Tpico


109/151


Testes Exploratrios

Introduo


110/151


Introduo


111/151


O teste exploratrio , na sua definio maisbsica, o aprendizado, acriao e a execuo

ao mesmo tempo de um teste. Quando serealiza um teste exploratrio, normalmente otestador no tem informaes detalhadas sobre oque vai testar e como vai testar. O testador sebaseia na sua experincia, assim como no

conhecimento que ele vai adquirindo sobre oaplicativo durante a execuo do testeexploratrio. A partir dessa perspectiva, podemosafirmar que o teste exploratrio uma atividadeiterativa e emprica de explorao que exige

idas e vindasnum processo de investigaocontnuo onde a intuio, a criatividade e aexperincia do testador so indispensveis paragarantir a eficincia do teste.

Cristiano Caetano: Testes exploratrios de A a Z

http://www.linhadecodigo.com.br/artigo/1102/Testes-Explorat%C3%B3rios-de-A-a-Z.aspx

Introduo


112/151


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 exploratrio sob o ponto de vista de um processo emprico eiterativo. Segundo Copeland, um possvel processo que pode ser aplicadodurante a execuo de um teste exploratrio, pode ser definido da seguinteforma:

Criao de uma hiptese. Um modelo mental representando ofuncionamento supostamente correto da rea do aplicativo que sertestada.

Planejar um ou mais cenrios de teste que possam comprovar se ahiptese verdadeira;

Aplicar os testes e observar os resultados;

Avaliar os resultados contra a hiptese levantada no primeiro passo; Repetir esse processo at que a hiptese seja comprovada (ou

no);



Introduo


113/151


Testes exploratrios (Caractersticas) Os testes no so criados com antecedncia

No segue um roteiro rgido (segue guias e diretrizes)

baseado em pensamento estruturado e explorao livre

adaptativo e flexvel

Enfoca o aprendizado em paralelo

A execuo do teste guiada/aprimorada com base em execuesanteriores

Exige profissionais experientes

Expande o escopo dos testes tradicionais baseados em roteiros(Injeta/introduz variao aos casos de testes)

Fluxo imediato de feedback (e correo de curso)

Amplifica a cobertura dos testes

Introduo


114/151


Testes exploratrios (Pontos fracos, restries e limitaes)

Oferece meios limitados de gesto das tarefas (difcil de coordenar)

Gera poucos (ou nenhum) indicadores e mtricas

Baixa reusabilidade dos testes

Baixa gerao de evidncias

Forte dependncia do testador (a experincia do testador afeta aqualidade do teste)

Testadores diferentes usando estilos de explorao diferentesdescobrem defeitos diferentes

No repettivel com exatido (inadequado para testes regressivos)

um teste puramente manual

Exploratory Testing An Agile Approach

http://xebee.xebia.in/wp-content/uploads/2009/11/Exploratory-Testing-an-Agile-approach.pdf

Introduo


115/151


Tipos de testes exploratrios

Ad-hoc

Baseado em sesses

Teste baseadoem roteiros Ad-hoc

Baseado emsesses

Muitofor

mal

Muitoinformal

Teste exploratrio baseado em sesses


116/151


Conceitos

Teste exploratrio baseado em sesses oferece ummecanismo para planejar, acompanhar e dar maiorvisibilidade ao teste exploratrio, sem no entanto,burocratizar a explorao



117/151


Elementos bsicos

Em uma sesso de trabalho com um perodopr-determinado de tempo, um testadorinterage com o software para cumprir os

objetivos de uma misso de testes e relatar osresultados.

James Bach. Exploratory Testing Explained

http://www.satisfice.com/articles/et-article.pdf



118/151


Elementos bsicos

Em uma sesso de trabalho com um perodopr-determinado de tempo, um testadorinterage com o software para cumprir os

objetivos de uma misso de testes e relatar osresultados.

James Bach. Exploratory Testing Explained

http://www.satisfice.com/articles/et-article.pdf



119/151


Testador No teste exploratrio o orculo o testador. Neste caso, a

experincia do testador afeta diretamente a qualidade do testeexploratrio.

Caractersticas: Criatividade

Observao cuidadosa

Metdico

Pensamento crtico

Aprendizado rpido

Intuio

Improviso

Auto-gerenciamento Idias diversificadas: baseia na sua experincia, mas usa heursticas, checklists, diretizes

e tcnicas formais (classes de equivalncia, valores limtrofes, tabelas de deciso,diagramas de estado, fluxogramas, etc)

Recursos: usa ferramentas de apoio



120/151


Software

o produto alvo da misso do teste exploratrio. Para que o testeexploratrio ocorra, necessrio que o software (funcionalidade,tela, etc) j tenha sido desenvolvido.



121/151


Misso

A misso tem o objetivo de determinar o objetivo da sesso de testeexploratrio de forma sucinta.

A misso determina o que deve ser testado (no como o teste deve serrealizado).

A misso pode ser criada na hora do teste exploratrio ou ser escolhidadentre uma lista de misses pr-determinadas (backlog de misses).

Ao final da sesso de teste exploratrio, novas idias, oportunidades ouproblemas encontrados pelo testador podem ser usados para a criao de

novas misses.



122/151


Misso

As misses no devem ser muito especficas (explorao de menos de 30minutos) ou muito genricas (explorao com mais de 2 horas)

Muito especfica:Verificar se o campo CPF obrigatrio.

Muito genrica: Verificar se o mdulo de emisso de NF Eletrnica funciona.



123/151


Misso

De onde surgem as misses: Reunies/Conversas com usurios, desenvolvedores, gerentes, etc

Estrias/Requisitos

Itens do menu do software

Manuais/Regulamentos/Leis

Softwares concorrentes/similares Verses antigas do mesmo software

Riscos

Etc..



124/151


Misso

De onde surgem as misses:

Catlogo de heursticas Heursticas com base na intuio e julgamento

Heurstica de consistncia

Heurstica HICCUPPS

Heurstica IOSC

Checklists Diagramas

Personas

Tolerncia a erros

Erros comuns

Pensamento lateral orientado a questionamentos

Especificaes Atributos da Qualidade

Learning Styles and Exploratory Testing

http://www.kaner.com/pdfs/ExploratoryTestingandLearningStyles(Final).pdf



125/151


Heurstica HICCUPPS

Validao do comportamento do software com base nas seguintes

caractersticas: (H)istory: As funcionalidades do software devem se comportar de

forma consistente ao longo do tempo

(I)mage: O comportamento e aparncia do software est alinhada com

a imagem que o fabricante deseja expor ao usurio

(C)omparable products: O software compatvel com softwaresimilares

(C)laims: O software se comporta de acordo com os requisitos

(U)ser expectation: As funcionalidades se comportam conforme a

expectativa do usurio

(P)roduct itself: As funcionalidades so consistentes entre si (P)urpose: As funcionalidades atendem o seu propsito

(S)tatuses: O produto est em conformidade, com leis, regulamentos,diretrizes, etc

Testing without a map

http://www.developsense.com/articles/2005-01-TestingWithoutAMap.pdf



126/151


Heurstica IOSC

Validao do comportamento do software com base nas seguintes

caractersticas: Input: Explorao do comportamento do software sob a perspectiva das

entradas de dados.

Output: Explorao do comportamento do software sob a perspectiva dassadas de dados.

Storage: Explorao do comportamento do software sob a perspectiva dosdados armazenados.

Computation: Explorao do comportamento do software sob a perspectivada computao/processamento dos dados.



127/151


Tolerncia a erros

Nesta tcnica, o testador d maior enfoque na criao de testes para demonstrar acapacidade do software em lidar, tolerar, tratar e manipular situaes com erro,introduzindo entradas/informaes da seguinte forma:

Ausente

Incorreta

Estranha

Fluxo errado

O objetivo desta tcnica demonstrar se o software trata/lida com situaeserrneas adequadamente e exibe mensagens adequadas e informativas (ao invsde erros no tratados).



128/151


Checklists

F50< # 20"%G" H0"%G$' I-JKL

A/$/)%2 S7*:",%2 :/$E),"-%2; *'/$* +"2 :/$/)%2; %)'T

_.)%,,&(DH%2 S'*.'%:*,; +%2:/5*,; +%2'".%')*,; $*)*, " (,"'%22"; %)'T

9".85&,*DH%2 S7%,2H%2 +/-%,%.)%2 +% 2"FG*,%; 2/2)%$* "(%,*'/".*:;

>*,+G*,%T

A"'*:/O*D1"Y_.)%,.*'/".*:/O*D1"

Q&2`.'/* +% ,%'&,2"2 S-*:)* +% %2(*D" %$ +/2'"; $%$C,/*; =*.+* +% ,%+%;

%)'T

"; %)'T

9".'",,`.'/* S7%,/8'*, * *)"$/'/+*+% +* ),*.2*D1" '"$ $a:K(:"2 &2&3,/"2

'".'",,%.)%2T

M%(%.+`.'/* S7%,/8'*, * '".2/2)`.'/* +% ,%:*'/".*$%.)"2 $%2),%R+%)*:>%T

V*),/L 9XbM S*',c./$" +% 9,%*)%; X%*+; b(+*)% % M%:%)%T

Test Heuristics Cheat Sheet

http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf



129/151


Diagramas (diagramas de estado, sequncia, etc)



130/151


Excurses

No livro "Exploratory software testing: tips, tricks, tours, and techniques to

manual testers", James Whittaker prope um catlogo de Excursesusando a metfora do turista.

Business district Guidebook tour: Explorar o sistema de acordo as informaes contidas no manual;

Money tour: Explorar o sistema nas reas que envolvem transaes monetrias (vendas,parcelamentos, etc);

Landmark tour: Explorar as funcionalidades-chave do sistema;

Intellectual tour: Explorar as funcionalidades e transaes complexas que exigemprocessamento intenso ou a execuo de clculos complexos;

FedEx tour: Explorar como os dados/informaes so usados no sistema (entrada de dados/processamento dos dados/uso/sada dos dados);

After-hours tour: Explorar rotinas complementares que no so usadas regularmente (backups,processamentos batch noturnos, rotinas de manuteno, etc);

Garbage collectors tour: Explorar uma rea ou funcionalidade especfica do sistema de formasuperficial buscando problemas bvios;



131/151


Gerador de idias



132/151


Gerador de idias



133/151


Sesso Compreende um perodo ininterrupto de tempo com durao de cerca de 1 a 2 horas.

Alguns autores recomendam 90 minutos no mximo. Sesses com menos de 45 minutosso classificadas como Curta, sesses com 90 minutos so classificads como Normale sesses com aproximadamente 2 horas so classificadas como Longa.

Os testes realizados durante a sesso de responsabilidade do testador. O Testeexploratrio baseado em sesses no determina rigidamente o como os testes devemser realizados (ou quais testes devem ser realizados)

Durante a sesso, o testador cria e simultneamente executa os testes. Alm disso,tambm aprende mais sobre o funcionamento e comportamento do software.

Para cada misso, podem ocorrer vrias sesses de testes exploratrios.

O foco da sesso cumprir o objetivo da misso. No entanto, permitido explorar novasoportunidades ou demais questes pendentes. Alm disso, durante a sesso o testadortambm investiga e registra defeitos, assim como, configura e prepara o ambiente detestes.



134/151


Sesso (Anatomia de uma Sesso) Preparao (Setup): Preparao do ambiente de testes,

configurao de massa de dados, leitura de manuais, requisitos,diagramas, etc.

Especificao (Design): Definio (modelo mental) dos casos detestes (hipteses) baseados em heursticas, idias, checklists, etc.

Execuo (Execution): Execuo propriamente dita do testeexploratrio para demonstrar se as hipteses/expectativas foramatendidas (ou no).

Oportunidades (Opportunities): Tempo gasto em atividades/exploraes/Investigaes que no esto no escopo ou foco damisso.

Relato de defeitos (Bug investigation/Report): Investigao eregistro de defeitos.



135/151


Relatar os resultados

Durante o teste exploratrio o testador registra os resultados no Relatrio

da Sesso.

O relatrio inclui notas sobre o que foi testado, o ambiente de testes,arquivos de dados, defeitos encontrados, algumas mtricas bsicas, entreoutras informaes.


M%33.' M%)%,$/.* " "=B%K7" +" )%2)%


136/151


M%33.' M%)%,$/.* " "=B%K7" +" )%2)%

+"0#3 M%2',%7% *2 3,%*2Y-&.'/".*:/+*+%2 ".+% "2 )%2)%2 -",*$ ,%*:/O*+"2I P%,7%(*,* +%)%,$/.*, * '"=%,)&,* +"2 )%2)%2

N*,+G*,%Y2"FG*,%; "&),*2 *K7/+*+%2 .1" ,%:*'/".*+*2 *" )%2)%; %)'T

M%33.' 8 S/'"5:(%$#$0 9"$(*,*D1" +" (%,'%.)&*: +" )%$(" 5*2)" .* $/221" %$ ,%:*D1" *" )%$("

5*2)" %$ "(",)&./+*+%2

N"T:%2'3 $0 $#$'3 A/2)* +"2 *,4&/7"2 +% +*+"2 &2*+"2 '"$" $*22* +% +*+"2

K'5#3 M%2',%7% 2&'/.)*$%.)% " 4&% -"/ ,%*:/O*+" +&,*.)% " )%2)%

=0O0%5'3 M%2',%7% "2 +%-%/)"2 %.'".),*+"2

U:035V03 /0($0(503 M%2',%7% *2 4&%2)H%2 (%.+%.)%2 4&% %L/5%$ &$* /.7%2K5*D1"

Exemplotpico

deumRelatrio

deSesso

Session-Based Test Managementhttp://www.satisfice.com/articles/sbtm.pdf


M%33.' M%)%,$/.* " "=B%K7" +" )%2)%


137/151


M%33.' M%)%,$/.* " "=B%K7" +" )%2)%

+"0# M%2',%7% *2 3,%*2Y-&.'/".*:/+*+%2 ".+% "2 )%2)%2 -",*$ ,%*:/O*+"2I P%,7%(*,* +%)%,$/.*, * '"=%,)&,* +"2 )%2)%2

N*,+G*,%Y2"FG*,%; "&),*2 *K7/+*+%2 .1" ,%:*'/".*+*2 *" )%2)%; %)'T

M%33.' 8 S/'"5:(%$#$0 9"$(*,*D1" +" (%,'%.)&*: +" )%$(" 5*2)" .* $/221" %$ ,%:*D1" *" )%$("5*2)" %$ "(",)&./+*+%2

K'5#3 M%2',%7% 2&'/.)*$%.)% " 4&% -"/ ,%*:/O*+" +&,*.)% " )%2)%

=0O0%5'3 M%2',%7% "2 +%-%/)"2 %.'".),*+"2

U:035V03 /0($0(503 M%2',%7% *2 4&%2)H%2 (%.+%.)%2 4&% %L/5%$ &$* /.7%2K5*D1" ("2)%,/",



138/151


Prestao de contas (Debrief)

A prestao de contas uma conversa rpida entre o testador e o lder/

gerente de testes que ocorre aps a realizao do teste exploratrio (no uma etapa obrigatria). Nesta conversa o testador descreve o queaconteceu durante a sesso, o problemas, seus sentimentos, etc. JonBach, um dos criadores do teste exploratrio baseado em sesses,recomenda que a prestao de contas siga a estrutura descrita peloacrnimo PROOF (abaixo):

(P) Past (passado): O que aconteceu durante a sesso?

(R) Results (resultados): Quais resultados foram atingidos durante asesso?

(O) Obstacles (obstculos): Quais obstculos atrapalharam aexplorao?

(O) Outlook (previso/perspectiva): O que ainda falta fazer?

(F) Feelings (sentimentos): Como o testador se sente (em relao aoteste ou qualidade)?

How to Manage and Measure Exploratory Testinghttp://www.quardev.com/content/whitepapers/how_measure_exploratory_testing.pdf

Tpico


139/151


Ferramentas de apoio aoTeste Exploratrio

Ferramentas de apoio

P l t E l N t d


140/151


Papel, caneta, Excel e Notepad


Wi k (f )


141/151


Wink (free)

http://www.debugmode.com/wink/




G t d i bl


142/151


Gravar etapas para reproduzir um problema

Nativo do Windows - Gratuito


S i T t


143/151


Session Tester

http://sessiontester.openqa.org/download.html


S i C t


144/151


Session Creator

https://sites.google.com/site/sessioncreator/the-tool/downloads


T tLi k


145/151


TestLink

http://www.teamst.org/


TestExplorer ($200)


146/151


http://www.testexplorer.com/


Qtrace ($ 49)


147/151


Qtrace ($ 49)

http://www.qasymphony.com/qtrace-features.html


TestPad (9$ por usurio por ms)


148/151


TestPad (9$ por usurio por ms)

https://ontestpad.com/


TestPad


149/151


TestPad



TestPad


150/151


TestPad


Dvidas?

Contato


151/151

Contato:

Email: [email protected]

Telefone: (48) 3285 5615 / 9645 5506

Endereo: Rua Patrcio Antnio Teixeira, 317, Sala 406-A, Jardim Caranda. Biguau/SC. CEP 88160-000

testes ageis sp

Documents