Praticas e Tendencias em Testes Thoughtworks PDF

PRTICAS E
TENDNCIAS
EM TESTE
Um conjunto de experincias
entregando software de alta qualidade
2015
compartilhe este ebook
AUTORES
DANIEL
AMORIM
MARCOS
BRIZENO
NEIL PHILIP
CRAVEN
RAFAEL
GARCIA
RAQUEL
LIEDKE
MAX
LINCOLN
LUCAS
MEDINA
FABIO
PEREIRA
NICHOLAS
PUFAL
TAISE
SILVA
LEONARDO
STEFFEN
RODRIGO
TOLLEDO
JURACI
VIEIRA
CONTEDO
6 regras de ouro para ser um QA arretado* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Testador gil 3.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Preveno de defeitos usando tcnicas geis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Mockar ou no mockar, eis a questo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 noes bsicas essenciais para a criao de uma sute de automao para aplicativos web. . . . . . . . . 20
Escreva testes melhores em 5 passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Trs falcias sobre BDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Apenas execute o build novamente - ele deve ficar verde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Entrega Contnua com build quebrado e conscincia limpa. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Melhorando a qualidade de projetos atravs do poder das nuvens. . . . . . . . . . . . . . . . . . . . . . . . 38
Melhoria da qualidade com a nuvem - parte II. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Protractor: testando aplicaes angularJS com uma soluo integradora . . . . . . . . . . . . . . . . . . . . 47
Protractor na prtica em 3 passos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Gatling: uma ferramenta de testes de performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Alternativas ao Testflight para Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
OK, O CDIGO DE
TESTE TESTA O CDIGO
FUNCIONAL.
MAS QUEM TESTA
O CDIGO DE TESTE?
Anos atrs, seguidamente me faziam tal pergunta. E eu me
enrolava todo tentando responder. Eram os anos iniciais de
mtodos geis. TDD e integrao contnua ainda eram novidade
para a maioria das pessoas nas conferncias de TI. E eu ali,
tentando falar de um pedacinho da parte visvel do iceberg.
Nessa poca, a indstria de software j se sentia evoluda. UML,
base de dados relacional, Java (escreva uma vez e execute em
qualquer lugar!). Ah, e os cargos. Todos bem definidos e de acordo
com as fases de desenvolvimento de software. Analista do negcio,
desenvolvedor e testador. E, para garantir o sucesso, arquitetos e
gerentes.
Mas o nosso mundo mudou, e rpido! Est tudo nas nuvens. Os

mtodos so geis, e estamos no caminho da Internet das Coisas.
Ferrou! Desculpem o meu francs, mas ferrou. Como vamos
construir software de qualidade? Constri a que depois algum
testa no cola mais. Tampouco aquela minha viso simplista de
que teste automatizado com integrao contnua iria resolver
todos os seus problemas.
Era apenas a ponta do iceberg e, quando voc ia mergulhar para
entender a parte imersa, veio o tal do Global Warming e derreteu
tudo. O bloco de gelo no est mais separado. Derreteu e se
juntou ao mar que o rodeava.
A metfora era falha! A separao entre departamentos tambm.

Assim como a clareza das fases de desenvolvimento de software
e seus respectivos guardies. Qualidade e, portanto, testes e
verificao no so mais atividades separadas da criao do
software.
E isto que meus prezados colegas compartilham neste e-Book,

por meio de contos, histrias e dicas sobre software e qualidade:
compartilham como fazemos para alcanar valor mais rpido e
com maior frequncia.
Boa leitura!
A frase estava errada. No que o cdigo de teste testa o

cdigo funcional. Mas sim que o time preza por qualidade, e est
colaborando para gerar valor mais rpido e com maior frequncia.
E eis que surgem pessoas interessadas nessa nova filosofia. E elas
no se identificam claramente por um cargo ou papel: testadores
com skills de programao, analistas de qualidade, analistas do
negcio, DevOps ou desenvolvedores com perfil analtico e de
qualidade.
PAULO CAROLI
Consultor principal da Thoughtworks e cofundador da AgileBrazil.
6 REGRAS DE OURO
PARA SER UM QA
ARRETADO*
Leonardo Steffen
Voc sabe o que te faz querer ir para o trabalho, mesmo quando

o trabalho no est to divertido assim? Sabe o que te mantm
forte quando todos os testes esto falhando e as pessoas ao seu
redor ficam o tempo todo perguntando o que est acontecendo de
errado?
Eu no sabia. Ou pelo menos no tinha conscincia.
Mas a vida como consultor nos ensina muitas coisas sobre
pessoas, suas interaes com os membros da equipe e a forma

como decises so tomadas e aplicadas.
Prestei ateno no meu prprio modo de agir e no que me fazia
feliz ao longo do dia, mesmo quando o dia no era dos melhores.
Isso me ajudou a criar uma lista de princpios que eu utilizo como
guia, e sempre que algo no est bem eu me pergunto o quanto
estou me esforando para aplicar esses princpios ao meu dia.
Experimente e me conte se funcionou para voc tambm.
PRTICAS E TENDNCIAS EM TESTES | 6
Princpio # 0 | Tenha a mente aberta

Preso a um aplicativo legado? At mesmo a pior tecnologia j teve
seu momento de glria.
difcil concordar com tudo o que se passa com times que
trabalham em aplicaes legadas. Mas as pessoas trabalham
fazendo o seu melhor, e isso que devemos ter em mente.
Tcnicas, ferramentas, plataformas, linguagens e metodologias so
escolhidas com as melhores intenes. Antes de abandonar uma
tecnologia, entenda o contexto das escolhas anteriores e veja se
possvel melhorar a forma ela utilizadaa, dado o contexto atual.
Princpio # 1 | Pense no futuro

Prepare-se para o futuro. Testes so a mais valiosa documentao
de um sistema.
meses?. Esse teste est testando um nvel apropriado? Deveria

ser unitrio, de servio ou via interface grfica?.
Princpio # 3 | Pense com sabedoria

No automatize tudo s porque voc pode e porque a ferramenta
legal, ou porque o seu gerente pediu.
difcil no colocar as mos naquele novo framework do qual
todos esto falando. A questo : precisa mesmo automatizar
tanto assim? Escreva testes demais e voc vai acabar com muitas
horas de trabalho extra apenas para mant-los passando. A dica
(clich, mas sempre boa): pense antes de automatizar. Decises
tcnicas cabem a voc.
Princpio # 4 | Mantenha a calma

Quebrar build no uma coisa ruim.
Aprenda a escrever testes. Aprenda a entend-los tambm.

Compartilhe o seu conhecimento e ajude outros membros da
equipe. Reveja os testes e elimine aqueles que no so mais teis.
Modifique testes sempre que necessrio - eles no so imutveis e
existem para te ajudar, no para te dar mais trabalho.
Desde que voc saiba por que quebrou. Se voc no sabe, preste
ateno nos princpios # 1, # 2 e # 3. Pergunte-se: nossa pipeline
de build realmente uma pipeline? ou possvel saber quais
alteraes de cdigo esto envolvidas nessa falha?.
Princpio # 2 | Pense grande
Princpio # 5 | Seja gentil
Projete seus testes pensando em mais do que os critrios de

aceitao.
Trate o seu cdigo de automao de teste com todo o respeito dado

ao seu cdigo de aplicao.
Ao projetar um teste, entenda as aes dos usurios do sistema e

construa testes robustos ao invs de simples scripts focados em
estrias de usurios. E, sempre que voc se deparar com um teste,
pergunte a si mesmo: o que esse teste vai me dizer daqui a cinco
No existe essa histria de cdigo de teste e cdigo de

desenvolvimento. Testes e aplicao podem ter focos diferentes,
mas tm o mesmo objetivo final - entregar valor para o cliente. E
enquanto o seu sistema existir, esse cdigo tambm existir.
Esses so meus princpios para poder contribuir consistentemente

no trabalho como um QA. Voc j pensou nos seus? Pense e me
diga o que voc descobriu! incrvel como um pedao de papel e
alguns minutos de introspeco podem ajudar a transformar um
dia ruim em uma grande oportunidade de consultoria.
*No pude encontrar palavra melhor do que essa para o termo

Awesome, ento a vai uma dica de podcast tecnologicamente
arretado.
*Outra dica de leitura - o artigo Agile Tester 3.0. Esse artigo descreve
uma viso com a qual simpatizo, e diz respeito aos perfis de
atuao de um QA. Aps ler os 6 princpios, reflita sobre qual
dimenso cada um deles se enquadra. Vale a pena!
TESTADOR
GIL 3.0
Daniel Amorim
Testadores geis so muitas vezes conhecidos como analistas de

qualidade (QAs), engenheiros de software em testes, engenheiros
de testes, lideres de qualidade, entre outras variaes. Eu tenho
trabalhado como um Agile QA por um tempo - em portugus
podemos traduzir como analista de qualidade gil. Eu gostaria
de compartilhar meu ponto de vista sobre como um QA trabalha
em um time gil. Nesse artigo eu vou usar a terminologia QA para
representar o testador gil.
A maioria das pessoas, mesmo em times geis, trata QAs como
sub-papis ou papis separados do time. Eu acredito que isso
esteja totalmente fora de moda. A diferena entre um QA e um

desenvolvedor (tambm chamado de Dev) apenas o jeito de
pensar (ou mindset para os que esto acostumados com o termo).
Mas o que distingue QAs entre eles mesmos? Perfis de QA podem
ser classificados em 3 categorias: Negcio, Tcnico e DevOps. Eu
chamo essas trs de 3 dimenses de perfis de QA. QAs podem
ter tanto um desses perfis como tambm podem combinar os trs
perfis de acordo com o seu nvel de conhecimento em cada uma
das dimenses.
Vamos mergulhar mais a fundo nessas dimenses e entender

melhor cada uma delas:
Dimenso de negcio
Esses QAs geralmente leem livros como:

Specification by Example: How Successful Teams Deliver the Right
Software
Os QAs nessa dimenso so realmente dirigidos a negcio. Eles

tm habilidades que ajudam seus times a entender o contexto
de negcio dado pelo cliente. Eles tm boas habilidades de
comunicao que auxiliam o time a focar no problema de negcio
durante o projeto todo.
Bridging the Communication Gap: Specification by Example and Agile

Acceptance Testing
Extrair testes de aceitao do cliente uma das especialidades

e BDD uma das tcnicas usadas para quebrar a barreira entre
contexto de negcio vindo do cliente e contexto tcnico vindo dos
engenheiros do time.
Dimenso tcnica
Eles trabalham em par com os desenvolvedores para alinhar o

que precisa ser feito com o cliente antes de comear a jogar as
estrias. Durante esse perodo eles guiam o par para escrever
testes de aceitao que certifiquem que a estria estar testada
antes de moverem adiante.
The Cucumber Book: Behaviour Driven-Development for Testers and

Developers
Eu me identifico com essa dimenso porque os QAs aqui so

muito tcnicos e tm boas habilidades de programao. No mundo
ideal, no deveria exisitir nenhuma diferena entre um QA e um
desenvolvedor. Em um time gil, todo mundo um engenheiro e
deveria ser tratado como tal.
Os QAs tcnicos trabalham em par com desenvolvedores para
construir a aplicao sem gap tcnico. Eles codam juntos. Eles
tambm ajudam os desenvolvedores a desenvolver usando TDD,
promovendo boas prticas como cdigo limpo e padres de
desenvolvimento, garantindo um cdigo de alta qualidade.
Eles tm muito conhecimento em automao de testes e ajudam o
time a escolher o melhor framework de testes para o projeto. Eles
tambm so responsveis por garantir que o time tenha uma boa
estratgia de testes em mos.
Os QAs na dimenso tcnica podem tambm trabalhar com testes
de performance e segurana, dependendo do quo avanado o
conhecimento deles em testes no funcionais.
Para testes de performance, eles trabalham com o cliente

para descobrir os SLAs (Service Level Agreement). Dadas essas
informaes, eles criam os testes de performance para mensurar e
rastrear as melhorias feitas na aplicao relacionadas aos SLAs.
The Art of Application Performance Testing: Help For Programmers and

Quality Assurance
Esses QAs tambm so envolvidos em segurana. Eles entendem

o contexto de negcio com o cliente e analisam possveis
vulnerabilidades. Com isso, eles criam testes de segurana para
garantir que essas possveis vulnerabilidades esto sendo cobertas
por algum mencanismo de segurana.
Como DevOps est relacionado a testes? Existem vrias coisas

que QAs podem fazer para ajudar o seu time atravs do seu
conhecimento em DevOps.
Dimenso de DevOps
Eles introduzem a prtica de Entrega Contnua e ajudam o time

a criar um pipeline de integrao contnua para receber um
feedback mais rpido aps cada commit. Isso ajuda o time a
fazer deploy de novas funcionalidades para produo mais vezes.
Em alguns casos, cada commit vai diretamente para produo
aps executar todo o pipeline com sucesso. Esse pipeline ir
tambm executar o build e empacotar a aplicao, ferramentas
de qualidade de cdigo, testes unitrios, testes de componente e
testes funcionais.
Os QAs DevOps configuram scripts para o time rodar mais
facilmente os testes em suas mquinas locais. Em alguns
casos, mquinas virtuais so necessrias e nelas os testes so
configurados para executar em paralelo.
QAs nesta dimenso geralmente leem livros como:
Eles usam task runners para que o time execute tarefas repetitivas
sem muito esforo, tais como auto watches para executar
testes automatizados depois de cada vez que algum salva
o cdigo fonte. Isso diminui o tempo de feedback durante o
desenvolvimento de novas funcionalidades.
Test Driven Development: By Example

