Conhecendo o Hodman

Obrigada Galani por me empurrar o Desafio Agile Testers :) Eu tava mesmo enrolando para dar uma olhada no Hodman e assim eu arranjei uma desculpa para não procrastinar muito.

Recentemente o Felipe Knorr compartilhou um artigo falando sobre um framework de testes usando Selenium e Javascript. O framework é composto pelo Hodman, uma biblioteca de selenium que inclui page objects, o Kobold, uma ferramenta para comparar screenshots entre uma versão e outra do software, especialmente útil para testes de regressão, e o Preceptor, com o intuito de orquestrar a execução dos testes em paralelo, sequencialmente ou uma mistura dos dois, gerando um único report dos resultados e cobertura.

Esse artigo tem como foco o Hodman apenas.

Pré requisito:

. Node instalado

. Um servidor Selenium rodando (no meu caso, usando a porta 4444)

Crie uma pasta para esse exemplo, e no terminal, digite:

npm init

Vão surgir algumas perguntas. O que você não souber responder ainda, pode simplesmente pressionar enter até o fim. Após esse procedimento, terá um arquivo chamado package.json na sua pasta.

Abra o arquivo e adicione no fim duas dependências: o cabbie e o hodman. Se você foi preguiçosa como eu e simplesmente saiu apertando enter pra quase tudo, o seu arquivo deve estar mais ou menos assim:

https://gist.github.com/sarahpimentel/904d012e670508cc3f93

É muito importante colocar essas dependências nesse arquivo. Nas minhas primeiras tentativas, eu simplesmente instalei a versão disponível no npm do Hodman e o Cabbie com e muita coisa deu errado. A versão do Cabbie no npm atualmente é a 0.0.9, cuja última atualização foi em Abril/2014. O último commit no projeto é de Outubro/2014. A última versão do Hodman é a 0.9.5. Essas linhas garantem que você vai estar usando o código do HEAD de ambos os projetos.

E o que é esse Cabbie? É um webdriver, também escrito em Javascript. No momento, o Hodman utiliza somente essa opção. Caso você se interesse em desenvolver um adaptador para outro webdriver, basta acessar o projeto, abrir um issue e submeter o código.

O arquivo de exemplo é bem simples:

https://gist.github.com/sarahpimentel/82ea0d486f95ddd50764

Configurações e inicialização

As primeiras instruções são configurações do driver. E depois temos a página do Google que é uma extensão da classe PageObject. Os seletores da página são definidos na inicialização da página e caso os seletores mudem, esse é o único local em que será necessário efetuar mudanças. Também é importante salientar também que o único seletor usado no momento é o css. No código, esses seletores são as classes dos objetos que eu pretendo avaliar. No fim, o comando addLoadSelectors. Nele, eu indico um seletor para ser usado para verificar se a página já foi carregada corretamente.

Métodos

Adicione então todos os métodos necessários para o seu teste nessa página. Vamos executar uma pesquisa no Google, então os métodos são:

performSearch, que recebe o termo a ser pesquisado, preenche o campo da pesquisa (setSearchTerm) após certificar-se de que não há nenhum outro valor no campo (clearSearchInput), submete a pesquisa e espera pela página de resultados.

URL

BASE é a URL principal da página. Por exemplo, http://www.amazon.com. O resto da URL é formado com o atributo abaixo.

URL é o complemento da URL BASE citada acima. Nesse caso, não precisei complementar a URL, então usei apenas ‘/’. Se no exemplo da amazon, dado acima, eu quisesse acessar uma página específica, por exemplo, a seção de brinquedos da amazon, o valor desse campo seria ‘/toys’.

Apesar de parecer opcional, se esse parâmetro não for informado, você receberá um erro como esse:

<caminho do projeto>/node_modules/hodman/node_modules/preceptor-core/lib/utils.js:133

       } else if ((result.substr(-1) === glue) || (arg.substr(0, 1) === glue)

                                                       ^

TypeError: Cannot call method 'substr' of undefined

EXPECTED_URL é uma expressão que será avaliada para determinar se o script chegou à página certa. Nesse caso, eu optei por colocar apenas o pedaço principal da URL, já que ao acessar o Google, a URL pode mudar um pouco. Sem esse parâmetro é provável que você encontre o erro:

Error: Waited for an event, but timed-out. Message:Waited for url that matches 'https://www.google.de/'.

Assert

O Hodman não tem métodos que permitam fazer assert, portanto é necessário importar algum módulo que tenha essa capacidade. Para simplificar, importei o assert. Pelo que vi em uma apresentação sobre esse framework, o Yahoo está usando Mocha para os testes e Chai para realizar os asserts.

Opinião

Mastigadinho assim, o framework parece bem simples. Eu acabei por demorar bem mais do que eu esperava para chegar nesse exemplo. Acho que ainda falta desenvolver melhor a documentação e alguns tratamentos de erros. Tem muito potencial, mas ainda é pouco maduro. O projeto é aberto, portanto quem se interessar, é só baixar e melhora-lo. Se ficou curioso, dá uma olhada na captura de imagem e quem sabe, já segue dando uma olhada no Kobold, faz uma análise e publica um post. :)

