Conhecendo o Hodman

Obrigada Galani por me empurrar o Desafio Agile Testers :) Eu tava mesmo enrolando para dar uma olhada no Hodman e assim eu arranjei uma desculpa para não procrastinar muito.

Recentemente o Felipe Knorr compartilhou um artigo falando sobre um framework de testes usando Selenium e Javascript. O framework é composto pelo Hodman, uma biblioteca de selenium que inclui page objects, o Kobold, uma ferramenta para comparar screenshots entre uma versão e outra do software, especialmente útil para testes de regressão, e o Preceptor, com o intuito de orquestrar a execução dos testes em paralelo, sequencialmente ou uma mistura dos dois, gerando um único report dos resultados e cobertura.

Esse artigo tem como foco o Hodman apenas.

Pré requisito:

. Node instalado

. Um servidor Selenium rodando (no meu caso, usando a porta 4444)

Crie uma pasta para esse exemplo, e no terminal, digite:

npm init

Vão surgir algumas perguntas. O que você não souber responder ainda, pode simplesmente pressionar enter até o fim. Após esse procedimento, terá um arquivo chamado package.json na sua pasta.

Abra o arquivo e adicione no fim duas dependências: o cabbie e o hodman. Se você foi preguiçosa como eu e simplesmente saiu apertando enter pra quase tudo, o seu arquivo deve estar mais ou menos assim:

https://gist.github.com/sarahpimentel/904d012e670508cc3f93

É muito importante colocar essas dependências nesse arquivo. Nas minhas primeiras tentativas, eu simplesmente instalei a versão disponível no npm do Hodman e o Cabbie com e muita coisa deu errado. A versão do Cabbie no npm atualmente é a 0.0.9, cuja última atualização foi em Abril/2014. O último commit no projeto é de Outubro/2014. A última versão do Hodman é a 0.9.5. Essas linhas garantem que você vai estar usando o código do HEAD de ambos os projetos.

E o que é esse Cabbie? É um webdriver, também escrito em Javascript. No momento, o Hodman utiliza somente essa opção. Caso você se interesse em desenvolver um adaptador para outro webdriver, basta acessar o projeto, abrir um issue e submeter o código.

O arquivo de exemplo é bem simples:

https://gist.github.com/sarahpimentel/82ea0d486f95ddd50764

Configurações e inicialização

As primeiras instruções são configurações do driver. E depois temos a página do Google que é uma extensão da classe PageObject. Os seletores da página são definidos na inicialização da página e caso os seletores mudem, esse é o único local em que será necessário efetuar mudanças. Também é importante salientar também que o único seletor usado no momento é o css. No código, esses seletores são as classes dos objetos que eu pretendo avaliar. No fim, o comando addLoadSelectors. Nele, eu indico um seletor para ser usado para verificar se a página já foi carregada corretamente.

Métodos

Adicione então todos os métodos necessários para o seu teste nessa página. Vamos executar uma pesquisa no Google, então os métodos são:

performSearch, que recebe o termo a ser pesquisado, preenche o campo da pesquisa (setSearchTerm) após certificar-se de que não há nenhum outro valor no campo (clearSearchInput), submete a pesquisa e espera pela página de resultados.

URL

BASE é a URL principal da página. Por exemplo, http://www.amazon.com. O resto da URL é formado com o atributo abaixo.

URL é o complemento da URL BASE citada acima. Nesse caso, não precisei complementar a URL, então usei apenas ‘/’. Se no exemplo da amazon, dado acima, eu quisesse acessar uma página específica, por exemplo, a seção de brinquedos da amazon, o valor desse campo seria ‘/toys’.

Apesar de parecer opcional, se esse parâmetro não for informado, você receberá um erro como esse:

<caminho do projeto>/node_modules/hodman/node_modules/preceptor-core/lib/utils.js:133

       } else if ((result.substr(-1) === glue) || (arg.substr(0, 1) === glue)

                                                       ^

TypeError: Cannot call method 'substr' of undefined

EXPECTED_URL é uma expressão que será avaliada para determinar se o script chegou à página certa. Nesse caso, eu optei por colocar apenas o pedaço principal da URL, já que ao acessar o Google, a URL pode mudar um pouco. Sem esse parâmetro é provável que você encontre o erro:

Error: Waited for an event, but timed-out. Message:Waited for url that matches 'https://www.google.de/'.

Assert

O Hodman não tem métodos que permitam fazer assert, portanto é necessário importar algum módulo que tenha essa capacidade. Para simplificar, importei o assert. Pelo que vi em uma apresentação sobre esse framework, o Yahoo está usando Mocha para os testes e Chai para realizar os asserts.

Opinião

Mastigadinho assim, o framework parece bem simples. Eu acabei por demorar bem mais do que eu esperava para chegar nesse exemplo. Acho que ainda falta desenvolver melhor a documentação e alguns tratamentos de erros. Tem muito potencial, mas ainda é pouco maduro. O projeto é aberto, portanto quem se interessar, é só baixar e melhora-lo. Se ficou curioso, dá uma olhada na captura de imagem e quem sabe, já segue dando uma olhada no Kobold, faz uma análise e publica um post. :)

Testing War Room - Google Docs

Esta semana experimentei usar o Google Docs como War Room para testes e foi super produtivo. Além disso, foi um bom insight para tirar o pó aqui do blog que já não via um post há bué da tempo. Bué da tempo ? Ok, expressão portuguesa. Tradução: há muito tempo. Nesse tempo que o blog ficou às traças muita coisa aconteceu, inclusive minha mudança para Lisboa! :) Mas bem, vamos voltar ao assunto central.

Primeiro, que idéia é essa de Testing War Room?

War room
Acredito que por volta do ano 2000 algumas empresas de TI começaram a experimentar colocar o time de desenvolvimento em ambientes como salas de reuniões onde a comunicação fosse aumentada e as ações fossem tomadas mais rápida e acertivamente.

Ainda era muito comum os desenvolvedores ficarem um tanto isolados uns dos outros (que dirá da equipe de testes), com divisórias na mesa e pouca comunicação, o que fez dessa prática algo inovador na época. Um bom exemplo da aplicação dessas war room eram as ‘crises’, problemas críticos em produção que precisavam de atenção imediata e esforço conjunto coordenado.

Com o tempo, o conceito de war room começou a ficar um pouco descabido já que empresas/pessoas que praticam agilidade já promovem naturalmente um ambiente com menos obstáculos para comunicação.

A motivação
Não foi uma crise, mas a necessidade de focar os testes em uma funcionalidade que precisava ser entregue rapidamente que motivou a recuperação desse conceito, ainda que de uma forma adaptada a nossa realidade.

Bem, na minha empresa as mesas não tem divisórias e o time encontra-se todo na mesma sala. Além disso, anteriormente já tive a experiência de sentar com meu notebook ao lado do desenvolvedor e ir testando, reportando, ele corrigindo, eu re-testando e testando outras coisas na sequência. Mas o trabalho ficava muito ping pong e precisávamos de mais agilidade.

A ferramenta e o processo
Resolvemos experimentar o google docs como virtualização desse conceito de war room. Funcionou assim: Eu ia testando, escrevendo no google docs os problemas encontrados, incluindo prints quando necessário. Ao lado de cada problema, eu colocava um comentário. Os comentários tem opção de Reply e de Resolve. E ainda há a opção do chat para comunicação.

Quando o desenvolvedor interagia com o meu comentário, eu recebia e-mail comunicando da alteração e o ponto que foi corrigido. Isso claro, fora o aviso verbal. Além disso, por concentrarmos o essencial da comunicação no documento, no caso de precisarmos desviar o nosso foco para outra tarefa momentaneamente, não perdíamos a sequência do que estávamos fazendo.

Exemplos:
Email com issue solved:

Comentários, reply e alterações:

Vantagem
Eu podia testar todo um aspecto da feature e ir apontando os problemas, sem precisar interromper meu teste para comunicar ao desenvolvedor de um problema intermediário e sem ter que esperar terminar todo o fluxo pretendido para então reportar o problema. Também, o desenvolvedor não precisava esperar que eu revalidasse uma correção para fazer a próxima correção.

Final feliz
E depois de muitos ‘git pull’, problemas resolvidos e feature entregue! :)