Clean Code: A Handbook of Agile Software Craftsmanship
Selenium Testing Tools Cookbook
Esse QA geralmente l livros como:

Continuous Integration: Improving Software Quality and Reducing Risk
Continuous Delivery: Reliable Software Releases through Build, Test and
Deployment Automation
Alm de compartilharem a responsabilidade dos testes com o

time, tambm transmitem para o time todo o conhecimento que
eles tm sobre testes. Atravs dessa abordagem, cada membro
do time pensar sobre testes independentemente de seu papel.
QAs vestem muitos chapus, mas seu foco principal deveria ser em
ajudar o time a entregar valor de negcio frequentemente e com
qualidade.
As melhores referncias em portugus so:

DevOps na prtica: entrega de software confivel e automatizada
Entrega Contnua: Como Entregar Software de Forma Rpida e
Confivel
O que comum para todos os QAs?

QAs em todas essas trs dimenses mantm o time focado
em entregar o valor certo para o cliente durante cada ciclo
de desenvolvimento. Ao mesmo tempo, eles devem estar
preocupados com a qualidade do produto que est sendo
entregue.
Livro que todos os QAs geis deveriam ler (que a atual bblia do
Agile Testing)
Agile Testing: A Practical guide for Testers and Agile Teams
E voc? Onde voc est nessas dimenses? Em qual delas voc
tem interesse em melhorar?
...e vamos comear!
PREVENO DE
DEFEITOS USANDO
TCNICAS GEIS
Lucas Medina & Raquel Liedke
Inmeros podem ser os deslizes cometidos ao descrever uma

estria. Eles podem levar a defeitos de implementao caso no
sejam validados antes da estria ser desenvolvida. Detalhes que
aparentemente esto claros na cabea do analista de negcio, ou
mesmo do cliente, acabam no sendo completamente detalhados
na descrio da estria.
Prevenir defeitos no software o mais cedo possvel um objetivo
sempre almejado por qualquer projeto de desenvolvimento
de software e muitas tcnicas so utilizadas para achar esses
defeitos precocemente. Uma delas nos tem dado um retorno bem

interessante na manuteno da qualidade no projeto: o kick-off e o
desk-check de estrias.
Como estrias em anlise ainda esto abertas a sugestes, uma
proposta seria uma reunio para discutir as prximas estrias,
na qual o analista de negcio (ou um integrante com contexto),
apresenta as prximas estrias, comenta a origem, o valor de
negcio e o porqu so necessrias. O time discute detalhes
tcnicos, faz questionamentos sobre os requisitos e avalia se
o tamanho da estria est adequado. Esse feedback pode ser

usado para dividir a estria onde for apropriado, ou adicionar mais
detalhes e exemplos para clarificar reas que causaram confuso.
traz tona os conceitos e objetivos sem deixar passar detalhes

importantes, alm de enriquecer o contexto com o ponto de vista
de pessoas em diferentes papis.
Em um cenrio ideal, a participao de analistas de negcio, do
analista de qualidade e dos desenvolvedores fundamental no
kick-off para que todos fiquem a par da funcionalidade a ser
desenvolvida e para que o debate seja mais produtivo e proveitoso.
Confira uma sugesto de kick-off abaixo:
Checklist para o Kick-off
Envolvidos: Analista de Negcios, Analista de Teste,

Desenvolvedores
O kick-off, que na traduo literal seria ponta-p inicial, trata-se

de uma lista de checagem com vrios itens a serem verificados
antes de iniciar o desenvolvimento da estria. Essa lista inclui
validaes como: a estria est completa e realmente pronta
para o desenvolvimento? Que consideraes tcnicas precisam
ser observadas durante o desenvolvimento? J sabemos sobre
o design visual? E quanto a abordagens para controlar erros e
mensagens de ajuda?
Outro problema muito comum so premissas que esto na cabea
do desenvolvedor e no compartilhadas entre desenvolvedor e
analista (falha de comunicao). Sendo assim, o bate papo inicial
A anlise da estria est completa?

Houve reviso de QA na anlise?
A estria est completa com detalhes e toda a informao
relevante?
O valor da estria foi bem compreendido?
H dependncia em futuras estrias?
H algum dbito tcnico relacionado?
H design visual para a estria?
A estria possui mensagens de erros detalhadas?
H mensagens de ajuda e outros labels definidos na estria, j
revisados?
O tamanho da estria apropriado?
Pelas mesmas razes justificadas no kick-off, o analista de negcio,
o analista de qualidade e desenvolvedores devem estar presentes
para ampliar o debate sobre dvidas e problemas durante o
desenvolvimento. Seria importante considerar que para estrias
grandes, podem ser feitas checagens durante o desenvolvimento,
afim de garantir que se est no caminho certo. Deve-se ter ateno
para que estes feedbacks no ultrapassem o escopo da estria e,
se eles fizerem sentido, provavelmente a anlise da estria no foi

acurada.
O desk-check (teste de mesa), trata-se de uma lista de checagem
a ser utilizada na validao da estria aps o desenvolvimento. Na
listagem abaixo, vemos validaes como: foram implementados
os testes unitrios e de aceitao? J foi feita uma reviso do
cdigo com outro par? Funciona nos principais navegadores? Tais
perguntas so importantes para a preveno de dores de cabea
no futuro. Exemplo: a funcionalidade est linda no Google Chrome,
mas sequer aparece no Internet Explorer porque as bibliotecas ou
a verso do html no funcionam l.
Checklist para o Desk-Check
Envolvidos: Analista de Negcios, Desenvolvedores e pessoas

interessadas
Pode-se dizer que a maioria dos defeitos de fato encontrada

durante o desk-check, por razes bvias, visto que quando
a estria est sendo entregue e quando realmente possvel
fazer um teste preliminar na funcionalidade desenvolvida. De
qualquer forma, recomendvel uma ateno especial ao
kick-off, pois onde o mal entendido ocorre e as coisas so
implementadas diferentemente do ideal.
Vale salientar que estas listas de checagem no devem ser
rgidas, escritas na pedra e seguidas risca. O importante
que o benefcio dessa abordagem est em verificar se
aqueles passos foram seguidos durante o desenvolvimento
da estria. Outro aspecto relevante que essas listas devem
ser personalizadas, uma vez que cada projeto tem suas
particularidades e necessidades. Crie a sua lista e veja os
benefcios surgindo logo no incio. Mantenha o hbito para que
isso no seja esquecido com o tempo.
H cobertura de teste suficiente?

Outro par foi convidado para revisar o cdigo?
A estria foi testada manualmente?
A verificao da estria pode ter impactado em outra coisa?
Todos os critrios de aceitao foram cobertos?
Ser que a estria precisa de algum tipo de feedback ou
correo?
Foi feita uma completa jornada de usurio atravs da estria?
A interao com a UI est consistente com o resto da
aplicao?
Funciona nos principais navegadores?
O texto na estria est consistente com outros textos e labels
na aplicao?
O contedo dos textos possui erros gramaticais?
O esquema de cores est consistente com outras cores na app?
MOCKAR OU
NO MOCKAR,
EIS A QUESTO
Fabio Pereira
O recente e polmico debate TDD Morreu? entre DHH, Martin

Fowler e Kent Beck trouxe tona o nvel de insatisfao relacionado
ao uso excessivo de mocks e stubs em testes automatizados.
DHH expressou fortemente sua opinio sobre o fundamentalismo
a respeito do nvel de isolamento das classes sendo testadas
e criticou a necessidade demasiada que alguns testes tm de
segregar completamente todos os seus colaboradores. Esse
tambm foi um dos pontos mais importantes deste post recente de
Martin Fowler. Durante o hangout, os 3 afirmaram quase no usar
mocks.
O teste que te faz dormir tranquilo

Kent Beck enfatizou que, no final do dia, como desenvolvedores/
programadores, nossa responsabilidade ter a certeza de que
podemos dormir tranquilos a noite sabendo que no quebramos
nada. Uma mentalidade bem diferente de antigamente, quando
desenvolvedores simplesmente comitavam o seu cdigo e
esperavam por outro grupo de pessoas - os testadores - para
ter certeza de que tudo ainda funcionava. Este um dos
principais objetivos de uma sute de testes automatizados,
independentemente desses testes terem sido escritos antes do

cdigo (com a prtica de test first) ou depois que o cdigo havia
sido escrito.
A finalidade de testes automatizados verificar, de forma rpida e
confivel, que o sistema ainda funciona e que o novo cdigo escrito
no afeta negativamente o cdigo j existente. este tipo de
confiana e feedback que no alcanado quando mocks e stubs
so exageradamente utilizados.
existe. Vou ilustrar a seguir um exemplo real, no o nico, que

j vi acontecer diversas vezes. Digamos que existe um controller
(MyController) cuja responsabilidade validar um model (MyModel)
e exibir os seus erros. O model possui um mtodo errors. A
imagem abaixo ilustra esse exemplo:
Por que mockar demais perigoso?

A culpa no dos mocks e stubs. Esses dois, assim como qualquer
outra ferramenta, so meras vtimas do seu uso indevido. So
tcnicas extremamente teis quando precisamos isolar pontos
de integrao externos, como Web Services e bancos de dados,
por exemplo. O perigo existe quando usamos mocks e stubs para
isolar classes e mtodos que pertencem ao nosso prprio cdigo
em camadas que no necessariamente precisariam ser isoladas.
Tautological TDD um anti-padro que explica algumas situaes
nas quais o uso excessivo de mocks e stubs perigoso. Durante
o hangout foi dito: se fao TDD, eu posso refatorar meu cdigo.
Testes tautolgicos, que so muito caixa branca, checam mais
interaes do que comportamento, geralmente precisam ser
modificados quando refatoramos nosso cdigo. Se voc precisa
mudar o seu teste pra cada refatorao que fizer no seu cdigo,
como saber se a mudana do cdigo no quebrou nada? J vi
muita gente mudar o cdigo e mudar o teste s pra fazer o teste
passar.
TTDD j perigoso em linguagens como Java e C# e a situao se
agrava quando passamos para linguagens dinmicas como Ruby e
JavaScript, nas quais pode-se mockar um mtodo que nem mesmo
Ao testar o controller, mockistas tendem a isolar o model

criando um mock ou stub para o mtodo errors. Ruby, com seu
dinamismo, e frameworks de testes como Mocha, nos permite
atingir este nvel de isolamento.
Se prestarmos ateno, o mtodo no model chamado errors
(plural). Entretanto, o cdigo do controller tem um problema,
chama o mtodo no singular, mas o mock/stub faz com que tudo
funcione, porque o mtodo mockado tambm est errado. O teste
passa! O que temos aqui? Um falso positivo. Um teste verde dando
ao desenvolvedor uma sensao falsa de confiana, quando o
cdigo est, na verdade, quebrado. Esse apenas um, entre vrios,

dos exemplos que mostra o perigo do mau uso de mocks e stubs.
Recentemente, depois de fazer uma atualizao de uma
dependncia, descobrimos que o retorno de um mtodo que
estava sendo mockado na maioria dos testes unitrios havia
mudado: antes retornava nil, agora retorna um array vazio. Mais
uma vez, todos os nossos testes passaram, mas o cdigo estava
quebrado.
Mais importante do que nomes de mtodos errados e valores de
retorno quando o comportamento de uma determinada classe
ou entidade mockada levando em considerao premissas
erradas. Quando o propsito dos testes focado principalmente
na verificao da interao entre colaboradores (testes muito caixa
branca), essas interaes e as expectativas dos mocks nos testes
faro todos os testes passarem. Ao ver todos os testes passando,
os desenvolvedores iro pra casa dormir tranquilos pensando que
nada est quebrado, quando na verdade, alguns destes problemas
vo direto para produo, sendo identificados por usurios reais.
J vi isso acontecer vrias vezes, problemas que poderiam ter sido
identificados por um teste no to caixa branca, mas acabaram
indo para produo. E voc, j?
Como definir uma unidade?

A unidade a ser testada um dos grandes pontos de confuso
e debate. Martin nos alerta sobre algumas definies de unidade
utilizadas: o design orientado a objetos tende a tratar uma
classe como uma unidade, abordagens procedurais e funcionais
consideram uma funo como sendo uma unidade. Uma unidade
deve ser um comportamento (behavior). mais importante
testar O QUE uma entidade faz, do que COMO essa unidade
consegue faz-lo. O critrio do que deve ser uma unidade tem
que ser definido pelo desenvolvedor escrevendo o cdigo e
o teste. Muitas vezes, um grupo de classes pode alcanar um
comportamento, portanto, este grupo de classes a unidade.
Pense e defina a profundidade dos seus testes, sem nenhum dogma
ou fundamentalismo definido pelo paradigma da linguagem que
est usando, de forma que eles garantam a certeza de que o
comportamento daquela unidade est funcionando.
A imagem abaixo ilustra o conceito de profundidade de teste:
O perigo de ter testes assim que eles nos do um falsa sensao

de segurana e confiana. Vemos um build passando, com todos
os testes verdes e temos a certeza de que no h nada quebrado.
Precisamos pensar melhor quando escrevemos um teste, s vezes
melhor escrever um teste que acesse um grupo de classes e
no use tanto mock assim para termos a segurana de que tudo
funciona. Outra discusso interessante durante o hangout e alguns
outros posts foi o que uma unidade em testes unitrios?
Uma unidade no necessariamente uma classe ou um mtodo

ou uma funo, mas o que VOC, desenvolvedor escrevendo
o teste e o cdigo, decidir que seja, baseado no seu design
e nas suas fronteiras. E, obviamente, se depois de definida a
profundidade do seu teste voc achar sensato utilizar um mock
ou um stub para alguns dos seus colaboradores, v em frente!
No vamos mockar algo simplesmente porque nos sentimos
obrigados por alguma definio embasada em um paradigma de

