Bug no Gmail

Estava desenvolvendo a funcionalidade de aplicação de tags para as menções no Vizir, e durante o desenvolvimento tomei como base do comportamento dessa funcionalidade,  a aplicação de labels do Gmail.

Durante o estudo do funcionamento da criação dos labels no Gmail, acabei encontrando um bug interessante, que mostra bem como nem sempre podemos cobrir todas as situações de erro, uma vez que elas são muitas.

Para quem não conhece essa funcionalidade do Gmail ou não usa o Gmail, segue uma breve explicação sobre ela:

Você quer aplicar um label (marcação) para um e-mail, por exemplo: todos os e-mails de promoções com o label “promoções”. O que essa funcionalidade faz, é exatamente prover uma maneira de aplicar labels aos seus e-mails.

Vamos direto em como reproduzir o bug:

  1. Clique no checkbox ao lado do e-mail que você quer aplicar o label;
  2. Clique no combo-box Labels;
  3. Clique na opção Create new (um pop-up irá aparecer);
  4. Digite o nome do seu label e clique no botão OK (“OK” para um botão de criação é estranho hein, poderíamos sugerir uma melhoria).

Pronto, viu o bug? Não?

Sem um screenshot fica difícil, neh. Segue abaixo uma imagem com cada passo feito, clique nela para visualizar numa resolução maior .

E agora viu o “danado”?

Se você nunca usou essa funcionalidade dessa maneira (tem como usar ela criando filtros pré-definidos), está descontado. Mas se você já usou deve/deveria ter reparado que faltou algo.

Quando você aplica um label na mensagem duas coisas acontecem:

  • Uma mensagem aparece em cima da box dos e-mails, avisando que a “conversação” foi adicionada no label (The conversation has been added to “qualidadebr”.)
  • O e-mail/conversação é marcado com o label.

O que faltou foi a segunda forma de notificação, o label não foi adicionado no e-mail (visualmente, se você atualizar a página irá visualizar o e-mail com o novo label). O interessante que esse bug só ocorre quando você aplica um novo label ao e-mail, se você for aplicar um label já existente, o bug não irá ocorrer.

Abaixo, o resultado esperado:

Pelas entranhas do bug

Com a explicação acima um bom desenvolvedor já iria descobrir o porquê do bug existir.

O que ocorre por de trás das câmeras quando você aplica um label ao e-mail, é que uma atualização via AJAX é feita em duas partes da página: no div da mensagem e no div dos labels.

O problema não é que a atualização não é feita no div dos labels, e sim que o elemento não é adicionado, provavelmente porque o novo label não foi adicionado na varíavel que contém os labels.

E como saber tudo isso?

Te contar que nem precisa entender muito de Javascript e HTML. Utilizando o formidável Firebug você já consegue observar esse comportamento. Difícil é entender o HTML gerado pelo javascript do Gmail (se estiver curioso em entender um pouco como o Gmail funciona esse artigo pode ser útil).

Como solucionar esse bug?

Eu passei pelo mesmo problema na implementação da funcionalidade de aplicação de tags nas menções no Vizir. A solução que encontrei foi dá um refresh na página, quando uma nova tag é inserida. Desta forma, o objeto que armazena os labels já é atualizado com o novo label.

Não deve ser a solução mais linda e elegante, talvez seja possível atualizar a lista de labels do combo-box, via Javascript. Mas como eu não sei fazer isso (preciso dá uma pesquisada se é possível e como fazer [canelada pra mim]),  e essa solução se comportou bem e foi eficiente para o problema que enfrentei. 🙂

Como esse bug escapou dos jardins do Google?

Sou usuário do Gmail desde 2007, e desde lá, só uso ele como cliente de e-mail, tanto para uso pessoal como profissional. E só no começo desse mês que encontrei esse bug.

Ou seja, acredito que este bug não se apresenta com tanta frequência, pois nem todos usuários utilizam esse recurso (diria até, que uma minoria utiliza). Além disso, o uso mais frequente dos labels, pelo menos o uso que mais faço e vejo as pessoas fazerem, é na criação dos filtros.

E a equipe de Teste de Software do Gmail, por que será que eles não encontraram esse bug?

Tenho duas especulações quanto a isso:

  • Encontraram o bug, porém como a sua ocorrência não é tão frequente e sua presença não atrapalha muito o usuário, o bug ainda não foi corrigido (tá na fila no bugtracking deles, com prioridade baixa);
  • Não encontraram, pois não tinham um caso de teste que cobria esse cenário.