Disclaimer
A utilização de uma ferramenta colaborativa não exclui a necessidade de comunicação verbal, de levantar-se e ir a mesa do seu colega de trabalho. Essa comunicação pessoal é essencial no dia a dia. Nesse caso, a utilização da ferramenta tem por objetivo contribuir para organização e produtividade.


Se você já utilizou da característica de colaboração do google docs para ajuda-lo(a) nos seus testes, ou outra ferramenta com o mesmo intuito, conta a sua história também :)

Dica: How to share and collaborate using Google Docs.

Gente, eu estou na InfoQ !

A palestra sobre testes em produção que eu ministrei no TDC2012 foi disponibilizada no site da InfoQ. Dá uma olhada ;)

Aproveito pra já ajudar a divulgar dois dos meus eventos preferidos que já estão com datas marcadas para 2013:
Agile Brazil 2013 será de 26 a 28 de junho em Brasília

E o TDC2013 já tem datas!
TDC Floripa: 24 a 26 de Maio de 2013
TDC Sampa: 10 a 14 de Julho de 2013

O período de submissão desses eventos abrirão em breve, então já comecem a preparar suas apresentações.

Testes em produção: paraíso ou inferno?

No próximo final de semana estarei no TDC Goiânia coordenando a trilha de testes e apresentando a palestra "Testes em produção: paraíso ou inferno?".

Você tem algum caso de teste de produção com sucesso ou não que queria compartilhar? Coloca nos comentários!

Aguardo vocês lá pra gente bater um papo legal sobre o assunto! :)

Testing Dojo Brasil

O Site testingdojo.com.br nasceu com o objetivo de concentrar informações sobre dojos de teste no Brasil, facilitar a promoção desses encontros e dar visibilidade às comunidades de teste.

No dia 13/09/2012 rodou em São Paulo o primeiro Testing Dojo  registrado no site Testing Dojo do Brasil, que contou com o apoio da Open4Education, uma iniciativa da Globalcode que promove minicursos gratuitos online e presenciais.

A dinâmica contou com mais ou menos 8 participantes e os facilitadores, eu e o Alan Correa Morais . O desafio foi identificar padrões em uma aplicação que gera anagramas e foi escolhido através no site testing-challenges.

Os papeis aos quais demos destaque foram piloto e co-piloto. Preparamos duas mesas/cadeiras e um notebook ligado a um projetor. O co-piloto ficava operando o notebook e o co-piloto ajudando a anotar as hipóteses e resultados. Após 7 minutos, o piloto voltava para a plateia, o co-piloto assumia o computador e alguém da plateia assumia o papel de co-piloto.

A sessão começou as 19:50 e foi até as 21:00. Depois fizemos uma retrospectiva onde os participantes puderam apontar pontos positivos e negativos relacionados ao local, a dinâmica, ao desafio, etc.

Como resultado da retrospectiva:

•        O espaço da Globalcode foi fantástico. Os participantes elogiaram o espaço e o carinho do pessoal de deixar um lanchinho de welcome pra nós. Fora que o auditório e a arrumação atenderam 100% a nossa dinâmica.
•        A atividade escolhida foi desafiadora e divertida.
•        Os participantes gostaram do formato.
•        Os participantes entenderam que transmitir o dojo ao vivo, ou mesmo gravar, poderia inibir a participação.
•        Foi levantado que o co-piloto também poderia ter um computador disponível para fazer as anotações

No fim, a minha opinião em relação ao dojo é que foi desafiador e motivador! E que venham outros! :)

Garotas nos trilhos

No último final de semana rolou também o Rails Girls, um evento que nasceu na Finlândia em Helsinki em 2010 e ganhou o mundo. No Brasil, o primeiro evento foi em Porto Alegre e nos dias 7 e 8 de setembro foi a vez da edição São Paulo.

Rails, pra quem não conhece, é um framework web open source para a linguagem de programação Ruby (mesmo que não tenha entendido nada do que eu falei agora, você pode ir a um evento do Rails Girls :) )

O objetivo do Rails Girls é o de difundir a cultura de programação, trazer mais mulheres para a área técnica e compartilhar esse “poder” de fazer ideias tornarem-se projetos reais.

