Por que alguns programadores não gostam de escrever testes automatizados?

Quebrar um paradigma de formação não é difícil, mas não é impossível.

Como tratamos de assuntos ligados as metodologias ágeis, vou abranger os testes automatizados e o que o mesmo poderá beneficiar o programador.

Os teste automatizados são uma maneira de garantir a qualidade de código, sendo assim, cliente e programadores ganham. O cliente vai ganhar um produto com qualidade melhor e o programador terá um aliado que são os testes automatizados para garantir que seu código tem qualidade.

Testes automatizados contribuem para princípios ágeis com software funcionando, adaptação a mudança, colaboração com o cliente e indivíduos em interações.

Problemas sem testes automatizados:

  • Muito tempo na depuração;
  • Erros encontrados tardiamente;
  • Difícil repetir testes;
  • Demorado;
  • Cansativo;
  • Executado poucas vezes.

Benefícios dos testes automatizados:

  • Segurança para mudanças de código e externa;
  • Aumento o tempo de vida útil do software;
  • Testes executados a qualquer momento;
  • Ajuda a encontrar erros;
  • Aumenta a velocidade de programação.

E como deve ser código do teste?

O código do teste merecem os mesmos cuidados que o código do sistema.

O código do teste sofre manutenção e também pode ter erros, portanto deve ser legível e simples.

Tipos de testes

O tipo de teste que o programador geralmente faz na metodologia ágil são os testes de unidade, que possuem as seguintes características:

  • Encontra muitos erros;
  • Tipo focando na funcionalidade(caixa-branca).

O demais testes são:

  • Aceitação;
  • Interface  do usuário;
  • Mutação;
  • Desempenho;
  • Estresse;
  • Segurança;
  • Integração.

Os demais testes o programador pode até fazer, mas necessita-se de um analista de teste, pessoal de infraestrutura ou arquiteto, conforme o teste e experiência requerida. Também existem diversos softwares (frameworks) para os demais testes, sendo um exemplo o JUnit e outros para testes de unidade.

Colegas programadores, com os testes automatizados você somente tem a ganhar na execução do seu trabalho e na formação profissional. Tendo uma visão focada nos negócios, além de tecnologias.

Qualquer funcionalidade que não possui testes automatizados simplesmente não existe.

Kent Beck

Os Melhores Podcasts de Tecnologia para Desenvolvedores

Post excelente escrito pelo André Faria Gomes. Muito bom mesmo! Podcasts sem dúvida são um dos meios mais indicados para adquirir conhecimento em tecnologia, ainda mais quando você está antenado no que Martin Fowler, Kent Beck, Rod Johnson entre outros estão falando. Retirado do andrefaria.com.

Um dos maiores problemas da sociedade moderna é a dificuldade de locomoção diária, a maioria das pessoas passa horas em seus carros, ou em meios de transporte públicos para irem de lugar a outro. Há alguns anos atrás quando morava na zona norte de São Paulo e trabalha na zona sul, essa era minha realidade. Uma vez que naquela época passar por isso era inevitável procurei formas de fazer com esse tempo pudesse de alguma forma torna-se produtivo, foi então que comecei a ouvir à podcasts.

iPod FM radio remote por dan taylor
iPod FM radio remote por dan taylor

De acordo com a Wikipedia, Podcasting é uma forma de publicação de arquivos de mídia digital (áudio, vídeo, foto, etc.) pela Internet, através de um feed RSS, que permite aos utilizadores acompanhar a sua atualização. Assim, é possível o acompanhamento e/ou download automático do conteúdo de um podcast.

Neste post apresentarei os podcasts aos quais escuto e os episódios principais para que você ouça. Sugiro que você utilize o iTunes para inscrever-se nos podcasts e sincronizar com seu iPod.

Desenvolvimento Ágil

por pcalcado
por pcalcado

Podcast da ImproveIt

por Vinícius Teles
http://improveit.com.br/podcast
Português

AgilCast

Por AgilCoop
http://agilcoop.incubadora.fapesp.br/portal/agilcast
Português

Agile Toolkit Podcast
http://agiletoolkit.libsyn.com
Inglês

ThoughtWorks Podcast

http://www.thoughtworks.com/what-we-say/podcasts.html
Inglês

Open Source

FLOSS Weekly

por Leo Laport, Jono Bacon e Randal Schwartz
Inglês

Java

HorecaExpo - Java por bramloquet
HorecaExpo – Java por bramloquet

JavaPosse

Por Tor Norbye, Carl Quinn, Dick Wall e Joe Nuxoll
Inglês
http://www.javaposse.com

Java Technology Insider

Inglês
http://www.javaworld.com/podcasts/jtech

