2013

segunda-feira, 21 de outubro de 2013

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!

quinta-feira, 26 de setembro de 2013

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.

segunda-feira, 16 de setembro de 2013

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!

quinta-feira, 12 de setembro de 2013

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.

quarta-feira, 4 de setembro de 2013

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:

Dado um endereço, acessar uma página html
Renderizar o conteúdo em DOM, executar scripts dentro da tag script, e torná-lo disponível na página
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:

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!

quinta-feira, 29 de agosto de 2013

Pare de criar scripts de teste e comece a pensar

Sim, PARE!!!
Vamos contextualizar o título.

Conceituação

Hoje o mercado pede automação de teste e as pessoas, obviamente vão em busca do que o mercado pede. Não todas obviamente, mas uma grande parte. Com a ascensão da agilidade na entrega dos softwares hoje em dia, onde muitos tomam como base um produto que é potencialmente entregável em uma variação/período de tempo de 2 a 4 semanas (obviamente não é a regra mas muitas equipes trabalham com essa variação).

Ai comece a pensar o seguinte: como eu vou garantir que, a cada variação destas (2 a duas semanas ou 4 a 4 semanas), para um mesmo produto, eu conseguirei garantir a qualidade do que está sendo desenvolvido?

Vamos incluir aqui a automação de teste em todos os níveis, segundo a pirâmide de automação de teste.
Olhando esta variação notamos que há uma grande vantagem em automatizar tudo o que pudermos ao invés de executar testes manualmente, certo? Obviamente sabemos que os testes automatizados não substituem os testes manuais por completo, mas essa é uma linha de raciocínio que não é falsa.

Logo, precisamos nesta variação, automatizar o que for factível para que no final:

o produto potencialmente entregável funciona como esperado (aspecto implícito de qualidade)
que, durante as próximas entregas de novas funcionalidades ou alteração de funcionalidades existentes, o tempo não seja desperdiçado na execução do teste manual e que o(s) script(s) de teste executem, onde ganhamos um feedback continuo dos testes

Senso comum

Ótimo Elias, você me convenceu, automatizar é a solução... Então vamos logo automatizar!

O que o mercado faz

O termo "mercado" aqui diz respeito ao profissional, seja ele desenvolvedor, tester ou qualquer outro papel, que vai automatizar algo. Também é a minha visão e opinião sobre o mercado.

Dado a agilidade na entrega do software o que o mercado faz é entender a funcionalidade e começar a automatizar nos períodos pertinentes.
Só que existem problemas quando "baixamos a cabeça" e começamos a automatizar...

Nem sempre a funcionalidade que será automatizada é realmente entendida pelo automatizador ou mesmo pela equipe
A automação, as vezes, é feita sem um conhecimento geral sobre programação com a utilização de ferramentas record & play
A execução da automação é feita um a um. Ou seja, existem diversos scripts de teste, mas o profissional abre e executa cada um
Depois de um tempo, o próprio profissional não sabe o que o script faz
Mesmo com uma série de scripts prontos, um novo bug sempre é encontrado pelo cliente

O mercado em si também trabalha muitas vezes de uma forma que não há ganhos em automatizar. Ex: um profissional de teste recebe, para poder automatizar, uma série de documento de requisitos, regras de negócio e casos de uso para automatizá-los. Com isso o foco da automação fica apenas na visão de um único requisito/caso de uso/regra. Isso pode ser extremamente ruim porque a automação dificilmente vai mostrar valor no conjunto da obra.

Não vou comentar aqui sobre testar/automatizar quando não se tem quase documentação porque, neste caso e na minha visão, existe uma grande chance de você conseguir testar e automatizar certo... mas isso é outro post...

Para de criar scripts e comece a pensar!

OK, temos um curto período de tempo se falarmos em agilidade (lembra das 2 a 4 semanas mágicas que muitos adotam), então começar a automatizar o mais rápido possível é a solução!

Sim, pode ser, mas pare de criar scripts e comece a pensar!

A grande maioria das pessoas que me procuram pedindo ajuda em automação, principalmente automação funcional/UAT é que os scripts param de funcionar e estes não conseguem mais "fazer com que o script passe".
E sabe porque isso acontece? Porque estas pessoas simplesmente "baixaram a cabeça" e começaram a automatizar.
Também há outro problema que é a falta de conhecimento na ferramenta em que se está utilizando.

Explicando no lado técnico da coisa

Começando do básico, e um dos exercícios que eu faço muito com meus alunos no meu Treinamento de Selenium/WebDriver, é primeiro olhar como a página funciona num olhar de usuário, não de testador (embora o testador tenha um olhar de usuário, no momento em que ele vai automatizar algo ele olha como olhar de tester).
Vamos pegar um exemplo, e você não vai perder mais 5 min neste post :)

O teste é simples:

Acesse a página http://eliasnogueira.com/arquivos_blog/geral/collapse/
Clique sobre a 'div preta' "Minhas Páginas"
Clique sobre o link "Treinamento Agile Testing"

Simples não? Porque então não automatizar logo???
Bom, antes de continuar lendo o post tente automatizar na sua ferramenta de automação web preferida.

Resultado da automação sem pensar no comportamento

Se você automatizar exatamente os passos o teu script falhará! Sim, ele vai falhar!
Provavelmente ele vai falhar quando você executa o terceiro passo, que é clicar no link "Treinamento Agile Testing"