O formato do evento é um workshop de um dia e meio, que começa geralmente numa noite de sexta-feira com uma “Installation Party”. Esse é um momento no qual as meninas se encontram para preparar seus notebooks para programar no dia seguinte. É também um momento de interação entre coaches e “alunas” e acontecem algumas lightnings talks motivacionais, geralmente falando sobre mulheres na TI, mulheres na programação, porque programar, e outros temas correlatos.

No dia seguinte, todos se reúnem com o objetivo de criar uma aplicação. Outras lightnings acontecem durante o dia, especialmente com o objetivo de dar algum norte para quem nunca ouviu falar nada de programação, nem sabe o que é uma tag HTML. :) As “alunas” são organizadas em grupos, que tem um coach responsável. O coach é quem vai de fato ensinar as mulheres a programar e vai orientar o desenvolvimento de alguma página que elas queiram.

No evento de São Paulo, tivemos aplicações super interessantes como a de controle de treinos de natação, a que permite que o usuário indique o quanto um local está cheio quando faz check in, a de classificação de livros por influência, entre várias outras aplicações legais.

É emocionante acompanhar esse processo de aprendizado e ver pessoas que não tinham o menor contato com esse mundo técnico se surpreendendo consigo mesmas ao não só criar o seu próprio site funcional como também deixa-lo publico.

O Brasil se encantou pelo Rails Girls, e temos vários outros eventos acontecendo ainda esse ano. O próximo será em Recife nos dias 28 e 29 de Setembro e já temos meninas organizando edições no Rio de Janeiro e em Belém.

Acompanhe o Rails Girls:
Facebook
Twitter
Twitter Brasil

Agile Brazil 2012 sob um olhar diferente

Em 2011 participei do Agile Brazil que aconteceu em Fortaleza e isso fez uma baita diferença na minha vida profissional. Conheci várias pessoas, assisti a palestras muito legais e sai de lá muito mais critica com relação ao meu trabalho. Isso fez com que eu buscasse novos desafios, trocasse de empresa e ainda, pouco depois de voltar do evento de Fortaleza, em 5 de Julho de 2011 dar o primeiro passo para ajudar a organizar o evento de 2012 em São Paulo. Simplesmente mandei um e-mail para um dos organizadores e disse que queria ajudar, nem que fosse apenas dando pitaco nas palestras de teste de software.

Não pude nem prever que ficaria tão envolvida com esse projeto. Participei de iniciativas de divulgação via twitter, no facebook e em eventos, da organização da Virada Ágil, da manutenção do site, da revisão das submissões, da montagem da grade, especialmente em relação as palestras de Desenvolvimento e Teste e acompanhei várias outras frentes nas quais não estive tão ativa quanto nessas que citei.

Em alguns momentos houve a insegurança de o evento não deslanchar e termos problemas por assumirmos o evento, já que o Agile Brazil não é uma organização ou uma empresa. É um evento montado e levado por voluntários da comunidade com muita vontade de fazer acontecer, mas com pouco conhecimento e experiência em fazer eventos desse porte. Para nosso alivio, felicidade e tranquilidade, o evento já foi um sucesso em 2010, 2011 e o mesmo sucesso acompanhou 2012. Tivemos um grande número de inscritos e muitos feedbacks positivos.

Durante os 3 dias de eventos foi um corre-corre para fazer tudo dar certo e não teríamos conseguido fazer do evento o sucesso que foi se não fosse a ajuda e a energia dos voluntários. Ao final de cada dia, fazíamos retrospectivas, recolhíamos os feedbacks deixados no mural e tomávamos ações para melhorar ainda mais o evento.

No pré-evento eu aprendi bastante sobre organização de eventos, fiz vários contatos legais, conheci bastante pessoas, vi e vivi situações de conflito, aprendi mais um pouco sobre trabalho em equipe, como lidar com as pessoas e suas diferenças e foi um crescimento fantástico.

Durante o evento, exercitei bastante a capacidade de reagir rápido a mudanças e a problemas e muito mais do que ouvir sobre agile, SER ágil, que pra mim é algo que transcende as teorias, frameworks e livros e está muito mais ligado a entregar valor e resolver problemas, que foi a nossa rotina maluca dos 3 dias de evento.

Participei de bem menos palestras esse ano que no ano passado, mas talvez eu possa chamar toda essa experiência de um grande workshop que durou pouco mais de um ano e além de todo esse conhecimento, trouxe grandes amizades. Trabalhei muito próxima de algumas pessoas em especial:

Dairton Bassi, coordenador geral do evento
Ceci, que alias fez um excelente trabalho a frente do voluntários
Fabio, que estava cuidando de boa parte do site
Hugo, coordenando o comitê de programa e da trilha de desenvolvimento e testes comigo
Luca Bastos, grande parceria, super comprometido e amigo durante todo esse processo do evento
Rafa, que deu a maior força na equipe da Virada Ágil

Reencontrei pessoas super especiais também como a Teresa que foi minha professora na especialização e gerente no C.E.S.A.R. e Daniel Wildt que foi o meu canal para fazer parte de tudo isso.

Todos os outros coordenadores e colaboradores também fizeram um trabalho incrível e tem meu respeito e admiração. Apenas citei os que eu trabalhei bem mais perto nesse período.

Conclusão: Organizaria outro Agile Brazil? Com certeza! Manoel Pimentel, “priminho”, #tamojunto no Agile Brazil 2013 em Brasília. Participaria de outro Agile Brazil? Tantos quantos tiverem. Mesmo que daqui há uns anos o evento mude a cara e os assuntos, é um grupo que tem muito a acrescentar e do qual eu pretendo e recomendo estar sempre perto.

Meu muito obrigado a todos que fizeram essa jornada comigo.

Eu sou o bug escondido...

Esse eu tive que compartilhar com vocês! :D

Mulheres são maioria na TI

Ficou curioso(a) com o título? :) Não tenho números que confirmem ou não esse título, mas se for pela impressão acho bem provável que a sua seja parecida com a minha: ainda temos poucas mulheres na tecnologia.

Engraçado que tenham poucas mulheres técnicas, considerando que o “pai” da programação na verdade é a mãe :) Se não conhecem a história da Ada Lovelace, dá uma olhada nesse link da Wikipedia.

Há muitas ações pelo mundo inteiro tentando reverter esse quadro e trazer cada vez mais mulheres para a tecnologia. E cá entre nós esse negocio de que mulher não gosta de tecnologia é ridículo. Afinal de contas, pra quem mais seriam esses fancy widgets? Ok, nesse caso, não basta ser girl ou geek, tem que ter um gosto e um bolso extravagante também. :)

No mundo inteiro há um tempo estão sendo promovidas ações para inspirar a mulherada a entrar na área de tecnologia. Em especial, eu gostaria de falar de dois para vocês.

O primeiro é o Girl Geek Dinner que começou em 2005 em Londres com uma geek girl que como muitas de nós se sentiu frustrada por ser uma das únicas mulheres que participam em eventos técnicos. Ela entrou em contato com alguns blogueiros conhecidos, e publicou sobre sua ideia de juntar outras meninas e durante um jantar conversarem sobre tecnologia. Com a ajuda de alguns amigos, ela organizou o primeiro Girl Geek Dinner com 35 participantes. E quando as pessoas começaram a ouvir falar da ideia e do evento, começaram a aparecer empresas querendo patrocinar os jantares. Ela treinou outras meninas e o Girl Geek Dinner tomou o mundo. E claro, chegou no Brasil!!

As primeiras edições do Girl Geek Dinner aconteceram em Porto Alegre e a última foi essa semana aqui em São Paulo. Nesse final de semana ocorreu a QConSP e o período foi aproveitado para juntar algumas geek girls e conversar um pouco sobre tecnologia. Foi o meu primeiro Girl Geek Dinner, mas depois dessa experiência sei que virão muitos! Tinha meninas da área de TI e meninas que não são da área. Tinha da área de marketing, uma formada em fisioterapia, uma estudante de direito e até uma filósofa! :) O encontro foi na Adaptworks que também patrocinou nosso lanchinho junto com a ThoughtWorks.

Algumas falaram sobre sua experiência com TI, como escolheram essa profissão, outras falaram dos seus receios em relação a área. Falamos também sobre o Mulheres na tecnologia e o Rails Girls, e esse é o segundo evento do qual eu gostaria de falar nesse post.

