The Bug Bang Theory Hi everyone, be welcome to my blog. Here, you will get very interesting information about subjects like Software Testing, software architecture, Agile Process, Software Deveopment Tools, ALM Tools and Programming! The opinions expressed at this blog are responsibility of the author and it not represents any opnion of the company that I'm working.

29set/114

Notas sobre o Curso Certified ScrumMaster (CSM)

Esta semana eu tive o prazer de participar do curso Certified ScrumMaster ministrado pelo Heitor Roriz da empresa Massimus C&T (Curso oficial da Scrum Alliance) aqui em Porto Alegre.

O meu principal objetivo com o treinamento era reforçar os conceitos, ferramentas, práticas e principalmente valores do Scrum, visualizar os objetivos do scrum master (focando um contexto diferente do que estou habituado) em relação aos team members e em especial aos QAs e claro, buscar referências para continuar aprendendo e estudando agile.

"This course focuses on the basics of the Scrum framework, including team roles, activities, and artifacts, so that you can be an effective member of a Scrum team."
(http://www.scrumalliance.org/pages/CSM).

Outro ponto que hoje é uma das minhas prioridades é a busca por melhorias das minhas soft skills, ou seja, das minhas habilidades de comunicação, planejamento, auto-gerenciamento, estimativas, resposta a mudanças e a problemas, comunicação com o cliente entre outras habilidades, que não estão relacionadas diretamente aos conhecimentos técnicos. Esse curso coube como uma luva, pois pude discutir com muitos scrum masters com mais experiência do que eu, ao mesmo tempo alinhar muitas dúvidas e expectativas sobre o Scrum e sobre agile de um modo geral.

Certified ScrumMaster

Certified ScrumMaster Course

The Certified ScrumMaster (CSM) course offers training in the Scrum fundamentals essential for ScrumMasters or Scrum team members.

O curso foi muito interessante, primeiro por proporcionar um ambiente de profunda discussão sobre os mais variados temas, desde o uso de scrum para gestão de projetos de software até sua aplicação em gestão de projetos de engenharia civil. O Instrutor mostrou profundo domínio e experiência, juntando uma dose de teoria à aplicando diversas dinâmicas onde simulados todas as práticas e ferramentas oferecidas pelo framework scrum.

A busca pelo conhecimento em Scrum tem se mostrado cada vez maior entre os brasileiros. Não somente agilistas, como também muitos profissionais que trabalham com modelos tradicionais de desenvolvimento de software, pois o scrum pode ser implementado parcialmente para solucionar problemas em quase todos os tipos de projetos, principalmente os problemas de comunicação.

Post to Twitter

26set/117

Penso, logo automatizo

Estamos com muitas discussões sobre o tema: "Automatizar os meus testes é mais caro/demorado/arriscado e tudo de ruim se comparado com executar os testes manualmente".  Bom. . . Se pensarmos com bons certificados que somos, sim, qualquer resposta diferente disso é menos um ponto na maioria das provas de certificação.

Muitos slides por aí na internet, inclusive meus (Y_Y) também falam sobre isso. Então não tem mais o que discutir certo? Nem tanto . . .

O problema da automatização não é a automatização em si, mas sim, a automatização sem planejamento, sem uma arquitetura mínima. E quando falamos de planejamento, não estou falando de documentação extensiva nem de horas e horas nas salas de reunião com o seu gerente, o presidente da empresa e mais três pessoas que não fazem a mínima ideia do que seja arquitetura de software e padrões de projeto, mas sim de bons QAs e bons developers pareando e pensando juntos em como desenvolver uma arquitetura para testes automatizados que seja adequado ao seu projeto, sustentável, fácil de entender, extensível e acima de tudo flexível a mudanças.

Estamos falando justamente sobre isso no GUTS-RS e também no DFTestes, quando um colega na discussão questionou como isso funciona em termos práticos, por isso estou postando este exemplo usando um framework gratuito e portável para automação de testes funcionais, o Watir.

Para rodar todos os exemplos deste post você precisa apenas instalar o ruby 1.8.7 ou superior na sua máquina com windows ou linux e em seguida executar o seguinte comando:

Windows: ~$ gem install watir-webdriver
Linux: ~$ sudo gem install watir-webdriver

Pronto :)

Para exemplificar como isso funciona na prática, vamos imaginar  um cenário bem simples que vai ficando mais complexo, exatamente como um projeto de software funciona:

Um QA qualquer recebeu a seguinte tarefa: Inclua o texto "Automação Rocks!" no google e em seguida verifique se é apresentado o texto "The Bug Bang Theory 2.0". Esse QA poderia optar por três alternativas:

  1. Executar testes exploratórios: Sem evidenciar ou documentar os testes (planejar != documentar). Em teoria, esse é o teste mais rápido que existe, logo mais simples também. As suas desvantagens são exatamente a falta de evidências e a incerteza ao relatar a cobertura dos testes.
  2. Documentar os testes em uma ferramenta de gestão de testes: Documentando e evidenciando as execuções manuais dos testes em uma ferramenta como por exemplo o TestLink. Esse é o segundo teste mais rápido*, e agora com a vantagem que temos a nossa cobertura bem definida e evidencias das execuções para nossos PMs e ou clientes.
  3. Automatizar os testes: Escrever testes automatizados para que os testadores fiquem livres para criar novos cenários e testar a aplicação em outros aspectos. O problema aqui é que esse teste é muito caro**, as empresas não tem ambiente para isso**, e segundo alguns CONSULTORES da nossa área, dificilmente o ROI de automatizar um projeto é sustentável***.

*Argumento que contrario neste post :D
**Outros argumentos que contrario aqui . . . :p
***Argumento ultrapassado usado nos anos noventa e que continua sendo usado na atualidade. . .  tsc tsc tsc

Lembrando que BDD e TDD também são formas de automação.

Post to Twitter

13set/1112

The Bug Bang Theory 2.0 – Agile and Technical Testing Rocks!

O blog The Bug Bang Theory está passando por uma mudança (para melhor).

Até hoje, o blog não tinha um foco, explorando diversas áreas, inclusive antagônicas. Isso não é de todo ruim, mas de uma certa forma, acaba deixando a desejar quando ao mesmo tempo fala sobre processos tradicionais e ágeis por exemplo, ou quando exemplifica execuções manuais no TesLink e exemplos básicos de automação em várias suítes diferentes. Escrever sem um foco acaba te tornando muito generalista e imparcial. Acredito que nós profissionais de teste de software devemos ser multidisciplinares, mas não generalistas.

A ideia do blog agora é focar nas principais, mais modernas e mais acessíveis técnicas e ferramentas da atualidade.

Por que a mudança?

Estou reaprendendo MUITO sobre agile, testes e automação. Muitas das coisas que eu acreditava ou era tendencioso há alguns meses atrás, já não parecem ter tanto sentido, e muitas das coisas que você pode ler nos posts anteriores a esse, podem ser contrariadas nos posts daqui para frente. Inclusive é por esse motivo que estou sumido da comunidade e do blog nos últimos meses.

Pra início de conversa, eu pensei MUITO sobre começar a escrever os posts em inglês (visando discutir com outros QAs de fora), mas lembrei que o que me motivou a iniciar o blog não foi simplesmente o fato de estudar mais, mas também ajudar outras pessoas no Brasil e fomentar o crescimento técnico e intelectual no Brasil. Por isso vou manter os posts em português. :)

Algumas das principais mudanças que serão realizadas são:

Adeus TestLink, Mantis e controle arcaico de teste de software: Acreditei durante muito tempo no modelo de escrita sistemática de casos de teste, mas hoje em dia não vejo mais esse modelo antigo funcionando. O TestLink pode até ser um grande passo em empresas mais tradicionais, ou onde não é depositada muita confiança nos QAs / Testers, mas não adianta focar nos sintomas, temos que mudar pela doença. O que quero dizer é que não adianta continuar focando 50% a 80% do nosso esforço e tempo documentando, controlando e evidenciando nosso trabalho para demonstrar o valor do Teste de Software. Temos que demostrar o valor no dia a dia, através de resultados no software (no real valor para o cliente), inclusive usando este tempo para isso. A mentalidade das organizações modernas não pode mais continuar baseada em ferramentas de controles de tarefas, mas sim em times que desejam entregar o melhor para o cliente e por isso vão fazer o melhor todos os dias (e isso não é frase de professor).

Reviews de Livros Técnicos: Leio e coleciono livros sobre teste de software, segurança web, desenvolvimento ágil, desempenho web, programação entre outros temas. A partir de agora teremos uma série de posts sobre os principais livros em que eu estudei e/ou estou estudando. Esses posts serão uma tentativa de estimular a leitura e a discussão de temas relacionados aos principais autores no mundo, focando em tópicos que não são discutidos pela certificação A ou B, mas sim por doutores, pesquisadores e principalmente profissionais de teste de software com real vivencia nas praticas atuais do mercado.