uma linguagem. Vamos parar com afirmaes do tipo: um teste
unitrio da classe A no pode acessar a classe B porque no um
teste unitrio. Vamos mockar quando acharmos que devemos,
baseados no nosso prprio julgamento de forma que os nossos
testes ainda sejam teis e alcancem o seu objetivo: feedback
rpido sobre o funcionamento do nosso cdigo.
3 NOES BSICAS
ESSENCIAIS PARA A
CRIAO DE UMA SUTE
DE AUTOMAO PARA
APLICATIVOS WEB
Taise Silva
Este artigo foi escrito a fim de compartilhar que existem padres

e ferramentas que, quando combinados, podem oferecer testes
automatizados com alto valor de negcio e baixo custo em termos
de manuteno do cdigo.
O Cucumber uma ferramenta que suporta Behavior Driven
Development (BDD), que consiste em descrever o comportamento
de um usurio. Dessa forma, as necessidades reais do usurio
so descritas. Selenium WebDriver uma ferramenta que simula
aes do usurio em navegadores web. Este artigo descreve como
usar o Cucumber, juntamente com Selenium WebDriver, para

implementar testes automatizados com alto valor de negcio e de
baixa manuteno.
Cucumber usado para descrever o valor do negcio em
uma linguagem natural, por isso permite que equipes de
desenvolvimento de software descrevam como o software deve se
comportar em texto simples, escrevendo especificaes atravs
de exemplos. Uma boa vantagem de escrever especificaes
com Cucumber que qualquer um na equipe consegue ler e
entender as especificaes em texto simples - de pessoas de

negcios a desenvolvedores de software. Alm disso, ele ajuda a
obter feedback dos stakeholders de negcios para que a equipe
construa a coisa certa antes mesmo de comear. Ele tambm
ajuda a equipe a fazer um esforo intencional para desenvolver
uma linguagem ubqua compartilhada para falar sobre o sistema.
Outra vantagem que a especificao uma documentao viva,
porque apesar de ser escrita em texto simples, origina testes
automatizados executveis, como voc ver mais adiante no artigo.
A estrutura que o Cucumber usa para as especificaes o
formato Given/When/Then em conformidade com gramtica da
linguagem Gherkin. A parte Given (Dado) descreve uma prcondio existente do estado de software antes de comear o
comportamento que voc est especificando. A seo When
(Quando) o prprio comportamento. O Then (Ento) descreve o
resultado esperado do comportamento. Por exemplo: dado que
me inscrevi para Loja de Livros Online, quando eu acesso a loja
com minhas credenciais, ento vejo uma mensagem Bem-vinda
Loja de Livros Online!. Continue lendo para encontrar mais
exemplos.
Selenium WebDriver simula as aes do usurio definidas pelas
descries do Cucumber em um browser. Ele usado para
testar automaticamente aplicaes web, uma vez que conduz um
browser utilizando recursos nativos de cada browser. Selenium
ainda movido por cdigo, de modo que os testes automatizados
so escritos em uma linguagem de programao que define as
aes do usurio e controla Selenium WebDriver. H muitas
linguagens de programao diferentes que podem ser usadas com
Selenium WebDriver, tais como Java, Ruby, Python e JavaScript. No
entanto, existe uma linguagem ainda mais simples para descrever
cenrios de teste: a linguagem natural.
possvel escrever testes automatizados com Cucumber em

diferentes linguagens naturais, tais como Portugus e Ingls,
entre mais de 40 outras lnguas. Por outro lado, Cucumber no
interage diretamente com a aplicao de software. por isso que
normalmente utilizado em conjunto com ferramentas como
o Selenium WebDriver. Desta forma, os testes automatizados
servem como documentao, porque podem ser escritos em
uma linguagem especfica de um domnio e legvel do ponto de
vista de negcios. Eles tambm podem ser executveis, porque
possuem a camada do Selenium WebDriver rodando por trs da
camada do Cucumber; e podem ser de fcil manuteno porque a
camada do Cucumber no precisa saber como as aes do usurio
so simuladas, j que este o trabalho do Selenium WebDriver.
Portanto, se a aplicao web muda a forma como o usurio
interage com ela, tudo o que precisamos fazer alterar a camada
do Selenium WebDriver e manter a camada do Cucumber como
estava. Leia mais para ver exemplos das camadas de Cucumber e
Selenium Webdriver.
Existem outras opes de ferramentas para a gesto de casos
de teste, tais como TestLink, que armazena os casos de teste
escritos em linguagens naturais. Essas ferramentas tendem a ser
desconectadas do cdigo real e os testes ficam desatualizados
rapidamente. A maior vantagem do Cucumber sobre TestLink
que os testes escritos em texto simples so tambm testes
automatizados, que sempre iro falhar quando a aplicao sai
de sincronia com os scripts do Cucumber. Isso ajuda a manter
a documentao atualizada, porque falhas na execuo sero
notificadas caso ela no esteja. Cucumber tambm suporta a
execuo do caso de teste, uma vez que mais fcil de identificar
quais cenrios de funcionalidades esto em execuo atravs
da leitura de linguagem natural, em vez de ler a linguagem de
programao.
Seguem trs passos para escrever testes automatizados com alto

valor de negcio e de baixa manuteno: definir o valor do negcio,
automatizar testes e refatorar para baixa manuteno.
Definir o valor do negcio
negcio em vez de descrever testes usando termos tcnicos que so

apenas mais uma variante de uma linguagem de programao.
Para ter testes automatizados com alto valor de negcio, Cucumber
consiste em uma face de negcio e uma face de tecnologia.
Seguem alguns princpios de BDD utilizados em Cucumber para

escrever testes automatizados com alto valor de negcio.
til escrev-los em texto puro antes de implement-los e garantir
que as partes interessadas no negcio dem feedback sobre
os testes descreverem ou no o comportamento correto do
software. Se as partes interessadas no negcio derem o feedback
aps o comportamento do software j ter sido implementado,
provavelmente vai levar muito mais tempo para corrigir o cdigo
do que seria necessrio para corrigir um texto simples que
descreve o teste. Ento, testes automatizados escritos antes de
construir o software trazem valor atravs da economia de bastante
tempo do time de desenvolvimento de software.
Escrever narrativas tambm traz valor para o teste porque
descreve em uma frase qual o motivo de implementar a
funcionalidade em primeiro lugar, e ajuda a entender sobre o que
so os cenrios da funcionalidade. Por exemplo: para que eu possa
identificar dinossauros, como um colecionador de ossos, eu quero
acessar informaes sobre os dinossauros.
Outra qualidade importante em testes automatizados valiosos
que o texto simples usa um vocabulrio especfico do domnio
do negcio para que eles sejam compreendidos por qualquer
pessoa da equipe: usurios, stakeholders de negcios e o time de
desenvolvimento de software. Isso traz valor para a comunicao
da equipe, porque faz com que ela desenvolva uma linguagem
ubqua compartilhada para falar sobre o software e focar no
Fonte: Traduo da imagem do livro The Cucumber Book: BehaviourDriven Development for Testers and Developers, by Matt Wynne and Aslak
Hellesy
A face de negcio definida dentro de um arquivo de funcionalidade
com a extenso .feature. Ela contm a descrio da funcionalidade
e os cenrios com os passos escritos em linguagem natural, como o
portugus. Por exemplo:
Fonte: https://github.com/taisedias/selenium-cucumber
Automatizar testes
A face de negcio por si s no um teste automatizado
executvel que exercita a funcionalidade da aplicao (que pode
ser Web, Android ou WebService). A fim de torn-la executvel,
Cucumber tem uma face de tecnologia que consiste em definies
de passo, cdigo de suporte e de biblioteca automao. A
definio do passo implementada utilizando uma linguagem
de programao para cada passo do cenrio nos arquivos de
funcionalidades. Esse cdigo usa uma biblioteca de automao
de teste, como Selenium ou Watir (outro exemplo de WebDriver
usado com Ruby), para acessar a aplicao e executar os testes
automatizados.
Fonte: http://www.slideshare.net/taisedias/cucumber-qanight
O exemplo seguinte mostra a face de tecnologia implementada
em Java. Cada mtodo Java uma definio do passo descrito
no arquivo de funcionalidade do exemplo anterior. O corpo do
mtodo usa o cdigo de suporte que chama a biblioteca de
automao, que chama o Selenium, que contm o WebDriver que,
finalmente, vai acessar a aplicao:
identificadores para o driver usar. Esse deve ser o nico lugar onde
o identificador registrado.
Refatorar para baixa manuteno
Um padro amplamente utilizado na implementao de testes

automatizados o padro PageObject, que consiste basicamente
em mapeamentos entre os elementos da pgina da aplicao e
uma classe. Ele tambm define as aes do usurio na pgina
usando seus elementos. O exemplo a seguir um PageObject
LoginPage, que mapeia os elementos da pgina de login (como
o campo de nome de usurio, campo de senha e boto), bem
como define as aes como logar na pgina. As aes conduzem o
Selenium para acessar e acionar os elementos da LoginPage.
O exemplo a seguir um PageObject representando a pgina de
login. Esse objeto mapeia seus elementos individuais com seus
Cdigo de teste cdigo, por isso to importante refatorar

cdigo de automao de teste quanto refatorar cdigo da
aplicao. Caso contrrio, os testes vo ser to difceis de manter
que vai ser melhor jogar tudo fora e comear de novo. Esse
um custo que pode ser evitado se seguirmos algumas dicas que
ajudam a reduzir os custos de manuteno do cdigo, arquivos de
features e definies de passos.
O uso do padro PageObject torna mais fcil a manuteno de
testes automatizados porque as alteraes em elementos de
pgina so apenas alteradas uma vez no PageObject. Arquivos de
funcionalidades e definies de passo no possuem informaes
especficas sobre a pgina e, portanto, no precisam ser
atualizados. Em outras palavras, se qualquer elemento na pgina
de login muda (como caminho de URL ou o nome do boto), a
manuteno ser feita no LoginPage.java somente, e no haver

necessidade de atualizar o arquivo de funcionalidade (que contm
os cenrios) e a classe LoginStepDefinition.java.
importante escrever funcionalidades declarativas, de modo que
os cenrios sejam descritos como um usurio poderia descrevlos, o que os torna altamente manutenveis quando comparados
com cenrios que descrevem apenas clicar em links e preencher
os campos de formulrio. Por exemplo:
Algumas outras boas prticas que ajudam a manter os testes de

Cucumber podem ser encontradas aqui: http://blog.codeship.com/
cucumber-best-practices/.
Concluso
Outra dica para reduzir o custo de manuteno em cenrios de

Cucumber evitar passos que contm duas aes, porque um
deles pode ser reutilizvel em diferentes cenrios:
Em suma, este artigo descreve brevemente o uso do Cucumber

com Selenium WebDriver para implementar testes automatizados
com alto valor de negcio e baixa manuteno usando os padres
BDD e PageObject. Todo o cdigo apresentado est no github.
Apesar de termos falado sobre Cucumber e Selenium, existem
tambm outras ferramentas de BDD e WebDriver semelhantes que
podem ser combinadas para criar uma sute de automao de alto
valor de negcio e de baixa manuteno, desde que voc use as
prticas sugeridas neste artigo.
ESCREVA TESTES
MELHORES EM 5
PASSOS
Marcos Brizeno
Os pontos que vou discutir aqui me ajudaram bastante a ter mais

conscincia dos meus testes e o que eu poderia melhorar neles. Se
voc tem experincia em escrever testes, provavelmente sabe do
que eu vou falar, mas ainda assim ser bom refrescar a memria e
adicionar mais referncias ao assunto. Se voc comeou a escrever
testes a pouco tempo e est procurando maneiras de melhorar,
ento veio ao lugar certo!
Antes de comear, gostaria de avis-lo que est no uma lista
extensiva com tudo o que voc precisa saber para se tornar um
especialista em escrever testes, mas eu tentei ao mximo colocar

referncias para permitir um aprofundamento maior em cada
tpico. Adicione essa pgina aos favoritos e volte de tempos em
tempos para investir em aprender um pouco mais sobre cada rea
especfica.
#1 Trate Cdigo de Teste como Cdigo de

Produo
Geralmente escutamos pessoas falando sobre a importncia de
ter cdigo limpo. O mesmo pricpio deve ser aplicado para cdigo
de testes. O feedback fraco que voc recebe de uma sute de teste
suja no lhe permite saber quando voc quebrou algum teste ou
se basta executar a sute novamente.
Este artigo de Robert Martin (Uncle Bob) apresenta uma boa
discusso sobre tratar cdigo de teste como cdigo de produo.
Ele tambm dedicou um captulo inteiro do livro Clean Code para
falar sobre Testes Unitrios. Testes so uma das ferramentas mais
poderosas para alcanar flexibilidade, ento devem ser robustos
e limpos. Mudanas acontecem todos os dias e precisamos estar
preparados.
A melhor caracterstica para testes limpos a legibilidade. Se voc
pode ler e entender um caso de teste, voc sabe como o cdigo
funciona, como as regras de negcios so aplicadas e consegue
achar o que est quebrado. Eu prefiro ter cdigos de teste que
sejam claros do que cdigos sem repetio, conhecidos como
DRY - Dont Repeat Yourself (no entanto as ferramentas atuais
permitem alcanar ambos). Ter cdigo legvel o objetivo principal.
#2 Utilize Padres de Testes Para tima

