Brincando com PhantomJS e CasperJS

Esses dias usei o PhantomJS para converter uma imagem em SVG para PNG, e gostei bastante, tanto que dei uma olhada mais a fundo em como ele pode ser usado. E umas das formas é para testar aplicações.

Com o Phantom você pode testar de forma headless, ou seja, sem usar a interface gráfica, o que resulta numa diminuição do tempo dos testes.

Mas ele por si só não é um framework de teste, portanto quando usado pra testar você geralmente vai querer usar algum framework de teste como o Jasmine.

Pra minha brincadeira eu acabei usando apenas o CasperJS, que abstrai o PhantomJS visando a execução de testes. Assim sendo ele nos dá funções de navegação, preenchimento de campos, screenshot, etc.

Casper

Após instalar o PhantomJS e o CasperJS (versão 1.1 beta 1). Dei uma olhada nos samples do Casper, e usei o “googletesting.coffee”, para entender como ele funciona, e fiz uma pequena mudança, para capturar um screenshot no último teste, como pode ser visto no código abaixo:

Como vocês podem ver, a declaração do teste é bem similar a qualquer xUnit da vida.

Portanto, se você tiver procurando formas de testar usando Javascript/CoffeeScript, o PhantomJS pode te ajudar com certeza, e o CasperJS pode ser uma opção dentre as várias existentes.

Se quiser saber mais, sobre o PhantomJS o projeto é bem documentado, portanto dê uma olhada na doc e pra saber do CasperJS, veja a documentação e principalmente os samples.

Crowdtest – Minhas impressões

Nos últimos anos surgiram plataformas que utilizam o “poder das massas”. Essas plataformas são chamadas de crowdsourcing, e muitas delas são focadas no financiamento de projetos, como por exemplo o famoso KickStarter e a “versão” brasileira Catarse.me.

Nessa onda de crowdsourcing nasceu o Crowdtest em 2010, criado pela empresa mineira Base2 Tecnologia. O Crowdtest se apoia no crowdsourcing para fornecer serviços de Teste de Software. O seu foco é “organizar mão-de-obra disponível na Internet para execução de testes”.

Participei recentemente de um projeto no Crowdtest, mas antes de falar da minha impressão sobre a plataforma. Vou explicar como ela funciona.

Primeiro é bom entender que a Crowdtest faz a interface entre os Testadores e os clientes. O cliente cadastra o projeto no site e a equipe da Crowdtest monta a equipe de Testadores, avisando os Testadores já cadastrados no site.

Após montada a equipe, o projeto tem início e os Testadores testam os projetos com o objetivo de encontrar bugs. Cada bug encontrado é validado pela equipe da Crowdtest em conjunto com o cliente, e caso aprovado irá render uma remuneração ao Testador, de acordo com o tipo de bug encontrado (interface, funcional e impeditivo).

Eu participei do projeto de teste do novo portal da Natura e foi um experiência bem interessante, pois além de Testador, tenho a Vizir, portanto olhei o Crowdtest das duas perspectivas.

Primeiro vou falar da perspectiva de Testador.

A primeira coisa que me impressionou foi o profissionalismo. Logo que você entra no projeto de teste, há uma página informando detalhes do projeto. Nela é bem explícito os objetivos do teste e quais áreas que o Testador deve ter mais foco.

Uma vez ciente das informações de acesso e dos objetivos, vamos à diversão, ou melhor, aos testes. Aí é hora de arregaçar as mangas e fazer o máximo de testes exploratórios que você puder.

A cada bug encontrado, você primeiro pesquisa se o mesmo, já não foi encontrado por outro testador. Se o bug é “novinho em folha”, você cadastra todas as informações dele, e cadastra de forma bem completa, informando todos os dados necessários para o pessoal da Crowdtest poder reproduzir e identificar a ocorrência.