Sem mais CMMi, modelo V, processos tradicionais e modelos ultrapassados de desenvolvimento: O mundo do desenvolvimento de software não estaria tão desenvolvido hoje se não fossem esses pioneiros do desenvolvimento, criando modelos e processos complexos, com templates, fluxogramas e certificações para empresas e profissionais. Mas esse tempo passou e hoje as empresas mais conceituadas no mundo adotam agile, vendem agile, compartilham agile e respiram agile. Entre elas o Google, a ThoughtWorks, o Facebook, o Flicker, Microsoft, Twitter e dezenas de outras empresas. As principais startups de hoje também adotam modelos ágeis de desenvolvimento de software. Porque continuar vivendo do passado?

Automação, Automação e Automação!!!: A partir de agora vai ter MUITO conteúdo técnico sobre testes ágeis, uso de ferramentas e técnicas do dia a dia, principalmente do ponto de vista ágil, sem aquela "renca" de documentação e planejamento desnecessário. Muitas novidades para o mundo Ruby de teste de software, Selenium webdriver, Cucumber, Twist entre outras ferramentas.

Soluções free e Open-source: A partir de agora vou focar em soluções totalmente acessíveis ao mercado brasileiro, sem nenhum custo de implementação, como Selenium, JMeter, LoadUI, Watir, Session Tester, SkipFish, entre outras. Sim, é possível ter produtividade, qualidade e controle usando ferramentas open source, tão bons ou melhores que os oferecidos por suítes caríssimas no mercado.

Não quero que achem que estou ficando xiita, mas sim que o blog passará a ser exclusivamente técnico, focando automação e desenvolvimento ágil, do lado dos testadores. A partir de agora vamos discutir conhecimento técnico sem churumelas.

Como sempre, mais do que qualquer outra coisa, este é um canal para discutir ideias, levantar questões e sanar dúvidas. Não é simplesmente porque estou mudando o contexto que vou deixar de responder dúvidas sobre o TestLink por exemplo, ou que eventualmente exista um post relativo a algum dos tópicos de antigamente, estou apenas falando que não será mais o foco.

Infelizmente, sei que essas novidades não vão agradar inicialmente a todos os leitores, mas espero que com o tempo possamos discutir e entender os motivos dessa mudanças.

Espero que gostem da nova versão do The Bug Bang Theory e vamos torcer para que essa tenha menos bugs que a anterior :)

Muito obrigado e bem vindo ao novo blog!

Camilo Ribeiro

Post to Twitter

30mai/113

Palestra UniBH: Desenvolvimento Dirigido por Testes

A UniBH (Universidade de Belo Horizonte) me convidou no ano passado para falar sobre teste de software na Jornada Tecnologica,  e eu ministrei a palestra "Introdução a automação de testes", comentada aqui no blog. Também fui convidado para esse ano, com o objetivo de abordar algo relacionado a teste de software, mas não diretamente sobre teste. Optei por falar sobre desenvolvimento dirigido por testes, já que percebi muito interesse das pessoas depois que publiquei os posts "Uma Introdução a TDD com JUnit" e principalmente "Testes de unidade para quem não sabe nada de programação".

A UniBH novamente foi extremamente organizada. Contava com diversas palestras em várias salas e com uma recepção de primeira qualidade. Os alunos foram participativos e contei com a presença do Eduardo Habib, Test Manager da empresa Synergia, mestre em Ciência da Computação pela UFMG e professor dos cursos de computação da UniBH, uma das lendas da nossa área que ainda habitam Belo Horizonte.

A palestra iniciou com os conceitos de teste de unidade e desenvolvimento difirigo por testes seguiida de uma abordagem bem prática, através da demonstração de exemplos e criação de testes na hora.

Abaixo os slides e comentários:

Post to Twitter

11mai/115

Palestra PUC: Certificações em Teste e Qualidade de Software

Fui convidado para realizar a minha terceira palestra na PUC Minas, na 6ª Semana de Sistemas de Informação.

Ano passado já realizei as palestras "Carreira em teste de software" na 5ª Semana de Sistemas de Informação na PUC Barreiro e "Palestra PUC São Gabriel – Teste de Software: Introdução à Qualidade" na semana de sistemas de informação 2010 da PUC São Gabriel.

É uma honra palestrar em uma universidade com o prestígio da PUC Minas e uma honra maior ainda ser convidado para uma terceira palestra, pois me da a certeza que aquelas quase quatro horas agregaram conhecimento e enriqueceram um pouco mais aos ensinamentos dos mestres e doutores que lecionam lá.

Muito obrigado ao Professor Marcelo Werneck por mais uma vez tornou essa apresentação possível e por confiar novamente suas turmas à mim. Espero que os alunos e professores presentes tenham gostado e que possa ajudar a orientar melhor quais as certificações estejam buscando.