Legibilidade
Padres melhoram cdigo de teste da mesma forma que
melhoram cdigo de produo. Um padro que eu gosto bastante
o Arrange Act Assert (Organizar, Agir e Verificar), ou apenas 3-As.
Ele basicamente diz que:
Arrange (Organizar): Configure suas informaes e qualquer
outro dado necessrio ao teste;
Act (Agir): Execute a ao que o teste vai validar;
Assert (Verificar): Veja que o que era esperado realmente
aconteceu - ou no;
Outro padro sobre organizao dos testes o clssico do BDD

- Given, When, Then. Martin Fowler faz uma boa descrio desta
tcnica. Tambm existem padres que vo alm de organizar o
cdigo. O livro XUnit Test Patterns de Gerard Meszaros tem vrios
Padres, Tcnicas e Heursticas (Code Smells) para testes e pode
ser lido online.
#3 Evite Testes Instveis

O teste realmente quebrou ou basta execut-lo novamente?
Se voc chegar ao ponto de escutar algum falando isso ou at
mesmo voc fazer essa pergunta, provavelmente voc tem um
problema. Neil Craven tem um timo post sobre o assunto, com
algumas dicas de como se livrar de testes no determinsticos,
por exemplo reescrevendo o teste um um nvel mais baixo, entre
outras.
Martin Fowler tambm tem um timo post sobre testes no
determinsticos explicando em detalhes o dano que eles podem
causar e como melhor-los, por exemplo colocar testes em
quarentena e outras ideias.
O livro XUnit Test Patterns tambm inclui uma profunda discusso
sobre testes frgeis e as possveis causas, como falta de isolamento,
ou alta sensibilidade da interface.
#4 Teste no Nvel Apropriado

Todo teste que voc escreve tem um custo. E no apenas o
custo de escrever que apontado logo de cara, mas tambm o
custo de execut-lo. Pode ser que seja bem pequeno, como testes
de JavaScript que rodam em 10 segundos, bem como testes que
utilizam Selenium e so executados em paralelo demorando 1
hora para terminar.
Martin Fowler faz uma simples diviso de testes em 3 grupos,

Unitrios, Servio e Aceitao, e os organiza em um modelo de
Pirmide de Testes. A Pirmide sugere que voc tenha uma grande
nmero de Testes Unitrios com uma boa cobertura e feedback
rpido, menos testes de Servio e uma poro bem pequena de
testes de Aceitao. Fabio Pereira escreveu um bom caso de estudo
da Pirmide de Testes.
Alguns anti-padres so fceis de identificar, como a casquinha de
sorvete de Alister Scott, que parece com uma pirmide invertida,
com muitos testes de aceitao ou manual, e o cupcake de teste,
que parece um quadrado onde se busca o mximo de cobertura
em todos os nveis.
Uma boa metfora, feita por Fabio Pereira, descrevendo a
importncia de focar no que importante para o teste descrita
neste post.
#5 Utilize Dubls de Teste

Dubls de Teste - ou Mocks como so mais conhecidos - ajudam
a reduzir o custo dos testes ignorando comportamentos
desnecessrios. Ento, eu acho que voc deve sim utilizar Dubls
de Testes para conseguir testar no nvel apropriado. O problema
aparece quando os Dubls so muito utilizados e voc acaba por
no utilizar o que voc deveria testar!
Outros artigos que discutem o isolamento de testes e os prs e

contras do uso de Dubls de Testes so apresentados e discutidos
em mais detalhes por Gary Bernhardt e Fabio Pereira. Eles devem de
dar ideias sobre como utilizar a dose certa.
Concluso
Alm dos pontos discutidos aqui, tem muito mais informao sobre
TDD (a srie recente de Google Hangouts por Martin, DHH e Kent
sobre as vantagens e desvantagens do TDD, chamada de Is TDD
Dead bem esclarecedora), BDD, ADD e vrias outras maneiras de
abordar design de software e testes automatizados. Eu realmente
gosto do fluxo de desenvolver testes, pensando sobre design
e implementao que TDD e BDD do, bem como mantendo a
ateno na qualidade do cdigo de teste. Mas depende de voc
achar qual funciona melhor no seu contexto.
Como dito antes, mesmo no sendo uma lista completa, ela vai
prover informaes suficientes para continuar a ler e aprender
mais sobre testes. E, no importa qual caminho siga, vai ser uma
experincia de aprendizado til.
Uncle Bob publicou um excelente artigo sobre os vrios tipos de

Dubls de Testes e os seus objetivos. Com certeza conhecer qual
tipo de Dubl utilizar em cada situao vai te ajudar bastante a
evitar atirar no prprio p.
TRS
FALCIAS
SOBRE BDD
Nicholas Pufal e Juraci Vieira
BDD, do ingls Behavior Driven Development ou desenvolvimento

orientado por comportamento, se tornou um termo da moda
entre desenvolvedores, analistas de qualidade e analistas
de negcios. Apesar de suas fortes ideias, geralmente mal
compreendido. Seguidamente escutamos times que afirmam
estar se utilizando de BDD, mas ao olhar mais de perto vemos
que o que o time acaba fazendo usar uma ferramenta de BDD
para automao de testes - e no aplicando os conceitos em si.
No final das contas, ns escutamos pessoas reclamando dessas
ferramentas, e no sobre as ideias que inspiraram a criao dessas

ferramentas. O resultado disso uma srie de queixas que vemos
em diversos blogs pela internet - pessoas que passam a rejeitar
toda a ideia por trs do BDD, tendo em vista que tentaram usar
uma ferramenta sem antes mudar de atitude com relao forma
que desenvolvem software.
Frequentemente escutamos essas trs reclamaes sobre BDD:
#1 O cliente no se importa com testes

Essa a principal reclamao. Faz todo o sentido afirmar isso,
visto que para o cliente o que realmente importa um software
que atenda s suas necessidades e que funcione. Se voc
comear uma discusso sobre testes, muito provvel que as
pessoas envolvidas com o negcio vo acender a luz verde para
se desligar do assunto. Alm disso, a palavra teste infelizmente
carrega consigo uma conotao negativa na comunidade de
desenvolvimento de software.
Se o cliente escrever as especificaes ele no ir se beneficiar

de algo chamado diversidade cognitiva, e essa diversidade s
aparece em grupos heterogneos de pessoas trabalhando juntas.
Ele precisa do conselho de engenheiros que sabem os aspectos
tcnicos do problema que ele est tentando resolver. Ele tambm
precisa do paradigma de um analista de qualidade, o qual vai
auxiliar na criao de cenrios que ningum pensou antes. Caso
contrrio, a soluo na qual ele pensou pode ser muito mais
complexa do que ela precisa ser.
Mas espere um pouco, ns estamos falando de BDD, que

desenvolvimento orientado por comportamento, e isso de nada
tem a ver com testes. Testar algo que voc no pode fazer
enquanto o software no existir. Testar significa verificar, e em BDD
ns estamos tratando de especificar antes de mais nada.
injusto reclamar sobre algo que ns, como o time de

desenvolvimento, que deveramos ser os responsveis por ajudar
nossos clientes.
BDD uma atividade de design, na qual voc constri partes

da funcionalidade de maneira incremental guiado pelo
comportamento esperado. Em BDD ns samos da perspectiva
orientada a testes e entramos na perspectiva orientada a
especificaes, o que significa que essa reclamao nasceu mal
colocada.
Essa no a ideia. O que ele realmente precisa fazer, prover

ao time informaes sobre o problema que ele quer resolver, e
juntos podem pensar nos exemplos concretos que vo nortear o
processo de desenvolvimento.
#2 O cliente no quer escrever as especificaes

Essa a segunda reclamao mais usada. Vamos falar sobre ela
em duas partes.
O cliente deve escrever as especificaes por conta prpria
Quem faz uso dessa reclamao est afirmando que esperado
que o cliente proponha a soluo para o seu prprio problema problema esse que o seu software que deveria resolver.
O cliente precisa interagir diretamente com a ferramenta
#3 Voc consegue alcanar o mesmo resultado

sem uma linguagem especfica de domnio (DSL)
Esse argumento encontrado comumente entre desenvolvedores.
A maior parte desses desenvolvedores argumenta que no
existe um benefcio real em acrescentar mais essa camada - que
descreve comportamento em linguagem natural - visto que ela
apenas adiciona complexidade e faz com que o conjunto de testes
fique lento.
Se ns olharmos essa reclamao focando em uma tech stack em
Ruby, isso geralmente significa que ao invs de usar o Cucumber,
voc pode usar o Capybara + RSpec para obter o mesmo benefcio

e ainda por cima ter uma melhor performance ao rodar seus
testes.
aquele nico arquivo que uma maneira no abstrata de

demonstrar ideias - o arquivo das especificaes, que descreve
todos os cenrios da funcionalidade. Alm disso, estaro usando
suas diferentes capacidades cognitivas para juntos pensarem em
qual o melhor caminho para transformar uma especificao na
concretizao das necessidades do negcio.
Um caso de sucesso usando BDD

O quo complicado seria para voc explicar para uma criana de 3
anos de idade como uma transao bancria funciona? O mesmo
desafio se aplica durante o desenvolvimento de software, visto que
o domnio do cliente pode, por diversas vezes, ser bastante vago e
nebuloso para o time de desenvolvimento.
O ser humano precisa de exemplos para compreender um tpico.
Exemplos reais so uma excelente forma de se comunicar, e no
nosso dia-a-dia ns os usamos, sem nem mesmo perceber. Ao
trabalhar com exemplos reais ns nos comunicamos melhor,
pois as pessoas sero capazes de se relacionar com eles mais
facilmente.
A verdade que essa comparao no faz sentido. como
comparar mas e laranjas: so coisas totalmente distintas.
Isso tudo muito mais perceptvel quando o domnio do negcio

complexo.
O benefcio em se utilizar de uma linguagem especfica de domnio

que pessoas do negcio podem ler - como as especificaes
que escrevemos no Cucumber nesse caso - vai alm do que a
perspectiva de um desenvolvedor capaz de compreender. No se
trata de cdigo, se trata de aprimorar a comunicao entre todos
os membros do time.
Um bom exemplo disso um projeto no qual trabalhamos, de um

banco de investimentos. Como de se esperar em um domnio
desses, as terminologias eram muito complicadas, tornando um
tanto quanto difcil a vida dos desenvolvedores na hora de manter
um dilogo com os analistas de negcios do banco.
Ou seja, ter os analistas de negcio dialogando com os

desenvolvedores e analistas de qualidade, todos eles aprimorando
No intuito de nos comunicarmos melhor, parte do nosso

processo era, antes de comear uma estria, ter o par de
desenvolvedores fazendo uma rpida chamada de udio/vdeo
com o analista de negcios responsvel por ela. Esse analista por

sua vez compartilhava com os desenvolvedores o arquivo com
as especificaes - tambm conhecido como feature file - o qual
continha todos os cenrios nos quais ele pensou.
Visto que neste time no haviam analistas de qualidade,
importante mencionar que durante essa sesso um dos
desenvolvedores deveria manter um pensamento mais alinhado
com o de um analista de qualidade - focando em aprimorar os
cenrios j criados e sugerindo a criao de cenrios que ainda
no haviam sido explorados - enquanto o outro desenvolvedor
focaria mais nos desafios tcnicos da implementao, como por
exemplo sugerir mover um cenrio para uma especificao em
nvel de cdigo - que oferece um feedback mais rpido no conjunto
de testes. Todos tambm podiam sugerir mudanas aos passos
de um cenrio, caso isso fizesse mais sentido compreenso de
todos.
Ao utilizar esse processo os analistas de negcios expandiam o seu
conhecimento ao compreender melhor os desafios tcnicos de
cada cenrio e os desenvolvedores conseguiam ter uma ideia mais
clara das necessidades do negcio, facilitando na compreenso
do que realmente precisava ser desenvolvido. Alm disso, sempre
que mudanas fossem necessrias, apenas aquele nico pedao
de informao seria mexido, o que significa que todo o time estaria
sempre atualizado.
Indo mais fundo no assunto

Para finalizar, a principal ideia por trs do BDD o seu foco em
prevenir falhas de comunicao, o que significa ter todos no time
comunicando de maneira mais frequente, melhor e baseados em
exemplos reais - no somente abstraes e requisitos imperativos.
Esperamos que este artigo ajude as pessoas a entender melhor os
benefcios por trs do BDD - e que fique claro que as ferramentas
de BDD so apenas complementares a essa metodologia gil
completa que o BDD .
Se voc quer ir mais a fundo no assunto, ns sugerimos as
seguintes fontes:
Specification by example do Gojko Adzic
The RSpec Book do David Chelimsky
Dave Astels and Steven Baker on RSpec and Behavior-Driven
Development
Gojko on BDD: Busting the Myths
APENAS EXECUTE O
BUILD NOVAMENTE ELE DEVE FICAR VERDE
Neil Philip Craven
Apenas execute o build novamente - ele deve ficar verde.

Voc escuta isso no seu projeto? Seus testes so flaky (instveis
ou no-determinsticos)? O build muda de verde para vermelho e
vice-versa sem nenhuma razo aparente? O que voc tem feito a
respeito?
Recentemente ingressei em um projeto que tinha esse problema.
relativamente normal encontrar esse problema e ainda
mais comum contornar esse problema apenas executando
os testes novamente. Alguns times inclusive adicionam scripts
para, automaticamente ao final do build, re-executar testes que

falharam.
Testes flaky ou sistema flaky?

Mas como voc capaz de diferenciar um teste flaky de um
sistema flaky? Ns certamente no conseguimos - mais adiante
descobriu-se que o sistema era flaky e nossos usurios tiveram
problemas com isso. Esse no um problema simples de se
resolver. Aqui esto duas abordagens que nos ajudaram:
1. Identifique os testes no determinsticos:
2. No os ignore, conserte-os.
Voc deve identificar se o problema est no teste ou se est no

