ThoughtWorks Brasil Tech Radar – O Test Radar

What is hot… and what is not in software testing?

Essa últimas duas semanas foram completamente insanas na ThoughtWorks Brasil. Recebemos mais de quarenta visitantes de outros países e tivemos a oportunidade de conversar sobre dezenas de aspectos tanto da ThoughtWorks, quanto sobre justiça social e sobre o futuro de tecnologias.

Com a visita do Mike Mason (Head of Technology, Americas da ThoughtWorks) nós fizemos um exercício bem interessante, como se fosse um mini Tech Radar dentro do nosso escritório. Achei muito bom poder discutir e argumentar com o pessoal, e claro, expor o que um QA julga ser interessante ou não nessa sopa de letrinhas composta por ferramentas, técnicas, plataformas e etc.

Para quem não conhece, o ThoughtWorks Tech Radar é um conhecido jornal anual de tecnologia desenvolvido por um grupo sênior de tecnologistas chamado ThoughtWorks Technology Advisory Board que classifica diversas tecnologias, ferramentas, plataformas, técnicas e linguagens de programação em quatro níveis que são:

  • Adopt (Use) – Acreditamos fortemente que esses itens estão maduros e são confiáveis o suficiente para serem usados em projetos, e de fato são usados em nossos projetos. Acreditamos que a indústria deveria optar por essas soluções ao invés das demais citadas no Tech Radar.
  • Trial (Experimente) – Esses itens parecem confiáveis e podem ser usados em projetos que possam assumir um certo nível de risco.
  • Assess (Explore) – Experimente esses itens buscando o entendimento e como tirar proveito deles, mas eles ainda representam um grande risco para o projeto.
  • Hold (Melhor esperar) – Tenha cautela. Esse item pode ser muito novo para ser usado em projetos, pode ser questionável do ponto de vista técnico ou pode não ser produtivo se comparado com outros itens no mercado.

Se quiser saber mais sobre o Tech Radar pode acessar a página da ThoughtWorks sobre o assunto: http://www.thoughtworks.com/radar

O formato do nosso mini Tech Radar foi baseado em quatro passos:

  1. Brainstorm sobre diversas ferramentas que usamos no dia a dia, que ouvimos falar muito no mercado ou na comunidade, que gostaríamos de saber se alguém usa e que tivemos experiência em projetos, sejam ele open source  ou produtos.
  2. O segundo passo era um tempo para que cada um falasse um pouco sobre os itens que ele adicionou no quadro, de forma bem superficial, só para que todos conhecessem ou lembrassem desse item.
  3. Depois disso cada um pode colocar os seus itens no que eles julgavam que deveriam estar.
  4. Em um quarto passo, o grupo observava o quadro e questionava cada um dos itens lá colocados, e acredite…, isso deu muito barulho.
Quadro com itens alinhados após a discussão (Clique para ampliar)
Quadro com itens alinhados após a discussão (Clique para ampliar)

Eu chamo esse post de Test Radar porque vou focar nos itens mais importantes para QAs e Testers no meu ponto de vista. Claro que o quadro possui plataformas e linguagens de programação que são parte do nosso dia a dia e influenciam diretamente na nossa produtividade e na qualidade dos nossos projetos, mas por serem itens mais relacionados a desenvolvedores, vou esperar que algum developer presente nesse exercício escreva o ponto de vista dev e incluo aqui.

É importante ressaltar que esse post são as minhas notas e opiniões sobre um exercício inspirado pelo ThoughtWorks Tech Radar e representam somente a minha percepção sobre a discussão:)

