Mudança de endereço do blog

Olá pessoal!
Depois de muitos anos bom o SemBugs no Blogger estou mudando o local do blog.

Agora o Sembugs continua pelo endereço:
http://eliasnogueira.com/blog

Como estou fazendo a transição de posts, peço a ajuda de vocês caso algo esteja parecendo errado, desconfigurado ou mesmo com informações faltantes.

Todos os novos posts, a partir de hoje, passam a ser postados no outro endereço.

Abraços!

Integração do Testlink com Mantis - modo atual

Olá pessoal!
No post Integração do Testlink com o Mantis BugTracker eu apresentei a forma, na época, de fazer a integração com estas duas ferramentas que era via arquivo de configuração.

Nas versões mais atuais do Testlink (1.9.x) esse método mudou, onde não há mais a necessidade de integração via arquivos de configuração. A nova abordagem agora é na própria página do Testlink através de uma nova funcionalidade de Issue Tracker (Gestor de Falhas)

O vídeo abaixo mostra como fazer esta configuração nas versões mais atuais do Testlink.

Participação no blog da Adaptworks

Olá pessoal!
Também comecei a blogar, mais especificamente sobre Agile Testing, no blog da Adaptworks.

http://www.adaptworks.com.br/blog/2013/09/16/o-que-e-agile-testing/

A Adaptworks é uma das principais empresas de treinamento no Brasil e referência quando falamos de agilidade, tendo um grande portifólio de cursos voltados para a linha ágil e instrutores bem conhecidos neste meio.
http://www.adaptworks.com.br/about.php

Aproveitando, a Adaptworks também tem um treinamento sobre Agile Testing, que você pode acessar pela aba "Treinamento Agile Testing" aqui no blog ou pelo link http://www.adaptworks.com.br/treinamento/Agile-Testing

Abraços!

Há espaço para testadores no mundo ágil?

O pensamento de muitas empresas

Ágil, uma palavra que cada vez mais vem se tornando uma buzzword e cada vez mais tem feito empresas a se intitularem ágil pelo simples fato ou de ser mainstream ou por uma série de "benefícios" como o mito de ágil não tem documentação.

O pensamento inicial de algumas empresas, ao adotarem a metodologia ágil como parte do desenvolvimento do seu produto acredita que apenas dois papéis são necessários: o do product owner e os desenvolvedores.
Como um dos princípios da agilidade é a entrega frequente de valor e a rápida resposta a mudanças, porque iriamos ter agora uma área de testes com testadores que fazem a validação do software no final do desenvolvimento? Esse é um dos pensamentos de muitas empresas que "migram" dos moldes de desenvolvimento tradicional (cascata) para o ágil.
Logo não se tem mais testadores, porque temos um ciclo mais curto para uma entrega e com testadores no projeto só iríamos aumentar este tempo.

E como temos desenvolvedores no projeto, eles apenas precisam adotar TDD - Test Driven Development, que já estarão testando e fazendo com que o software fique livre dos defetos!

Observação: vale lembrar também que, muitas empresas de forma errônea, tomam como premissa que um período de tempo para a entrega de algum valor (funcionalidade ou requisito) tem 4 semanas (que é derivado do Scrum) e planejam o desenvolvimento (e somente o desenvolvimento) em 4 semanas.

Mas vamos pensar uma coisa: onde no manifesto ágil é dito que não precisamos de documentação ou que precisaremos "cortar" qualquer atividade do processo de desenvolvimento? Em lugar nenhum!!!

Uma pequena lembrança

Ágil está mais para uma filosofia do que um conjunto de práticas/regras/processos.
Quando adotamos tal filosofia o time pode (e deve) estudar qual(is) método(s) de desenvolvimento irá adotar e entender qual(s) pode(m) ou não funcionar no contexto da organização.

A realidade em um time ágil

Um time ágil bem estruturado (leia-se time como o time do lado do cliente e o time de desenvolvimento) todos estão envolvidos e colabora em todas as fases: planejamento, desenvolvimento, testes e retrospectiva. Logo podemos concluir que alguém testa, não é verdade? Não necessariamente precisamos de um testador, mas que alguém na equipe tenha tal papel fixo ou esporadicamente (seja ele por um curto ou logo período de tempo).

A transição de testes cascata para interativo-incremental

No modelo cascata, ainda amplamente utilizado quando temos uma setorização de times (analistas, desenvolvedores, testadores), temos testes ao final do desenvolvimento de uma release, onde o testador recebe uma especificação e cria casos de teste enquanto o time de desenvolvimento está desenvolvendo uma série de funcionalidades. O final do desenvolvimento desta release os testadores já estão com os casos de teste prontos e só precisam de tempo para testar e reportar bugs/inconsistências segundo a especificação que foi recebida.
Esse modelo como muito tempo, porque sempre há bugs/inconsistências, onde o time de desenvolvimento que já está trabalhando em outras atividades, tem que parar e corrigir um problema, virando assim ciclos longos de correção.