sistema. Pense a respeito da sua sute de testes - voc possui
algum teste no-determinstico? Voc provavelmente possui,
a menos que tenha sido muito cuidadoso. Voc pode tentar
descontruir seus testes no determinsticos e implement-lo em
um nvel mais baixo. Voc perder um certo grau de cobertura mas
os resultados do teste sero confiveis. Voc pode acompanhar
os logs em tempo real e, quando apropiado, verificar a interface
grfica da mquina de testes, enquanto os testes esto sendo
executados, para saber se eles se comportam da maneira
esperada.
Entender o seu problema no faz com que ele desaparea.

Voc precisa parar de adicionar novas funcionalidades ao redor
e consertar esse problema. Usando a abordagem de ignorar o
problema, nossa sute de testes funcionais passou de praticamente
verde para praticamente vermelha. O dia em que tivemos 13
dos 17 builds vermelhos foi a gota dgua e ns decidimos que
medidas drsticas deveriam ser tomadas. Qual foi nossa ao?
Simplesmente passamos a ter mais disciplina em relao ao
processo que ns impusemos. Nos decidimos que removeramos
a opo de re-executar a sute de testes caso o cdigo-fonte no
tivesse sido alterado, e ns reforamos a regra de que voc apenas
poderia enviar suas modificaes, para o servidor de controle de
verso, se elas estivessem relacionadas correo do build.
Como era de se esperar, no final do dia seguinte haviam 7 pessoas
ao redor da mquina de build tentando consertar esses builds
instveis. Como resultado, ns descobrimos alguns testes mal
escritos e encontramos seis problemas reais com o sistema. O
build ainda estava vermelho, mas ao invs de cruzarmos os dedos
ns tnhamos seis novos erros para consertar.
ENTREGA CONTNUA
COM BUILD
QUEBRADO E
CONSCINCIA LIMPA
Lucas Medina
J pensou em fazer Entrega Contnua no seu projeto? E Entrega

Contnua com o build eventualmente quebrado? Pode parecer
perigoso, mas na verdade no o fim do mundo e mais comum
no dia a dia dos projetos do que voc pensa. Concordamos que a
Entrega Contnua deve ser feita com a pipeline de build toda verde,
e esse o nosso objetivo. Este artigo compartilha a experincia de
um projeto especfico.
Pense em um cenrio no qual em torno de 5 builds vo para
ambiente de produo todos os dias, mesmo que o build esteja
quebrado; no qual fazemos o deploy da produo mesmo que o
build de desenvolvimento no esteja todo verde e nem todos os

testes estejam passando.
Pense em um projeto de gerenciamento de infraestrutura na
nuvem que recebe aproximadamente 10 mil visitas nicas dirias,
com 5 times desenvolvendo e empurrando cdigo de dois locais
diferentes. Manter o build verde num projeto em que qualquer
desenvolvedor trabalha em qualquer parte do cdigo um grande
desafio, porque todos os times tm autonomia para desenvolver e
entregar.
Para iniciar os trabalhos, criamos um branch de vida curta (short

lived branch) no master e uma flag de funcionalidade que permite
aos desenvolvedores continuar empurrando cdigo mesmo
que a funcionalidade no esteja completa, uma vez que ela fica
escondida pela flag at estar completa - e desenvolvemos a estria.
Ao final integramos novamente ao master, rodamos os testes e
mandamos ver, empurramos para produo. importante reforar
que este deve ser um branch de vida curta. Se cada time ou
funcionalidade acabar tendo um branch vida longa, isso poderia
gerar um problema em si e um verdadeiro inferno de merges.
perfeitamente.
Lembra das flags de funcionalidade? Pois , enquanto as
estrias estavam sendo desenvolvidas, o ambiente em preview
era onde as histrias que estavam escondidas no ambiente de
pr-produo eram testadas.
Por fim, produo era onde a festa acontecia. Era o ambiente
no qual o cliente usava a aplicao.
Para fazer tudo isso acontecer precisamos de uma sute de testes

boa e estruturada. Essa sute no de responsabilidade de um
time especfico, mas de todos os times envolvidos. Uma estria
entregue significa necessariamente testes unitrios e de aceitao
feitos e integrados. Sendo assim, toda nova funcionalidade est
coberta por testes automatizados, garantindo a preveno de
defeitos quando novas funcionalidades so adicionadas.
Um dos nossos times de desenvolvimento nesse projeto era
composto apenas por testadores. Estes eram responsveis por
automatizar reas que no foram cobertas no desenvolvimento
das estrias, manter as sutes de testes estveis e aprimorlas, alm de implementar os chamados caminhos no felizes e
corner cases.
E quais eram os ambientes em que estvamos trabalhando? Bom,
havia quatro tipos:
Um deles era o staging, um ambiente de adaptao, e tinha o
objetivo principal de encontrar erros de integrao com APIs
externas.
O ambiente de pre-produo era exatamente igual ao
de produo, ali tudo j precisava estar funcionando
Todo commit que integramos ao master passa pela sute de

teste. Atravs do fabuloso radiador de integrao, os times
acompanham o estado da integrao. Caso tudo passe, maravilha,
vai direto pra produo. Caso alguma sute falhe, investigamos a
causa e decidimos sobre fazer a entrega assim mesmo ou no.
Se decidimos que sim, o build quebrado vai para produo com a
segurana de que se trata ou de um teste/uma sute instvel, de
uma parte do cdigo que no foi alterada ou simplesmente de que
o teste que falhou no era expressivo o bastante para bloquear a
entrega.
Algumas consideraes finais sobre essa abordagem de Entrega

Contnua: quando testes de aceitao esto levando tempo
demais, talvez seja um sintoma de que sua aplicao est
grande demais ou que a unidade de deployment no granular
o suficiente. Crie flags de funcionalidade: isso facilita sua vida
se o time precisa desabilitar uma funcionalidade em produo.
Mantenha o foco e a mentalidade nos testes, porm no seja to
rgido e religioso, avalie os erros e use seu conhecimento para
tomar decises bem embasadas.
Como o nmero de integraes aumentou muito medida

que os times cresciam, rodar a sute inteira toda vez tornouse insustentvel. Por isso, criamos o conceito de nibus de
integrao. Esse nibus recolhe os passageiros a cada hora,
integra em um pacote nico e executa a sute de testes.
Como sabemos, nem tudo so flores, vrios so os desafios nessa
modalidade de Entrega Contnua:
sutes muito lentas retardam a entrega;
testes que falham aleatoriamente so inteis, pois no so
confiveis;
dependncia de APIs externas causa falhas em testes que no
so parte da camada em desenvolvimento;
a quebra das funcionalidades em produo acontece e
precisamos pensar na causa raiz para que o problema no se
repita.
DevOps, que foca na preparao dos ambientes e na Engenharia

de Release ao lidar com a pipeline de deploy no processo de
desenvolvimento, no opcional; o ideal ter uma ou duas
pessoas dedicadas a essa rea, para que voc possa fazer
Entrega Contnua com menos dores de cabea. Isso porque s
vezes precisamos de um par de olhos dedicado especialmente
qualidade da Automao de Infraestrutura e da Engenharia de
Release durante um tempo um pouco maior. Para garantir que
esse par no trave, e tambm para que todos no time entendam
e adquiram experincia com a Engenharia de Release e o trabalho
com deploy para produo, recomendamos fazer uma rotao
entre vrios membros do time ao longo do tempo.
A combinao da alternncia de funcionalidades com a habilidade
de ativar sutes de teste correspondentes sob demanda ajudam
a garantir que tanto as funcionalidades completas como as
incompletas possam ir ao ar sem comprometer a qualidade.
MELHORANDO
A QUALIDADE DE
PROJETOS ATRAVS DO
PODER DAS NUVENS
Max Lincoln
Seus processos de qualidade e ferramentas mudam para construir

uma aplicao na nuvem? A resposta bvia - depende. Mesmo
tendo a mais clara definio entre as buzzwords recentes,
existem vrios tipos de nuvem e muitas formas de integr-la com
sua aplicao ou processo de desenvolvimento. Se voc tem
um time experiente, capaz de escolhas bem informadas, ento
essas opes so uma grande recurso em favor da qualidade.
O time pode usar a nuvem com uma ferramenta para assegurar
qualidade, ao invs de torn-la apenas mais um aspecto que
precisa ser testado.
O que a nuvem?
Existem algumas poucas definies de nuvem que eu acredito
serem teis.
A primeira, do Gartner Group, descreve um caso singular de
utilizao que uma tima forma de promover qualidade da
nuvem:
Ambiente de laboratrio virtual. Esses consumidores

geralmente tentam prover infraestrutura auto-gerida para um
grupo de usurios tcnicos, como desenvolvedores, cientistas
ou engenheiros, para o propsito de teste e desenvolvimento,
computao cientfica ou outro tipo de computao em lote.
(Quadrante Mgico para Infraestrutura Pblica de Nuvem
como Servio - Gartner)
A natureza auto-gerida muito importante. Se voc precisa um
ambiente por apenas 30 minutos para um experimento, ento
um desperdcio gastar mais de 30 minutos orando ou agendando
a criao de tal ambiente. Um dos meus colegas enfatiza: Eu
posso iniciar mquinas virtuais em minutos, destru-las, e repetir
esse processo quo frequentemente eu precisar. Todo o resto
infraestrutura do passado. Se eu tenho que mandar e-mail para
algum, abrir um chamado, submeter um pedido para conseguir
uma mquina virtual, etc. ento infra-estrutura do passado.
A outra definio importante a definio oficial de computao
em nuvem do Instituto Nacional de Padres e Tecnologia (NIST). A
definio (de acordo com o sumrio feito por Martin Fowler) contm:
Cinco caractersticas essenciais: servio por demanda autogerida, ampla conectividade, resource polling, elasticidade
rpida e mensurvel.
Trs modelos de servio: software, plataforma e infraestrutura
(tudo como servio).
Quatro modelos de instalao: privada, comunitria, pblica e
hbrida.
Vantagens da Nuvem em favor da Qualidade

Vejamos como podemos tirar vantagem dessas caractersticas da
nuvem em favor das 8 dimenses da verificao de qualidade. Na
parte I iremos examinar como a nuvem ajuda com Performance,
Funcionalidades, Confiabilidade e Conformidade. Na parte II
iremos descrever os efeitos positivos da nuvem em termos de
Durabilidade, Serviciabilidade, Esttica e Qualidade Percebida.
#1 Performance
Performance refere-se s caracteristicas primrias de operao
de um produto e envolve atributos mensurveis. Eu acredito que
performance a funcionalidade de negcio #1. Tm havido muitos
estudos mostrando que mesmo a menor reduo de performance
pode ter um grande impacto no negcio. A nuvem ajuda voc a
manter sua performance de vrias formas.
a. Resource pooling e elasticidade rpida lhe do uma extra fora
quando voc precisa, e sem gastar mais do que o necessrio.
J que elasticidade rpida uma caracterstica essencial de
computao em nuvem, voc tem a opo de adicionar mais
recursos computacionais para atender picos de utilizao ou
acompanhar tendncias recorrentes na demanda.
Por exemplo, voc pode ter mais servidores rodando durante a
semana do que nos finais de semana. possvel fazer esses ajustes
finos sem sair do oramento, porque outra caracterstica essencial
- ser mensurvel - permite que voc seja cobrado por hora (ou
mesmo em intervalos menores de tempo) pelos recursos.
b. Ampla conectividade e Redes de Distribuio de Contedo

(CDN) permitem a voc estar mais pximo de seus clientes e
parceiros de negcio.
A caracterstica de estar amplamente disponvel globalmente torna
fcil tirar vantagem de redes de alta velocidade, rpidos servios
de resoluo de nomes (DNS), e CDNs como Akamai para acelerar
sua aplicao. Isso especialmente importante para aplicaes
mveis, nas quais redes so mais lentas, nas quais cada byte ou
milisegundo de latncia entra na conta.
Um CDN pode ajudar voc a cachear contedo prximo de seus
usurios, comprimir seu contedo, e garante que o mesmo
suporta requisies condicionais. Todas essas medidas podem
tornar seu site significantemente mais rpido.
c. Empresas de Testing as a Service permitem que voc possa
rapidamente alocar mais recursos e rodar testes de perfomance.
Existem muitos servios na nuvem que ajudam a testar ou
aumentar a performance de seu site. difcil e caro criar
seu framework para testes de performance com o poder de
rapidamente aumentar as requisies para simular um grande
nmero de usurios. Geralmente frameworks caseiros passam por
problemas porque eles enfrentam desafios relacionados a rede e
performance antes mesmo da aplicao a ser testada, ou porque
faltam funcionalidades para simular usurios de outras partes do
mundo, ou por conexes lentas. Ao invs de criar, possvel usar
um servio como o Blitz.io. Blitz pode de forma econmica simular
1000 usurios na rede de sua escolha por 1 minuto ou mesmo
escalar isso para 50000 usurios por 20 minutos.
Se voc precisa testar um fluxo mais complexo, voc pode usar
algo como BlazeMeter, que permite rodar testes com JMeter ou
Selenium a partir da nuvem.
#2 Funcionalidades
Funcionalidades so caractersticas adicionais para tornar um
produto ou servio mais atraente e entregar mais valor para
o usurio. Todavia, essa apenas uma hiptese at que voc
ponha a funcionalidade na frente de usurios reais e valide seu
valor. Funcionalidade que bem testada mas no til no uma
funcionalidade, uma inutilidade de alta qualidade. A nuvem
pode te ajudar a no tornar seu produto bloated e rapidamente
testar quais funcionalidades esto implementadas corretamente.
a. Ferramentas na nuvem permitem que voc sempre tenha poder
de teste suficiente.
Para testar funcionalidades rapidamente, voc pode tirar
vantagem das caractersticas elsticas da nuvem. Voc pode usar
ferramentas como [jclouds-jenkins] para se certificar que seu
pipeline de Entrega Contnua pode lidar com um pico em commits
sem ficar sem mquinas. Voc pode usar ferramentas como
Vagrant (com sua escolha de providers como VMWare ou vagrantrackspace, e provisionamento com Puppet, Chef ou Ansible) para
rapidamente criar um ambiente de testes e destru-lo assim que os
testes terminarem. Voc tambm pode usar servios de teste Saas,
como SauceLabs, Appium, Xamarin, Appium ou Soasta, para tornar
a execuo de testes mais rpida atravs de paralalizao ou
mais abrangente rodando contra vrios browsers ou dispositivos
mveis.
b. Os vrios modelos *aaS lhe do vrias opes de contruir-vscomprar. IaaS toma controle completo, PaaS lhe permite evitar
algumas decises arquiteturais, DBaas, Logging-as-a-Service,
etc. deixam certo aspecto de sua aplicao a cargo de um
fornecedor.
Uma estratgia para evitar desperdcio manter sua aplicao
focada em resolver o problema especfico de seu domnio, e