A grande lição que podemos tirar com esse bug, é que um sistema pode muito bem ir para produção, ser super bem elogiado pelos usuários e mesmo assim conter dezenas de bugs (eu conheço uns 3 ou 4 só do Gmail rs). Se você for querer ser perfeccionista ao extremo, você nunca irá colocar um sistema em produção. Um sistema sem bugs não é algo comum, e esse fato é até justificável, é só olhar para as pessoas que desenvolvem e usam os sistemas, elas são perfeitas?

Fique por dentro das novidades, assine o feed do QualidadeBR.

Anúncios

Bug na criação de listas no Twitter

Estava criando uma lista no Twitter do QualidadeBR (comecei a twittar hoje com ele, num outro post falo sobre o objetivo dele) e me deparei com um erro de usabilidade do Twitter.

Segue abaixo os detalhes do bug:

Título: Não aparece uma mensagem de erro, quando o nome da lista excede o limite de caracteres

Descrição: Não aparece uma mensagem de erro, quando eu tento criar uma lista com um nome longo, mais de 25 caracteres para ser preciso, e a lista não é salva.

Como reproduzir:

  1. Vá na sua página de listas;
  2. Crie ou altere uma lista;
  3. Preencha “List name” com um nome com mais de 25 caracteres (ex: “lista com mais de 25 carac”)

Um bug clássico de usabilidade, que vai contra a primeira heurística do Nielsen “Visibilidade e Estado do Sistema“. Além disso, uma melhoria poderia ser adicionada, seguindo a terceira heurística do Nielsen “Prevenção de Erros“, simplesmente adicionando um texto ao lado do campo, avisando o limite de caracteres, ou de uma forma mais elegante, adicionando uma validação via AJAX (usando o live validation por exemplo).

Em relação ao reporte do bug, ele é bem simples, já que o bug é simples. O maior trabalho é descobrir o limite de caracteres que são aceitos no campo, o que acaba sendo feito na tentativa e erro mesmo.

Abri um ticket no Twitter reportando o bug, porém recebi um e-mail avisando que eles estão de recesso (pena que os bugs não entram de recesso rs), e o ticket acabou sendo fechado (estranho que como resolvido).

Fique por dentro das novidades, assine o feed do QualidadeBR.

Quem é o grande vilão do Teste de Software, o bug ou o tempo?

A 20ª Mesa Redonda DFTestes teve como tema “Quem é o grande vilão do Teste de Software, o bug ou o tempo?”. A discussão teve 9 respostas e participantes, sendo eles: eu, Sarah Pimentel, Luís Barros, Shmuel Gershon, Rodrigo Almeida, Felipe Silva, Elias Nogueira, Humberto Barboza e Talita de Oliveira.

Abaixo, faço um “resumo” de como foi a discussão, sempre lembrando que quem quiser ela na íntegra é só acessar esse link (é necessário se inscrever no DFTestes).

Quem é o grande vilão do Teste de Software, o bug ou o tempo?

Segundo a Sarah Pimentel:

Tanto o tempo quanto os bugs são vilões, quem está sendo pior depende do projeto, eu acho. Existe tanto aqueles sistemas onde nenhuma pratica de prevenção de defeitos foi aplicada e chegam com bugs críticos que bloqueiam e atrasam testes, quando os projetos nos quais a definição de requisitos atrasou, a arquitetura atrasou, o desenvolvimento atrasou mais ainda e o tempo do teste ficou reduzido a 25% do que era antes e claro que sempre esperam que a equipe de testes faça milagres porque só ela não pode atrasar.
Quanto aos bugs podemos atacá-los através de processos de prevenção de defeitos e quanto ao tempo, revisando o planejamento, implementando um processo de gerenciamento de mudanças e procurando alinhar a equipe de vendas (normalmente o tempo começa a ser um problema já na venda do projeto) o que realmente é possível entregar no tempo acordado.
Apesar do desejo intimo de ter a aplicação 100% testada, sabemos que isso é dito como impossível. Para isso, há algumas técnicas que nos ajudam a selecionar/priorizar testes para que possamos aproveitar nosso tempo da melhor maneira possível.

O Luís Barros deu a sua opinião dizendo:

Na minha opinião o TEMPO hoje é o grande vilão do teste de software.