Como o tema desse ano foi Certificações em TI, não podia falar de um assunto diferente do que as certificações da área de teste e qualidade de software. Para isso realizei pesquisas e busquei bastante conteúdo já elaborado na internet.

Entre eles, destaco o artigo "Guia Completo para Certificações em Qualidade e Teste de software - Versão 2008" cedido pelo seu autor Fábio Martinho, que corre o risco de ser o artigo mais lido sobre teste de software no Brasil e o slide "Cargos e Salários 2010: Quanto Ganha um Profissional de Teste e Qualidade de Software no Brasil" cedido pelo Cristiano Caetano, que realiza as pesquisas mais sérias sobre cargos e salários e carreira em teste e qualidade de software, além de ser um dos maiores colaboradores da nossa área e o mantedor do TestExpert, a maior rede sócial de teste de software no Brasil. Portanto, fica aqui meu muito obrigado pela disponibilidade, prestatividade e agilidade com que me atenderam :)

Abaixo a Apresentação:






Comentários:

 

A palestra foi realizada para alunos do 5º ao 8º períodos do curso de sistemas de informação, e fez parte da VI Semana de Sistemas, dividindo espaço com outras palestras sempre com o tema, Certificação em TI. O tema faz parte de uma estratégia da PUC para estimular à obtenção de certificados entre os seus alunos, contando inclusive com uma parceria com a IBM para certificações mais acessíveis.

Post to Twitter

9mai/118

Qualité, Agilité, Automatiqué. 7 passos para revolucionar sua área de testes

Ok ,ok, o français errado e "mixuruca" do título foi proposital. Apenas uma forma de aproveitar d0 lema iluminista da revolução francesa, liberté, egalité, fraternité para escrever esse post sobre sete dicas para revolucionar a área de testes da sua empresa.

Este post é direcionado a todas aquelas áreas de teste ou qualidade de uma, duas ou três pessoas que ainda não tem visibilidade nas empresas e talvez não conte nem com uma liderança formal. Esse cenário é MUITO mais comum do que imaginamos. Quem acompanha as listas sabe do que estou falando. Aqueles e-mails que começam com a frase "A empresa que eu trabalho é pequena, e a gerente aqui pediu que eu automatizasse tudo e reduzisse os defeitos do software a zero, além de curar o câncer e promover a paz mundial, qual ferramenta eu uso? O TestLink ou o Mantis?" rs.

A má notícia é que além de não achar a cura do câncer e não promover a paz mundial, você também não vai automatizar tudo e não vai reduzir os erros das suas aplicações a zero. A  boa notícia é que você pode mudar a sua forma de trabalho, alinhar expectativas e melhorar um pouquinho a cada dia, o que já vai fazer a sua gerente ou o seu gerente ficar muito satisfeito e disposto a investir mais para ter mais resultados.

Apesar do termo revolucionar, os passos abaixo são apenas para iniciar a Evolução, afinal de contas, como disse o filosofo Tostoi, "Todos querem mudar o mundo, mas ninguém quer mudar a si mesmo", e os passos abaixo tem muito de mudar aos seus comportamentos como líder ou como representante de uma área de testes que ainda está germinando.

Post to Twitter

27abr/113

E quando o reuso de código é reuso de bugs?

A prática do reuso de código fonte de terceiros se torna cada vez mais comum, principalmente com a grande disponibilidade de pedaços de código, funções, exemplos e bibliotecas na internet, que estão em diversos canais de comunicação, mas principalmente neste canal de comunicação, o blog.

"Que atire a primeira pedra o desenvolvedor que nunca copiou uma rotina da internet."

Claro que o reuso de intelectual da comunidade é MUITO importante. Eu faço muito reuso de blogs e revistas na internet e claro que acredito que essa é uma boa prática. Com as rotinas prontas temos muito mais produtividade e evitamos muitos defeitos. O problema é confiar nisso de olhos fechados, ou seja, executar apenas um teste de fumaça simples em uma rotina antes de colocá-la em produção.

Esse post foi elaborado após a minha tentativa de cadastro no site http://precojustoja.com.br/, uma iniciativa do jornal Brasil 247 com o @FelipeNeto para tentar reduzir o nosso altíssimo número de impostos que acabam virando dinheiro desviado pelos nossos políticos que entre outras coisas, se sentem ofendidos e acusam os internaltas e a imprensa de Bullying (aff).

Ao tentar cadastrar o meu CPF, notei que uma validação estava me bloqueando. Tentei com e sem mascara, tentei em dois browsers e finalmente apelei para o debbuger de javascrip. Notei que o meu CPF, por uma característica especial, caia em um defeito no código javascript de validação de CPFs, que provavelmente é um desses casos de ctrl c / ctrl v sem testes.