confiar em parceiros SaaS para servios relacionados. Um bom
exemplo o envio de e-mail. No to fcil processar rapidamente
um template de e-mail e envi-lo para um grande nmero de
interessados. Adicione a isso a necessidade de processar pedidos
de usurios que no querem mais receber e-mails, reclamaes
de spam, agendamento de campanhas via e-mail, analytics e muito
mais. Provedores como Mailgun lhe permitem terceirizar esses
problemas e focar em seu negcio. Existem provedores disponveis
para vrias necessidades auxiliares, tais como processamento de
video atravs do Zencoder ou processamento de pagamento com o
Paypal.
c. Deployments fceis tornam testes A/B, MAB (Multi-Armed
Bandit) e outras opes mais viveis.
Aplicaes como Mailgun suportam analytics e testes A/B, dois
mtodos que ajudam a garantir a qualidade das funcionalidades
entregues. Analytics, A/B e testes multivariados tornam possveis
experimentos para verificar quais funcionalidades ou contedo
proveem mais valor. Outros servios na nuvem que ajudam a
implementar esses experimentos incluem Google Analytics Content
Experiments, Optimizely and Visual Website Optimizer. Voc tambm
pode integr-los diretamente em sua aplicao, usando bibliotecas
como a Ruby gem split.
Usando essas tcnicas, voc pode:
Otimizar a relao funcionalidade-desperdcio utilizando A/B
ou testes multivariados para provar que novas funcionalidades
entregam valor antes de decidir por lan-las para todos os
usurios.
Minimizar a quantidade de cdigo auxiliar e testes que voc
mantm atravs da utilizao de servios como Mailgun e
Zencoder.
Rapidamente testar as funcionalidades restantes atravs de

escalonamento elstico da infraestrutura de teste ou utilizando
servios na nuvem de provedores de testes.
A razo pela qual recomendamos tantas solues SaaS
porque eles so altamente confiveis. PayPal compartilhou que
a infraestrutura de nuvem o segredo para a confiabilidade de seu
servio.
#3 Confiabilidade
Confiabilidade a probabilidade de um produto no falhar
dentro de um perodo especfico de tempo, algo que pode
ser especialmente crtico para certos domnios. Confiabilidade
pode ser a dimenso da qualidade onde a nuvem prov a maior
vantagem. Mesmo que componentes individuais na nuvem possam
falhar, a nuvem torna fcil projetar para a falha. Dessa forma
voc ter aplicaes resilientes que podem sobreviver mesmo aos
problemas mais severos.
a. A nuvem permite que voc distribua sua aplicao atravs
de mltiplos data centers ou mesmo provedores, garantindo
Recuperao de Desastres.
A maioria de provedores pblicos de nuvem oferecem servios
de vrios data centers ao redor do mundo. Voc pode tirar
vantagem disso para facilmente construir uma aplicao altamente
redundante ou criar vrios sites para recuperao de desastre.
Se isso no for suficente, voc pode usar RightScale, que ajuda a
gerenciar mltiplos servios de nuvem no mundo inteiro, como
tambm seus servios de nuvem privada. Se voc quiser garantir
que sua aplicao nunca cair, voc pode execut-la de vrios
lugares do mundo com Rackspace, Amazon e com sua prpria
instncia de OpenStack.
b. A nuvem tambm lhe d capacidades de back-up e

armazenamento infinito, ento reteno de backup apenas uma
deciso de custo.
A nuvem torna extremamente simples gerenciar backups. Servios
Object Storage como Amazon S3 e Rackspace Cloud Files oferecem
redundncia de dados e armazenamento virtualmente ilimitado.
Voc pode simplesmente clicar (ou agendar) sempre que quiser
um backup.
c. Provedores de Nuvem e empresas de *aaS oferecem
monitoramento de todos os tipos.
Existem timos sistemas de monitoramento baseados na nuvem,
ento voc pode detectar a deteriorao de um servio antes
que isso se torne um grande problema. Voc pode definir alertas
de monitoramento para a maioria das infraestruturas de nuvem
atrves do prprio fornecedor, e pode tambm integrar sua
aplicao com timos servios de gesto de logs como NewRelic,
Loggly ou Splunk Storm.
#4 Conformidade
Confirmidade a preciso com a qual o produto ou servio atende
padres especficos. A nuvem pode lhe ajudar com necessidades
de conformidade ou compliance, seja evitando a necessidade de
conformidade com um padro utilizando um provedor de servio,
seja provendo infraestrutura consistente para ajudar a garantir
conformidade.
com tal requerimento diretamente. Voc pode usar a expertise

do Mailgun para lidar com o CAN-SPAM Act, para, por exemplo,
certificar-se que seus e-mails tero um link para remoo da lista
e um endereo fsico de correio. Voc pode deixar que o PayPal
ou Braintree Payment Gateway lide com a maior parte das suas
preocupaes relacionadas a compliance PCI-DSS.
Se voc precisa de auditoria forte e garantias de segurana,
existem servios como Dome9, que oferecem solues avanadas
de segurana, compliance e auditoria para sua infraestrutura de
nuvem.
b. Usar uma camada de caching oferecida pela Rede de
Distribuio de Contedo (CDN) da nuvem evita problemas com
clientes gerados por no conformidade.
No esqueamos daqueles testes que no intimidam tanto. Voc
est em conformidade com IEEE ou padres W3C? Se voc est
configurando servidores de cache por conta prpria possve que
um pequeno erro de configurao cause erros ou deixe mais lenta
sua aplicao para alguns usurios. Se voc est usando a camada
de caching oferecida pelo CDN da nuvem ento improvvel que
eles estejam configurados de forma a causar problemas.
Ferramentas como RedBot, que acham erros comuns de
protocolo, Google Page Speed ou YSlow podem ajudar ainda
mais, com verificaes no caching, negociao de contedo e
compresso.
a. Use opes de SaaS para evitar a necessidade de confomidade.

Geralmente, voc pode delegar uma funcionalidade auxiliar para
um provedor SaaS em conformidade, ento voc no precisa lidar
MELHORIA DA
QUALIDADE COM A
NUVEM - PARTE II
Max Lincoln
Na primeira parte do artigo sobre qualidade de processos na

nuvem examinamos como a nuvem ajuda com Performance,
Funcionalidades, Confiabilidade e Conformidade. Na parte II
descreveremos os efeitos positivos da nuvem sobre a Durabilidade,
Serviciabilidade, Esttica e Qualidade Percebida.
Durabilidade
Durabilidade mede a extenso de vida do produto. Quando um
produto pode ser reparado, torna-se mais difcil estimar sua
durabilidade, j que ele ser usado at no ter mais retorno

economico para ser operado.
O segredo da durabilidade usar peas intercambiveis. Um vela
de ignio tpica dura de 16.000 a 32.000 kilometros. Um carro
durar muito mais - contanto que voc substitua suas velas de
ignio, leo, os pneus, os freios e outras peas. Quando a vela de
ignio alcana o fim da sua expectativa de vida, ela substituda e
no reparada.
O mesmo deveria acontecer com os servidores. Servidores,

especialmente em nuvem, seriam supostamente commodities
idnticas. Mesmo existindo alguns tipos de servidores - servidores
web, servidores de banco de dados, servidores app X - servidores
do mesmo tipo deveriam ser idnticos. Por isso se um servidor
para de funcionar corretamente, deveria ser mais simples e fcil
substitu-lo do que consert-lo.
Servidores que so facilmente destrudos e substitudos so
chamados de Servidores Phoenix. Ns recomendamos que
servidores renasam das cinzas mais frequentemente, ao invs de
esperar eles quebrarem. Voc no iria esperar seu carro parar de
andar para substituir o leo. Por que deveramos esperar nosso
website cair para substituir o antigo servidor web?
Esse processo no se aplica apenas ao hardware. Ele involve
reverter a deriva de configuraes (ou configuration drift) mudanas ao longo do tempo que comeam a diferenciar
servidores que deveriam ser idnticos. Algumas vezes isso
acontece mesmo que voc esteja usando ferramentas de
automao de infraestrutura como Puppet e Chef. Seus servidores
antigos tm somente a tech stack atual como os servidores novos
ou eles tem algum resqucio de software antigo que voc esqueceu
de desinstalar?
Serviciabilidade
Serviciabilidade (ou Recuperabilidade) a velocidade com a qual
um produto pode ser colocado em servio quando danificado,
bem como a competncia e o comportamento do tcnico de
manuteno.
A nuvem incrivelmente fcil de ser mantida e nos possibilita
construir sistemas e produtos, de TI como servio, de uma maneira
jamais anteriormente criada. Mais uma vez, a caracterstica de selfservice da nuvem extremamente importante, como um recurso
de pooling. Se precisamos executar uma mudana ou manuteno
em um servio, ns podemos simplesmente remov-lo do pool,
repar-lo e recoloc-lo em servio.
1. Reduzir downtime e evitar janelas de manuteno para
deploy s 3am
Tcnicas como Blue/Green deployments so fceis na nuvem.
Essa uma estratgia de deploy na qual voc tem o balanceador
de carga com dois pools: azul e verde. Somente um pool est
ativo por vez, e voc pode fazer deploys com zero downtime
utilizando a alternncia entre os dois pools. Ento, se o pool azul
est ativo, voc faz o deploy das suas mudanas no pool inativo,
nesse caso o verde. Uma vez que voc rodou seu smoke test nos
servidores verde, voc pode desativar o pool azul e ativar o pool
verde. Se acontecer qualquer downtime, dever ser de cerca de
um segundo. Voc ento monitora seus sistemas e o feedback de
usurios para verificar quaisquer sinais de problemas. No primeiro
sinal de problema, voc s precisa trocar novamente para o pool
azul. Novamente, isso s durar um segundo. Voc no reverteu
e perdeu todas as suas mudanas do pool verde - voc s esta
comprando mais tempo para poder investigar os problemas
que foram apontados. E se voc determinar que um problema
mnimo ou um alarme falso, voc pode dar uma segunda chance
ao pool verde.
2. ... Ou considere iniciar um substituto
O padro azul/verde o mais fcil para visualizar, implementar e
zerar o downtime de deploy dos sistemas, mas h outras opes.
Algumas organizaes aplicam algo parecido com o padro
azul/verde, mas revertem para o seu sistema em um site de
Reparao de Desastre. Um bom benefcio dessa abordagem

exercitar alguns dos seus processos de Reparao de Desastre e
equipamentos a cada deploy - uma coisa que muitas empresas
deixam passar. O padro de deploy canrio uma tcnica que
redefine o que produo e verso de produo significam. Se
voc tem um grupo de servidores, voc poderia fazer o release de
uma nova verso em somente um deles. Voc verifica (exatamente
como no caso dos canrios em uma mina de carvo) se esse
servidor apresenta qualquer problema, e reverte o release caso
necessrio. Se no encontrar problemas, voc pode continuar
um novo release de maneira incremental - 10%, 25%, 50%, 80% e
finalmente 100% em seus servidores. Essas estratgias no exigem
fluxos de trabalhos manuais complexos e propensos a erros.
3. A nuvem altamente controlvel, com SDKs multi-nuvem com
vrias linguagens de programao e ferramentas disponveis de
fornecedores populares como PuppetLabs, OpsCode, Ansible e
HashiCorp.
A maioria dos provedores de nuvem fornece uma poderosa API de
controle para seus recursos. Frequentemente, voc pode escolher
seu conjunto de linguagens e ferramentas favoritas - a Rackspace,
por exemplo, suporta SDKs em Ruby, Java, .Net, Node.js, Python e
PHP. No subestime o poder de fazer deploys usando scripts que
seu time de desenvolvimento e operaes entendam, e fazendo o
deploy as 3pm ao invs das 3am, dessa forma o time que criou as
mudanas est por perto para suportar o seu lanamento.
Esttica
Esttica a medida subjetiva que indica como um usurio
responde a um produto. Ela representa uma preferncia pessoal.
Concordo que a nuvem pouco faz para embelezar o seu site.
Apesar disso, ambientes e servios na nuvem ainda assim so
ferramentas poderosas para refinar a esttica da sua aplicao.