O TEMPO compromete as verificações de documentação que, antes mesmo de ter uma aprovação formal já estão na mão dos desenvolvedores, pois o prazo já está apertado;
O TEMPO faz o desenvolvedor passar por cima dos testes unitários e de integração;
O TEMPO faz o prazo do time de teste ser reduzido. Aliás, a gente sofre muito com isso, pois o que é cortado primeiro de um projeto é sempre o teste;
O TEMPO faz um projeto ser “baseado em funcionalidade” (Funcionou tá bom!), onde só o “Caminho Feliz” importa.

E finalmente…
O TEMPO causa mais bugs pois, se tudo o que foi mencionado não acontecesse, certamente teríamos um software com muito menos bugs

Uma frase que já ouvi muito de caciques: “Não entregar tem um impacto muito maior do que entregar com erros!”

O Shmuel Gershon tem uma opinião diferente do pessoal:

Vilões? Ahn?

Primeiro, por que o bug seria um vilão? Se fosse um vilão, não ficaríamos tão feliz de achar um.
Acho que os bugs, longe de ser os vilões, são nossas bat-ferramentas, essenciais para sermos bons heróis. São eles que nos permitem aprender, e que nos permitem ensinar e transmitir informação adiante.

Segundo, por que o tempo? Tempo é o melhor amigo da qualidade de software. Se não tivessémos tempo suficiente, não ia dar pra fazer nada direito!
E a falta de tempo? Outro melhor amigo da qualidade, especialmente porque este fica do lado do cliente, defendendo seu valor — já pensou se ainda não tivéssemos recebido o Windows 97? não teria como avançar a tecnologia até chegar no Win7.

Bugs e Tempo, para ser vilões, só neste link e neste link. 🙂

O verdadeiro vilão dos testes, sou eu.
(não, não por que eu fico aqui contrariando todo mundo na DFTestes!)
Mas por que eu concordo com mas decisões, em vez de trabalhar com meus gerentes para tomar a decisão certa.
E porque eu não sou capaz de explicar toda a extensão do impacto de uma mudança no cronograma.
E porque as vezes uso métricas que em vez de ajudar, estão atrapalhando a operação.

É dura, esta vida de herói e vilão ao mesmo tempo…

Minha linha de pensamento sobre o assunto é bem parecida com a do Shmuel.

Todos são culpados! Até que se prove o contrário.

Em algumas organizações é muito fácil botar a culpa em fulano ou ciclano, principalmente, quando temos caciques (como lembrou o Luís), ou pessoas que gostam do poder, de tomar decisões sozinhas, etc.

Eu particularmente, vejo que o desenvolvimento de software é algo muito complexo, para um único ser humano levar a culpa. E por isso, sou a favor de quando algo de ruim acontece (“shit happens”), todos sentarem para buscar os fatores e a causa raiz para aquele problema ter ocorrido, deste modo todos evoluem e tem a oportunidade de discutir.

Nenhum dos dois são vilões, são apenas efeitos causados por seres humanos.

Porém, “o primeiro” bug, era sim um vilão, aquela traça maldita! rsrs

Hoje acredito que nenhuma falha acontece por causa de uma trasa, elas acontecem porque pessoas desenvolveram aquele sistema. E pessoas cometem erros, lembre-se errar é humano.

E como o Shmuel disse: “É dura, esta vida de herói e vilão ao mesmo tempo…”

O Rodrigo Almeida enfatizou a importância de termos um processo alinhado com a equipe de desenvolvimento, para podermos tornar o tempo o nosso amigo:

É preciso ter estratégia.

Estratégia para achar o bug nos testes críticos.

Tem que ter processo definido e alinhado com a equipe de desenvolvimento.

Desta forma o tempo vira aliado e não inimigo!

Segundo o Felipe Silva:

–  O tempo é um fator neutro, quem faz ele parecer mau ou bom é a “áurea espiritual da entidade responsável pela estimativa e cronograma”, se está estiver acima do “limite mortal humano” então o tempo leva a culpa mesmo sendo algo constante, caso contrário o tempo leva a culpa pelo desperdício de orçamento? Esta segunda resposta é única e exclusiva da “índole da(s) entidade(s) superior(es)”. Falando claramente tempo vilão = planejamento não reflete a realidade, isso também não quer dizer que o planejador é o culpado, a não ser que ele seja capaz de prever o futuro, mas ele é no mínimo cúmplice (rs).

– O bug pode ser um vilão, principalmente para nós responsáveis pela qualidade, mas é este também “paga meu salário todo mês”, estão se eu colocasse em uma balança ele é mais meu amigo do que meu inimigo, sobre o bug só posso dizer ele é mais previsível do que o tempo, embora não seja possível testar 100% do software é possível testar a parte mais usada e deixar o bug hibernando por tempo indeterminado, contanto que este não acorde ninguém vai reclamar.