CPF extraído do site http://geradorcpfcnpj.ureshino.org/ para simular o ocorrido com o meu CPF

Pra explicar o defeito, vamos entender um pouco sobre como funciona o CPF. Pesquisei e encotrei a algum tempo um blog (http://www.jalucrei.com.br/calculo_dv_cpf_cgc.htm) com tudo muito bem explicado explicado. Vou resumir o que nos interessa:

Post to Twitter

18abr/1110

Teste de unidade para quem não sabe nada de programação

Quando pedimos algum analista de teste para falar de testes de unidade, em 90% dos casos a resposta é automática: "Nível de teste em que o desenvolvedor valida uma unidade", "Teste de caixa branca", "Teste de desenvolvedor", entre outras respostas. Falo isso porque o teste de unidade ainda é teste, sendo assim, para ser um profissional completo, além da teoria temos que buscar a aplicação prática desse teste.

Não estou dizendo para largar os testes de sistema e debruçarem sobre os códigos fonte. Longe disso. Mas digo que temos que saber que os testes de unidade são o melhor momento para se pegar defeitos de software. A fase mais barata depois dos requisitos e análise e também a fase em que inserimos mais defeitos em todo o processo de desenvolvimento de software, a codificação.

Pra quem acompanha o blog deve lembrar de um post que eu fiz a pouco mais de um ano chamado "Uma introdução a TDD com JUnit". Naquele post falei um pouco sobre como implementar um teste genérico e passar uma collection para ser validada, usando também um pouco do conceito de DDT (Data Driven Testing).

No exemplo em citado acima, ainda precisaríamos conhecer um básico de orientação a objetos e de java, o que em muitos casos nos faz questionar a viabilidade  da participação do testador nesse nível de teste, já que a maioria dos nossos testadores e analistas de teste não possui fluência em alguma linguagem de programação. :(

Imagine se pudessemos fazer testes de unidade usando arquivos do Excel . . .  Quase um sonho. Não mais :)

Post to Twitter

20mar/111

Vocabulário básico para testadores ágeis

Estou preparando um material recheado de novidades sobre testes ágeis, mas estava ficando um pouco preocupado com o vocabulário que vou usar, cheio de termos em inglês ou traduções literais não costumeiras das nossas listas e livros, por isso decidi "preparar o terreno" com um post falando um pouco sobre cada um dos termos mais usados e discutidos no mundo agile.

Os termos abaixo em alguns casos tem mais de uma tradução ou podem ter mais de um significado. Peço a gentileza de compreender que esse post é focado em quem não entende nada de agile, portanto as explicações serão bem básicas e em alguns casos até incompleta. O foco aqui é criar uma introdução para abordar mais tarde. Caso queira mais informações sobre os termos aqui dispostos, leitores mais avançados no assunto podem consultar as referências e postar outros pontos de vista aqui nos comentários :)

Post to Twitter

Categorias: Agile Leia mais...
15mar/110

Meu primeiro bug

Será que todo testador se lembra do primeiro bug de software,  reproduzível e retestável que encontrou?

Eu me lembro. :D

Eu tinha 16 anos e estava fazendo estágio técnico em uma empresa de assessoria e cobrança aqui em Belo Horizonte. Lá tinhamos um sistema de cobrança tradicional. Com certeza absoluta tinha dezenas de defeitos, pois era desenvolvido por um único desenvolvedor, sem testadores ou qualquer outro papel da engenharia de software.

De qualquer forma, era um sistema desktop até grande, desenvolvido em Delphi com Sql Server, com dezenas de relatórios e com muitos usuários e dados sendo cadastrados a cada minuto.  Como eu não fazia parte da equipe (de uma pessoa) responsável pelo sistema de informação de cobrança, nem fazia idéia da quantidade de defeitos e na verdade nem sabia que existia esse tipo de coisa.

Mas o espírito testador que já habitava em mim me fez ter uma curiosidade muito diferente. Hoje em dia sei explicar o que aconteceu, mas na época parecia mágica.

O sistema tinha uma tela de login tradicional, com usuário, senha, um botão de OK e um botão de Cancelar, parecida com a tela abaixo:

Tela extraída do link http://soprogramando.wordpress.com/2008/09/30/sistema-de-login-simples/

Porem, tinha uma diferença. O botão de "OK" ficava fosco (Enable false) e quando eu digitava o meu usuário "camilo" com a senha correta ele ficava ativo. Então eu clicava em OK e finalmente estava logado no sistema.

Post to Twitter

Switch to our mobile site