Crow test é uma fase de teste (ou modalidade) onde você abre sua aplicação para que o “mundo inteiro” possa testar e cada bug que acharem, você paga um determinado valor.

Para uma explicação melhor e mais detalhada –> http://pt.wikipedia.org/wiki/Crowdsourcing

Por que subindo um nível?

Acredito que quase nenhum de vocês que está lendo este post agora conhece o jogo chamada “Diablo”. Este jogo será lançado dia 15 de março e a um tempinho vem rolando o chamado “Beta Testing” onde eles chamam algumas pessoas que são fãs da marca “Diablo” e que estão afim de doar seu tempo para testar a jogabilidade e dar palpites para a produtora.

Isso acontece com todos aplicativos de mercado. Podemos citar o sistema operacional Windows como uma aplicação que sempre tem “beta” e “alpha” test antes dos Release candidate e do lançamento definitivo.

Acontece que a blizzard me surpreendeu hoje.
Hoje ela está abrindo o beta teste para TODOS que queiram experimentar seu jogo antes do lançamento, porém ai está a grande jogada.
Diablo 3 é um jogo que requer conexão com a internet pois ele faz comunicação com servidores da blizzard para vc poder jogar, ou seja,  os servidores tem que aguentar muitos.. mas MUITOS jogadores simultaneamente.

Qual o grande risco da aplicação? DISPONIBILIDADE.
Todos sabemos que quando grande risco da sua aplicação é uptime e a disponibilidade, é essencial que testes de desempenho e stress sejam realizados.
Como fazer isso de uma forma simples e “barata”? Liberando a aplicação beta para todos testarem, “sem saber” que estão testando.

Porque eles não sabem que estão “testando”? Para o jogadores é so uma desculpa para ver o jogo antes, comentar, apontar “bugs” mas a real intensão  da Blizzard é verificar como os servidores do diablo3 e a aplicação em si aguentam tanto tráfego.

Isso pode ser um tiro no pé.

Quando eu falei que é uma forma “barata” de testar estava me referindo a sua mão de obra, servidores e tempo necessario para poder simular milhoes de jogadores ao mesmo tempo.
Só como eu disse antes, para o jogador ele está apenas testando o conteudo o jogo em si.. e não a conexão com o servidores e isso pode ser algo frustrante.

Se eu como jogador, testo o jogo na fase beta, o jogo funciona mas a conexão cai a todo segundo, posso pensar que quando lançar o jogo final a conexão será a mesma e a experiência pode ser comprometida.(É so ver os comentarios dos jogadores neste link aqui Beta Aberto de Diablo III no Fim de Semana )

No fim das contas eu admiro a Blizzard por fazer esse tipo de teste. Não sei se ela fez isso também para world of warcraft mas é isso que é dar um levelup no crowdsourcing teste.

Parece que a blizzard vai dar disponibilizar  alguns updates (quanto ao estagio dos testes de stress).
Assim que tiver mais dados sobre esse case eu vou atualizando.

Update1 – Primeira parte do Stress Test completo.

Parece que diminuiram drasticamente o numero de jogares permitidos no beta e farão algumas atualizações nos servidores e no cliente no que se diz respeito ao trafego de informação (client -server)

Isso já mostra que é melhor ter uns 300 jogadores decepcionados do que ter 1 milhão pedindo dinheiro de volta na data do lançamento

Update 2 – Its Over 300.000!

Segundo pessoal no twitter responsavel pelo jogo @JoshKo,  o pico de jogadores simultaneos do beta foi de 300 mil pessoas… no total eles não tem um numero definido.

Imagina agora quando o jogo for lançado. Pelo menos o teste valeu a pena e dia 15 os jogadores não terão surpresas

http://www.kotaku.com.br/com-quantas-pessoas-se-derruba-o-servidor-de-diablo-iii/

“@Blatantmistakes I think we peaked at around 300k concurrent. Total users? I don’t know… a lot.”