Testing War Room - Google Docs

Esta semana experimentei usar o Google Docs como War Room para testes e foi super produtivo. Além disso, foi um bom insight para tirar o pó aqui do blog que já não via um post há bué da tempo. Bué da tempo ? Ok, expressão portuguesa. Tradução: há muito tempo. Nesse tempo que o blog ficou às traças muita coisa aconteceu, inclusive minha mudança para Lisboa! :) Mas bem, vamos voltar ao assunto central.

Primeiro, que idéia é essa de Testing War Room?

War room
Acredito que por volta do ano 2000 algumas empresas de TI começaram a experimentar colocar o time de desenvolvimento em ambientes como salas de reuniões onde a comunicação fosse aumentada e as ações fossem tomadas mais rápida e acertivamente.

Ainda era muito comum os desenvolvedores ficarem um tanto isolados uns dos outros (que dirá da equipe de testes), com divisórias na mesa e pouca comunicação, o que fez dessa prática algo inovador na época. Um bom exemplo da aplicação dessas war room eram as ‘crises’, problemas críticos em produção que precisavam de atenção imediata e esforço conjunto coordenado.

Com o tempo, o conceito de war room começou a ficar um pouco descabido já que empresas/pessoas que praticam agilidade já promovem naturalmente um ambiente com menos obstáculos para comunicação.

A motivação
Não foi uma crise, mas a necessidade de focar os testes em uma funcionalidade que precisava ser entregue rapidamente que motivou a recuperação desse conceito, ainda que de uma forma adaptada a nossa realidade.

Bem, na minha empresa as mesas não tem divisórias e o time encontra-se todo na mesma sala. Além disso, anteriormente já tive a experiência de sentar com meu notebook ao lado do desenvolvedor e ir testando, reportando, ele corrigindo, eu re-testando e testando outras coisas na sequência. Mas o trabalho ficava muito ping pong e precisávamos de mais agilidade.

A ferramenta e o processo
Resolvemos experimentar o google docs como virtualização desse conceito de war room. Funcionou assim: Eu ia testando, escrevendo no google docs os problemas encontrados, incluindo prints quando necessário. Ao lado de cada problema, eu colocava um comentário. Os comentários tem opção de Reply e de Resolve. E ainda há a opção do chat para comunicação.

Quando o desenvolvedor interagia com o meu comentário, eu recebia e-mail comunicando da alteração e o ponto que foi corrigido. Isso claro, fora o aviso verbal. Além disso, por concentrarmos o essencial da comunicação no documento, no caso de precisarmos desviar o nosso foco para outra tarefa momentaneamente, não perdíamos a sequência do que estávamos fazendo.

Exemplos:
Email com issue solved:

Comentários, reply e alterações:

Vantagem
Eu podia testar todo um aspecto da feature e ir apontando os problemas, sem precisar interromper meu teste para comunicar ao desenvolvedor de um problema intermediário e sem ter que esperar terminar todo o fluxo pretendido para então reportar o problema. Também, o desenvolvedor não precisava esperar que eu revalidasse uma correção para fazer a próxima correção.

Final feliz
E depois de muitos ‘git pull’, problemas resolvidos e feature entregue! :)

Disclaimer
A utilização de uma ferramenta colaborativa não exclui a necessidade de comunicação verbal, de levantar-se e ir a mesa do seu colega de trabalho. Essa comunicação pessoal é essencial no dia a dia. Nesse caso, a utilização da ferramenta tem por objetivo contribuir para organização e produtividade.


Se você já utilizou da característica de colaboração do google docs para ajuda-lo(a) nos seus testes, ou outra ferramenta com o mesmo intuito, conta a sua história também :)

Dica: How to share and collaborate using Google Docs.

Gente, eu estou na InfoQ !

A palestra sobre testes em produção que eu ministrei no TDC2012 foi disponibilizada no site da InfoQ. Dá uma olhada ;)