Se for para pesar Tempo x Bug eu diria que o tempo tem maior peso, pois a falta deste primeiro ajuda o segundo ser um risco maior.

O Elias lembrou bem, que muitas vezes o grande vilão é a cultura da empresa:

O principal vilão do Teste de Software é a cultura!!!
Em um software de missão crítica ou relacionados (aviões, máquinas médicas, etc…) nem o tempo nem o bug serão um “vilão”, pois a cultura cultivada dentro de uma organização que desenvolve e testa um software dessa linha está preocupado com a qualidade.

O que nós enfrentamos no nosso dia-a-dia é prazos curtos e uma quantidade grande de bugs dado também a pressão colocada sobre a área de desenvolvimento para entregar ‘qualquer coisa’ de uma forma mais rápida.

Uma empresa que preza por uma cultura de qualidade dificilmente terá como o vilão o bug ou o tempo!

O Humberto Barboza deu a sua opinião dizendo:

Respondendo a pergunta e concordando com alguns, dentro do nosso paradigma de teste de software o tempo é o grande vilão.

Infelizmente para a nossa atividade nunca dispomos dele para realizar o trabalho ótimo. E na grande maioria das vezes somos obrigados a fazer o melhor trabalho que pode ser feito, priorizando as atividades, dentro do tempo que dispomos.

Claro que essa discussão como já pudemos perceber nessa mesa redonda envolve muitas variáveis: a cultura da organização passada hierarquicamente abaixo de que o teste pode ser cortado se não houver tempo, a pressão sobre a equipe de desenvolvimento que entrega o produto sem a qualidade esperada porque não realizou devidamente os testes unitários e de integração, a pouca importância dada a fase de planejamento dos testes e a adoção da estratégia “Sair fazendo” sem o devido planejamento, padrões engessados (inclusive estou sofrendo pra caramba com isso no momento, porque adotamos o Scrum, mas, com os padrões de documentos existentes hoje é inviável trabalhar e estou tendo que pensar no meio do sprint, por que não houve tempo antes rsrs, em como adaptar e gerar métricas no cenário atual visto que sequer utilizamos uma ferramenta de controle de defeitos).

Liderança desinteressada que deixa exclusivamente a cargo do QA todas decisões, por hora acho que é isso.

A Talita de Oliveira respondeu a pergunta dizendo:

Bom, pelos projetos que atuei, a maioria dos problemas em fase de teste foi o tempo, mas no meu ponto de vista uma coisa leva a outra, como disse o Humberto tem a ver com a cultura da empresa. Digo que uma coisa leva a outra pelo fato da pressa, como já diz o ditado que pressa é inimiga da perfeição, dificilmente um time de testes por mais competente que seja não conseguirá entregar um projeto com a % mínima de bugs se não houver tempo. E essa falta de tempo acontece porque a fase de testes na maioria dos projetos está no final, pelo menos é assim que tenho trabalhado…em fases finais.
E quanto a equipe de testes aceitar desafio, é normal, pois ao longo da minha experiência a pressão sempre foi alta porque ouvi sempre: “Vocês são a parte final do projeto” ou “Vocês que dirão se a aplicação está ok ou não”. Então..acho que não só a equipe de testes é culpada, mas todos os envolvidos tem sim sua parcela de culpa.

Por que gostamos tanto de terceirizar a culpa?

A Sarah Pimentel lembrou que é sempre mais fácil terceirizar a culpa:

Se eu assumo que a culpa é minha ou que eu tenho qualquer responsabilidade sobre o que está acontecendo, eu sou forçada fazer algo a respeito. Se eu jogo a culpa no outro, o problema é dele e ele que se vire pra resolver, não impacta no meu dia a dia. Fiz uma vez um treinamento de relações humanas e meu professor me disse algo óbvio: não podemos mudar os outros, a não ser que eles mesmos estejam procurando uma mudança. Então se há uma situação que você quer resolver, ao invés de esperar pelo outro, procure em você o que você pode fazer para mudar a situação e naturalmente (na maioria das vezes) o outro vai ser influenciado pela sua mudança de comportamento.

Na minha opinião é da natureza do ser humano culpar o próximo. A Dorothy Graham falou um pouco sobre isso no CInTeQ 2010, contando que irmãos mais velhos, gostam de colocar a culpa nos mais novos (eu mesmo fiz isso muitas vezes rsrs).