não entendeu? participa do #dfteste que você vai entender

2 – Automação de teste é mais programação do que teste.

3 – Defina seu escopo antes de começar a automatizar.

4 – Sempre pense na manutenção ao escrever seu código! Use OO / Page Objects.

5 – Não é uma boa idéia automatizar todos os casos de teste! Priorize.

6 – Utilize uma linguagem que você tenha familiaridade. Caso esteja começando, utilize uma linguaguem que você terá bastante suporte a curto prazo (fóruns, colegas de trabalho, equipe de desenvolvimento).

7 – Não reivente a roda! Utilize frameworks de teste unitário para ajudar na execução.

8 – Nunca use hardcode! Utilize massa de dados para teste OU arquivos de configuração.

9 – Melhor do que sair comentando todo o codigo é fazer uma logica que seja compreensivel ( nomes de classes e metodos).

10 – Devolva para comunidade o que você “tirou dela”. Compartilhe experiencias e soluções que você encontrou na sua jornada.

Também chegou a hora de mudar o nome do blog. Hoje não faço posts somente sobre automação com selenium e nome não estava refletindo.

Com os anos de casa vem a experiência e essa deve ser a nova cara do blog.

Mesmo com as dificuldades, mesmo com  os problemas , continue trabalhando.. continue testando

Antes de tudo gostaria de dizer que não sou xiita.. Acredito que purismo “non ecziste” no dia-a-dia de quem trabalha com teste ou desenvolvimento de software, mas acredito que é possivel melhorar o processos e deixar para trás métricas e processos que só fazem as empresas perder tempo e dinheiro.

Ser ágil não quer dizer ser relaxado.

Eu vou pular a parte de explicar como funciona as metodologias ageis e deixar que especialistas sobre assunto expliquem melhor (links nas referências). O que eu quero fazer aqui é discutir como utilizar a “filosofia” e as rotinas ágeis no dia a dia de uma fábrica de teste, que por definição, tem o processo engessado pelo seu modelo de negócio.

Vamos analisar primeiro como funciona uma Fábrica de teste:

1 – A Fábrica recebe uma requisição de teste para um projeto X;
2 – O cliente entrega os requisitos e escopo do projeto;
3 – A Fábrica separa a equipe para testar o projeto entre 1 gerente de projeto / 1 líder de teste / 1 líder de execução/  analistas / testers;
4 – Os analistas fazem os casos de teste baseados 100% na documentação entregue pelo cliente;
5 – O cliente recebe , analisa e aprova os casos de teste;
6 – Os analistas saem de cena e vão para outro projeto enquanto os testers irão executar os casos de teste;
7 – Líder de teste separa os casos de teste para cada tester e acompanha de perto se os Testers estão realizando sua produtividade diária (X casos de teste por Dia);
8 – Ciclo de execução termina, report de erros são enviados;
9 – Cliente entrega pacote com correção e o ciclo recomeça até chegar na data de entrega final;

Eu não acho que esse processo é ruim.. o problema começa quando o prazo aperta um pouquinho e o caos impera. Nessa bagança acontece de tudo e o que mais  acontece é testers ser rebaixados a um nível sub-humano, pior que telemarketing vendendo cartão de credito tentando realizar a cota do dia com o fantasma de demissão assombrando.

Sendo assim, vou tentar fazer um apanhado geral, mostrando alguns problemas do processo tradicional de fábrica e como ele poderia ser melhorado usando alguns princípios da metodologia ágil.

1 – Requisitos.

É dificil encontrar projetos com documentação atualizada.  Já fiz um post falando que não é dificil ver equipes de desenvolvimento escrevendo código ao mesmo tempo que analistas de requisitos escrevem especificações OU um  gerente de projeto mudando o escopo do projeto sem alterar os requisitos no meio do desenvolvimento.