Do ponto de vista de QA, tivemos os seguintes itens:

  • Cucumber – Ferramenta de BDD (Behavior-Driven Development)
  • Specification by Example – Técnica de desenvolvimento focado em documentação composta unicamente por testes automatizados
  • Selenium IDE – Plugin do Firefox para record and replay baseado no Selenium
  • Selenium 2 ou Selenium Webdriver – Ferramenta usada para desenvolvimento de testes de interface em javascript que pode ser usada para x-browser testing
  • Unit Test over Selenium – Ao invés de usar selenium ou uma ferramenta para UI testing, usar somente unit testing.
  • Sikuli – Ferramenta de testes automatizados baseada em imagens
  • JMeter – Ferramenta open source para testes de performance
  • Page-Object Model – Modelo de reutilização de elementos e páginas que separa testes automatizados em comportamento e páginas
  • Business-Oriented Model – Modelo que mescla BDD e Page-Object Model
  • UI/UX Testing – Testes Manuais e automatizados na interface.
  • Lean Startup – Técnica idealizada para testar um pequeno produto para feedback rápido do conceito do produto.
  • Jasmine – BDD para Javascript
  • Watir Webdriver – framework de testes semelhante ao selenium com interface mais simples

Nosso Mini Tech Radar teve como resultado o seguinte cenário:

Adopt:

Selenium Webdriver (Ferramenta) – O selenium é amplamente usado no mercado, é a principal ferramenta de teste de software, é usado em dezenas de projetos da ThoughtWorks e em outras empresas como Google, Yahoo!, Rackspace, Saucelabs etc., é portável e adaptável para diferentes linguagens e plataformas entre outras vantagens. BTW, Watir webdriver e algumas ferramentas proprietárias também são portáveis, algumas até mais simples de usar do que o Selenium, então porque ele foi considerado como adopt? Depois de alguns minutos de discussão, chegamos ao consenso que nenhuma outra ferramenta se mostra tão segura para x-browser testing quanto o Selenium webdriver, o que junto de todas as outras vantagens e quase uma década de melhorias dessa ferramenta open source nos mostrou que não seria justo considera-la em um nível diferente de adopt.

http://seleniumhq.org/projects/webdriver/ 

JMeter (Ferramenta) – Ferramenta open source amplamente usada para testes de carga e stress. Apesar de não ser uma ferramenta muito prática, por exigir certo conhecimento em requisições e respostas http, redes e shell script, o JMeter ainda é provavelmente a melhor ferramenta para realização de testes de performance em projetos de desenvolvimento de software. Mesmo com esses problemas, o JMeter é muito confiável, tendo sido usado em diversos projetos por vários ThoughtWorkers e por ser simples de usar uma vez que esses requisitos sejam superados. Além disso, é uma ferramenta em constante evolução e quase sem concorrentes, já que é uma ferramenta que suporta diferentes plataformas, tecnologias, possui dezenas de plugins e pode ser facilmente integrada a build pipelines, ao contrario de outras ferramentas proprietárias como LoadRunner e IBM RPT por exemplo.

http://jmeter.apache.org/

Page-Object Model (Técnica) – Outra grande discussão que terminou com final feliz no meu ponto de vista. O page-object é um modelo que possui alguns problemas, entre eles por ser usado para teste de UI e não ser focado, por natureza, em um modelo de descrição de testes do ponto de negócio, ou seja, se não implementamos uma camada de BDD por cima do Page-Objects, ele continua sendo teste de UI sem legibilidade para um cliente, o que vai em desacordo com algumas premissas que temos no quadrante de Business-Facing tests, que dizem que temos que ter testes de UI legíveis para uma pessoa de negócio e que de fato representem um pedaço dele. Além disso quando o Page Object Model é levado ao extremo, os testes podem ser focados em comportamentos de UI e não em ações do usuário, por exemplo quando usamos o teste como “Vá para a Home Page, Preencha o campo de pesquisa, Clique no botão de Busca” ao invés de “Busque or <texto>”.Embora o Page object Model não atenda a esses requisitos por natureza, chegamos ao consenso que ele tem o principal propósito de tornar o teste de UI mais fácil de manter, aliado a uma boa ferramenta de BDD pode ser trazer um grande resultado, tanto do ponto de vista de manutentabilidade quanto do ponto de vista de testes focados no negócio. O Page Object Model é um modelo fácil de aprender e de manter e muitos dos nossos projetos usam ou usaram em certo ponto esse modelo e ele tem se mostrado bem  produtivo, tanto quando precisamos de uma camada extra para BAs e POs quando usamos apenas para QAs e Devs.