Aproveito pra já ajudar a divulgar dois dos meus eventos preferidos que já estão com datas marcadas para 2013:
Agile Brazil 2013 será de 26 a 28 de junho em Brasília

E o TDC2013 já tem datas!
TDC Floripa: 24 a 26 de Maio de 2013
TDC Sampa: 10 a 14 de Julho de 2013

O período de submissão desses eventos abrirão em breve, então já comecem a preparar suas apresentações.

Testes em produção: paraíso ou inferno?

No próximo final de semana estarei no TDC Goiânia coordenando a trilha de testes e apresentando a palestra "Testes em produção: paraíso ou inferno?".

Você tem algum caso de teste de produção com sucesso ou não que queria compartilhar? Coloca nos comentários!

Aguardo vocês lá pra gente bater um papo legal sobre o assunto! :)

Testing Dojo Brasil

O Site testingdojo.com.br nasceu com o objetivo de concentrar informações sobre dojos de teste no Brasil, facilitar a promoção desses encontros e dar visibilidade às comunidades de teste.

No dia 13/09/2012 rodou em São Paulo o primeiro Testing Dojo  registrado no site Testing Dojo do Brasil, que contou com o apoio da Open4Education, uma iniciativa da Globalcode que promove minicursos gratuitos online e presenciais.

A dinâmica contou com mais ou menos 8 participantes e os facilitadores, eu e o Alan Correa Morais . O desafio foi identificar padrões em uma aplicação que gera anagramas e foi escolhido através no site testing-challenges.

Os papeis aos quais demos destaque foram piloto e co-piloto. Preparamos duas mesas/cadeiras e um notebook ligado a um projetor. O co-piloto ficava operando o notebook e o co-piloto ajudando a anotar as hipóteses e resultados. Após 7 minutos, o piloto voltava para a plateia, o co-piloto assumia o computador e alguém da plateia assumia o papel de co-piloto.

A sessão começou as 19:50 e foi até as 21:00. Depois fizemos uma retrospectiva onde os participantes puderam apontar pontos positivos e negativos relacionados ao local, a dinâmica, ao desafio, etc.

Como resultado da retrospectiva:

•        O espaço da Globalcode foi fantástico. Os participantes elogiaram o espaço e o carinho do pessoal de deixar um lanchinho de welcome pra nós. Fora que o auditório e a arrumação atenderam 100% a nossa dinâmica.
•        A atividade escolhida foi desafiadora e divertida.
•        Os participantes gostaram do formato.
•        Os participantes entenderam que transmitir o dojo ao vivo, ou mesmo gravar, poderia inibir a participação.
•        Foi levantado que o co-piloto também poderia ter um computador disponível para fazer as anotações

No fim, a minha opinião em relação ao dojo é que foi desafiador e motivador! E que venham outros! :)

Garotas nos trilhos

No último final de semana rolou também o Rails Girls, um evento que nasceu na Finlândia em Helsinki em 2010 e ganhou o mundo. No Brasil, o primeiro evento foi em Porto Alegre e nos dias 7 e 8 de setembro foi a vez da edição São Paulo.

Rails, pra quem não conhece, é um framework web open source para a linguagem de programação Ruby (mesmo que não tenha entendido nada do que eu falei agora, você pode ir a um evento do Rails Girls :) )

O objetivo do Rails Girls é o de difundir a cultura de programação, trazer mais mulheres para a área técnica e compartilhar esse “poder” de fazer ideias tornarem-se projetos reais.

O formato do evento é um workshop de um dia e meio, que começa geralmente numa noite de sexta-feira com uma “Installation Party”. Esse é um momento no qual as meninas se encontram para preparar seus notebooks para programar no dia seguinte. É também um momento de interação entre coaches e “alunas” e acontecem algumas lightnings talks motivacionais, geralmente falando sobre mulheres na TI, mulheres na programação, porque programar, e outros temas correlatos.

No dia seguinte, todos se reúnem com o objetivo de criar uma aplicação. Outras lightnings acontecem durante o dia, especialmente com o objetivo de dar algum norte para quem nunca ouviu falar nada de programação, nem sabe o que é uma tag HTML. :) As “alunas” são organizadas em grupos, que tem um coach responsável. O coach é quem vai de fato ensinar as mulheres a programar e vai orientar o desenvolvimento de alguma página que elas queiram.

No evento de São Paulo, tivemos aplicações super interessantes como a de controle de treinos de natação, a que permite que o usuário indique o quanto um local está cheio quando faz check in, a de classificação de livros por influência, entre várias outras aplicações legais.

