QualidadeBR no Twitter!

(Não, eu não vou falar que é uma inovação estar presente no Twitter, pois não é mais.)

Fazia tempo que eu tinha criado uma conta pro QualidadeBR no Twitter, porém só hoje comecei a usar pra valer.

Demorei esse tempo todo, pois no começo pensei que não era necessário ter uma conta só pro QualidadeBR, já que usava a minha pra divulgar o conteúdo do blog. Além disso, não estava a fim de ficar gerenciando mais uma conta no Twitter (rs).

No entanto, a minha conta pessoal no Twitter é uma “zona” (no bom sentido), lá eu falo de muitas coisas (tento evitar, tweets daqueles “estou na fila do banco #quesaco”, mas às vezes sai alguns rs). Outra coisa, foi que usando o Twitter eu percebi o quanto ele pode ser útil (sim, antes eu não via sentido em usar ele). E percebi também que a grande maioria dos testadores brasileiros não tem Twitter ainda.

Então o primeiro objetivo do twitter do QualidadeBR é ser um lugar para as pessoas verem quem está no Twitter, e que seria interessante seguir, além é claro divulgar o conteúdo publicado aqui, dicas e o conteúdo que a nossa comunidade publica.

Se você por exemplo quer saber quais profissionais da área estão no Twitter, você pode seguir duas listas do QualidadeBR:

  • Profissionais do Brasil: lista com os profissionais brasileiros que atuam na nossa área (se você atua na área e o seu perfil não está lá, me avise por favor);
  • Profissionais de fora: lista com os profissionais de fora do Brasil que atuam na nossa área.

Ambas as listas estão com 28 pessoas cada, e irei atualizar ambas conforme for encontrando novas pessoas.

Essas listas podem ter duas utilidades para você:

  • Conhecer as pessoas e seguir elas;
  • Seguir a lista. Desta forma você irá receber todos os updates das pessoas que estão na lista.

Além disso, estarei retweetando informações de vagas de emprego na área. Embora isso possa acabar poluindo a timeline do QualidadeBR, se acontecer, eu uso um perfil exclusivo para divulgar as vagas. 🙂

Então se você ainda não tem um Twitter, recomendo fortemente você criar a sua conta lá, afinal agora você pode fazer um uso efetivo dele logo de cara: conhecendo os profissionais da área, se informando a respeito de vagas e recebendo dicas e links com conteúdos da área de Teste e Qualidade de Software.

Siga o QualidadeBR no Twitter em: http://twitter.com/qualidadebr

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.

O melhor da semana 05/12 a 11/12

Pessoal,

Segue abaixo o “melhor da semana”. Desta vez o destaque é o post do Shmuel Gershon, com as suas impressões da palestra do Markus Gaertner, onde ele mostrou que há vários caminhos que podemos trilhar para aprender “sozinhos”  Teste de Software e também para o post com vários videos diretamente da Eurostar, legendados em inglês, com grandes nomes do Teste de Software Mundial.

Conhecimento a um clique, esse é o QualidadeBR. 🙂

Abraços! E tenham uma ótima semana!

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

Simulados Online da CTFL

O Fábio Martinho divulgou na lista do Quality Assurance vários simulados da CTFL. Segue abaixo, os links:

Os simulados estão em inglês e o resultado é apresentado, após você completar ele. Uma boa para quem está se preparando para a CTFL do ISTQB/BSTQB.

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

Qual o objetivo do Teste de Software?

Minha resposta para essa pergunta é bem simples e direta: obter informações.

Na lighting talk dada pelo Shmuel Gershon na EuroStar desse ano, ele fala sobre isso de uma maneira bem didática (vale a pena assistir!).

Não que as outras respostas estejam erradas, muito pelo contrário. Mas percebo que algumas são muito extensas e particularmente, gosto de simplificar as coisas.

Mas dentre as possíveis respostas para a pergunta do título desse post, há uma perigosa: encontrar bugs.

Seria como se eu perguntasse para um policial, qual o objetivo do trabalho dele e ele me respondesse que é prender os bandidos. Na verdade, esse é só um dos objetivos do policial, e encontrar bugs é só um dos objetivos do Teste de Software.

E o perigo para nós profissionais de Teste de Software, é quando os outros pensam que a nossa tarefa é só essa, ou pior ainda, quando nós mesmos nos limitamos a fazer apenas isso.

Durante a exploração do software, não podemos ficar esperando encontrar apenas bugs, precisamos focar em encontrar informações. Como o próprio Shmuel disse: ao obter uma informação, ao invés, de se perguntar se ela é algo ruim, podemos nos perguntar “o que podemos concluir a partir dessa informação?”. Parece ser a mesma pergunta, mas não é.

Além do mais, se você focar apenas em encontrar bugs, poderá perder facilmente a motivação, pois haverá dias em que você não encontrará nada, porém se você focar em obter informações, dificilmente passará um dia sem ter obtido uma informação interessante.

Notícias ruins é o que faz vender o jornal (rs) ou prender a atenção a TV, mas não se restrinja apenas as tragédias, há vários outros tipos de informações que podem ser até mais relevantes para a equipe, e que ajudarão eles a melhorar o sistema. E você não será mais visto, como o portador de notícias ruins (rs).

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

A importância da qualidade interna

A primeira vez que percebi o quanto a qualidade interna é importante, foi quando li o livro Scrum e XP direto das Trincheiras. Nele o Henrik Kniberg destaque que a qualidade interna do sistema é mais importante que a qualidade externa, tanto que ela é de responsabilidade da equipe e nunca (quase nunca) negocíavel com os clientes. E realmente é difícil discordar, uma vez que a qualidade interna irá acabar refletindo na qualidade externa do sistema, tanto que segundo o próprio Henrik: “[…] um sistema com baixa qualidade interna raramente terá uma qualidade externa alta.”

Mas qual a diferença entre qualidade interna e externa?

Em suma, qualidade interna é o sistema visto da perspectiva técnica, enquanto a qualidade externa é a visão do sistema, da perspectiva funcional.

Uma analogia seria a de uma montagem de um computador, você pode montar um computador com peças de vários fabricantes, e para o usuário pouco importará se a placa mãe é uma Asus, ou uma PCChips. O que o usuário verá será a qualidade externa, se o gabinete tem um design atraente se o computador não trava, essas coisas. Ele pouco irá importar se a memória RAM é Kingston ou não. O que importa na perspectiva funcional é realmente o funcionamento do computador e não como ele foi montado.

O que ocorre muito, é que há uma forte tendência no desenvolvimento do sistema ser guiado pelo “funcionou”, sendo que o “funcionou” pode ser um estado ainda crú da implementação da funcionalidade.

Monalisa

Citei a Monalisa no post anterior, desta vez ela será útil para nós, para entender como o processo de desenvolvimento de um software, é muito mais próximo do processo de pintura de um quadro, do que de um processo de construção civil.

Pesquisando na Internet encontrei informações de que a Monalisa foi pintada entre 1503-1514. Nesse período de mais de 10 anos, boa parte do tempo investido no quadro, foi em alterações técnicas, a base sempre foi permanecida.

Em outras palavras, podemos dizer que Leonardo Da Vinci levou 11 anos para finalizar o seu projeto, e boa parte do tempo, foi investido na manutenção do quadro, realizando refatorações e correções de bugs.

Uma característica que suponho que seja comum no processo de pintura de um quadro, principalmente quando ele é uma demanda, é a mudança constante. E mudança é uma das poucas certezas que temos no desenvolvimento de software, afinal um bom software está “sempre” em constante evolução/melhoria e quanto mais fácil for inserir mudanças no software, melhor será.

Mudar software é mais difícil do que mudar hardware

Vamos fazer uma breve viagem no tempo, o ano é 1946 e você está de frente ao ENIAC (foto abaixo). Se você perguntar para a pessoa na foto: o que é mais fácil mudar, o hardware ou o software? Ele com certeza, irá responder que é o hardware, e ainda irá achar a sua pergunta estúpida.

Agora voltando a 2010. O que é mais difícil, mudar o software ou o hardware?

Não há dúvidas que o software, não é? Hoje obter harware é MUITO fácil e barato, comparado a 1946. E com as VPSs da vida, ficou fácil obter hardware e uma ótima infraestrutura, você nem precisa sair de casa para ter o seu servidor rodando.

Monalisa, ENIAC, computação em nuvem e qualidade interna

Onde eu quero chegar com tudo isso?

Acredito que ficou claro que um dos grandes desafios para se desenvolver um software é conseguir mudar ele com o menor esforço necessário, mantendo o seu bom funcionamento. Costumo até dizer, que desenvolver software é fácil, comparado a manter o software.

Mas eu estou errado, pois desenvolver o software deveria ser mais difícil do que manter ele. Porém, seja por motivos externos (mudança frequente/drásticas de funcionalidades pelo cliente) e/ou motivos internos (pouca cobertura de testes, design fraco, falhas de comunicação, etc), manter o software acabou se tornando um tarefa mais difícil, do que a criação dele.

Voltando ao exemplo da Monalisa, vimos que Leonardo Da Vinci passou boa parte do tempo fazendo correções e melhorias no quadro, porém a sua essência foi mantida. Supunho que ele tenha feito um bom “design”, que permitiu inserir as correções e melhorias sem ter enfrentado maiores problemas.

O caso do ENIAC é interessante, pois mostra como as coisas mudaram MUITO do início da computação até hoje. Naquela época, e por um bom tempo, o hardware era o mais valorizado. Já hoje o software passou a ser o mais valorizado. E se antes os softwares eram escritos em cartões perfurados e pouquíssimas pessoas eram capazes de desenvolver software, hoje escrevemos software em linguagens quase naturais e conseguimos aprender a “desenvolver” por meio da Internet e de graça.

E a qualidade interna é peça fundamental para podermos conseguir alterar o código de forma “indolor”. E essa é apenas uma das vantagens que desenvolver software com uma boa qualidade interna traz. E vamos concentrar nela no próximo tópico.

Qualidade Interna

Qualidade interna também poderia ser traduzida em “fazer a coisa da forma certa”. Porém, essa tradução é muito simples e faz parecer que obter qualidade interna é fácil. Afinal seria só saber como fazer a “coisa” da forma certa, não é mesmo?

No entanto, há várias formas de fazer da forma certa no mundo do desenvolvimento de software. Por isso, uma das tarefas do desenvolvedor é fazer escolhas, e serão essas escolhas que irão influenciar diretamente a qualidade interna do software.

Os retornos com o investimento em qualidade interna ocorrem a médio e longo prazo, por causa disso, muitos acabam fazendo as escolhas “certas” a curto prazo, mas esquecem de avaliar o impacto que elas terão a médio e longo prazo.

E uma vez que escolhemos o caminho mais fácil, por exemplo adicionar mais um if, para atender uma alteração que o cliente pediu, ao invés, de extrair o comportamento para outro método, a tendência é acabar sempre escolhendo o caminho mais fácil.

Esse hábito, acaba sendo passado para os outros é acaba virando uma “cultura”. E aí, o caminho fácil será sempre tomado, e a possibilidade de tomar outras direções poderá nem passar pela cabeça mais. Sendo que essas direções diferentes, muitas vezes não representam um caminho difícil (ex.: escrever testes unitários), mas a mudança em si, é a parte difícil.

Desta forma, a qualidade interna acaba sendo colocada de escanteio. Porém, ao longo do desenvolvimento irão aparecer os sinais de que ela está muito baixa. Por exemplo: lançar uma nova versão demora cada vez mais tempo.

Como Obter Qualidade Interna

Algumas ações podem ajudar a desenvolvermos um software com uma boa qualidade interna:

  • Refatoração: alterar o código sem alterar o seu comportamento, focando na melhoria do código para favorecer a manutenibilidade dele;
  • Conhecer e utilizar boas práticas: princípios como o SOLID, ajudam a resolver os problemas com menos ruído e com soluções que favorecem a manutenção do software;
  • Comunicação: uma boa comunicação é essencial para o desenvolvimento do software, tanto externa (cliente), como interna (equipe). Muitos bugs acabam sendo inseridos e códigos duplicados, simplesmente porque houve falha na comunicação;
  • Estressar as soluções: geralmente, costumamos implementar a primeira solução que nos vem na cabeça, porém esquecemos que a primeira solução costuma não ser a melhor, por isso é importante pensar em outras formas de solucionar o mesmo problema e/ou conversar com alguém sobre;
  • Aprendizado contínuo: é importante estar sempre nos aperfeiçoando, se você for olhar algo que fez há 6 meses atrás e achou que não tem nada a ser melhorado, é sinal que você não aprendeu muito nos últimos 6 meses;
  • Saber quando parar: saber o momento de parar de ficar refatorando o código, é tão importante quanto saber quando é preciso melhorar ele, objetive a perfeição, mas não fique cego por ela;
  • Valorize o seu tempo: a vida é muito curta para ficar gastando tempo tentando entender aquele método com mais de 30 linhas que você escreveu há 3 meses atrás, ou ficar corrigindo bugs que poderiam ter sido encontrados antes com testes. Só nestes momentos, que você realmente percebe, o quanto a qualidade interna é importante;
  • Testes: por último e não menos importante, escreva testes. Além deles auxiliarem você a pensar melhor sobre as funcionalidades (se você usar TDD), eles irão te dá a tranquilidade necessária para refatorar o código. Afinal, refatorar sem testes, é algo muito difícil e arriscado, e isso incentiva a não refatoração e por consequência a uma baixa qualidade interna, portanto, escrever testes é fundamental para obter uma boa qualidade interna.

Conclusão

Enquanto a qualidade externa é a percepção do cliente para o software, a interna é a percepção dos desenvolvedores em relação a ele.

Devemos nos preocupar em manter uma boa qualidade interna, pois ela é essencial para a manutenção do software, e em cenários onde há entrega contínua do software (ex.: SaaS), a qualidade interna acabará sendo uma diferença competitiva. Afinal, uma das únicas certezas que temos no desenvolvimento de software, é que haverá mudanças, portanto, conseguindo reagir à tempo a elas, é fundamental para conseguir atender as demandas.

Os testes mais uma vez, representam um papel importante, pois é através deles que teremos a segurança necessária para refatorar o nosso código, implementar as alterações e novas funcionalidades.

Como anda a qualidade interna dos projetos que você está participando? A equipe tem consciência da sua importância?

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