Grails Podcast

Por Glen Smith e Sven Haiges
http://grailspodcast.com

Ruby

Ruby on Rails por Andrew*
Ruby on Rails por Andrew*

Rails Envy

Por Jason Seifer e Gregg Pollack
Inglês
http://railsenvy.com

Rails Podcast

por Geoffrey Grosenbach
Inglês
http://podcast.rubyonrails.com/

Rubiverse Podcast

Por Mike Moore
Ingles
http://rubiverse.com

JavaScript

jQuery Podcast

Português
http://blog.jquery.com/2009/11/13/announcing-the-official-jquery-podcast/

Gadgets

GeekBrief TV

por Cali Lewis
Inglês
http://www.geekbrief.tv

Software

Desk por Guillermo Esteves
Desk por Guillermo Esteves

Pragmatic Podcasts

por Pragmatic Bookshelf
Inglês
http://www.pragprog.com/podcasts

Software Engineering Radio

por Software Engineering Radio
http://www.se-radio.net
Inglês

Elegant Code

por Elegant Code Community
http://elegantcode.com
Inglês

Google Developer Podcast

http://code.google.com/p/google-developer-podcast/downloads/list
Inglês

Hearding Code

http://herdingcode.com
Inglês

Tecnologia

IT Conversations

http://itc.conversationsnetwork.org
Inglês

net@Night

por Amber MacArthur e Leo Laport
http://www.twit.tv/natn

Twit – This Week in Tech

por  Leo Laporte, Jeff Jarvis, Baratunde Thurston, e John C. Dvorak
http://www.twit.tv/twit

MacBreak Weekly

por Leo Laporte, Don McAllister, Paul Kent, and Andy Ihnatko
http://www.twit.tv/mbw

This Week in Google

por Leo Laporte, Gina Trapani, Jeff Jarvis e Mary Hodder
http://www.twit.tv/twig

SitePoint Podcast

inglês
http://www.sitepoint.com/podcast

Empreendedorismo e Negócios

37 Signals Podcast

por 37 Signals
Inglês
http://37signals.com/podcast

Max Gehringer (CBN)

por Max Gehringer
Português
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

Mundo Corporativo (CBN)

por Heródoto Barbeiro
Português em Áudio
http://cbn.globoradio.globo.com/servicos/podcast/NOME.htm

The Startup Success Podcast

http://startuppodcast.wordpress.com
Inglês

TED Talks

por TED Talks
Inglês
http://www.ted.com

Revista Software Test & Performance Magazine – Agosto/2009

Caros colegas, Segue abaixo o link para a edição da revista Software Test & Performance Magazine deste mês de Agosto. Eis o link para download abaixo (clique na imagem):

Revista Software Test & Performance Magazine – Julho/2009

Caros colegas,

Segue abaixo o link para a edição da revista Software Test & Performance Magazine deste mês de Julho. Eis o link para download abaixo (clique na imagem):

CURSOS-SÃO PAULO-SP – Primeiro Ensina aí! Cursos Grátis

Pessoal,

Aqui na empresa, vamos iniciar uma sequência de cursos, que dentro do possível serão abertos a pessoas de fora também.

A idéia inicial é que os colaboradores da empresa (ensinadores) que tem conhecimento sobre determinada área/assunto compartilhe esse conhecimento.

Demos o nome a esta sequência de cursos de ENSINA AÍ!

Alguns cursos ainda não tiveram data confirmada. Mas se você deseja participar de um destes, informe que contatamos quando a data estiver certa.

Quem quiser participar ou dar algum curso é só falar (via e-mail: ensinaai@voicetechnology.com.br) .

Segue abaixo, maiores informações sobre o primeiro ENSINA AÍ!.

Primeiro Ensina aí! Cursos Grátis

Pessoal,

No banner principal do blog Ensinar,  desde sua criação consta a frase “Compartilhando Conhecimento”. E é isto que temos tentado humildemente fazer nos últimos tempos. E é justamente para dar mais um passo neste caminho, iremos fazer nos meses de julho e agosto, o primeiro Ensina aí!

O Ensina aí! é uma sequência de cursos e palestras feitas por amigos e funcionários da Voice Technology. O público destinado é qualquer pessoa que deseje participar. O calendário de cursos do Ensina aí! ainda está em fase final de preparação.

Todos os cursos estão relacionados a algum conhecimento que é utilizado na empresa.

O professor, é alguém da nossa empresa que conheça e trabalhe com o assunto abordado. Como não somos professores / instrutores profissionais, chamaremos de “Ensinadores”…

Os cursos já confirmados são:

1. Scrum: Gerenciando e planejando projetos de software (10 horas).

