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. :)