Picture Driven Testing com o Sikuli

Esse post já era para ter saído há um bom tempo, mas só agora tomei vergonha na cara para escrever sobre o Sikuli. 🙂

O que é o Sikuli?

O Sikuli é um projeto sob a licença MIT, desenvolvido pelo User Interface Design Group e o MIT Computer Science and Artificial Intelligence Laboratory (CSAIL), que utiliza imagens (screenshots) para buscar padrões na interface gráfica do usuário (GUI – graphical user interface).

Ele foi criado em Python e roda sobre a JVM (Java Virtual Machine), por meio do Jython, uma implementação da linguagem Python que gera bytecode que pode ser interpretado pela JVM.

O Sikuli tem dois componentes:

  • Sikuli IDE:uma ambiente de desenvolvimento integrado (IDE) que possibilita a escrita de scriptsvisuais utilizando screenshots;
  • Sikuli Script: uma API de scripts visuais para Jython, é por meio dele que os scripts criados no Sikuli IDE, são processados.

Como o Sikuli funciona?

A imagem abaixo mostra os componentes do Sikuli e como eles se relacionam.

Como o Sikuli funciona
Como o Sikuli funciona (fonte)

Basicamente utilizando o Sikuli IDE estamos criando um script python e salvando imagens quando tiramos um screenshot. O script python já importa automaticamente o Sikuli Script, que é o responsável por toda a “mágica” do reconhecimento de imagens. E por fim, quando rodamos o script ele é interpretado pelo Jython sobre a JVM.

Para que posso utilizar o Sikuli?

Com o Sikuli é possível automatizar tudo que você vê na tela. Você pode controlar uma página web, uma aplicação desktop no Windows/Linux/Mac OS, e até mesmo uma aplicação do iphone rodando em um emulador.

O Sikuli pode ser utilizado para diversos fins, desde a automatização de tarefas de usuários até testes de interface.

Utilizando o Sikuli para executar testes

Dentre os vários usos que pode ser feito do Sikuli, um que se destaque é a possibilidade de executar uma suíte de testes de interface (GUI Testing).

A grande diferença do Sikuli, perante as demais ferramentas de automação de testes de interface, está no uso do reconhecimento da imagem (por isso o uso do termo Picture Driven Testing), ao invés, do nome do elemento, ou coordenada da tela. Além disso, a abordagem de busca de elementos por screenshots, torna fácil a aprendizagem e evita um dos grandes problemas da automação de testes de interface, relacionadas a testabilidade do sistema (ex.: elementos com nomes dinâmicos).

O tempo de criação dos testes, provavelmente será maior, comparado as ferramentas record-play (ex.: TestComplete, Selenium IDE, etc), uma vez que é necessário realizar todo o processo de criação do script, tendo pelo menos um conhecimento básico das funções do Sikuli, e ainda você necessitará ir realizando o teste manual e capturando os elementos da tela com screenshots.

Mas por outro lado, como o nosso teste é guiado por imagens, ela será mais difícil de ser quebrado, uma vez que o Sikuli realiza uma busca, de acordo com o padrão da imagem, ou seja, o elemento está em um local diferente da tela, que mesmo assim, o Sikuli o encontrará.

Além disso, o Sikuli já foi projetado para suportar testes de unidade para GUI, integrando com o Junit. Tanto que há um painel de visualização específico para os testes (View -> Unit Test ou o atalho Ctrl+U).

Um script de teste pode ter os métodos de preparação e finalização, além é claro dos seus próprios métodos:

  • setUp(): usado para preparar o ambiente de teste;
  • tearDown(): usado para voltar o ambiente de teste ao estado antes do teste;
  • com o préfixo test: esses serão os seus métodos, que representam os testes que serão feitos (ex.: testCriandoUmArquivoDeTeste);

O Sikuli também provê duas funções de asserção:

  • AssertExist: Verifica se o padrão de imagem, passado como parâmetro, existe na tela;
  • AssertNotExist: Verifica se o padrão de imagem, passado como parâmetro, não existe na tela (o contrário do AssertExist).

Abaixo, um vídeo explicando alguns comandos do Sikuli, no qual eu crio um script bem simples, que abre o notepad, digita um texto e salva o arquivo:

Impressões sobre o Sikuli

A “descoberta” do Sikuli foi feita quando eu estava avaliando algumas ferramentas para automatizar alguns testes que exigiam o uso de interface. E acabei optando por usar o Sikuli.