http://code.google.com/p/selenium/wiki/PageObjects

UI/UX/UA Testing (Técnica) – Sabemos o quanto testes manuais podem ser cansativos, chatos, ineficientes de um ponto de vista de longo prazo e tudo mais que reclamamos sobre esses testes, mas também sabemos que eles são necessários na maioria dos projetos, e muitas vezes são um fator de sucesso. O teste exploratório por exemplo, quando planejado e executado de forma correta pode ajudar na identificação de bugs, de novos cenários para se automatizar, de novas histórias para serem desenvolvidas etc. Além disso esses testes ainda são os mais eficientes para encontrar defeitos de UX e são os mais confiáveis para simular um teste de usuário da forma mais real. Esses testes devem ser mantidos mesmo em projetos de automação completa, como em Specification by Example por exemplo.

http://www.amazon.com/Exploratory-Software-Testing-Tricks-Techniques/dp/0321636414
http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468

Trial:

Watir Webdriver (Ferramenta) – Sem dúvida uma ferramenta fantástica. Por ter nascido com Ruby ao invés de java, ele herdou uma das características mais charmosas do ruby, a simplicidade, assim como o selenium incorporou a verbosidade do java, sua língua mãe. O watir usa por trás o mesmo core do Selenium, baseado no webdriver que funciona através de drivers nativos dos Browsers. Por esse motivo, muitas pessoas acreditam que ele é na verdade uma DSL para selenium. Ele é um pouco mais lento do que o selenium webdriver para identificar elementos, mas os dois motivos reais que levaram o SE a ser uma ferramenta adopt e o watir permanecer como quadjuvante foram a multilinguagem e a facilidade para testar x-browser. O watir, assim como o selenium, possui drivers que executam javascript em todos os browsers mais usados, mas não possui um mecanismo parecido com o selenium grid, que permite a configuração de forma simples de testes em vários browsers.

http://watirwebdriver.com/
http://watir.com/
http://watirmelon.com/ 

Jasmine (Ferramenta) – Uma ferramenta que suporta BDD para javascritp em headless browser, em outras palavras, testes muito mais rápidos do que selenium e tão bem descritos quanto RSpec. Olhando de fora parece uma ferramenta que deveria ser usada em todos os projetos web, mas ela ainda não é tão confiável quanto selenium ou outras ferramentas que navegam na interface. Simplesmente garantir que o javascript está funcionando pode até demonstrar que os requisitos foram atendidos, mas ainda não garante com precisão necessária para a maioria dos projetos, que um usuário consegue executar aquele cenário e muito menos que ele funciona em diferentes browsers. Jasmine é recomendadíssimo para projetos web em termos de testes de unidade de javascript. Para qualquer outro propósito (como testes de aceitação) é quase impraticável.

http://pivotal.github.com/jasmine/

Specification by Example (Técnica) – Na minha opinião, essa técnica que consiste em manter documentação viva do projeto durante todo o ciclo de vida, com automação, integração continua e proximidade do cliente levados quase ao extremo, deveria estar no adopt :p, mas tenho que concordar que SbE ainda é algo novo, que ainda não conhecemos suas limitações e claro, o mercado ainda não possui mão de obra suficiente para estabelecer uma zona de conforto e segurança em projetos com essa abordagem. De qualquer forma, projetos que possam absorve um pouco de risco podem explorar essa técnica e aos poucos vamos entender os problemas que o SbE possui e como podemos supera-los ou dribla-los. Mas é importante ressaltar que cada vez mais estamos caminhando para implantar esse tipo de documentação em projetos de desenvolvimento, principalmente ágil, onde a documentação deve ser evoluída no dia a dia do projeto, por isso é algo fortemente recomendado como material de estudo.

http://specificationbyexample.com/
http://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084