O Rails Girls começou em 2010 na Finlândia e também ganhou o mundo e também chegou no Brasil! \o/ Esse é um evento de dois dias que tem o objetivo de ensinar meninas a programar. Nesses dois dias as meninas podem conhecer outras meninas na área de tecnologia e mesmo sem ter nenhum background de programação, sair com a sua primeira aplicação feita! Fantástico, não?

O primeiro Rails Girls do Brasil foi em Julho em Porto Alegre e o próximo vai ser aqui em São Paulo e ainda teremos edições em Recife e Belém!

Espalhem por ai! Quem sabe um dia quando uma menina for para a sua primeira aula na faculdade de computação ela vai se deparar com uma turma de várias meninas?


Outros links do Girl Geek Dinner:
https://www.facebook.com/ggdbrazil
https://twitter.com/ggdbrazil
http://ggdbrazil.wordpress.com/


Outros links do Rails Girls:
https://twitter.com/railsgirls
http://www.facebook.com/railsgirls
https://twitter.com/railsgirls_br

Quero ser um caçador de bugs no TDC2012

Um pouco da minha palestra Quero ser um caçador de bugs apresentada na Trilha Testes University do TDC2012.

De uma maneira geral definimos bugs como não conformidades com a especificação. Mas se eu fiz um projeto de acordo com a especificação que me foi dada e o resultado alcançado não é o esperado, isso também pode evidenciar um bug? Na minha opinião, sim. Foi um problema de especificação ou de planejamento, ou alguma outra coisa, mas é um problema. Então generalizando, eu gosto de pensar em bugs como tudo o que está diretamente ligado ao produto e que impede que alcancemos o resultado esperado com ela.

E como os bugs nascem? Acredito que a grande maioria dos bugs nasçam de comunicação problemática. O cliente as vezes não passa uma informação ou passa de forma ambígua achando que o resultado final é óbvio; o analista as vezes não faz as perguntas corretas, o desenvolvedor muitas vezes implementa qualquer coisa que lhe é passada sem muitos questionamentos e até mesmo quando o testador vai atuar, esse também não se preocupa em ir atrás da informações. Sempre que uma situação dessas ocorre, morre uma fada, quer dizer, nasce um bug :)

E quando a gente pode encontrar esses bugs? Só quando a aplicação está pronta e ela vem pra teste? Claro que não! Se problemas de comunicação fazem bugs nascerem, então é justamente se comunicando que a gente pode evitar que eles nasçam. E essa comunicação não precisa estar associada necessariamente a reuniões formais. Muitas vezes conversando com seus colegas no cafezinho, no fumódromo, ou outras áreas comuns, quem sabe até no banheiro :) é possível perceber que um bug está se desenvolvendo ou prestes a nascer.

Muitas vezes encontramos os bugs já crescidinhos porque a atuação do tester é no final do projeto. Depois que está tudo pronto, todos os bugs já estão adultos e mais chatinhos de resolver. Isso torna a qualidade cara, ou melhor, o controle de qualidade, essa rede de proteção no final do projeto é cara. Quanto mais cedo conseguirmos identificar um problema, melhor. Não deixem chegar na fase de testes. Se vocês desconfiam que vai nascer um bug, já dá pra trocar uma ideia com o desenvolvedor. O teste deve ser uma atividade preventiva e de todos os membros do time.

Como estar preparado para encontrar esses bugs? Claro que experiência é sempre um diferencial, mas não dá pra comprar experiência na esquina. Então o caminho é estudar técnicas, ferramentas, manter-se atualizado através de leitura de blogs, participação em listas de discussão, etc. Bom, você já está lendo esse post, então já está em uma boa direção.

Bom, mas e quando a gente acha um bug? O que fazer? Ele deve ser corrigido? Deve ser catalogado?

Nem todos os bugs precisam ser corrigidos. Eventualmente a correção de um bug pode ser bem mais cara do que a convivência com ele. Essa em geral não é uma decisão do time de testes, mas sim do cliente que vai conviver com aquela praguinha. Se ele não vai se incomodar, nós também não.