De início as coisas estavam indo bem e parecia que tínhamos uma boa perspectiva futura com o seu uso. Porém, nem tudo são flores, e isso é mais verdade ainda quando falamos de testes que necessitam da interação com a interface, uma vez que eles são difíceis de se manter, e facilmente quebráveis.

E mesmo com o uso da imagem como “input”, se alguma mudança no visual ocorre na aplicação, os seus testes acabam quebrando, e foi justamente isso que ocorreu comigo. Já tinha automatizado os testes de uma nova funcionalidade da aplicação, porém ela sofreu uma grande mudança visual, e isso acabou quebrando todos os testes que eu tinha feito.

Além disso, na época em que usei ele (faz uns 2/3 meses) eu não consegui descobrir como chamar uma função python de dentro do próprio teste (a minha questão ficou por um bom tempo na lista de questões do Sikuli rs). E assim, acabava tendo que chamar um script em python (que fazia algumas asserções no banco de dados), via comandos do Sikuli + imagens, ou seja, uma solução bem paliativa.

Conclusão

Tendo em vista o pouco tempo de uso, a minha conclusão não pode ser negativa, mesmo não tendo tido sucesso no uso do Sikuli.

Afinal, o Sikuli é um projeto muito interessante e bem recente. E outras pessoas conseguiram bons resultados com ele (veja aqui e aqui).

O que recomendo para você, é testar a ferramenta, afinal ela é bem fácil de se usar, e analisar bem se a automação dos testes de interface é viável para a sua realidade. 😉

Saiba mais

Segue abaixo, alguns links de onde você encontrar mais informações sobre o Sikuli, e se aprofundar mais:

Fique por dentro das novidades, assine o feed do QualidadeBR.

Anúncios

O melhor da semana 02/05 a 08/05

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Receita do dia: Torta de bug

Momento Edu Guedes. Hoje vamos ver como preparar uma deliciosa torta de bug. A receita foi extraída do excelente capítulo No Bugs, do livro do James Shore “The Art of Agile Development”.

Para preparar a nossa torta de bug, primeiro iremos precisar de uma linguagem de programação desafiadora. Acredito que C pode ser uma boa. E iremos também dar uma pitada de Assembly.

Também precisamos adicionar alguns bugs misturando com programação concorrente. Afinal, os nossos velhos amigos segurança e disponibilidade estão felizes de lutarem um contra o outro para ver quem prover mais bugs. Eles até ajudaram os bugs da biblioteca multithread do Java por anos!

Agora vamos precisar de um problema de domínio bem difícil. Pode ser um sistema embarcado em tempo real.

Para cobertura desta receita de desastre, iremos precisar do tipo certo de programadores. Vamos ver… experts… acho que não, desenvolvedores sênior… também não! Juniores, ou melhor estagiários é o que precisamos.

Coloque os seus ingredientes: C, sistema embarcado em tempo real, multi-tarefas e não se esqueça dos estagiários e adicione um pouco de Assembly, bata bem e cozinhe por três anos.

Bom apetite, ou melhor, bons testes! 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Risk-based testing (RBT)

A 22ª Mesa Redonda DFTestes teve como tema “Risk-based testing (RBT)”. A discussão teve 3 respostas e participantes, sendo eles:  eu, Aderson Bastos e Robson Agapito.

A seguir, coloco a discussão na íntegra. 😉

Por que usar RBT?

O Aderson Bastos conseguiu responder a pergunta em uma frase:

No risk, no test… (Martin Pol) rs

Na minha opinião, RBT é uma abordagem muito útil para as equipes de teste e que pode ajudar na eficiência dos testes. Afinal, não podemos testar tudo, mas podemos testar o que tem maior risco de falhas.

É possível usar RBT sem ter um gerenciamento de riscos?

Segundo o Aderson Bastos:

Não, pois os riscos mudam e a ingerência destes comprometerá os testes.

Eu acredito que é possível sim, pois a própria equipe de testes poderá discutir quais áreas/funcionalidades da aplicações há maior risco. E é importante lembrar que umas das pessoas mais gabaritadas para realizar uma análise de risco é uma pessoa de teste. 🙂

Porém, acredito que o ideal seria que a análise de riscos seja feita junto com o planejamento da sprint/ciclo/projeto e que todos ou os cabeças chaves das equipes possam participar, pois assim, a análise poderá ser feita de forma melhor e todos estarão cientes dos riscos do produto.

Como devemos direcionar os testes usando RBT?

O Aderson Bastos lembrou muito bem da ISO 9126-1:

A ISO/IEC 9126-1 é uma ótima referência neste direcionamento.