Cucumber (Ferramenta) – Ferramenta que implementa BDD muito conhecida, usada, adorada e odiada nas comunidades ruby e open source. Ela é adorada pois cria uma interface de comunicação muito clara entre os profissionais de software e as pessoas de negócio, tornando toda a aplicação legível do ponto de vista de negócio e ao mesmo tempo, criando um conjunto de testes de regressão que ajudam a garantir que o que foi aceito pelo PO continue funcionando exatamente como foi aceito. Ela é odiada pois com sua popularidade, muitos projetos passaram a adotar esse framework sem necessidade, ou seja, criou-se a falsa ilusão que todos os projetos deveriam implementa-la, mesmo aqueles em que o PO e/ou BAs não veem valor em escrever cenários e executa-los ao final da iteração. Além disso, existe também em algumas comunidades, principalmente a de QA, que e que BDD é Cucumber ou Cucumber style e que outras ferramentas com approach diferente como RSpec, Spinach e Jasmine por exemplo continuam sendo unit test. Picuinhas a parte, o Cucumber se mostra uma ferramenta estável e simples de se escrever, mas pode tornar os testes desorganizados e difíceis de manter. Esses concerns sobre o Cucumber devem ser levados em consideração, principalmente quando a ferramenta for nova e não existirem motivações de negócio (PO e BAs devem usar) envolvidas na escolha da ferramenta, pois outras formas de documentação do código fonte como RSpec podem trazer menos handicap para o projeto.

http://cukes.info/
http://pragprog.com/book/hwcuc/the-cucumber-book

Assess:

Lean Startup (Técnica) – Implementar o mínimo possível para saber se a ideia é o que queremos e então investir mais no como a ideia será desenvolvida é um dos conceitos da moda, introduzido por Eric Ries. A ideia é fantástica, funciona e inclusive foi uma das referências (se não a principal delas) tema de uma palestra no GTAC (Google Test Automation Conference) do ano passado, a famosa e discutida palestra do Savoia Test is Dead. Porem a realidade do mercado ainda não permite que implementemos algo como o Lean Startup em projetos de software, uma vez que conceitos como MVP (Minimum Valuable Product) ainda são mal entendidos e questionados quanto a sua efetividade. Embora ainda não seja algo que deva ser adotado em projetos, mesmo os que podem assumir algum risco, definitivamente é algo que deve ser entendido e estudado, e quem sabe até aplicado em partes.

http://theleanstartup.com/
http://www.amazon.com/The-Lean-Startup-Entrepreneurs-Continuous/dp/0307887898

Hold:

Sikuli (Ferramenta) – Essa ferramenta, relativamente nova, vem sendo muito falada em listas brasileiras e internacionais. Ela foi desenvolvida pelo MIT (Massachusetts Institute of Technology) com o propósito de automatizar testes em qualquer tecnologia que use uma GUI (Graphical User Interface), ou seja, qualquer tela. A ferramenta funciona bem e a ideia é simplesmente genial, mas ambas ainda estão muito verdes para serem usadas de forma comercial. A ideia ainda não se propõe a resolver muitos problemas de escalabilidade e mesmo o conceito ainda não foi bem definido e a ferramenta também oferece poucos recursos para escrever testes e principalmente para manter testes. Muitas da técnicas que usamos no dia a dia mesmo sem perceber, como o Page-Object Model que comentamos ou DDT (Data-Driven Testing) não são suportadas na ferramenta. Por ser nova, e ter praticamente só o MVP (Minimum Value Product) disponível, qualquer project que dependa dessa ferramenta corre um sério risco de não poder evoluir os testes depois que uma nova versão for disponível, além de, frequentemente, se deparar com algum bug ou limitação.

http://sikuli.org/