Como melhorar isso?  O líder de teste ou gerente de projeto faz o mapeamento das histórias (requisitos transformados em histórioas – backlog) e os analistas de teste conversam com os desenvolvedores e clientes para saber  sobre o escopo do teste e como testar.

A filosofia ágil incentiva a comunição verbal.

2 – Casos de Testes.

É o tipico “finge que escreve que eu finjo que leio“.  Não é só a fábrica escrevendo os casos de teste e o cliente aprovando sem ler. É analista dando ctrlc + ctrlv em requisito ou caso de uso e  testador não dando a minima para o caso de teste e executando “de cabeça”.

Aqui tempos 2 “problemas”: O modelo de negócio e o insumo dos casos de teste (requisitos / casos de uso)

Para o insumo dos casos de teste, você pode trabalhar com as historias e tarefas que os analistas mapearam com a conversa com os desenvolvedores e pode até usar requistos como artefato adicional para os casos de teste.

Já sobre o modelo de negócio é complicado. Vamos começar olhando para o mercado:
Muitos clientes entendem que quantidade é qualidade e a Fabrica que infla a quantidade de casos de teste pelo mesmo preço de outras fabricas com menos casos de teste é que vai ganhar o projeto OU o cliente tem um projeto pré aprovado com uma fabrica x… ela vende cada caso de teste por 10 reais… ela vai vender 30 ou 200?  200 é claro…  Você acha que 30 casos de teste a 10 reais vai pagar um projeto? Não!

Infelizmente as metodologias ágeis nao podem responder essa pergunta.. isso é algo para outro post.. outra discussão.

3 – Execução.

“Uma corrente não é mais forte que seu elo mais fraco”

A fase de execução é a fase mais crítica e é onde os projetos geralmente falham. Nessa hora que você vai precisar que os testadores trabalhem a todo vapor, executando 20,30,40 casos de teste por dia fazendo 2~4 horas extras para poder realizar o prazo apertado definido pelo cliente / gerente de teste.

Uma coisa é você ter uma estimativa de casos de teste que podem ser executados para poder dizer o seu prazo, outra coisa é você impor metas diarias que só seriam realizadas em dias perfeitos, com tudo funcionando.

Eu sou contra a metas de execução. Testadores não deveriam ser tratados como macacos robos.
Testadores deveriam ser tratados como parte da equipe e que o sucesso de toda equipe só seria alcançado caso os testadores fizessem seu papel.

Motivação vai de contra-mão a metas de execução.

E como motivar seus testadores? Incluindo eles na rotina da equipe.
Criação de caso de teste pareado é um incentivo para os testadores ficarem integrados com o projeto e com a equipe.
Se o projeto é uma manutenção e se os testadores já realizaram testes do sistema, eles conhecem mais do dia-a-dia da aplicação do que os próprios analistas de teste.

Na fase de execução é possivel utilizar reunião de sprint,  mostrando as tarefas (testes que precisam ser executados) e incentivar a equipe pegar as tarefas. Caso isso não ocorra, o scrum master ou gestor deve conversar com a equipe sobre o trabalho em equipe e não chegar junto com a classica impossição “faz e cala boca”.

- Ciclos de Teste.

Ciclos enormes de teste não funcionam. Primeiro por que os desenvolvedores não vão ficar setandos esperando e segundo que os prazos são curtos, mas é preciso ter ciclos.
Quando um projeto de teste tradicional pega fogo, é correria.. o ciclo morre, defeitos sao corrigidos ao mesmo tempo que outros testes são executados.. e seus testes acabam virando lixo.

Ao utilizar os ciclos no formato de sprints,  você diminui o período dos ciclos de teste e foca a equipe em um aspecto do teste a ser executado. (“ex: vamos testar a funcionalidade x, y e z.. o resto veremos nos proximos sprints”)

—

Minha visão de Fábrica Ágil.