Abaixo vou colocar o trecho de código automatizando com WebDriver + Java, ignorando os devidos imports.

WebDriver driver = new FirefoxDriver();
driver.get("http://eliasnogueira.com/arquivos_blog/geral/collapse/");
driver.findElement(By.id("section1")).click();
driver.findElement(By.linkText("Treinamento Agile Testing")).click();

Vamos pensar no comportamento da página

Ao invés de automatizar com um olhar de desenvolvedor ou testador, vamos olhar como um usuário e mais: vamos descrever o comportamento da página.
O comportamento que eu vejo é o seguinte:

Eu acesso a página em questão e ele carrega
Me mostra algumas informações
Eu clico em "Minhas Páginas"
Um efeito é aplicado apresentando três links
Eu espero o efeito terminar
Eu clico no link "Treinamento Agile Testing"

Agora comparem a descrição do comportamento com os passos que eu descrevi anteriormente. Qual a diferença?
Descrevendo o comportamento da página eu coloquei uma coisa muito importante: que eu espero o efeito de clicar em "Minhas Páginas" acabar para que eu possa clicar no link "Treinamento Agile Testing"

O que faltou então: a espera!
Simples não, mas tem elementos simples que não nos damos conta que fazem nosso script falhar "sem razão".
Adicionando uma espera o script, funcional, fica assim:

WebDriver driver = new FirefoxDriver();

driver.get("http://eliasnogueira.com/arquivos_blog/geral/collapse/");

driver.findElement(By.id("section1")).click();

        

By byAgileLink = By.linkText("Treinamento Agile Testing");

WebDriverWait wait = new WebDriverWait(driver, 10);

wait.until(ExpectedConditions.elementToBeClickable(byAgileLink));

        

driver.findElement(byAgileLink).click();

Porque isso ocorre?

O primeiro problema é a afobação, sim!!!!
Logo quando vemos algo fácil (ou mesmo difícil), por pressão de tempo, por baixa complexidade ou por diversos outros fatores começamos logo a escrever scripts de teste automatizado "sem pensar".

O problema do lado da arquitetura

Poucos testers que eu conheço, sim poucos mesmo, pensam em arquitetura para a automação de teste!
O que eu quero dizer com arquitetura é você fazer as seguintes perguntas:

como eu executarei todos os scripts?
como eu saberei o resultado da execução?
como qualquer pessoa terá acesso aos scripts e a executá-los?
como eu irei escalar os scripts? (quando novas funcionalidades entrarem)
como eu farei a manutenção dos scripts?
como eu irei informar o ambiente que os scripts serão executados?

Existem muitas outras perguntas que podemos fazer, mas isso já te dá uma boa noção do que é pensar em arquitetura para a automação de teste.

Então não é apenas "baixar a cabeça" e criar scripts. Imagine que o software a cada variação/período, tenha mais e mais funcionalidades. Como você vai responder as perguntas acima?
Se você não pensar nestes aspectos vai ser muito, mas muito mais vantajoso executar os testes manualmente porque você perderá muito tempo tentando arrumar/consertar os scripts.
É neste ponto que a maioria dos profissionais falha na nossa área: vendemos automação como sendo algo legal, mas depois nossos pares/colegas/gerentes veem isso como uma coisa difícil de manter e complicada, caindo em descrédito e não enxergando benefícios.
Tudo isso porque não pensamos antes de fazer!!!

Dica

Sempre, sempre que você for automatizar qualquer funcionalidade que seja, escreva em um bloco de notas ou pense quais são os reais passos que você está executando como um usuário. Depois disso, se você ainda não estiver muito familiarizado com a ferramenta que estás utilizando, tenta substituir cada ponto anotado por comandos. Obviamente terão pontos que não serão comandos, mas isso fará você pensar em tudo o que ocorreu na página e cobrir isso na criação do script.

Também conheça muito bem da ferramenta que você está utilizando e evite ao máximo record & play.
Uma ferramenta com record & play, muito provavelmente, não terá pontos de sincronização (a espera que fizemos) e você vai esquecer rapidinho de que existe uma sincronização a ser feita.

Conclusão

Testar coisa é uma tarefa investigativa, então tudo começa com um curiosidade e estudo do comportamento das coisas.
Todo o teste deve ser sempre baseado em uma hipótese, e quando você cria uma hipótese qual a primeira coisa que fazemos? Estudamos as possibilidades, analisamos comportamentos e depois aplicamos o teste para validar que a hipótese é ou não é verdadeira.

O nosso senso de urgência e conhecimento sempre vai nos dizer para não perder tempo pensando, afinal eu já tenho conhecimento e experiência bastante para fazer isso. Mas a prática real é bem diferente. Estudar comportamentos e pensar antes de qualquer coisa, não só para criar scripts de teste, nos dá uma visão muito melhor do que fazer.

Leitura recomendada: Tester, para de testar!

segunda-feira, 26 de agosto de 2013

O que aprendemos com teste de software

Eu vi uma pergunta desta no fórum do Software Testing Club e resolvi fazer a mesma coisa, só que no fórum do DFTestes.

Creio que é extremamente importante saber o que meus colegas estão aprendendo também. Isso nos dá uma visão não só de aprendizado mas também de mercado.

As respostas foram:

Aprendi que QAs devem ir fundo no paradigma funcional, logo estou estudando Erlang e pretendo estudar Elixir

Aprendi utilizar AspectJ nos testes (Selenium+JUnit)... testadores também devem saber o básico da programação