Selenium IDE (Ferramenta) – Esse item foi uma das decisões mais simples durante esse exercício. Se o Tech Radar tivesse uma opção de avoid, provavelmente esse seria um dos itens a ocupar uma das primeiras opções. O Selenium se mostra uma ferramenta portável, multi-browser, fácil de manter, amplamente utilizada e estável. Exatamente em contramão encontra-se esse filho feio. O Selenium IDE é um plugin originalmente desenvolvido para o Firefox que utiliza um pedaço da engine do selenium framework para execução de comando javascript em páginas web. O IDE é muito usado principalmente por QAs por sua simplicidade em gravar e reexecutar testes automatizados, o problema é que essa ferramenta cria código extremamente vinculado ao comportamento, com dezenas de repetições, fortemente vinculada a dados, sem nenhum reuso, totalmente estrutural, de difícil manutenção e cheia de acoplamento. Em consenso chegamos a conclusão que essa ferramenta deve ser evitada principalmente pela quantidade e variedade de ferramentas que são mais adequadas para o desenvolvimento de testes automatizados.

http://seleniumhq.org/projects/ide/

Unit Test over UI testing (Selenium) (Técnica) – Na verdade a técnica seria o uso de testes de unidade para cobrir, além do design do código, também toda a parte de aceitação do usuário. Esses testes são muito mais rápidos de executar e muito mais simples de desenvolver e manter uma vez que é comum que existam antes do código de produção como previsto pelo TDD. O problema é ainda não existem frameworks de testes de unidade que sejam seguros o suficiente para que possamos abandonar os nossos UAT que navegam pela aplicação, portanto essa técnica deve ser evitada por enquanto e sempre que possível, os testes devem ser classificados quanto ao seu objetivo. Se for um teste de usuário, é melhor que seja executado como um usuário faz, navegando no produto final e não validando pedaços de código que o usuário não faz ideia de como funciona. Embora o uso de testes de unidade no lugar de testes funcionais automatizados tenha sido classificado como hold, existem formas de usá-los com sabedoria e responsabilidade para tirar um bom proveito deles. Uma forma interessante é manter testes de unidade para cobrir cenários secundários, como validações de campos, validações de mensagens de erro, tamanho de campos, etc., todos esses casos em que um teste usando Selenium por exemplo, tomaria muito tempo e agregaria o mesmo valor.

Discrepancias entre o ThoughtWorks Tech Radar e esse post

Existem algumas diferenças entre esse post e sua fonte de inspiração, o ThoughtWorks Tech Radar. Essas diferenças podem ser resultado de um conjunto de fatores, entre eles o cenário brasileiro foi enfatizado nesse exercício, a experiência dos profissionais, o formato e tempo gasto no exercício que foram muito inferiores e a minha percepção do que foi visto durante o exercício assim como a forma com que eu estou descrevendo. Portanto, entre a visão desse post e a do ThoughtWorks Tech Radar, procure sempre se guiar pela original. Além disso, esse post foi criado com a intenção de compartilhar as poucas horas que discutimos durante esse exercício e como foi realizado, para que outras pessoas e empresas possam fazer o mesmo.

Leve esse tipo de discussão para a sua empresa, simule o seu próprio Tech Radar. Proponha aos seus colegas de trabalho esse exercício e descubra o que as pessoas que trabalha com você acredita ser o melhor do ponto de vista técnico. Tudo o que você precisa é um quadro branco, alguns post-its e pouco menos de duas horas. Desse exercício podem sair ideias para melhorar projetos, ferramentas para estudar mais, feedback de novidades do mercado e até blog posts :)

Agradecimento especial para Mozair do Carmo e Carlos Villela pela revisão do post e notas :)


Camilo Ribeiro

Test Engineer at Klarna
Desenvolvedor, testador e agilista desde 2005, atualmente trabalhando na Suécia.