É emocionante acompanhar esse processo de aprendizado e ver pessoas que não tinham o menor contato com esse mundo técnico se surpreendendo consigo mesmas ao não só criar o seu próprio site funcional como também deixa-lo publico.

O Brasil se encantou pelo Rails Girls, e temos vários outros eventos acontecendo ainda esse ano. O próximo será em Recife nos dias 28 e 29 de Setembro e já temos meninas organizando edições no Rio de Janeiro e em Belém.

Acompanhe o Rails Girls:
Facebook
Twitter
Twitter Brasil

Agile Brazil 2012 sob um olhar diferente

Em 2011 participei do Agile Brazil que aconteceu em Fortaleza e isso fez uma baita diferença na minha vida profissional. Conheci várias pessoas, assisti a palestras muito legais e sai de lá muito mais critica com relação ao meu trabalho. Isso fez com que eu buscasse novos desafios, trocasse de empresa e ainda, pouco depois de voltar do evento de Fortaleza, em 5 de Julho de 2011 dar o primeiro passo para ajudar a organizar o evento de 2012 em São Paulo. Simplesmente mandei um e-mail para um dos organizadores e disse que queria ajudar, nem que fosse apenas dando pitaco nas palestras de teste de software.

Não pude nem prever que ficaria tão envolvida com esse projeto. Participei de iniciativas de divulgação via twitter, no facebook e em eventos, da organização da Virada Ágil, da manutenção do site, da revisão das submissões, da montagem da grade, especialmente em relação as palestras de Desenvolvimento e Teste e acompanhei várias outras frentes nas quais não estive tão ativa quanto nessas que citei.

Em alguns momentos houve a insegurança de o evento não deslanchar e termos problemas por assumirmos o evento, já que o Agile Brazil não é uma organização ou uma empresa. É um evento montado e levado por voluntários da comunidade com muita vontade de fazer acontecer, mas com pouco conhecimento e experiência em fazer eventos desse porte. Para nosso alivio, felicidade e tranquilidade, o evento já foi um sucesso em 2010, 2011 e o mesmo sucesso acompanhou 2012. Tivemos um grande número de inscritos e muitos feedbacks positivos.

Durante os 3 dias de eventos foi um corre-corre para fazer tudo dar certo e não teríamos conseguido fazer do evento o sucesso que foi se não fosse a ajuda e a energia dos voluntários. Ao final de cada dia, fazíamos retrospectivas, recolhíamos os feedbacks deixados no mural e tomávamos ações para melhorar ainda mais o evento.

No pré-evento eu aprendi bastante sobre organização de eventos, fiz vários contatos legais, conheci bastante pessoas, vi e vivi situações de conflito, aprendi mais um pouco sobre trabalho em equipe, como lidar com as pessoas e suas diferenças e foi um crescimento fantástico.

Durante o evento, exercitei bastante a capacidade de reagir rápido a mudanças e a problemas e muito mais do que ouvir sobre agile, SER ágil, que pra mim é algo que transcende as teorias, frameworks e livros e está muito mais ligado a entregar valor e resolver problemas, que foi a nossa rotina maluca dos 3 dias de evento.

Participei de bem menos palestras esse ano que no ano passado, mas talvez eu possa chamar toda essa experiência de um grande workshop que durou pouco mais de um ano e além de todo esse conhecimento, trouxe grandes amizades. Trabalhei muito próxima de algumas pessoas em especial:

Dairton Bassi, coordenador geral do evento
Ceci, que alias fez um excelente trabalho a frente do voluntários
Fabio, que estava cuidando de boa parte do site
Hugo, coordenando o comitê de programa e da trilha de desenvolvimento e testes comigo
Luca Bastos, grande parceria, super comprometido e amigo durante todo esse processo do evento
Rafa, que deu a maior força na equipe da Virada Ágil

Reencontrei pessoas super especiais também como a Teresa que foi minha professora na especialização e gerente no C.E.S.A.R. e Daniel Wildt que foi o meu canal para fazer parte de tudo isso.

Todos os outros coordenadores e colaboradores também fizeram um trabalho incrível e tem meu respeito e admiração. Apenas citei os que eu trabalhei bem mais perto nesse período.

Conclusão: Organizaria outro Agile Brazil? Com certeza! Manoel Pimentel, “priminho”, #tamojunto no Agile Brazil 2013 em Brasília. Participaria de outro Agile Brazil? Tantos quantos tiverem. Mesmo que daqui há uns anos o evento mude a cara e os assuntos, é um grupo que tem muito a acrescentar e do qual eu pretendo e recomendo estar sempre perto.

Meu muito obrigado a todos que fizeram essa jornada comigo.