Estou aprendendo a usar a ferramenta TestLink

Aprendi um pouco sobre teste de performance, usando o NeoLoad, o SilkPerform e na batalha com o JMeter

Aprendendo Robotium

Aprendi TestLink e execução de Query's

Model cheking com LTSA graças a cadeira de VeV na minha faculdade

Aprendendo sqlmap para usar nos testes de segurança

Aprendi a usar Selenium WebDriver com Python (minha linguagem do coração :) )

Aprendi e apliquei técnica de automação de escrita de caso de teste com data driven

Aprendi Scrum, Kanban, Lean e Agile

Aprendi e implantei Jira e Greenhopper para Agile

Aprendi e implantei Continuous Integration e Continuous Deploy em PHP com GIT, AWS

Analisando as respostas podemos perceber algumas coisas bem interessantes:

Muitos testers estão aprendendo ferramentas de automação. Isso indica que eles já estão preocupados em estar no mesmo fluxo que o mercado que quer uma entrega/repsosta mais rápida

Alguns testers já estão aprendendo sobre itens não funcionais em teste de software, e isso prova que não é somente de teste funcional que se vive de teste de software

Que alguns testers estão entrando num contexto ágil, aprendendo coisas além do assunto especifico sobre teste de software

E vocês leitores, o que aprenderam com teste de software?

terça-feira, 6 de agosto de 2013

Formação à distância de Selenium 32h em Setembro/2013(Básico e Avançado)

A Qualister realizará em Setembro a formação à distância de Selenium (32h). Se o aluno quiser, poderá participar somente do módulo Fundamentos (16h) ou somente do módulo Avançado (16h).

Segue abaixo maiores detalhes:

Fundamentos
Carga horária: 16 horas
Valor: 650,00 (por aluno)
Data: 14 de setembro e 21 de setembro
Módulo 1: (8h) – 14 de setembro, sábado das 08:00 às 17:00
Modulo 2: (8h) – 21 de setembro, sábado das 08:00 às 17:00

Avançado
Carga horária: 16 horas
Valor: 650,00 (por aluno)
Data: 28 de setembro e 05 de outubro
Módulo 3: (8h) - 28 de setembro, sábado das 08:00 às 17:00
Módulo 4: (8h) - 05 de outubro, sábado das 08:00 às 17:00

Formação (Fundamentos + Avançado)
Carga horária: 32 horas
Valor: (1.300,00 - 25% de desconto) = 975,00 (por aluno)
Data: 14 de setembro, 21 de setembro, 28 de setembro e 05 de outubro
Módulo 1: (8h) – 14 de setembro, sábado das 08:00 às 17:00
Modulo 2: (8h) – 21 de setembro, sábado das 08:00 às 17:00
Módulo 3: (8h) – 28 de setembro, sábado das 08:00 às 17:00
Módulo 4: (8h) - 05 de outubro, sábado das 08:00 às 17:00

Forma de pagamento: cartão de crédito em até 12x (com juros), boleto ou transferência bancária.

LOCAL
Treinamento à distância. Será realizado no seu computador via Internet utilizando ferramenta de web-conferência.

INFRA-ESTRUTURA
Sistema Operacional: Windows ou MacOS (O GotoMeetting não suporta Linux)
Plugin para acesso ao GoToMeeting através do navegador (no dia do treinamento o participante receberá um link para acesso a sala de conferência)

MINISTRANTE
Elias Nogueira é Arquiteto de Teste de Software com ênfase em Automação de Teste. Possui certificação CSTE pela QAI Brasil e já palestrou em diversos eventos relacionados a Teste de Software. Ativo na comunidade de teste é entusiasta que todo testador precisa ser técnico e pensar "fora da caixa". Ja atuou em diversos projetos de teste em diversos segmentos de mercado como varejo, bancário, comércio eletrônico, geomarketing, mineração de dados. Blogueiro do SemBugs http://sembugs.blogspot.com.br

INCLUI
Certificado em formato digital (PDF) e acesso ao material em formato digital (PDF)

TÓPICOS ABORDADOS
Módulo 1
Este módulo apresenta as principais funcionalidades da ferramenta Selenium IDE totalmente aplicadas em 10 exercícios práticos baseados em dúvidas sobre a ferramenta. Ao final dos exercícios o aluno estará apto a automatizar qualquer página web, inclusive com Ajax (requisições assíncronas).

Ementa

Record and Play
JavaScript
Alertas e Confirmações
Popup’s
Elementos HTML
Expressões Regulares
Ajax Loading
Ajax AutoComplete
Ajax Carrinho de Compras
Combo Cidade/Estado

Módulo 2
Este módulo apresenta pontos avançados do Selenium IDE com mais exercicíos de variáveis e como manipulá-las através de javascript. Aprenderemos também a criar comandos customizados através de user-extensions e utilizaremos os principais plugins existentes para o Selenium IDE. Como último conteúdo aprenderemos a criar scripts orientados a massa de dados (data driven). Com o Selenium RC iremos executar todos os testes criados no Selenium IDE em diversos browsers web através de linha de comando, criando uma suite de testes automatizados com execução automática, bem como executar scripts data driven via linha de comando sem precisar de programação.

Ementa