Descrição: abordar os conceitos do Scrum, sua utilização e alguns pequenos exemplos práticos.

Público-Alvo: interessados em metodologias ágeis e projetos de software.

Data: 20, 21 e 22 de julho. Das 19:00 às 22:30

Ensinador: André Pantalião


2. Introdução ao Teste de Software: uma abordagem prática (10 horas).

Descrição: aborda os conceitos básicos do teste de software utilizando exemplos práticos para ilustrá-los. Não é só teoria!

Público-Alvo: interessados em teste de software e iniciantes na área.

Data: 27, 28 e 29 de julho. Das 19:00 às 22:30

Ensinador: Fabrício Campos


3. Linux (10 horas) – Assuntos da certificação LPIC-1 (Prova 101)

Descrição: Abordar os assuntos da prova de certificação LPIC-1 (Prova 101).

Público-Alvo: interessados em Linux e certificação LPIC-1 (Prova 101)

Data: a ser confirmada, em setembro.

Ensinador: Adelson Junior



4. Oracle 11G – Fundamentos de SQL I (10 horas)

Descrição: Conteúdo do curso baseado na primeira prova da certifica ção para OCA-DBA.

Público-Alvo: usuários de banco de dados, sejam eles desenvolvedores, testadores, etc.

Data: a ser confirmada

Ensinador: Fabrício Campos

5. VoIP (8 horas)

Descrição: abordar conceitos básicos, componentes e arquitetura de soluções Voz sobre IP.

Público-Alvo: interessados em telefonia e Voz sobre IP

Data: a ser confirmada

Ensinador: Antonio Anderson


6. Utilizando Maven com Java (8 horas)

Descrição: mostrar a utilização do Maven, desde sua instalação até exemplos práticos.

Público-Alvo: programadores Java.

Data: a ser confirmada, em setembro.

Ensinador: Marcos Hack

Ainda colocaremos mais palestras e cursos, se quiser participar de algum curso ou dar uma palestra.

Quer participar do Ensina aí? Mande e-mail para ensinaai@voicetechnology.com.br.

Segue abaixo, informações sobre o local do cursos:

Voice Technology
Rua Líbero Badaró, 293 – cj. 30 A
Centro – São Paulo

Revista Software Test e Performance – May/2009

Caros colegas,

Está disponível para leitura e download gratuito a revista Software Test & Performance (May/2009), voltada aos profissionais da área de Teste e Qualidade de Software. O conteúdo desta edição aborda:

May 2009 – Vol. 6, No. 5

Cover Story: Testing By The Numbers: Basics of Ajax Unit Testing

Feature Articles

  • Testing With Data Patterns
  • Load Testing To Avoid Unwanted Attention

Editorial: You learn from us, we learn from you, and we all enjoy a song or two. Isn’t that what a conference should be?

Conference News: Bonus coverage from the Software Test & Performance Conference in Silicon Valley.

ST&Pedia: An expanded look at unit testing and how its idioms can be harnessed to test larger chunks of code.

Best Practices: Static and dynamic analysis — they run separately but work together.

Future Test: Is testing a right-brain activity?

Eis o link para download.

Boa leitura!

P.S. : Créditos a Fábio Martinho Campos, que disponibilizou a informação na lista do grupo BSTQB.

(Atualizado as 12h01 de 29-06-09)

Já está disponível a versão do mês de junho através do link:

A seguir, os assuntos:

June 2009

Cover Story

A Build Management Study: Keep Your Dominos In a Row
A veteran of software development and testing takes you on a journey though his experiences fixing broken build systems. Read how he did it.
By Chris McMahon

Feature Articles

One Last Look at Data Patterns
Understand the data in your organization and improve quality assurance. This final installment covers data patterns of interaction, human error and those that trigger measureable results.
By Ross Collard

Pick The Best Players and Your Team Will Win
Interviewing for a job requires preparation regardless of which side of the table you’re on. Learn how to prepare your team to hire the best automation experts that come your way.
By Bernie Gauf and Elfriede Dustin

The Real and Perceived Business Processes
Things are not always what they seem. As a manager you might think you know how the job is getting done, but what goes on behind the scenes? Here’s how to find out.
By Robin Goldsmith

P.S. : Créditos a Marcos Diniz, que disponibilizou a informação na lista do grupo BSTQB.

Eis o link para download.

Boa leitura!

P.S. : Créditos a Fábio Martinho Campos, que disponibilizou a informação na lista do grupo BSTQB.

Automação de Testes de Aceitação – Teoria ou Prática