Percebam que o que falei não é utopia e é plenamente passivel de sucesso.
Tendo em vista como funciona uma fábrica de teste,  esta é minha visão de como ela , a fábrica, poderia funcionar usando algumas filosofias e rotinas ágeis:

1 – A fábrica recebe uma requisição de teste para um projeto X;
2 – A fábrica recebe requisitos / casos de uso do cliente, entende a aplicação e marca conversa com o cliente e desenvolvedores;

Veja que eu não disse reunião e sim conversa. São duas coisas diferentes.
Reunião é formal, envolve ata de reunião, confirmações por email do que foi dito.  Em uma conversa informal você incentiva ao cliente se sentir mais a vontade e o desenvolvedor a “baixar” a guarda e consegue informações que irão fazer  o teste ser mais funcional e pratico.

3 – A fábrica separa a equipe para testar o projeto entre gerente de projeto /  analistas / testers;

Se você tem uma equipe auto gerenciavel, você pode ter niveis de senioridade dentro da equipe mas não precisa de alguem batendo o tambor, concorda?

4 – Os analistas fazem os casos de teste baseados nas conversas com cliente, desenvolvedores e requisitos , pareados com testadores para disseminar conhecimento do negócio;
5 – O cliente recebe, analisa e aprova os casos de teste;
6 – Os analistas não saem totalmente de cena e guiam os testadores na elaboração dos sprints de execução;
7 – A propria equipe de teste separa os casos necessários para execução e quebra em sprints (ciclos) melhorando o escopo de teste a cada sprint;

O scrum master  (um analista sênior ou gerente de projeto) informa a equipe o status do projeto,  guia a equipe mostrando quais os cenários mais criticos para serem feitos primeiro e os testers pegam as tarefas (blocos de casos de teste a serem executados) por iniciativa própria.

8 – O sprint termina, report de erros são enviados e uma reunião de final de sprint é realizada, com lições aprendidas;
9 – Cliente entrega pacote com correção e um novo sprint começa, fazendo este ciclo até terminar o projeto;

Tudo isso é baseado em confiança nas pessoas.
Você precisa confirmar na sua equipe para ela andar sozinha.. e confiança se conquista.
Se sua equipe tem pro atividade, por que não começar deixar ela andar com as proprias pernas?
E é logico que  é necessario contratar pessoas que tenham esse perfil pró ativo. Não adianta nada contratar um cara que não faz nada se o “patrão” não pedir.

Obrigado pela leitura e postem suas opiniões

Must Read!

http://www.bugbang.com.br/?p=2496

Xpath deve ser sua última opção na hora de automatizar um teste web com selenium porém ela não te deixará na mão se você souber como usar.

Quando digo para utilizar ela como último recurso é devido a sua velocidade de execução.
Localização de objetos via xpath demora… é 1~20 segundos mais devagar do que se você usa-se outro método de localização. Agora multiplique isso pela quantidade de interações que você tem que para testar um determinado fluxo. Estamos falando de um delay de 1-n minutos na sua execução. (time is money!)

(eu perdi o link com o comparativo de localização de um elemento com id e via xpath.. mas acredite.. em alguns casos a diferença é gritante)

Para você que esta se perguntando… “que raios é esse tal de xpath.. eu uso o que o selenium mostra mas nunca entendi como funciona”, eu vou explicar:

Xpath, também conhecido como “XML Path Language” é o padrão utilizado para definir caminhos para se pegar determinada string dentro de um XML (resumo grosseiro mas deu para entender né).

Exemplo:

<?xml version="1.0"?>
<catalog>
 <book id="bk101">
  <author>Gambardella, Matthew</author>
  <title>XML Developer's Guide</title>
  <genre>Computer</genre>
  <price>44.95</price>
  <publish_date>2000-10-01</publish_date>
  <description>An in-depth look at creating applications with XML.</description>
 </book>
 <book id="bk102">
  <author>Ralls, Kim</author>
  <title>Midnight Rain</title>
  <genre>Fantasy</genre>
  <price>5.95</price>
  <publish_date>2000-12-16</publish_date>
  <description>A former architect battles corporate zombi an evil sorceress, and her own childhood to become queen of the world.</description>
 </book>
 <book id="bk103">
  <author>Corets, Eva</author>
  <title>Maeve Ascendant</title>
  <genre>Fantasy</genre>
  <price>5.95</price>
  <publish_date>2000-11-17</publish_date>
  <description>After the collapse of a nanotechnology society in England, the young survivors lay the
foundation for a new society.</description>
 </book>
</catalog>

Para buscar um determinado livro neste xml sem eu saber o Book ID (atributo).. você poderia usar xpath e procurar direto pelo nome do autor ou nome do livro (elemento)

Usar Xpath para procurar objetos na pagina não foge muito dessa idéia.

Xpath Web

Vamos imaginar o seguinte codigo fonte web:

<html>
<header>
<some header info>
</header>
<body>
<div>
	<div id="menu">
		<span> Menus </span>
		<span> <a hreaf="xxxx"> menu1 </a> </span>
		<span> <a hreaf="xxxx"> menu2 </a> </span>
		<span> <a hreaf="xxxx"> menu3 </a> </span>
		<img src="xxxx" alt="unica imagem da pagina">
	</div>
</div>
</body>
</html>

Lembram que eu fiz um tutorial explicando que você tem que conhecer pelo menos a estrutura HTML de uma pagina para poder se localizar e saber como melhorar seu script?
Bom você vai usar seu conhecimento HTML aqui

Quando for gravar um teste, repare nos steps que o selenium cria assim que você realizar uma ação e veja o “alvo” que ele deixa disponível para você. Dependendo da página, ele dá diversas opções de como encontrar o objeto (xpath:link, xpath:idRelative, xpath:position, xpath:etc..)
Para tentar explicar de uma forma mais lúdica, vou separar em 2 tipos de xpaths: posicional e relativo por atributos. (lembrando que o nem selenium nem a documentação w3c separada desta forma – é uma separação para explicar melhor as formas de escrever o xpath).
No posicional você faz o caminho completo até o elemento (não é uma boa pratica!) e o relativo por atributo quando você usa um atributo do objeto html para localização (boa pratica!)

Exemplo1: Preciso clicar na imagem no final do menu.

Caminho Posicional: “//div/div/img” ou “//img”
Você pode utilizar o caminho completo até chegar ao elemento ou, caso so exista um elemento do tipo procurado, você pode acessar ele diretamente.

Caminho Relativo por atributo: “//div[id='menu']/img” ou “//img[@alt='unica imagem da pagina']”
No exemplo acima só existe uma imagem, logo desta forma eu oriento ao selenium buscar diretamente de acordo com seu atributo ‘alt‘, ou busco por um elemento anterior (div) com um atributo (id) e a partir dai eu defino o caminho até chegar a imagem.

Exemplo2: Preciso clicar no menu2

Caminho Posicional: “//div/div/span[3]/a” ou “//span[3]/a”
Quando tempos mais de um elemento dentro do mesmo espaço, você acessa o elemento pela a posição dele… se ele é o terceiro “ que aparece, você utiliza a posição dentro entre Colchetes “[x]“.

Caminho Relativo: “//a[contains(text(),'menu3')]”
Da mesma forma que você consegue localizar objetos pelo atributo ID, você também pode localizar objetos pelo texto contido dentro dele e qualquer outro parâmetro que você queira utilizar.

Lembrando que as “aspas dlupas” do xpath não compoem a sintaxe! não utilize aspas duplas no xpath!

ps: As vezes o selenium ‘come bola’ e te da um xpath tipo esse: //div[@id='center']/div[4]/div/div[2]/div/div/div[5]/a/div[2]/p[2] mas se você usar um firebug da vida (HTML!!!) você pode analisar o codigo e chegar em um cara assim –> //div[@class='box_widget' and contains(.,'Atendimento')]/a/div[2]/p[@class='adicionar'] que fica MUITO mais facil de ler e entender