Criação de comandos customizados através de user-extensions
Criação de scripts data driven sem programação
Aprendendo os principais plugins
Screenshot tirada automaticamente quando o script falha (ScreenShot on Fail)
Evidências de Teste (Tesingt Evidence)
Esperas automáticas (Implicity Wait)
Visualização das variáveis (Stored Variables)
Fluxos de Controle (Flow Control)
Executando scripts criados no Selenium IDE em diversos browsers com Selenium RC
Executando scripts data driven via linha de comando com Selenium RC

Módulo 3
Sabemos que o Selenium IDE tem diversas funcionalidades, mas muitas vezes fica limitado em sua utilização. Neste módulo aprenderemos a programar utilizando a API do Selenium chamada Webdriver com Java através de exercícios práticos. Aprenderemos porque agora existem classes para cada browser e como executar os testes sem precisar mudar o código, além de usar todo o poder dos frameworks de teste unitário para nos auxiliar nos testes.

Ementa:

Interagindo com elemento HTML com Webdriver
Automatizando uma paginação
Esperas por requisições assíncronas (Ajax)
Webdriver + JUnit
Webdriver + TestNG
Data Driven com Webdriver
Automatizando para diversos browsers

Módulo 4
Neste módulo aprenderemos como definir uma arquitetura reutilizável para os testes automatizados utilizando Webdriver e um padrão chamado PageObjetcs, bem como utilizar a massa de dados diretamente de um banco de dados. Também aprenderemos como integrar o Webdriver com o Testlink para apresentar os resultados de execução e também a abertura automática de bugs em conjunto com o Mantis. Além disso também aprenderemos a colocar os scripts dentro de um ambiente de Integração Contínua.

Ementa

Arquitetura com Page Objetcs
Gerando Evidências em PDF
Arquitetura de dados com Webdriver e acessoa banco
Integração Testlink + Webdriver
Integração Mantis + Webdriver
Integração Mantis + Testlink + Webdriver
Execução automática de testes em um ambiente de integração contínua com Jenkins

INFORMAÇÕES
treinamento@qualister.com.br
48 3285-5615

LINK DO CURSO
http://www.qualister.com.br/curso-treinamento-formacao-no-mes-de-setembro-formacao-a-distancia-de-selenium-basico-e-avancado

domingo, 28 de julho de 2013

Como foi a Trilha de Teste do TDC 2013 SP

Como foi a Trilha de Teste do TDC 2013 SP?

Fui um sucesso!!!

Coordenação

Eu comecei na coordenação da Trilha de Teste do TDC a convite do Jorge Diz, que já era o coordenador anterior, e o evento sempre tem a dinâmica de ter dois coordenadores.
A partir dai vim coordenando a Trilha de Teste atá agora, sendo já 8 participações como coordenador e algumas delas como palestrante.
Nestes últimos dois anos, para também incentivar os outros estados que tem o TDC (São Paulo, Santa Catarina, Goiás, e agora os novos Rio Grande do Sul e Pernambuco), comecei a convidar pessoas para a coordenação no intuito de "assumir" essa posição muito importante para o evento.
Em Florianópolis eu tive ajude de duas grande gurias:
   - Maira Stella [1] em 2012
   - Fernanda Thiessen [2] em 2013

Uma das duas, ou as duas devem assumir a Trilha de Teste do TDC 2014 Florianópolis :)

Em São Paulo tivemos dois coordenadores:
   - Leonardo Oliveira [3] em 2012
   - Alan Correa [4] em 2013

O Alan deve assumir a Trilha de Teste no TDC 2014 São Paulo :)

A Trilha

Ela foi muito bacana e a mais lotada do evento (pra ter noção eu não tinha onde sentar).
Este ano, como recebemos diversas palestras muito boas acabamos dividindo alguns slots (espaço de tempo de uma palestra de 50 min) em dois (25 min para cada palestra) para trazer assuntos interessantes para vocês. As únicas palestras que tiveram 50 min foram as de patrocinadores, que não foram nem um pouco ruins, pelo contrário :-)

Para se ter uma noção da quantidade de assuntos diferentes que foram abordados em um único dia de evento, dê uma olhada na lista de assuntos abaixo:

Mobile
Automação
Qualidade
Ferramentas (Jenkins e WebDriver)
Cloud Test
Agile Testing

Todas as palestras estão disponíveis na página da Trilha de Teste do TDC 2013 [5] ou abaixo

Links relacionados

[1] http://themonsterbug.blogspot.com.br/
[2] http://about.me/fernandathiesen
[3] http://br.linkedin.com/in/leonardoro
[4] http://about.me/alancmorais
[5] http://www.thedevelopersconference.com.br/tdc/2013/saopaulo/trilha-testes#programacao

terça-feira, 9 de julho de 2013

Apresentação sobre CasperJS no Test Web Meeting

Oi pessoal!
Hoje tivemos a primeira reunião do Test Web Meeting, uma iniciativa do site/blog Qualidade de Software do Eduardo Freitas que visa reunir os ~~nerds~~ testers a falar sobre algum tema que foi votado antes da reunião através do Call4Paperz.

Hoje (09/07/2013) eu falei sobre CasperJS, uma excelente ferramenta de automação web headless browser. O foco nesta primeira apresentação foi mostrar, de forma bem básica, como começar a utilizar o CasperJS e uma pequena comparação com o Selenium em termos de tempo de execução, onde ele costuma ser quase 2x mais rápido do que o Selenium.

Abaixo está o vídeo da primeira reunião!
Não deixe de acessar o site Qualidade de Software, submeter uma apresentação e votar nas ativdas no Call4Paperz.