Ah, mas se acharmos um bug temos que prendê-lo, cataloga-lo, pendura-lo numa moldura para que todos vejam, certo? Não necessariamente. Tudo depende da política da sua empresa e do enfoque que você quer dar nos bugs. Eu não vejo problema algum em chegar no lado do desenvolvedor, avisar que tem um bug em algo que ele trabalhou ou está trabalhando e se der ele já resolve ali mesmo e fica no “ninguém viu”. Se existe algum motivo pelo qual você acha que eu falei uma heresia, pense um pouco e veja se realmente é. Muitas vezes nem fazemos nada com toda essa informação que catalogamos e mais! As vezes o tempo de você chegar no desenvolvedor e ele corrigir o problema é até menor do que você ficar simulando de novo e de novo, coletando evidências e preenchendo bug trackers. O que é mais útil pra você? Pense.. É uma resposta que depende de contexto.

Falando em bug tracker, será que uma ferramenta para gerenciar os bugs é realmente essencial? Será que eu não poderia gerenciar os bugs com post its mesmo? Se você trabalha com um quadro kanban (times que usam scrum geralmente usam um desse) você não poderia utiliza-lo para colocar uns post its de defeito também junto aos post its de atividades? No seu contexto pode ser melhor usar um bug tracker, mas se você não sente que está perdendo nada em não usar, eu acho muito mais prático, fácil e produtivo o uso de post it para isso.

Mas talvez você tenha mesmo que usar um bug tracker por N razões do seu contexto. Então, o que é importante ter um bug tracker quando eu vou reportar um bug? Eu considero como itens básicos:

. um título – um breve resumo de uma linha que faça com que o bug seja identificável facilmente
. como reproduzir e dados de teste
. ambiente em que o problema foi encontrado (se você testa em mais de um ambiente)
. criticidade – o quanto esse bug incomoda
. módulo – em que parte da aplicação foi encontrado
. evidência

Ai está uma coisa importantíssima. Já que você optou por usar um bug tracker, é bem provável que os defeitos que você abre não sejam corrigidos na mesma hora e esse já é um bom motivo para colocar uma evidência de que houve o problema. Isso facilita o entendimento do programador na hora de corrigir.

Na hora de reportar um bug, tenha certeza que você sabe que comportamentos você efetuou que desencadearam a praga.

. Teste com cuidado
. Reproduza o problema mais de uma vez
. Isole o problema, identifique a causa
. Generalize, veja outras áreas correlatas em que o mesmo problema ocorre
. Seja objetivo na sua descrição
. Revise o bug antes de submetê-lo na ferramenta, afinal, você é tester, mas também erra

Continuarei falando um pouco mais da palestra no próximo post.

Comentários são bem vindos :)

Quer ver os slides? Olha aqui no slideshare.

Quero ser um caçador de bugs - TDC-SP

Na próxima semana vou palestrar no TDC-SP! \o/
Estarei na trilha de testes university falando sobre bugs para a galera que está iniciando na area de testes.
O objetivo da palestra é discutirmos como nascem os bugs, como trata-los, o que é importante quando reportamos um bug, se ferramentas de bug tracking são essenciais, como entender melhor o projeto e desenvolver a equipe avaliando bugs.

Espero vocês lá! :)

Inscrições promocionais do Agile Brazil 2012 encerram-se próximo dia 25/06

A Agile Brazil é a mais relevante conferência brasileira sobre Métodos Ágeis de desenvolvimento de software.

Em 2012, a conferência será sediada em São Paulo no mês de setembro e não poderíamos planejar nada menos do que a maior conferência ágil do Hemisfério Sul, reunindo grandes empresas e os mais experientes profissionais do mercado brasileiro de agilidade, sem falar nos convidados internacionais de primeira linha. Todos eles estarão compartilhando suas experiências em cursos, palestras, workshops, relatos de experiência, debates e muito mais. Não perca!

Veja no site os convidados especiais e cursos da Virada Agil.

Precos promocionais ate 25/06 !!

www.agilebrazil.com.br

TDC Call4Papers

O TDC está chegando e a Call4Papers vai apenas até domingo! Você já submeteu a sua palestra? Já fez a sua inscrição e aproveitou os preços baixíssimos desse super evento? Não fique de fora. É uma super oportunidade de networking. Saiba mais

Pesquisa crowdtesting

Oi pessoal,

uma aluna minha da Unisinos está preparando a sua monografia sobre Crowdtesting como trabalho de conclusão da especialização.