Como muito fcil colocar para rodar um ambiente na nuvem,
voc pode facilmente criar um para demonstrar uma proposta de
alterao visual ou para melhorar a experincia de usurio.
Se voc est construindo um website, especialmente um website
para dispositivos mveis, um grande desafio certificar-se de
que ele est esteticamente bom, no s no seu laptop, mas
tambm em cada navegador e dispositivo mvel usado pelos
seus usurios. Ferramentas de teste baseadas na nuvem tornam
fcil o processo de comparar a aparncia da aplicao quando
executada nos diversos dispositivos. Se voc criar um ambiente
para homologao, voc pode utilizar servios cloud do tipo amplo
acesso (Broad Network Access) como mogotest, Browsershots,
Browserstack ou Cross Browser Testing. Voc tambm pode criar
seu prprio ambiente de testes na nuvem, utilizando ferramentas
como Selenium, Huxley ou dpxdt.
Qualidade percebida
A percepo da qualidade uma qualidade atribuda a um bem ou
servio baseada em medidas indiretas como histria do produto.
O seu site pode estar livre de problemas agora, mas se voc teve
um monte de problemas no passado seus usurios ainda podem
estar com a sensao de que seu site de baixa qualidade. No
apenas o nmero de bugs que voc teve mas tambm o quo
rpido voc os corrigiu.
O uso da nuvem, combinado com Entrega Contnua, torna mais
fceis e rpidas a reproduo, correo e lanamento da correo
de bugs. Torna tambm mais fcil lanar novas funcionalidades e
melhorias baseadas em feedback do usurio.
Esse ciclo rpido de correo de bugs e entrega de melhorias

o que d ao usurio uma percepo de qualidade. Aumentar
a percepo de qualidade a chave para fazer seus usurios
sentirem-se como parceiros e promover o seu produto fazendo
indicaes.
A nuvem e as oito dimenses

Eu acredito piamente que desenvolvendo, testando e fazendo
implantao na nuvem voc pode construir produtos de melhor
qualidade. A capacidade de construir um produto de melhor
qualidade em todas as oito dimenses pode no ser exclusividade
da nuvem, mas a nuvem ajuda a remover quaisquer barreiras que
estejam impedindo voc de atingir estas metas.
PROTRACTOR:
TESTANDO APLICAES
ANGULARJS COM UMA
SOLUO INTEGRADORA
Daniel Amorim
Se voc est desenvolvendo uma aplicao AngularJS, use

Protractor para test-la. Porqu?
Protractor um framework de testes funcionais para
aplicaes AngularJS e funciona como uma soluo integradora
combinando poderosas ferramentas e tecnologias tais como
NodeJS, Selenium, webDriver, Jasmine, Cucumber e Mocha.
Existem diversas customizaes do Selenium para facilitar a
criao de testes para aplicaes AngularJS
Protractor tanto acelera quanto evita a necessidade do uso
de sleeps e waits em seus testes tendo estes otimizados
internamente.
Como baseado nos conceitos do AngularJS, fcil aprender

Protractor se voc j conhece sobre AngularJS e vice-versa.
Protractor permite que seus testes sejam organizados
baseados no Jasmine, possibilitando que voc escreva tanto
testes unitrios quanto funcionais no Jasmine.
Executa em navegadores reais e headless.
O que mais voc precisa de um framework de testes
automatizados?
Entendendo o Protractor mais a fundo

A primeira verso do Protractor foi lanada em julho de 2013,
quando o framework era basicamente um prottipo de um
framework de testes. Porm o Google, com o apoio da comunidade
de testes, est evoluindo o framework para acompanhar a
evoluo do AngularJS e para satisfazer as necessidades da
comunidade que est usando-o.
O projeto do Protractor publico no Github e voc pode
acompanhar as issues do projeto, adicionar issues que voc ache
interessantes, comentar nas issues abertas pelos outros, fazer
pull requests para colaborar com o projeto, etc. Qualquer um que
esteja interessado em colaborar com o crescimento do projeto
ser bem-vindo!
O Protractor um framework de automao de testes funcionais,

ento o intuito dele no ser a nica forma de testar a sua
aplicao AngularJS, mas sim cobrir os critrios de aceitao
exigidos pelo usurio. Mesmo existindo testes que executem
em nvel de UI, com o Protractor ainda necessria a criao
de testes unitrio e de integrao. Esse um framework para
testes funcionais que roda em cima do Selenium, ento ele j
contm todos os benefcios e facilidades do mesmo alm das
funcionalidades que ele prov para testar aplicaes AngularJS
especificamente. Pelo fato do Protractor rodar em cima do
Selenium possvel a utlizao dos drivers que implementam
o WebDriver, tais como ChromeDriver e GhostDriver. No caso
do ChromeDriver possvel rodar os testes em cima dele sem a
necessidade do Selenium Server. J para utilizar o GhostDriver
necessria a utilizao do PhantomJS, o qual se utiliza do
GhostDriver e nesse caso permite rodar os testes em Headless
mode.
O framework permite que seja utilizado Jasmine para organizar e
criar seus testes e resultados esperados. O Jasmine compatvel
com o Protractor pelo fato de que todos os recursos que so
extrados do browser para fazer os testes so promises, e o
comando expect do Jasmine trata internamente essas promises e
faz parecerem transparentes as validaes dos testes.
No incio, como o Protractor ainda era recente e ainda estava em
fase de maturao, a documentao para us-lo era restrita e
ficava desatualizada rapidamente devido sua evoluo constante.
Porm, nos ltimos meses a colaborao da comunidade tem
crescido bastante e essa documentao tem sido mantida mais
atualizada. Isso se deve facilidade que a comunidade tem de
questionar e colaborar atravs do projeto publico no Github. A
nica burocracia que voc precisa assinar o contrato digital de
colaborador do Google.
PROTRACTOR
NA PRTICA
EM 3 PASSOS
Daniel Amorim
No s com teoria que se aprende automao de testes (assim

como vrias prticas de desenvolvimento). Por isso, nesse artigo
vamos utilizar uma abordagem prtica de como utilizar Protractor.
Seguindo os 3 passos abaixo, voc j saber o bsico para avanar
na criao dos seus testes sozinho.
Com apenas um simples comando npm install protractor -g o

Protractor estar instalado em sua mquina e pronto para ser
executado atravs do comando protractor. Porm, ao executar
esse comando, o protractor vai emitir a mensagem de que exige
um parmetro para a execuo do Protractor.
Passo 1 - Instalando
Esse parmetro exigido pelo Protractor o caminho do arquivo de

configurao do mesmo, pois para executar os testes necessrio
ter um arquivo de configurao que vai guiar o Protractor em como
ele deve ser executado.
Um pr-requisito para o uso do Protractor o Node.js, pois o

framework de testes um pacote node que deve ser instalado
atravs do NPM (Node Package Manager).
Passo 2 - Configurando
Existem vrios parmetros que permitem a voc configurar o
Protractor. Abaixo eu descrevo alguns que penso serem os mais
importantes.
SeleniumAddress: Permite informar uma URL do Selenium
Server que o Protractor usar para executar os testes. Nesse
caso o Selenium Server deve estar previamente iniciado antes
de rodar os testes no Protractor.
SeleniumServerJar: Permite informar o caminho do arquivo
.jar do SeleniumServer. Caso esse parmetro seja utilizado,
o Protractor ir controlar a inicializao e a finalizao do
Selenium Server, no sendo necessrio iniciar o Selenium
Server antes de executar o Protractor.
SauceUser e SauceKey: Caso informados o Protractor ir
ignorar o parmetro SeleniumServerJar e ir executar os testes
contra um Selenium Server no SauceLabs.
Specs: Um array de arquivos de testes pode ser passado
atravs do parmetro specs, o qual o Protractor ir executar.
O caminho dos arquivos de teste deve ser relativo ao arquivo
de configurao.
seleniumArgs: Permite passar parmetros para Selenium caso
o Protractor inicialize-o atravs do SeleniumServerJar.
capabilities: Parmetros tambm podem ser passados para
o WebDriver atravs do capabilities, onde informado o
browser contra qual o Protractor vai executar os testes.
baseUrl: Uma URL de acesso padro pode ser passada
para o Protractor atravs do parmetro baseUrl. Com isso
toda a chamada feita para um browser ser para essa URL
especificada.
framework: O framework de testes e de assertions que ser
utilizado pelo Protractor pode ser determinado pelo parmetro
framework. Para este existem as seguintes opes: Jasmine,
Cucumber e Mocha.
allScriptsTimeout: Para configurar um timeout para cada teste

executado, o Protractor prov o parmetro allScriptsTimeout,
o qual deve receber um valor em milisegundos.
Todos esses parmetros so encapsulados em um objeto node
com nome de config para que o Protractor possa identificar esses
parmetros.
No cdigo abaixo temos um exemplo de arquivo de configurao
do Protractor que foi salvo como config.js.
Nesse exemplo est configurado o parmetro seleniumServerJar

para iniciar o Selenium Server atravs do Protractor. O arquivo
de testes que ser executado neste exemplo o hello_world.
js que est dentro da pasta tests. Estes testes sero executados
contra o navegador Chrome devido ao parmetro capabilities
estar configurado com o atributo browserName como chrome.
O timeout configurado para a execuo de cada teste de 30
segundos.
Aps ter o arquivo de configurao pronto, basta ir at a pasta do

arquivo e executar o comando protractor config.js e o Protractor
ir executar seguindo as intrues passadas no arquivo. Porm,
a mensagem abaixo ser exibida pelo fato de no termos um
arquivo de testes chamado hello_world.js ainda.
O AngularJS utiliza algumas tcnicas especficas para manipular

o DOM, inserindo ou extraindo informaes do HTML. Exemplos
disso so a utilizao do ng-model para a entrada de dados, o
binding de atributos para exibir dados no DOM e o ng-repeat para
a exibio de informaes no HTML que estejam contidas em uma
lista no javascript.
Para capturar um elemento na interface que contenha um
ng-model, por exemplo, o Protractor prov o comando
by.model(nome). Atravs desse comando o framework retorna o
WebElement o qual contm a diretiva ng-model com o valor nome.
Passo 3 - Criando testes

Como j citado nesta introduo, o Protractor roda em cima do
Selenium e por isso ele se utiliza de todas as vantagens que o
Selenium tem embutidas em si. Porm, o que faz do Protractor
o melhor framework de automao de testes para aplicaes
AngularJS so as facilidades criadas nele especificamente para
testar esse tipo de aplicao.
Os comandos customizados pelo Protractor visam capturar os
elementos da interface da aplicao atravs das diretivas do
AngularJS. Isso torna o framework interessante pelo fato de que o
profissional que aprender a utilizar o Protractor, automaticamente
vai aprender sobre o comportamento do AngularJS em relao
renderizao de elementos na interface. O inverso tambm
acontece: a partir do momento que se conhece AngularJS,
facilmente se aprende a utilizar o Protractor.
Dado o exemplo acima, quando executado o comando element(by.

model(nome)) o Protractor retorna o WebElement abaixo:
Para capturar elementos dos quais o AngularJS faz binding de

alguma informao, o comando um pouco diferente, mas a lgica
a mesma do model. O exemplo abaixo demonstra como utiliz-lo.
Acima temos um cdigo no qual fizemos alguns bindings de

informaes atravs do AngularJS. Ao executar o comando
element(by.binding(endereco)) pelo Protractor, retornado o
WebElement abaixo:
O cdigo a cima uma estrutura HTML criada para rodar uma

aplicao AngularJS. Dado que a nossa lista de alunos seja um
array com os alunos Andr, Fernando e Jos, o HTML gerado pelo
AngularJS ficaria da seguinte forma.
Na utilizao do ng-repeat o Protractor fornece o comando

by.repeater(aluno in alunos) o qual retorna um array de
elementos.
Este comando permite encadear as chamadas das funes row e
column para tornar sua busca mais especifica.
Encadeado com o comando row retorna o elemento em que o
ng-repeat est, porm com as informaes do objeto na posio
passada por parmetro ao comando row. Ex: by.repeater(aluno in
alunos).row(0) retorna o primeiro elemento da lista de nomes, pois
o javascript inicia a contagem do 0.
Caso queira buscar um elemento especfico dentro da estrutura do
repeater, possvel utilizar ainda o comando column encadeado
com os outros dois anteriores. Neste comando passa-se o nome
do atributo no qual est sendo feito binding no HTML, com isso
o Protractor retornar o WebElement no qual este binding est
sendo feito.
Dado este exemplo podemos entender como funciona o comando

by.repeater do Protractor.
No caso de executado o comando element(by.repeater(aluno
in alunos)) o Protractor ir retornar toda a estrutura HTML
apresentada acima.
Executando o comando element(by.repeater(aluno in alunos).
row(1)) retornada apenas a estrutura de HTML abaixo:
O exemplo abaixo demonstra como funcionam esses comandos.
E no caso mais especfico para buscar um elemento final,

executando o comando element(by.repeater(aluno in alunos).
row(1).column(nota)) o Protractor retorna apenas a tag span
abaixo:
Agora que j sabemos como usar alguns dos comandos do