Links de ferramentas e conceitos comentados na apresentação:

Abraços!

terça-feira, 2 de julho de 2013

Trilha de Teste no TDC 2013 São Paulo #vemprotdc

Olá pessoal! A grade da Trilha de Teste do TDC 2013 SP já está publicada!
Este ano em São Paulo eu, juntamente com o Alan Correa estaremos coordenando a Trilha de Teste na Universidade Anhembi Morumbi no dia 12/07
http://www.thedevelopersconference.com.br/tdc/2013/data-e-local

Alan Correa é o cara que mais entende das ferramentas de teste da Microsoft.
É atuante na área de teste de software e tem diversas iniciativas bacanas, uma delas de ensinar as próprias ferramentas de teste da Microsoft de forma gratuita
http://goo.gl/2aG4h

Este ano teremos 10 palestras na trilha, isso mesmo 10!!! Como recebemos ótimas submissões e não queríamos deixar nenhum de fora resolvemos dividir um slot (período de tempo de uma palestra de 50 min) para que estes comportassem duas palestras.

Confira a grade de palestras

Abaixo também há um vídeo com um convite meu para a Trilha de Teste desta edição de SP.

Não deixe pra última hora e faça sua inscrição, ela acaba beeeemmmm rádipo!
http://www.thedevelopersconference.com.br/tdc/2013/inscricoes#saopaulo

Até lá!

segunda-feira, 13 de maio de 2013

O papel do testador em uma equipe agil

Atualizado em 21/08/2013!

Olá pessoal!
Dia 11 de Maio de 2013, na Unicamp, eu apresentei no DevCamp uma palestra sobre "O papel do testador em uma equipe ágil.

Vídeo

No site da Infoq BR é possível ver o vídeo da apresentação pelo link abaixo. Também é possível fazer o download do áudio da palestra em .mp3
http://www.infoq.com/br/presentations/testador-equipe-agil

Apresentação!

DevCamp - O papel de um testador em uma equipe ágil from Elias Nogueira

Abaixo segue um resumo do que comentei.

Hoje muitas empresas falam, quando sobre desenvolvimento ágil, muito de Scrum (e isso é bom ou ruim). Em teste de software temos um grand problema: além dos testadores não serem técnicos (muitos poucos são), eles querem aplicar em um contexto ágil (ou quase), as técnicas utilizadas em um modelo burocrátivo/engessado sempre pensando a fase de criação e, posteriormente, execução é um sprint separado do de desenvolvimento (não colaboram).

Testadores também não gostam de programar. Muitos foram para a área de teste por esse "benefício". Muitos são programadores que não deram certo ou pessoas querendo uma porta de entrada em TI ou para algum outro cargo, como um Analista de Requisitos/Negócio. Estou falando alguma mentira?

Emfim, em um mundo não tão distante o testador quer continuar acomodado e ainda discute itens básicos e, as vezes, nem condizentes como onde ele pode obter simulados da certificação XYZ ou como escrever um caso de teste.

Neste momento começamos a discutir sobre Agile Testing, que vale muito a pena salientar que Agile Testing é nada mais que seguir as práticas ágeis em primeiro lugar. Claro que existem técnicas, algumas já amplamente usadas, e outras novas, mas em um primeiro momento Agile Testing é uma prática que segue a "linha" ágil. Sempre falo que, para aprender Agile Testing, é necessário primeiro o testador dar um passo para trás e aprender o que é realmente ágil e nem ler sobre Scrum.

Em seguida comento algo que, em algumas empresas é sempre nítido, mas em outras nem acontece: O testador tem que interagir com todos! Desenvolvedor, cliente e analistas entendendo a visão do cliente (onde ele quer chegar) e a complexidade de viabilizar essa visão (como ajudar ela a chegar no objetivo).
O testador tem que estar inserido junto ao time e deve ajudar o cliente a entender onde ele precisa chegar, através de perguntas e transformando o entendimento em algo que possa ser entendido e testável por todos.

E o que o testador fará enquanto os desenvolvedores estão criando código?
Várias coisas! Entre elas, pairing, ajudando os desenvolvedores nos testes unitários (a ter mais testes/cenários) e principalmente automatizam (existem muitas outras coisas que o testador pode fazer)! Sim, automatizam sem ter uma interface gráfica. E isso é possível adotando práticas como BDD e ATDD para que tenhamos boa parte dos testes já automatizados.
E, obviamente, um testador ágil tem que conhecer sobre o Quadrante Ágil (ou quadrantes de Bryan Merick). É essencial que ele conheça os quatro quadrantes e as atividades recomendadas em cada quadrante.

Para entender quando podemos automatizar, é interessante falar sobre a Pirâmide de Automação de Testes, onde a base da pirâmide (e o mais barato) são os testes unitários. Claro que não iremos desenvolver os testes unitários (mas se soubermos, nada contra), mas apoiaremos os desenvolvedores a criar uma gama de testes unitários que façam sentido para o negócio (e aqui aquele testador que adora testar limites, pode fazer aqui, e não na interface gráfica...)

Após seguimos pelos serviços, onde ainda sem interface gráfica conseguiremos testar a integração do sistema e, através de Fixtures ou BDD, viabilizar estes testes.
Por último, na automação, temos a interface gráfica. Esta mais cara e demorada. Mas é um ponto os testadores tradicionais começam por conhecerem ferramentas de automação e entenderem que é importante testar o que o usuário irá utilizar.