E qual a graça disso tudo, você pode está se perguntando? Bem, se você é Testador e gosta do que faz, só o fato de existir um sistema que acabou de nascer, já basta para você fazer uma boa “caça”. Mas brincadeiras à parte, o que eu achei interessante, foi que o Crowdtest te permite ter uma experiência real no mundo do Teste de Software, pois mesmo se você não estiver nessa área, o “reporte” de outros bugs irão te ensinar como fazer um bom “reporte” e dá dicas de onde procurar por bugs. Além disso, ao cadastrar o bug e ele ser aceito pela equipe da Crowdtest (eles verificam se não há duplicidade no bug e se ele realmente ocorre para poder validá-lo), você recebe uma remuneração.

Agora da perspectiva da empresa, a Crowdtest surge como uma boa alternativa para estressar o sistema que está para ser lançado.

Aqui na Vizir por exemplo, nós não temos uma equipe dedicada exclusivamente para os testes, portanto ter a rede de pessoas que a Crowdtest tem, testando sistemas que desenvolvemos em fase beta, seria uma boa opção. Uma vez que isso iria reduzir o número de bugs que nossos clientes encontrariam na realização de seus testes.

Principalmente para sistemas que vão alcançar um grande público, como por exemplo o próprio portal da Natura, usar a plataforma da Crowdtest faz com que o sistema seja testado por centenas/milhares de Testadores usando diferentes sistemas operacionais (mobile e desktop) e versões de navegadores. Só esse fato por si só, já te dá um feedback do nível de interoperabilidade do seu sistema.

Resumindo, a Crowdtest é uma ótima forma de você profissional de Teste de Software, viver experiências novas. E para você que está lançando um novo site/sistema/app, seja mobile ou web, aí está uma boa forma e a baixo custo, de você reduzir surpresas em suas apresentações para o cliente ou até mesmo em produção.

Para saber mais sobre o Crowdtest, veja o blog dele: http://crowdtest.me/crowdtest/

Automação de testes: Aproximando contextos

A área de Teste evoluiu muito desde quando eu iniciei nela, em 2007. Hoje mesmo não atuando nela, eu vejo o quanto é diferente a forma de se testar, de quando eu comecei na área.

Naquela época automação de testes era um assunto ainda muito pouco difundido e as ferramentas usadas pagas, de grandes suítes de teste como a Rational.

Hoje em 2013 o cenário muito bastante, práticas ágeis estão mais difundidas, a comunidade brasileira está mais madura e ferramentas open sources dão todo o “ferramentário” necessário para a automação.

Para chegarmos no estado de hoje, várias mudanças e revoluções ocorreram. E como toda revolução, ela promete algo muito melhor ao status quo e para se prevalecer, muitas vezes ela se apoia em dizer que tudo está errado.

A automação de testes surgiu como um “lobo mau” para muitos Testers e outros se agarram a ela, como se ela fosse o único caminho de se testar. Com o tempo perceberam que ela nada mais é do que uma evolução. Ela não veio pra expurgar testes manuais, ela veio pra trazer maior eficiência aos testes e evitar o “caos” das manutenções de software.

Um dos efeitos colaterais da automação de teste, foi a aproximação da área de Teste com a área de Desenvolvimento. Ela ocorreu fisicamente com os Testadores sentando mais próximos dos Desenvolvedores, pra facilitar a comunicação quando é preciso tirar dúvidas sobre programação.

Mas ela ocorreu mais ainda na formação do Tester, no próprio DNA do Tester, uma vez que programar não é mais uma arte usada apenas para construir, ela também é usada para “quebrar ” (testes de carga usando JMeter), pra verificar (testes de aceitação usando Jasmine) e pra dá segurança para mudar (testes unitários com RSpec).

Com isso dois contextos que de forma errada muitas vezes eram separados, hoje estão mais próximos. Afinal, Desenvolvimento e testes sempre existiram pelo mesmo propósito, entregar software de qualidade.