Vocês já participaram de algum projeto assim? Essa parte da pesquisa tem o objetivo de fazer uma avaliação sob a perspectiva dos testadores. Agradeço se puderem responder o questionário abaixo. Ao final do projeto eu dou uma palhinha do trabalho aqui. :)

https://docs.google.com/spreadsheet/viewform?formkey=dHF6QzBTcHlPNHBScmRPWG91Z1VOZ1E6MQ

Novo blog sobre cursos de testes

Depois de fazer a pesquisa sobre especializações em Teste de Software pelo Brasil, que resultou em uma planilha com uma lista de cursos, criei o blog Avançando no Teste de Software.

O objetivo é ter um ponto de consulta de cursos em todo o Brasil. Por enquanto estou colocando os cursos de pós graduação indicados pela comunidade, mas a ideia é que o blog tenha cursos técnicos e inclusive graduações que possuam disciplina de Teste de Software.

Quer indicar um curso para o blog? Comenta no post de Introdução do blog Avançando no Teste de Software e eu vou criando as páginas.

Configurando visibilidade de produtos no bugzilla

A correria anda grande e quase não tenho postado, mas esse eu achei que valeria a pena vir compartilhar.

Precisei configurar o bugzilla para um grupo de beta testers utilizarem. O objetivo era que os beta testers reportassem os bugs na mesma ferramenta que já estamos usando internamente para reportar os bugs para o time de desenvolvimento, evitando retrabalhos como copiar descrições ou importar/exportar de outras ferramentas.

Até ai, tudo bem, mas como os beta testers estão testando livremente, sem nenhum treinamento na aplicação e não tem nenhuma formação em teste, eles podem abrir bugs que seriam apenas sugestões e não defeitos, ou ainda abrir defeitos em funcionalidades que não foram desenvolvidas, entre outros mal entendidos que enxeriam a caixa dos desenvolvedores de questões não pertinentes e acabariam atrasando o trabalho deles.

Para isso então, criamos módulos separados dentro do mesmo projeto que seriam visíveis apenas para os beta testers enquanto os bugs já conhecidos, que os desenvolvedores já estão trabalhando, ficariam visíveis apenas para a equipe interna. E ai começou a trabalheira de encontrar como poderíamos omitir alguns produtos para uns e outros produtos para outros usuários.

O caminho natural foi procurar no manual do bugzilla, mas apesar de o manual explicar os parâmetros do bugzilla, ao menos para minha equipe não ficou claro como fazer o passo a passo para que funcionasse. Fuçando no google e no bugzilla, encontramos uma solução:

Menu Administration > Parameters > Group Security

Tem um parâmetro chamado usevisibilitygroups que deve ser ligado:

Feito isso, será necessário criar dois grupos de usuários. Esse foi o nosso erro mais insistente. Imaginamos a principio que como todos já estavam vendo os bugs, seria necessário criar apenas um grupo e limitar a visualização desse grupo. Mas na verdade não conseguimos fazer funcionar assim. Apenas quando criamos os dois grupos conseguimos gerenciar corretamente a visualização.

Para criar os grupos:

Menu Administration > Groups > Add Group

Há uma explicação no próprio bugzilla sobre como preencher os campos abaixo:

Lembre-se, crie os 2 grupos!

Agora vamos setar a visibilidade desses dois por produto.

Menu Adminsitration > Products e escolha um produto

Agora para cada produto será necessário dizer quem ve e posta bugs neles e quem não vê (e consequentemente não posta bugs).

Acesse um produto e vá em Edit Group Access Controls. Devem aparecer os dois grupos criados. E essa foi a configuração que funcionou pra nós.

Configuração para produtos acessíveis apenas pelos beta testers:

Configuração acessível pelos outros usuários que não são beta testers:

E não esquecer o mais importante agora: colocar cada usuário no grupo correto.

Menu Administration > Users > Search

Espero que você não tenha muitos usuários no sistema, agora será necessário atualizar um por um.

Observação: Nesse caso em que setamos a configuração de acesso para todos os produtos e todos os usuários, usuários novos que não pertençam a nenhum grupo não poderão abrir bugs.

Espero que o post seja útil para economizar um tempinho para você ou, se você tiver um jeito mais pratico, faz um post e linka aqui. :)