Mas não podemos somente falar em automação... em ágil também fazemos testes manuais, mas estes devem ser mais "inteligentes". Essa inteligência pode ser a utilização de uma técnica chamada SBT - Session Based Testing, por exemplo.

E como ficam os defeitos? Reportamos em uma ferramenta de bugtracker, faremos uma parada para todos os devs corrigirem defetos?
A resposta sempre é depende!
Mas vamos pensar em algo lógico: estamos trabalhando (falando) de agilidade, certo? O que é mais ágil: reportar um defeito em um ferramenta ou parar ao lado do desenvolvedor, mostrar o bugs e ajudá-lo a criar um teste automatizado para que aquilo não ocorra?

No final existe uma série de fatores de sucesso, mas o principal, sempre é COLABORACÃO!!!

quarta-feira, 10 de abril de 2013

Treinamento Selenium 01 e 02 de Junho

No mês de Junho: Automação de Testes Funcionais com Selenium à distância.

Data

01 e 02 de Junho

Horário

Dia 01, sábado - 09:00 às 18:00

Dia 02, domingo – 09:00 às 18:00

Investimento

550,00 para pagamentos até data 10 de Maio

650,00 após esta data

Forma de pagamento: cartão de crédito em até 12x, boleto ou transferência bancária

Local

Treinamento a distância. Será realizado no seu computador via Internet utilizando ferramenta de web-conferência.

Infra-Estrutura

Sistema Operacional: Windows ou MacOS (O GotoMeetting não suporta Linux)

Plugin para acesso ao GoToMeeting através do navegador (no dia do treinamento o participante receberá um link para acesso a sala de conferência)

Instrutor

Elias Nogueira

Possui MBA em Teste de Software e a certificação internacional de teste de software CSTE - Certified Software Tester, oferecida pela QAI Brasil. Atualmente é arquiteto de testes na InMetrics, consultor de automação de testes e instrutor pela Qualister e pela Iterasys. Trabalhou em projetos de engenharia de teste de qualidade de dados (Data Mining, Data Cleasing, Data Profiling, Noisy text analysis) e Georeferenciamento (Marketing de Precisão) e atualmente trabalha em projetos de automação de teste de software na InMetrics em diversos segmentos (bancário, varejo e cartões). Tem grande foco e conhecimento em ferramentas open source de automação de teste. É colaborador freqüente das listas de discussões sobre Teste de Software e posta suas experiências e dicas no blog Sem Bugs (http://sembugs.blogspot.com).

Carga Horária

16 horas

Inclui

Certificado em formato digital e acesso ao material em formato digital

Tópicos Abordados

Selenium IDE

- Record and Play

- JavaScript

- Alertas e Confirmações

- Popup’s

- Elementos HTML

- Expressões Regulares

- Ajax Loading

- Ajax AutoComplete

- Ajax Carrinho de Compras

- Combo Cidade/Estado

Selenium RC

- Executando scripts criados no Selenium IDE em diversos browsers com Selenium RC

WebDriver

- Interagindo com elemento HTML com Webdriver

- Esperas por requisições assíncronas (Ajax)

- Webdriver + JUnit

- Data Driven com Webdriver

- Automatizando para diversos browsers usando o Webdriver

Informações

treinamento@qualister.com.br

48 3285-5615

quinta-feira, 28 de fevereiro de 2013

Imagens de Windows x IE gratuitas (ótimo para testar sites no IE)

Você sabia que pode utilizar uma ferramenta gratuita da Microsoft para testar sua aplicação web em diferentes browsers e versões do Windows?

Existem uma pagina de downloas chamada Internet Explorer Application Compatibility VPC Image que lista uma seria de maquinas virtuais com a configuração de browser x sistema operacional, onde voce pode encontrar a seguinte combinação:

Windows XP + IE 6
Windows Vista + IE 7
Windows 7 + IE 8
Windows 7 + IE 9

Cada arquivo que você baixar (no formato .exe) irá pedir uma pasta para descompactação do arquivo .vhd (imagem do Virtual PC), onde basta você abrir o Virtual PC e selecionar o arquivo .vhd descompactado.
Mas atenção: leia o arquivo .txt contido na extração, pois o mesmo possui as senhas de acesso para a VM.

Com essas imagens você consegue criar um ecossistema de VMs com as principais versões do Internet Explorer que ainda são utilizadas em mercado.

Observação: para instalar o Virtual PC, caso você não tenha, e necessário ter um Windows original, pois o mesmo passa pelo processo de verificação do Windows ;-)

[1] Virtual PC: http://www.microsoft.com/windows/virtual-pc/
[2] Internet Explorer Application Compatibility VPC Image: http://www.microsoft.com/en-us/download/details.aspx?id=11575

segunda-feira, 25 de fevereiro de 2013

Como aprender sobre Selenium (de forma gratuita ou paga)

Olá pessoal!
Recebo quase todos os dias e-mails de profissionais da área perguntando como eles podem aprender sobre Selenium e onde podem encontrar materiais.

Este post se destina a isso: como aprender Selenium de uma forma "gratuita" ou não!
Quando eu falo Selenium, na verdade estou falando de WebDriver (apesar de existirem pessoas que querem aprender sobre o Selenium IDE e vou citar isso, o foco maior é em WebDriver)

Aprendendo Selenium de forma gratuita
Atualmente, até onde eu sei, não existe nenhum treinamento gratuito sobre Selenium.
O aprendizado gratuito pode se dar através de:

Leitura da documentação
Leitura e entendimento da API
Prática
Apresentações
Desafios Selenium

Leitura da documentação
Existem duas documentações padrão do Selenium:

Através do site http://seleniumhq.org: neste site você pode acessar a 'aba' Documentation e ler realmente a documentação. Há muita coisa boa lá e realmente te dá uma boa base inicial

Através do site http://selenium.googlecode.com: neste site há uma sessão Wiki onde você pode, por demanda ou necessidade, ler as páginas contidas neste Wiki. Eu dou ênfase as seguintes páginas que podem ser lidas na sequência:

O ideal é você ler todos os documentos contidos no Wiki, mas estes itens acima já irão lhe dar um overview sobre o WebDriver

Leitura e entendimento da API
Com o WebDriver é inevitável: temos que programar/desenvolver nossos testes utilizando alguma linguagem de programação!
Logo é um pré-requisito que você conheça, pelo menos, o básico da liguagem de programação de sua escolha e que também saiba como ler a API (documentação das ferramentas/plugins/frameoworks) implementados em uma determinada linguagem.

Podemos visualizar abaixo a lista das linguagens de programação formalmente suportadas com WebDriver e o link de cada API (documentação):

Prática!
Para aprendermos qualquer ferramenta não tem jeito: temos que praticar!
Logo a prática é um elemento fundamental do nosso aprendizado.
Você pode praticar em diversos sites web, mas aqui vai minha recomendação:

Começe a praticar em sites/aplicações simples
NUNCA tente praticar automatizando o login do Gmail, Yahoo! e outros...
Utilizar CMS ou lojas virtuais open source para praticar é uam boa. Você pode praticar num Joomla, Prestashop, por exemplo

Apresentações
Sempre é bom dar uma "Googleada" para encontrar apresentações ou links.
Eu recomendo dar uma olhada no SlideShare, site que contém uma gama de apresentações publicadas e diversas sobre Selenium.

Pesquisa por Selenium: http://www.slideshare.net/search/slideshow?searchfrom=header&q=selenium
Pesquisa por WebDriver: http://www.slideshare.net/search/slideshow?searchfrom=header&q=webdriver

Desafios Selenium
Foi uma iniciativa que eu criei em 2011 lançando um problema real, onde o mesmo deve ser automatizado com Selenium IDE.
Os desafios possuem a resolução explicada em vídeo, o que facilita o entendimento.
Por enquanto eu tenho somente 5 desafios e todos com respostas para o Selenium IDE, porém logo em breve voltarei a postar mais desafios em ambos os formatos: Selenium IDE e WebDriver!

Desafios Selenium: http://www.eliasnogueira.com/arquivos_blog/selenium/desafio/

Aprendendo Selenium de forma paga
Obviamente sempre temos alternativas pagas! Geralmente esta alternativa foca mais no que cada um precisa aprender e dependendo da forma que você escolher, um curso por exemplo, você conseguirá (ou não, pois depende de você) tirar um maior proveito e resolver problemas e dúvidas que você possa ter. O aprendizado pago pode ser:

Através de Cursos
Através de Livros

Atavés de Cursos
Existem dois treinamentos sobre WebDriver (um que cobre Selenium IDE que eu conheço), que serão listados abaixo:

Treinamento de Selenium (IDE, RC, WebDriver) do Elias Nogueira (eu)
Há algum tempo eu dou treinamento sobre Selenium.
Os treinamentos são no formato EAD síncrono, traduzindo, são treinamentos via videoconferência ao vivo. O aluno acessa um link onde vê a tela do instrutor e segue suas instruções.

Atualmente o curso é dividido em 4 módulos:

Selenium IDE Básico
Selenium IDE Avançado
WebDriver Básico
WebDriver Integrações

Todos os exercícios cobrem as principais dúvidas e interações que faremos na "vida real". Os exercicios resolvidos no Selenium IDE e WebDriver são disponibilizados, bem como uma apostila e certificado de participação.

Para saber mais sobre o treinamento acesse: http://sembugs.blogspot.com.br/p/curso-de-selenium.html

Treinamento de WebDriver (em inglês) do Alan Richardson (EvilTester)
Um cara chamado Alan Richardson, mais conhecido como EvilTester (seu blog) criou um treinamento sobre WebDriver no site Udemy.
O treinamento são video-aulas em inglês que mostram como trabalhar com o WebDriver em diversos pontos:

Navegação
Suporte dos testes com JUnit
Locators
Interações
RemoteWebdriver
CI

Link do treinamento: https://www.udemy.com/selenium-2-webdriver-basics-with-java/

Através de Livros

Existem livros muito bacanas sobre Selenium, mas infelizmente para alguns estes livros são em inglês (pra quem não consegue ler livros em inglês ainda fica o incentivo para aprender!)

Livro: Selenium Simplified

Este livro é do mesmo autor do curso do Udemy que eu coloquei acima: Alan Richardson. Este livro sobre a utilização do Selenium RC/WebDriver utilizando Java e JUnit.
É muito parecido com o próprio treinamento que o autor tem, mas os itens cobertos no livro possuem mais detalhes.

Link da página do livro: http://www.compendiumdev.co.uk/selenium/

Livro: Selenium Testing Tools Cookbook