Com a dinâmica atual do mercado de TI, não há mais espaço pra guerrinhas setorias, nem para Desenvolvedores que só cospem código, e nem pra Testadores que só navegam por telinhas. Não é mais questão de ser generalista, é questão que saber analisar um problema é tão básico para um Desenvolvedor, como programar é para o Testador.

Retornando?

Olá pessoal! A quanto tempo não escrevo no QualidadeBR! Bom estar de voltar.

Na verdade eu nunca estive longe, só estive ausente mesmo.

Essa ausência que ocasionou mais de um ano de lacuna nas publicações tem vários motivos, sendo o mais importante, o fato de eu não mais atuar na área de Teste de Software.

Quem me acompanha no Twitter e Facebook, deve ter percebido as mudanças que ocorreram tanto na minha vida profissional, quanto na pessoal. Muita coisa mudou nesse 1 ano que estive digamos de “férias” do QualidadeBR.

Para aqueles que não sabem o porquê desse período sabático, e gostariam de saber, abaixo eu explico o motivo principal, para os que não querem, podem pular o próximo parágrafo. :)

Como eu sair da área de Testes, aliás, isso ocorreu bem antes do início do período sabático, foi no começo de 2010. A saída da área inicialmente não era total e eu ainda participava das Mesas Redondas que ocorriam no DFTestes (aliás, hoje em dia as Mesas Redondas ocorrem até em eventos, muito bom ver o pessoal continuando o trabalho e ampliando!). Porém com o tempo e principalmente com o início da Vizir, empresa na qual eu atuo e sou sócio-fundador, o recurso tempo ficou mais escasso, e nesse momento decidi por sair das minhas atividades relacionadas a Teste de Software, pois vi que não consegueria manter tudo e principalmente o nível de qualidade dos posts.

Agora sobre o título do post, não sei ao certo se estou realmente retornando as atividades do blog. De momento, o que posso dizer é que tenho algumas ideias de publicações sobre a área. :)

Agora de outra perspectiva, acredito que há até bastante coisa pra escrever sobre Teste de Software, mesmo não atuando na área (isso não é tão verdade assim, uma vez que parar de testar,  eu nunca parei hehe).

Abraço! E desculpas pelo longo período sabático, e obrigado a todos que ainda consultam o blog e assinam o feed, eu fico muito feliz em saber que o conteúdo aqui publicado ao longo dos anos, ajuda tantas pessoas. :D

Seja o “Curador” das Mesas Redondas

Como puderam perceber, há um bom tempo que não atualizo o blog. E não apenas ele, mas também a minha participação em grupos de discussão da nossa área, twitter, etc foram afetadas devido ao ritmo frenético do trabalho, o que é bom por um lado, mas tem suas consequências e demanda de certos “sacrifícios” e escolhas (o que é normal na vida de qualquer adulto).

Uma das atividades que faço na nossa comunidade e que foi afetada, é a organização das Mesas Redondas que ocorrem no grupo DFTestes. Atualmente eu apenas abro as votações e inicio as discussões,  não conseguindo mais acompanhar, participar e resumir as discussões, como eu fazia antigamente.

E é exatamente esse o trabalho que estou querendo passar para outra pessoa, pois hoje a minha contribuição é muito baixa, e não consigo dedicar o tempo que seria necessário para fazer um bom trabalho.

Basicamente, as atividades do “Curador” das Mesas Redondas são:

  • Abrir a votação 1/2 semanas antes do final do mês;
  • Fechar a votação no primeiro dia do mês;
  • Abrir a discussão no primeiro dia do mês, do tema mais votado;
  • Abrir a discussão no dia 15 do mês, com o tema que ficou em segundo lugar na votação.
A criação do resumo de cada discussão, também é algo que seria legal de fazer, uma vez que o conteúdo gerado nas Mesas Redondas costuma ser de alta qualidade e relevância, mas essa atividade não é mandatória da função, embora altamente desejável.
Se você tem interesse em ser o “Curador” das Mesas Redondas, me mande um e-mail para ffc.fabricio@gmail.com. E qualquer dúvida, só me mandar um e-mail ou postar um comentário.