Mais um post esclarecedor e de bom conteúdo, relacionado a Qualidade de Software. Meus parabéns ao trabalho da Gisela Nogueira pelo trabalho de tradução e divulgação! Leia abaixo o texto retirado do InfoQ.

Existem relatos esporádicos do sucesso em escrever requisitos e automatizá-los como teste de aceitação (algumas vezes chamado de test driven requirements, story driven development, e – dependendo de quem você pergunta – behavior driven development).  Até agora essa prática é utilizada por uma minoria da comunidade. Alguns líderes dizem que é uma idéia ruim e um desperdício de esforço. A automação de testes de aceitação escritos no início de cada interação seria somente uma afirmação teórica que se mostrou ineficaz pela falta de utilização?

Primeiramente, vamos definir o que significa automação de testes de aceitação: são testes escritos geralmente no início de uma interação e são uma forma de execução dos requisitos. Eles são exemplos detalhados de como o sistema supostamente deve funcionar quando o requisito descrito está completo – uma resposta para “Como se parece quando está pronto?” Historicamente FIT and FITNesse são as ferramentas escolhidas, no entanto, atualmente existem novas ferramentas como cucumber e rspec.

Esse tipo de teste realmente não pegou. De fato, houve recentemente uma conversa chamada Is FIT Dead?. Também, em uma entrevista com a InfoQ no Agile 2008, Brian Marick fez seu registro:

InfoQ: Então isso parece interessante. Faz sentido para mim estes testes no nível de negócio em si, coisas que o cliente entende e pretende ver. E você fala sobre exemplos. Não sei se você está utilizando isso para simplificar, para se livrar da palavra teste. Mas você está realmente falando sobre testes para cliente, não está? Você pode nos falar mais sobre isso?

Brian: O que tenho notado de interessante é que isso não parece funcionar em nenhum ponto tão bem quanto o teste unitário do Test Driven Design, no seguinte sentido: quando você desenha um teste, você geralmente focaliza tudo o que significa, realmente, um ganho. E claro, os testes unitários fazem a mesma coisa que os testes unitários costumavam fazer. Mas a escrita real do código de teste, que é necessário para criar aquele exemplo, aquele teste automatizado para ser executado sem intervenção humana, com muita freqüência, não tem o mesmo resultado tipo “Oh! Estou realmente satisfeito de ter escrito este código, eu realmente aprendi algo, é meu, eu já escrevi um monte de códigos chatos, e não aprendi nada” então não há uma recompensa por ter escrito aquele código, você não tem um real benefício, além do benefício do próprio teste. E também, aparentemente, estes exemplos externos, não são testes de aceitação que realmente geram conseqüências estruturais profundas como uma refatoração faz em testes unitários. Então a pergunta que eu faço é se o valor está na criação do teste, e há um custo substancial para escrever todo esse código, vale realmente a pena gastar o nosso dinheiro automatizando estes testes? Porque se não compensar financeiramente, por que simplesmente não fazer os testes num quadro, com os programadores implementando-os, um de cada vez, checando-os manualmente, e até mesmo mostrando-os ao dono do produto, manualmente, e ao finalizarmos, simplesmente os apagamos e esquecemos? Porque temos esta necessidade de salvar estes testes e executá-los outra vez e mais e mais vezes, diversas vezes novamente?

Então, existem vários outros lideres na comunidade que ainda recomendam a utilização de testes de aceitação automatizados; entre eles incluem-se nomes como Robert C. Martin, Joshua Kerievsky, e James Shore, para mencionar alguns.

Chris Matts apresenta uma forma interessante de olhar o problema, como um problema de chegada das informações. Suponha que você tenha um processo de desenvolvimento de software (não necessariamente Ágil-específico) que não tem testes de aceitação escritos com antecedência. Os times de QA tipicamente executam seus próprios cenários de teste e quando o defeito é localizado é passado para os desenvolvedores. Esses defeitos são localizados randomicamente e, portanto, afetam a velocidade do time do software randomicamente porque um percentual da sua capacidade é utilizado para detectar esses defeitos. Novas informações chegam randomicamente para o time do desenvolvimento.

Agora, considere se o teste é escrito pelo departamento de QA antes que o desenvolvimento comece. A informação fornecida por esses cenários agora ocorrem no início da interação de forma previsível. Portanto, as incertezas são reduzidas, a velocidade se torna mais estável (menos interrupções randômicas), e isso significa mais previsibilidade.

Então, teste de aceitação automatizada é somente alguma coisa que a elite (ou sorte) consegue fazer funcionar? Existe uma falha interna, que não é vista, que causou a utilização menor do que a esperada? Ou é simplesmente difícil e com eficácia comprovada além de ser uma prática que todo time de desenvolvimento de software deveria adotar?