No modelo ágil cada iteração se torna um processo paralelo no que diz respeito a desenvolvimento e testes. Enquanto o desenvolvimento de uma funcionalidade é realizado há formas e maneiras de testar o que está sendo desenvolvido, onde conseguimos um rápido feedback e, caso ocorra alguma inconsistência, uma correção na própria iteração.
Todas as tarefas de teste manual existentes no modelo cascata agora tornam-se automatizáveis em diversos níveis do desenvolvimento. A automação traz uma velocidade ainda maior no feedback quando a próxima iteração começa, onde o testador agora, ao invés de executar todos os testes manuais das funcionalidades existentes na iteração anterior, executa a batera de testes automatizados criada anteriormente, ou nem se preocupa em executar se a equipe utiliza a prática e integração contínua.

Então, precisamos de testadores?

Sim! Sabemos que o testador tem a tendência de pertencer aos dois times: cliente e desenvolvimento e ajuda o cliente a entender o que ele precisa expressando seus desejos em testes e os desenvolvedores a entender o que precisa ser entregue de valor.

Não é atoa que grandes empresas como Microsoft, Google, Apple, Yahoo!, Twitter, Facebook, Amazon e diversas outras que utilizam práticas ágeis possuem posições de testadores expressadas de diversas maneiras: QA Engineer, Software Engineer in Test, QA Automation Engineer, Test Engineer, etc...

Nos próximos post vamos falar dos skills que um testador precisa ter para trabalhar em uma equipe/time ágil.

O que é Headless Browser e porque você testador deve saber sobre

O que é Headless Browser

Do início, qualquer browser web tem que ser capaz de fazer três coisas:

1. Dado um endereço, acessar uma página html
2. Renderizar o conteúdo em DOM, executar scripts dentro da tag script, e torná-lo disponível na página
3. Renderizar o DOM em um conteúdo visual

Um browser que somente faz o primeiro item é chamado de "text-based"
Um browser que cobre os três itens são os browsers que conhecemos atualment
Um headless browser cobre os dois primeiros itens

Logo, headless browser um browser web sem uma interface gráfica, ou seja, não conseguimos ver o conteúdo da página na nossa tela, mas este browser consegue executar qualquer ação sobre a URL desejada.

Para que ele serve?

Basicamente para duas coisas: como crawler e como um browser para testes mais rápidos.

Browser para testes mais rápidos?

A crescente utilização de headless browsers é a capacidade de executarmos testes de uma maneira muito mais rápida do que um browser com interface gráfica.
Ele se torna mais rápido por não necessitar carregar alguns conteúdos visuais, como aplicar estilos visuais em elementos e carregamento de imagens.

Eles podem ser utilizados para executar a sua suíte de automação por completo, mas o maior ganho em ter scripts de teste executando em um headless browser é velocidade com que temos um feedback.

Pense em um sistema de Integração Contínua, a cada comportamento (commit, tempo, versão, etc...) um sistema de CI faz todo um processo (compilação, testes unitários e/ou integração, deploy e testes de aceitação). Neste processo um dos últimos (se não o último) são os testes de aceitação (aquele que abre um browser web e executa todas as ações), mas executar estes testes diariamente em um ambiente de CI toma muito tempo para nos dar um feedback que necessitamos.

O que algumas pessoas costumam fazer é separar uma pequena parte dos scripts mais importantes (smoke ou sanity) com ferramentas conhecidas (Selenium, Watir, Robot Framework), mas estes ainda tomam um tempo precioso na execução por abrirem um browser real e executarem uma série de ações.

Outras pessoas, e isso vem se tornando popular, criam ou atualizam scripts para executarem sobre headless browser. Isso nos dá um enorme ganho de execução nestes testes mais importantes e um feedback mais rápido se algum comportamento que será visualizado pelo usuário não estiver ok.

Quais headless browsers podemos utilizar?

Há uma séria de headless browser disponíveis. A grande maioria delas (e as melhores) são inclusive open source. Uma grande parte dela é construida sobre o WebKit e é escrita (tanto o código do browser quanto o script para executar o teste) em JavaScript.
Abaixo vou listar apenas alguns, e mais populares:

• PhantomJS
• CasperJS
• SlimerJS (Gecko)
• HtmlUnit
• ZombieJS

Um ponto interessante é que o Selenium/WebDriver pode executar testes em dois dos mais populares headless browsers:

• HtmlUnit através do HtmlUnitDriver
• PhantomJS através do GhostDriver

Onde posso ver um exemplo?

Aqui mesmo no SemBugs existe um post de uma apresentação minha no Web Test Meeting sobre como usar o básico do CasperJS.
O vídeo possui um pouco mais de 1h.

Apresentação sobre CasperJS no Test Web Meeting

Observação

Os possíveis termos que você testador pode não conhecer contém links para a sua descrição.
É totalmente recomendado que você leia também cada item com um link ;)

Abraços!