IEEE 1028 – Padrão para Revisões de Software

Um amigo meu, o Edimilson Estevam, fez o último exame da CTFL, e comentou comigo que caiu algumas questões a respeito desse padrão do IEEE.

Eu particularmente nunca tinha ouvido falar a respeito dele, nem na época que me preparei para a CTFL.

O intuito desse post, é compartilhar esse padrão (enviado pelo Edimilson – obrigado!), e também fazer um resumo a respeito dele.

O que é o IEEE 1028?

Como todo padrão elaborado pelo IEEE (lê-se “I três E”), o 1028 é fruto do trabalho voluntário de alguns membros do IEEE. E sendo um padrão, eles nos traz algumas importantes e relevantes informações a respeito de revisão de software. Mas é sempre bom lembrar, que ele deve ser usado com bom senso, pois o contexto sempre prevalece sob o padrão (ou deveria prevalecer).

O IEEE 1028 nos traz cinco tipos de revisão de software, junto com os procedimento necessários para a execuçaõ de cada tipo. Está fora do escopo do padrão questões como: quando uma revisão se faz necessária? como escolher qual tipo de revisão deve ser usado?

Os 5 tipos de revisão abordados são:

  • Revisões gerenciais;
  • Revisões técnicas;
  • Inspeções;
  • Walk-throughs;
  • Auditórias.

Os cinco tipos de revisão

Segue abaixo, a tradução do anexo B do padrão, que contém uma tabela comparativa entre os tipos de revisão (o texto original está numa linguagem meio chata de entender, e não consegui melhorar muito na tradução – se notarem algum erro ou melhoria, por favor me avisem):

Característica Revisão gerencial Revisão técnica Inspeção Walk-through Auditória
Objetivo Garantir o progresso; recomendar ações corretivas; garantir alocação correta dos recursos Avaliar a conformidade do estado atual com as especificações e planos; garantir integridade da mudança Encontrar anomalias; verificar decisões; verificar a qualidade do produto Encontrar anomalias; examinar alternativas; melhorar o produto; fórum para aprendizado Avaliação independente de cumprimento com os objetivos de padrões e regulamentos
Tomada de decisão A equipe de gerenciamento traça o curso da ação; decisões são feitas na reunião ou como resultado das recomenda-ções A equipe de revisão solicita aos gerentes ou a liderança técnica que atuem nas recomendações A equipe de revisão escolhe as disposições pré-definidas do produto; os defeitos devem ser removidos A equipe concorda com as mudanças para serem feitas pelo autor Organização auditada, iniciador, comprador, cliente ou usuário
Verificação das mudanças O líder verifica que itens são fechados; a verificação das mudanças é deixada para outros controles do projeto O líder verifica que itens são fechados; a verificação das mudanças é deixada para outros controles do projeto O líder verifica que itens são fechados; a verificação das mudanças é deixada para outros controles do projeto O líder verifica que itens são fechados; a verificação das mudanças é deixada para outros controles do projeto Responsabili-dade da organização auditada
Tamanho recomendado do grupo Duas ou mais pessoas Três ou mais pessoas Três a seis pessoas Duas a sete pessoas Uma a sete pessoas
Quem participa Gerentes, liderença técnica e algumas pessoas de outras áreas Liderença técnica e algumas pessoas de outras áreas Pessoas da área com acompanhe-mento documen-tado Liderença técnica e algumas pessoas de outras áreas Auditores, organização auditada, pessoal de gerência e técnico
Grupo da liderança Normalmente o gerente responsável Normalmente o engenheiro líder Um facilitador treinado O facilitador ou o autor O auditor líder
Volume de materiais Moderado para muito, depende dos objetivos da reunião Moderado para muito, depende dos objetivos da reunião Relativa-mente baixo Relativa-mente baixo Moderado para muito, depende dos objetivos da reunião

Abaixo, segue o link para baixar o padrão IEEE 1028:

http://bit.ly/ieee_1028