Bom, agora que você conhece +- como funciona o xpath, você pode bricar um pouco ele e fazer umas mini bruxarias, tipo:

//img[@alt='unica imagem da pagina']/../span[2]

Com esse xpath você consegue pegar o menu1 da pagina..
(pra quem ja trabalhou com prompt de comando.. sistema de diretórios e afins, vai ser moleza!)

Lembrando que existe diferença no nome dos atributos que você utiliza. Alguns Browsers jogam tudo para lowercase, outros browsers são caseSenSiTiVe, sendo assim, sempre utilize case Sensitive para evitar problemas!

ps: Quando for referênciar um atributo dentro de um objeto HTML, utilize sempre o ‘@’ antes do nome do atributo (@class, @id, @sytle@, @name, etc..) porém quando você for procurar pelo texto dentro de um objeto, utilize text() e não @text.

Usando “contains” e “starts-with”

Acredito que são as funções do xpath mais utilizadas atualmente (ou suportadas pelo selenium, eu ainda não utilizei as outras, quando o fizer, atualizarei o post)

“Contains”

Como visto no caminho relativo do exemplo dois, eu utilizei o atributo “contains” do xpath para poder achar um texto.
Eu poderia ter usado ” text()= ” também para pesquisar, mas em minhas últimas experiências eu não fui muito feliz.

O contains, é isso que você esta pensando mesmo. Você procura um elemento que contenha o que você colocar de parametro, ou seja, se a string 1 contem o que tem na string 2

Você pode usar a string um como text() para procurar um texto especifico ou . (isso mesmo, um ponto) que funciona como um * ..rs (tome cuidado, pode achar um objeto diferente do esperado)
ex: //div[@class='box_widget' and contains(.,'Atendimento')]/a/

“starts-with”

É uma função que uso bem pouco atualmente mas vale a pena comentar pois é funcional quando você está trabalhando com aplicações que utilizem “id” dinamicos, geralmente o começo da identificação é o mesmo “id=button-xx723y61731″ você pode fazer algo como //input[starts-with(@id, 'button-')] (exemplo retirado do site do seleniumhq)

Espero que este post tenha sido produtivo!
Continuarei adicionando conteúdo a medida do possivel.
Dúvidas ou críticas (caso tenha alguma coisa errada aqui e eu comi bola) .. comentem!

Referências:
http://www.w3.org/TR/xpath/
Selenium JavaDocs
funções xpath

Se você é um preguiçoso de plantão, essa é uma excelente oportunidade para começar a apreender pouco de lógica de programação e melhorar seus scripts de selenium

http://www.codecademy.com/

dica do @camiloribeiro

O pessoal que manja de selenium até pode dizer que não tem nada a ver, mas recentemente em um projeto ( e de um pessoal no grupo de discussão do webdriver)  o webdriver não clicava nunca em um determinado xpath…dai começei a rodar os testes com o internet explorer maximizado e não tive mais problemas, sendo assim ai vai

Enquanto uma resposta na comunidade não sai, segue abaixo a solução paleativa que estou usando:

((JavascriptExecutor)  driver).executeScript("if (window.screen) {window.moveTo(0, 0);window.resizeTo(window.screen.availWidth,window.screen.availHeight);};");

créditos para comunidade webdriver no google groups.

UPDATE:  tem uma issue aberta para isso… talvez na versão 2.18 será corrigido.
se você está tendo muitos problemas em relação a isso, mantenha a versão 2.14 e espere a versão 2.18

Para você não se perder (e melhorar a leitura do seu script), use o evento findelement click BY XPATH (no selenium IDE use o alvo “xpath:attributes” ) mapeando o ID e o VALUE  do input… como no exemplo abaixo:

 //input[@name='gender' and @value='M']