Quando crescemos aprendemos que podemos botar a culpa não são nas pessoas, mas também no processo, metodologia, ferramenta, bug, tempo, etc. E assim fazemos, quantas vezes você já ouviu falar que vários projetos falharam por causa que usavam o modelo Cascata. Mas quem escolheu usar o modelo Cascata? As pessoas não foi!?

Segundo o Humberto Barboza:

Infelizmente quase nunca fazemos um “Mea Culpa”. Concordando com o que foi dito já na lista, boa parte da culpa é nossa que por gostar de desafios ou situações desafiadoras, aceitamos irresponsavelmente trabalhar com tempo reduzido, padrões engessados, ausência de ferramentas adequadas e até liderança inoperante, infelizmente. Tecnicamente erramos por exemplo estimando mal nosso trabalho, priorizando atividades menos relevantes e cedendo às pressões do nosso meio. Precisamos defender o nosso trabalho e demonstrar a importância de ser bem planejado, projetado e executado e qual o impacto na qualidade do produto e as consequências que pode ter.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Fique por dentro das novidades, assine o feed do QualidadeBR.

O que é bug?

O uso do termo bug já é antigo, dizem que ele foi criado por Thomas Edison quando um inseto causou problemas de leitura em seu fonógrafo em 1878.

O primeiro bug em computadores possivelmente ocorreu em 1947. Quando os engenheiros que trabalhavam com o Harvard Mark I, o primeiro computador digital automático de larga escala desenvolvido nos EUA, encontraram uma traça entre seus circuitos, que causou um erro nos cálculos da máquina, prenderam-na no livro de registro e rotularam-na como o “primeiro bug” encontrado, como vemos na figura 1.

Naquela época, havia literalmente bugs, devido as proporções gigantescas dos computadores (figura 2), que serviram de abrigo para vários insetos e até para ratos. Situação essa, que em muitas vezes ocasionava problemas no sistema.

O primeiro bug.

Figura 1 (retirada do myoldmac)

Harvard Mark I, o primeiro computador digital automático de larga escala desenvolvido nos EUA.

Figura 2 (retirada de IBM Archives )

Mas e hoje, em pleno século XXI por que os bugs ainda fazem parte das notícias de TI e são tão freqüentes?

Errar é humano.

Essa frase tão prolixa é o motivo da existência dos bugs, afinal por mais experiente que seja o programador, ele também é humano (embora alguns duvidem) e passa por dias ruins. No entanto, não é no desenvolvimento que ocorre a maioria dos bugs, segundo informações do QAI (Quality Assurance Institute), 36% dos erros encontrados nos softwares são provenientes da codificação, e os outros 64% são erros de desenho e análise.

Um exemplo dessa proporção é o bug mais famoso do mundo, o bug do milênio. Quem não se lembra do temor causado na passagem do ano de 1999 para 2000, devido ao armazenamento de datas com apenas 2 dígitos para o ano, ficando os restantes implicitamente entendidos como sendo “19”. Desta forma cada data armazenada deixava de ocupar oito bytes (dois para o dia, dois para o mês e quatro para o ano), e passava a ocupar somente seis bytes (somente dois no ano). Assim, quando o calendário mudasse de 1999 para 2000 o computador iria entender que estava no ano de “19” + “00”, ou seja, 1900.

E a decisão do uso de apenas 6 bytes, ocorreu devido a necessidade real de economia de memória e espaço de armazenamento. Hoje isso parece insignificante, mas na época isso foi o suficiente para justificar a adoção do padrão, tamanho o custo das memórias e dispositivos de armazenamento.

Para resolver o problema, velhos programadores de COBOL foram tirados da aposentadoria, para voltar a trabalhar em sistemas muitas vezes desenvolvidos por eles mesmos, vinte anos antes. Pagando-se a eles 1 dólar por linha revisada.

O bug do milênio foi um marco para a Qualidade e Teste de Software, no qual percebeu-se o quanto uma falha pode custar caro e como até mesmo o risco de tal, pode abalar empresas e levar a perda de dinheiro e credibilidade. Tirando como lição aprendida a importância do processo de testes, durante o desenvolvimento do software, para que se possa minimizar a probabilidade e o impacto dos riscos e diminuir o número de defeitos.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://pt.wikipedia.org/wiki/Bug_do_mil%C3%AAnio

http://www.clubedohardware.com.br/artigos/492/3