Protractor, vamos criar alguns testes para demonstrar na prtica
o uso dos mesmo. Vamos utilizar o exemplos de site do AngularJS
(http://angularjs.org/) que apresento abaixo.
Colocando esses testes dentro do arquivo hello_world.js conforme

configuramos no captulo anterior, far desta a sua atual suite de
testes.
O que voc precisa fazer agora rodar novamente o Protractor e
agora no ser mais uma mensagem de erro que ser exibida, mas
o status de cada um dos testes executados.
Para essa aplicao podemos criar dois testes como exemplo:

No primeiro vamos verificar se o texto inicial da tag h1 Hello !,
pois no temos nenhum valor no atributo yourName ainda.
Em seguida usaremos Protractor como entrada de dados para
representar o atributo yourName e verificar novamente se
o texto dentro da tag h1 contm o valor Hello Protractor!. O
comando sendKeys(Protractor) um mtodo do WebElement
para digitar o valor dentro do campo texto.
Voil! Seus testes esto funcionando. Voc pode incrementar a

sua sute de testes quando for preciso ou ainda melhor, integr-la
a uma ferramenta de integrao contnua para mant-la rodando
constantemente.
GATLING: UMA
FERRAMENTA
DE TESTES DE
PERFORMANCE
Rodrigo Tolledo
Gatling uma poderosa ferramenta open-source para Teste de

Performance, lanada em dezembro de 2011. Ela foi mencionada
no ThoughtWorks Technology Radar de 2013 e 2014 como uma
ferramenta que vale a pena conhecer. Gatling uma DSL (domainspecific language) leve, escrita em Scala que vem com uma premissa
interessante de sempre tratar seus testes de performance como
cdigo de produo.
Um outro ponto interessante sobre o Gatling que voc pode
definir e escrever seus cenrios de teste de performance da
mesma forma como voc est acostumado a faz-los com outras

ferramentas de automao. Assim, voc pode escrever cdigo de
performance de forma legvel e de fcil manuteno, que pode ser
manipulado por qualquer sistema de controle de verso.
Gatling integra facilmente com Jenkins atravs do jenkins-plugin e
tambm pode ser integrado com outras ferramentas de integrao
contnua. Isso timo porque voc pode obter feedback constante
de seus testes de performance. Outra vantagem que voc pode
facilmente executar os testes atravs do Maven e do Gradle com a
ajuda do maven-plugin e do gradle-plugin. Gatling tambm fornece

relatrios elegantes e com informaes significativas sobre o
funcionamento da sua aplicao. A ltima verso estvel (2.1.7)
suporta Linux, OS X e Windows.
Portanto, agora que sabemos um pouco mais sobre Gatling, que
tal entender melhor tudo isso?
Basicamente, a estrutura do Gatling pode ser definida em trs
partes:
1. Configurao do protocolo HTTP - Define a URL base
que voc vai executar seus testes. Alm disso, voc pode
definir outras configuraes, como user agent, language
header, conexo e assim por diante.
2. Definio de Cenrio - o ncleo do seu teste! Um
cenrio um conjunto de aes (GET, POST, etc) que
sero executadas, a fim de simular uma interao do
usurio com o aplicativo.
3. Definio de Simulao - Define a carga (quantidade de
usurios) que ir executar simultaneamente seu cenrio
por um perodo de tempo.
Vamos imaginar uma aplicao web simples onde os usurios
podem cadastrar modelos de computadores. Essa aplicao
fornece feedback para o usurio logo depois que o modelo de
computador inserido corretamente na base de dados.
Em primeiro lugar, vamos adicionar algumas informaes bsicas
e comear definindo a nossa configurao HTTP. Montamos nossa
base URL para http://computer-database.gatling.io. Isto significa que
cada vez que executar um request, o Gatling vai utilizar nossa base
URL.
Depois disso, vamos definir um cenrio chamado First Simulation.

Este cenrio ir executar um conjunto de aes. A primeira ao
ser um GET para pgina inicial. A segunda ao novamente
ser um GET, dessa vez, acessando o form de cadastro de
computadores. Note que estamos utilizando um comando
interessante aqui: check(). Basicamente o que o comando faz :
aps enviarmos nossa requisio, usamos check() para verificar se a
requisio foi efetuada com sucesso.
Nossa terceira ao um POST. Como voc pode ver logo abaixo,

agora estamos inserindo informaes no form de cadastro de
computadores. Note que estamos realizando essa operao
utilizando identificadores nicos para cada elemento dentro do
form. Alm disso, utilizamos check() novamente para verificar a
nossa resposta. Nesse caso, a resposta dever conter erros, pois a
informao fornecida possui problemas.
Na ltima ao do nosso fluxo, estamos fazendo mais um POST.

Dessa vez, iremos fornecer informaes vlidas para completar o
nosso form. A resposta do servidor dever ser ento positiva.
Ok, agora temos o nosso fluxo definido: acessamos a nossa

homepage, tentamos inserir um modelo de computador utilizando
dados invlidos e, por fim, utilizamos dados vlidos para cadastrar
um novo modelo de computador. Mas, o que queremos testar
exatamente aqui? Isso o que ns precisamos dizer ao Gatling
atravs de setUp(). Em nosso setUp() estamos dizendo ao Gatling:
Ei, por favor simule o meu cenrio para 3 usurios. Basicamente,
significa que os nossos usurios vo comear a interagir com a
nossa aplicao ao mesmo tempo.
O Gatling pode ser utilizado tambm para explorar e entender

melhor respostas HTTP. Voc pode utilizar Gatling Assertions
para verificar se as suas solicitaes (requests) retornaram um
cdigo 200 ou qualquer resultado esperado, como um valor
JSON especfico, por exemplo. Gatling permite usar expresses
regulares, CSS Selectors, XPath e JSONPath para analisar a sua
resposta, extrair a informao que te interessa e at utiliza-la em
seus prximos passos!
Para que voc no fique com aquela curiosidade sobre como a
pgina de relatrios do Gatling, aqui vai um exemplo (claro que
existem muitos outros modos de visualizao):
Vale a pena mencionar que o Chrome Dev Tools pode ajudar na

hora de identificar requisies HTTP, mensagens ou seja o que for
que voc deseja simular. A guia Network extremamente til nesse
caso. Eu tambm recomendo que voc utilize a ferramenta cURL
como ferramenta de apoio. Ela pode ajudar a simular facilmente
seus pedidos antes de mape-los para dentro de seus cenrios de
teste no Gatling.
Dica extra: No Chrome Dev Tools, na guia de Network, voc pode

clicar com o boto direito sobre a solicitao/request do seu
interesse e selecionar a opo Copy as cURL ;)
Gatling tambm fornece uma interface grfica que permite que

voc grave seus cenrios. Entretanto, o uso dessa interface no
algo necessrio devido simplicidade da DSL.
Ento, agora hora de botar a mo na massa e comear a tratar
os seus testes de performance como cdigo de produo!
ALTERNATIVAS AO
TESTFLIGHT PARA
ANDROID
Rafael Garcia
Como voc deve ter ouvido falar, o Testflight est dando fim ao
seu suporte para Android em 21 de maro de 2014, mas no se
preocupe, pois mostraremos algumas alternativas ao Testflight
para que voc possa escolher a ferramenta mais adequada s suas
necessidades.
Permisso individual para testadores.

Permisso via lista de distribuio.
Custo.
Primeiramente, definiremos alguns critrios para analisar:
Com os critrios estabelecidos, vamos primeiro olhar o Testflight

para ter um ponto de partida e ento olharemos outras 5
ferramentas:
Implantao contnua.
Possui verso mobile para instalar verses.
HockeyApp
Appaloosa
TestFairy
Play Store
Apphance
Verso mobile:
Testflight (https://testflightapp.com/)
Implantao contnua: Upload de novas verses via API e plugin

para Jenkins.
Permisso individual para testadores: Selecione os usurios para

os quais quer dar permisso e voil.
Permisso via lista de distribuio: Crie a lista selecionando os

usurios. Digite o nome da lista no parmetro distribution_list da
API.
Verso mobile:
Custo: Free
HockeyApp (http://hockeyapp.net/)
a verso hospedada do projeto open source HockeyKit. Um pouco
confuso de entender o fluxo de uso no comeo, mas tem um bom
custo-benefcio no quesito funcionalidades.
Permisso individual para testadores: No possui.

Permisso via lista de distribuio: Crie tags e selecione os
usurios. Digite o nome da tag no parmetro tags da API.
Implantao contnua: Upload de novas verses via API e plugin

para Jenkins.
Custo: Primeiro ms free e o plano o Bsico. Confira os planos

aqui.
Appaloosa (http://www.appaloosa-store.com/)
Permisso via lista de distribuio: Crie grupos, ligue os usurios

ao grupo e informe na app quais grupos tem permisso.
A usabilidade no to legal, porm bem simples de comear a

usar.
Custo: Free, com limite de 1 app e 10 usurios. Confira os planos

aqui.
Implantao contnua: Plugin para o Jenkins
Verso mobile:
TestFairy (http://testfairy.com/)
Boa interface, simples de usar, vrios relatrios, d suporte s apps
com SDK do Testflight. Peca por no ter uma verso mobile, mas,
segundo o suporte do site, esto trabalhando nisso e pretendem
lanar uma app nativa em pouco tempo, ento fique de olho.
Implantao contnua: Upload de novas verses via API, alm de

plugin para Gradle.
Custo: Free.
Verso mobile: Ainda no possui.
Permisso individual para testadores: Selecione os usurios que
quer convidar para testar sua app
Play Store (http://developer.android.com/)

O Google oferece o Developer Console para fazer Beta testing.
Um tanto burocrtico, preciso informar vrias configuraes da
app antes de comear a usar de fato o servio, alm disso no
gostei de precisa criar grupos de testadores fora da interface do
Developer Console.
Permisso via lista de distribuio

Crie grupos para os usurios e informe o nome do grupo no
parmetro TESTER_GROUPS no script de deploy. Ser enviado um
email para os usurios do grupo com o link para download do apk.
Implantao contnua: No possui.
Implantao contnua: Possuem, ferramenta de automao de

builds para projetos mobile.

Verso mobile: No possui.
Permisso via lista de distribuio: Crie um grupo no Google
groups ou uma nova comunidade no Google+.
Custo: cobrada uma taxa de registro. Veja como criar seu Google
Play Developer Console.
Apphance (http://www.utest.com/apphance)
Permisso individual para testadores: Selecione os usurios que

recebero link de download da app via email.
Permisso via lista de distribuio: No possui.

Custo: Free com limite de 1 app e 50 dispositivos. Para saber
valores preciso contact-los.
O mais simples de todos em funcionalidades e bem fcil de usar.
Aqui est uma tabela comparativa dos servios:
ENTRE EM CONTATO
thoughtworks.com
BELO HORIZONTE | PORTO ALEGRE | RECIFE | SO PAULO

Praticas e Tendencias em Testes Thoughtworks PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Praticas e Tendencias em Testes Thoughtworks PDF

Загружено:

Авторское право:

Доступные форматы

PRTICAS E

Mas o nosso mundo mudou, e rpido! Est tudo nas nuvens. Os

A metfora era falha! A separao entre departamentos tambm.

E isto que meus prezados colegas compartilham neste e-Book,

A frase estava errada. No que o cdigo de teste testa o

Consultor principal da Thoughtworks e cofundador da AgileBrazil.

Voc sabe o que te faz querer ir para o trabalho, mesmo quando

pessoas, suas interaes com os membros da equipe e a forma

PRTICAS E TENDNCIAS EM TESTES | 6

Princpio # 0 | Tenha a mente aberta

Princpio # 1 | Pense no futuro

meses?. Esse teste est testando um nvel apropriado? Deveria

Princpio # 3 | Pense com sabedoria

Princpio # 4 | Mantenha a calma

Aprenda a escrever testes. Aprenda a entend-los tambm.

Princpio # 2 | Pense grande

Princpio # 5 | Seja gentil

Projete seus testes pensando em mais do que os critrios de

Trate o seu cdigo de automao de teste com todo o respeito dado

Ao projetar um teste, entenda as aes dos usurios do sistema e

No existe essa histria de cdigo de teste e cdigo de

PRTICAS E TENDNCIAS EM TESTES | 7

Esses so meus princpios para poder contribuir consistentemente

*No pude encontrar palavra melhor do que essa para o termo

PRTICAS E TENDNCIAS EM TESTES | 8

Testadores geis so muitas vezes conhecidos como analistas de

esteja totalmente fora de moda. A diferena entre um QA e um

PRTICAS E TENDNCIAS EM TESTES | 9

Vamos mergulhar mais a fundo nessas dimenses e entender

Esses QAs geralmente leem livros como:

Os QAs nessa dimenso so realmente dirigidos a negcio. Eles

Bridging the Communication Gap: Specification by Example and Agile

Extrair testes de aceitao do cliente uma das especialidades

Eles trabalham em par com os desenvolvedores para alinhar o

The Cucumber Book: Behaviour Driven-Development for Testers and

Eu me identifico com essa dimenso porque os QAs aqui so

PRTICAS E TENDNCIAS EM TESTES | 10

Para testes de performance, eles trabalham com o cliente

The Art of Application Performance Testing: Help For Programmers and

Esses QAs tambm so envolvidos em segurana. Eles entendem

Como DevOps est relacionado a testes? Existem vrias coisas

Eles introduzem a prtica de Entrega Contnua e ajudam o time

QAs nesta dimenso geralmente leem livros como:

Test Driven Development: By Example

PRTICAS E TENDNCIAS EM TESTES | 11

Esse QA geralmente l livros como:

Alm de compartilharem a responsabilidade dos testes com o

As melhores referncias em portugus so:

O que comum para todos os QAs?

PRTICAS E TENDNCIAS EM TESTES | 12

Inmeros podem ser os deslizes cometidos ao descrever uma

defeitos precocemente. Uma delas nos tem dado um retorno bem

PRTICAS E TENDNCIAS EM TESTES | 13

o tamanho da estria est adequado. Esse feedback pode ser

traz tona os conceitos e objetivos sem deixar passar detalhes

Checklist para o Kick-off

Envolvidos: Analista de Negcios, Analista de Teste,

O kick-off, que na traduo literal seria ponta-p inicial, trata-se

A anlise da estria est completa?

PRTICAS E TENDNCIAS EM TESTES | 14

se eles fizerem sentido, provavelmente a anlise da estria no foi

Checklist para o Desk-Check