Eu vejo que a ideia por trás do RBT é você testar a área que mais dói, portanto e lá que você concentrar os seus esforços iniciais, seja ela, uma funcionalidade com um algoritmo por trás, onde ouve mais mudanças, etc.

E uma vez identificada tal área, é sempre bom lembrar de Pareto, e então tentar descobri o mais cedo possível as falhas, seja usando automação, alocando o testador mais experiente, etc.

Quando utilizamos RBT precisamos focar onde o risco é maior, por isso da necessidade de fazer uma boa análise de riscos, pois senão, você poderá estressar uma área que não era tão importante assim.

Como foram as suas experiências com RBT?

O Aderson Bastos compartilhou as suas experiências dizendo:

É muito difícil usar RBT sem os riscos identificados e gerenciados! rs

Das poucas vezes que me deparei com cenário propício, a abordagem se mostrou bastante eficaz.

O Robson Agapito relatou uma pouco da sua experiência dizendo:

Aqui utilizamos algo parecido com a análise de risco… criamos um processo que não é uma análise de risco completa, mas adaptado ao nosso processo.

Todo requisito que vem para teste classificamos de duas maneiras, o impacto e a probabilidade. Mas falar somente impacto e probabilidade parece muito vago então focamos mais para a equipe de testes o que seria cada uma destas características.

O impacto não muda muito, seria o impacto da funcionalidade do requisito para o negócio que é visualizado para o cliente.

Já a probabilidade, contamos com a probabilidade desta funcionalidade conter defeitos (o risco de se identificar o defeito. Isso é algo específico aqui, pois temos Analistas de Testes experientes com relação ao sistema, isto é, conhecem muito sobre o negócio e o sistema que estão trabalhando. Então fica mais fácil de se identificar os pontos mais críticos para se ter um defeito. Mas nada que uma reunião com os analistas e desenvolvedores não nos faça identificar tal situação.

Com estas duas características identificadas, conseguimos definir a ordem dos testes.

Então temos a probabilidade e o impacto podendo ser classificado como :

1         – Muito Baixo

2         – Baixo

3         – Médio

4         – Alto

5         – Muito Alto

E utilizamos a seguinte ordem para os testes, sempre realizar os testes primeiramente dos requisitos com maior impacto, e para desempate utilizar a probabilidade de se identificar defeito começando pelo Muito Alto e indo até o Muito Baixo nas duas situações.

Com isso conseguimos priorizar, quando necessário, os testes a serem realizados primeiro.

É uma maneira simples e bem parecida (apenas uma pequena parte) da análise de risco.

As minhas foram muito boas! Como disse no começo, era é uma abordagem muito útil e ser usada com outras técnicas, como por exemplo, Teste Exploratório, pode garantir uma boa e eficiente cobertura de teste.

E ela pode direcionar tanto a execução dos testes como as outras atividades, e desta forma, podemos encontrar as falhas de forma mais rápida.

E o interessante do Teste Baseado em Riscos, é que ele pode trazer bons resultados independente da metodologia do projeto. E a sua aplicação faz o teste ser mais inteligente, principalmente pelo fato de estarmos testando com foco e sabendo o porquê.

Saiba Mais

Uma leitura recomendada sobre o assunto, é esse post da Sarah Pimentel.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Rapid Software Testing: Visão Geral

Publiquei um artigo sobre Rapid Software Testing no TestExpert. Segue abaixo, o link:

http://www.testexpert.com.br/?q=node/1741

No artigo eu apresento uma visão geral sobre o Rapid Software Testing (“Teste de Software Rápido”), que é uma metodologia bem interessante de Teste de Software, com características da Escola Direcionada pelo Contexto (Context-Driven School).

Aproveitando para avisar que desde do mês passado, estou participando do TestExpert como colunista. 😀

Minha meta é de elaborar dois artigos por mês lá. Logo após a publicação deles, irei avisar aqui criando um post com o link e uma breve descrição do artigo (o primeiro artigo eu não divulguei aqui, pois era um conteúdo já conhecido por vocês leitores[as]).

De início eu não pretendo repetir conteúdo do QualidadeBR para o TestExpert, e vice-versa, pois ambos são conteúdos Creative Commons, portanto de acesso livre. 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

O melhor da semana 25/04 a 01/05

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

Fique por dentro das novidades, assine o feed do QualidadeBR.

http://www.testexpert.com.br/?q=node/1740Nova comunidade que poderá revolucionar as ações sobre a divulgação de Testes: TESTADORES