2 thoughts on “ThoughtWorks Brasil Tech Radar – O Test Radar

  1. Primeiramente parabens pelo post e por compartilhar este tipo de informação bem valiosa para nós! :)
    Tenho algumas dúvidas e pontos… rs

    Sobre Page Object Model
    Tu não acha que seria “redundante” ter uma camada com BDD e outra com PO (Page Objects)?
    Entendia tua peocupação na descrição de cada PO, onde o tester pode deixa-la realmente passo-a-passo ou deixa-la como um exemplo, mas isso vai da maturidade do testador em criar esta pratica (baseado em contexto)

    Sobre UI/UX/UA Testing
    Quando estive na ThoughtWorks Brasil ano passado me impressionou o fato de nenhum dos QAs que eu conversei conhecerem sobre SBT – Session Based Testign utilizado em Testes Exploratórios.
    Vocês agora fazem sessões de SBT?

    Sobre Watir Webdriver
    Ele é utilizado ai na TWBR mesmo tendo um bind/gem do Webdriver para Ruby?

    Sobre Specification by Example
    Tem um trecho que tu fala “Mas é importante ressaltar que cada vez mais estamos caminhando para implantar esse tipo de documentação em projetos de desenvolvimento, principalmente ágil…” deu a entender que vocês não tem/executam somente projetos guiados por principios ágeis. Confere? :P

    Tu tens agumas referêcias sobre o termo “Unit Test over UI Testing (Selenium)?
    Sinceramente ainda não tinha visto esta definição :-)

  2. Olá Elias :)

    Obrigado pelo comentário :D

    Seguem respostas:

    Sobre Page Object Model
    Tu não acha que seria “redundante” ter uma camada com BDD e outra com PO (Page Objects)?
    Entendia tua preocupação na descrição de cada PO, onde o tester pode deixa-la realmente passo-a-passo ou deixa-la como um exemplo, mas isso vai da maturidade do testador em criar esta pratica (baseado em contexto)

    Nem um pouco redundante. Os conceitos e propósitos das duas técnicas são completamente distintos e a implementação também é totalmente diferente.

    Page-Object Model está relacionado a legibilidade, manutentabilidade e principalmente reuso de testes, enquanto o BDD existe para focar o desenvolvimento no negócio. O DBB pode sim ajudar no reuso se usado de uma forma menos purista (tipo os antigos web_steps do Cucumber), mas quase sempre peca na manutentabilidade por exemplo, enquanto o page-object não ajuda em nada no negócio, é puramente técnico.

    Uma implementação de page object deve conter uma page e pode conter um flow que usa a page para escrever testes no modelo “script” que todos conhecemos bem, ou podemos implementar um Cucumber e chamar a page direto nos step definitions.

    Abaixo um exemplo de cada:

    Puro Page Object Model:
    flow.rb
    require "rubygems"
    require "pages"
    module SearchTestHelper
    def classic_search(configuration,text_to_search, expected_result)
    home = Search::HomePage.new(configuration)
    home.visit
    home.input_search(text_to_search)
    home.run_search
    result = Search::ResultPage.new(home.browser)
    assert result.should_have_text_present(expected_result)
    (home.browser).close
    end
    end

    =====
    Extraído de: http://www.bugbang.com.br/?p=2108

    Exemplo com Cucumber (BDD):

    feature.feature

    Scenario
    Feature: Search
    As a Bug Bang reader
    I want to navigate on the basic scenarios

    Scenario: Basic search for common users
    Given I am on The Bug Bang Theory home page
    When I write “Camilo Ribeiro” on search field
    And ask to search
    Then I should see the follow results:
    | BugBang Responde I: Horas x Qualidade (A eterna briga das empresas) |
    | The Bugbang Theory |
    | Penso, logo automatizo |
    | The Bug Bang Theory 2.0 – Agile and Technical Testing Rocks! |
    ========
    steps.rb

    Dir[File.dirname(__FILE__) + "/../../pages/*.rb"].each do |file|
    require file
    end

    Given /^I am on The Bug Bang Theory home page$/ do
    @home = BugBang::HomePage.new
    end

    When /^I write "(.*?)" on search field$/ do |search_text|
    @home.search_field_fill_with(search_text)
    end

    When /^ask to search$/ do
    @home.search_button_click
    end

    Then /^I should see the follow results:$/ do |results|
    results.hashes.each do |text|
    @home.search text.to_s
    end
    @home.close
    end

    ========
    Extraído de: https://github.com/camiloribeiro/cello

    Os exemplos ainda estão “pobres”, mas acho que da pra perceber que em um dos casos é preciso ser um QA/dev para definir os testes e a fragmentação ainda fica muito mais focada na parte técnica e no bom senso do que no negócio. Já o segundo exemplo implementa o mesmo page object mas agora, ao invés de um arquivo cheio de código, temos o step definition onde cada pedaço de negócio implementa os steps usando o page. Além disso, o segundo pode ser apresentado em um Build demonstrando o que está falhando, o que está pendente e o que está passando do ponto de vista funcional e não que existe “alguma coisa” que não está passando. Dei exemplo do Cucumber, mas isso pode ser feito com RSpec, Spinach, JBehave ou qualquer outra ferramenta que implemente BDD.

    Acho que as duas implementações tem espaço, mas gosto muito de ver testes como requisitos e por isso estou tentando facilitar isso no Cello :)

    Espero ter sido claro, mas realmente é uma área meio nebulosa e muita gente tem essa dúvida.

    Sobre UI/UX/UA Testing
    Quando estive na ThoughtWorks Brasil ano passado me impressionou o fato de nenhum dos QAs que eu conversei conhecerem sobre SBT – Session Based Testign utilizado em Testes Exploratórios.
    Vocês agora fazem sessões de SBT?

    Estou aqui a quase um ano e já vi algumas vezes, mas não diria que é uma prática, ainda porque nosso teste é muito mais preventivo do que reativo (a maior parte do tempo queremos evitar defeitos e não encontrar defeitos). Mas sim, como consultores sabemos identificar os momentos em que uma abordagem é mais interessante do que outra e em alguns casos com limitação de tempo, o velho session based testing pode ser útil.

    Quanto aos qas que conversaram contigo não reconhecerem a técnica pelo nome, acho que seja normal, dado que sbt é uma técnica relativamente antiga, vinculada a execução manual de testes e em contextos onde Specification by Example e Continuous Delivery são implementados ela não seja uma técnica produtiva.

    Pra quem não sabe, Session Based Testing é nada mais do que um teste exploratório com time box predefinida e com alguns facilitadores, como listas para colocar defeitos, listas para colocar dúvidas, listas para descrever os testes etc . Lembrando que todo teste exploratório tem planejamento anteriormente :) http://en.wikipedia.org/wiki/Session-based_testing

    Sobre Watir Webdriver
    Ele é utilizado ai na TWBR mesmo tendo um bind/gem do Webdriver para Ruby?

    Yep, inclusive um dos frameworks de page object mais interessantes para ruby (o Taza ) usa o watir-webdriver como base e foi criado por TWers. Além disso, o Watir Page Helper também foi desenvolvido por outro TWer.

    Sobre Specification by Example
    Tem um trecho que tu fala “Mas é importante ressaltar que cada vez mais estamos caminhando para implantar esse tipo de documentação em projetos de desenvolvimento, principalmente ágil…” deu a entender que vocês não tem/executam somente projetos guiados por princípios ágeis. Confere? :P

    Nesse ponto eu queria falar nós, como mercado, não como ThoughtWorks, estamos adotando documentação executável cada vez mais, começando com um build, depois um deploy automatizado, algumas bdd features etc. Mas respondendo a sua pergunta, o nosso core é entregar valor para o cliente, o que temos alcançado com louvor usando ágil e continuous delivery :)

    Tu tens agumas referêcias sobre o termo “Unit Test over UI Testing (Selenium)?
    Sinceramente ainda não tinha visto esta definição :-)

    Nops. É algo bem falado e visto e conhecido na comunidade open source e no github, mas ao mesmo tempo não tem um nome ou referências em livros, blogs etc. Basicamente é usar unit tests frameworks como JUnit para fazer testes que normalmente usamos selenium, watir entre outros. Ainda não inventaram uma buzzword pra quem gosta de buzzwords.

    Obrigado novamente e abraços :)

Leave a Reply