Este livro mostra, além do básico de programação com WebDriver, problemas reais e como resolvê-los.
Também apresenta como fazer integrações de ferramentas de BDD e ATDD, como executar testes no Selenium Grid, como capturar evidências e como executar testes em browsers de dispositivos móveis (Android e iOS)

Link da página do livro: http://www.packtpub.com/recipes-to-master-selenium-2-testing-tools-cookbook/book

Livro: Selenium 2 Testing Tools

Este livro é de autoria de um dos commiters do Selenium: David Burns. Neste livro o autor aborda todos os conceitos básicos do WebDriver unidos a alguns Design Patters para ajudar o leitor a desenvolver melhor usando o WebDriver.

Link da página do livro: http://www.packtpub.com/selenium-2-testing-tools-beginners-guide/book

Espero que este post seja de grande ajuda aqueles que desejam iniciar o aprendizado do Selenium.
Qualquer dúvida ou sugestões de links, cursos e livros deixem um comentário neste post :-)

Abraços!

terça-feira, 5 de fevereiro de 2013

TDD - Test Driven Development para Testadores

Olá pessoal!
No dia 02/02/2013 eu tive o prazer de falar sobre TDD - Teste Driven Development no Campus Party Brasil 2013.

Nesta palestra abordei um conteúdo mais prático, que pode ser visto nos slides e também um exemplo guiado que está disponível no GitHub:
https://github.com/eliasnogueira/tdd-exemplo

Mais abaixo vou escrever os pontos mais importantes da apresentação.
Fica a dica para você:

Ler o post
Ver a apresentação
Ver o projeto no GitHub
Tentar executar o projeto do GitHub em casa.

Mas porque o Elias, um tester, deu palestra sobre TDD (que é de dev)?
Cada vez mais, na minha visão, o testador se faz um profissional cada vez mas técnico e polivalente (palavra bonita), mas que em poucas palavras quer dizer que o tester não precisa programar todo o dia usando TDD, mas precisa saber o que é como como utilizar essa técnica.

TDD - Test Driven Development from Elias Nogueira

Se software fossem carros... como poderíamos garantir que tudo funciona? Se pensarmos um pouco no processo de criação de um carro temos uma infinidade de peças que devem, além de ser criadas por si só, devem funcionar com outras peças, resultado ao final um carro totalmente utilizável.

Pense que você precisa "testar um carro"... e guarde esse pensamento com você por enquanto.

Mas quem testa? O desenvolvedor? Pelo que conhecemos de Teste de Software não!

No modelo que conhecemos o testador que executa esta atividade certo? Ele deve garantir que o sistema funciona depois que um ou mais funcionalidades foram desenvolvidas.

No modelo tradicional de desenvolvimento de software (cascata, e sim, eu apresentei um modelo cascata ao invés do RUP porque grande parte ainda desenvolve assim) temos as conhecidas fases do desenvolvimento, mas teste é a penúltima fase. Logo testar torna-se um processo que, além de oneroso, é muito caro!

Logo como garantir uma melhor entrega para testes com uma maior qualidade?

Uma técnica conhecida (deveria ser bem mais conhecida) e muito negligenciada por diversos fatores é o TDD - Test Driven Development, ou Desenvolvimento Orientado a Teste.

Com ele o próprio desenvolvedor (e seria muito legal se adicionássemos: "com a ajuda do testador") cria testes de um jeito diferente de programar e garantir que o que ele está desenvolvendo terá uma melhor qualidade.

Agora é interessante dar uma olhada na sequencia de slides que explica como desenvolver um código para converter os símbolos do número romano em símbolos.

Depois vale muito a pena olhar o projeto no GitHub e tentar segui-lo em sua máquina local: https://github.com/eliasnogueira/tdd-exemplo

O processo de desenvolvimento de uma funcionalidade ou aplicativo utilizando TDD é bem simples: primeiro criamos um teste que não passa, depois testamos refatorá-lo para que ele passe sempre, obviamente, penando na melhor e mais simples implementação naquele momento.

Se você notar todos os passos do projeto descrito no GitHub são guiados através de TDD.

E, obviamente, existem muitos benefícios em adotar esta técnica, onde um dos maiores benefícios são a simplicidade, feedback rápido e segurança.

Conseguimos ter uma bateria de testes de unidade criados sem grande esforço e já cobrindo boa parte da funcionalidade.

Assim o novo código criado já nasce testado!

Utilizando TDD conseguimos facilmente mostrar o ganho em tempo, onde desde o inicio o código sai testado e pronto para ser alterado (refatorado) ou usado por outro método/classe.

Se compararmos com o modelo tradicional, teríamos apenas testes no final do desenvolvimento de todo o código.

E, apenas para alinhar, TDD não é teste! TDD é uma técnica de design de código que ajuda, e muito o testa da aplicação/funcionalidade.

Embora o termo "teste" seja utilizado ao usar TDD estamos dando muito mais atenção ao design da classe/funcionalidade do que realmente teste.

A palestra possui vários insights e o exemplo dos números romanos retirados do livro "TDD - Teste Driven Development: Teste e Design no Mundo Real" do autor Maurício Aniche, editora Casa do Código
http://www.casadocodigo.com.br/products/livro-tdd

Abraços!

terça-feira, 29 de janeiro de 2013

Treinamento Selenium a Distancia em Fevereiro 2013

Olá pessoal!

Na data abaixo estarei dando um treinamento de Selenium a distância que vai abordar um pouco de cada ferramenta com abordagem totalmente pratica!