A ilusão do “Tá tranquilo, Tá favorável!”

 

Olá!

Pessoal, estou sem computador em casa, quer dizer…tem o da minha mãe, mas é muito desconfortável escrever nele , por isso não estou postando com a frequência esperada, tem um post agendado para o final do mês, e decidi passar aqui só pra fazer um post bem simples 🙂

Esse post é mais pra dar uma reforçada para tomarmos cuidado com aquela ilusão de que determinada função vai passar sem nenhum erro….

Continue lendo

Diário de um bug

Olá!

Ano passado eu tinha lido essa tirinha que fala como tratar um bug, ( A leitora liz.sunshine achou o link e me enviou! muito obrigado s2), a tirinha trata bugs como pequenas pessoas, alguns pontos por exemplo:

” Bugs são sentimentais, lembre-se do seu primeiro encontro com ele”

“Bugs gostam de ser fotografados”

“Bugs não costumam andar sozinhos”

Entre vários outros itens similares, uma brincadeirinha bem simples que acompanhada de uma explicação ajuda a lembrar de algumas boas práticas que podem aliviar e muito a nossa vida… eu gosto muito dessa proposta de dar personalidade para coisas, é bem “bobo” mas dá uma aliviada e facilitada para o entendimento quando estamos tendo nossos primeiros contatos com algum tema. Logo, inspirado nessa tirinha eu já vinha pensando em um post aonde o bug é que vai falar conosco… esse post vai ser um modelo bem diferente, podemos dizer que é um teste (não que eu planeje fazer outros com esse molde)

Espero que agrade =]

Continue lendo

Que usuário sou eu?

Olá!

Pelo menos mais um post esse ano tinha quer (mesmo que um post feito nas pressas =/)

Mas é um tema que já tinha pensado em comentar faz um tempo, teve um caso no qual fui testar o site de um amigo meu, era basicamente uma espécie de fórum, onde a pessoa podia postar notícias sobre um determinado tema, poderia avaliar as notícias dos outros usuário e teria um ranking…. uma ideia bem simples, e fui lá na casa dele testar e dar minha opinião de quase QA.

Continue lendo

Qa X Dev?

Olá!

Eu tenho observado que a grande maioria do pessoal já entendeu que essa história de Qa x Dev é uma grande perda de tempo, quando eu comecei a ler sobre essa briga entre áreas, e olhava aqui na Iterative e pensava “Nossa, dei muita sorte, o pessoal aqui não tem essa briga!”, e depois fui vendo com pessoas de outras empresas que essa ideia já está bem firme no mercado, mas ainda existem casos aonde essa rixa existe, agora imagina se você que está começando agora acaba entrando numa dessas empresas, você pode acabar entendendo tudo errado, e o maior prejudicado será você, que vai ter dificuldade em se adaptar em uma empresa melhor no futuro ou pior ainda…desistir da área (eu mesmo provavelmente teria desistido se tivesse que participar de uma guerra com meus colegas).

Vamos pensar em motivos para que essa briga exista:

Não consigo pensar em nenhum motivo que seja válido, a não ser claro insegurança das pessoas em quanto a perder seu emprego, ou o pessoal achar que existe um problema pessoal “ele manda o negócio todo bugado pra aumentar meu trabalho” ou “ele só acha bug pra aumentar meu trabalho”… sério, não consigo imaginar alguma utilidade/motivo real para essa rixa.

Vamos usar a lógica, Qa e Dev fazem parte de uma mesma equipe, com o mesmo objetivo: Entregar o software que o cliente quer e precisa com a melhor qualidade possível. ou seja as ações de ambos devem levar para o mesmo objetivo, o desenvolvedor não vai colocar bugs de propósito (até por que ele que vai ter que resolver depois), e o analista de Qa não vai “procurar mais” só por que foi você que fez a aplicação, caso você realmente acredite que isso está acontecendo, converse com o colega com o qual você está tendo o problema, se um problema realmente existir conversem para que isso não interfira com o serviço dos dois.

Se por um acaso você cair em uma empresa que tenha essa cultura de briga entre as equipes, você tem algumas opções que posso sugerir:

  • Corre, sério… não é a melhor opção, mas é valida.
  • Faça amor, não faça guerra, mostre para o pessoal que não existe essa necessidade de brigas, apresente as vantagens de uma equipe unida, a produtividade aumenta, fica todo mundo mais relaxado por trabalhar com amigos.
  • Mostre que é menos estressante trabalhar sabendo que o seu colega não está querendo prejudicar o seu trabalho, mas sim querendo ajudar.
  • Transforme a competição em uma brincadeira, existe o conceito de “Gamificação”, que cria objetivos diversos, fazendo a rotina lembrar um jogo (e seres humanos costumam ser competitivos), então tente montar times de Qas e Devs unidos, deixando claro que eles tem o mesmo objetivo (Por exemplo, se o QA achae aponta um bug, e o desenvolvedor consegue replicar e solucionar o bug sem precisar pedir explicações para o Qa, a equipe ganha um ponto), cria “jogos” onde o pessoal fique motivado a melhorar, mas não com medo de perder (com premiações para os melhores, mas sem punição para aqueles que não foram bem)..e pode até mesmo dar uns achievments “Passou 1 projeto sem ter discussões com a de Devs/Qa” e aí ganha o título de “da paz”, e se passar 15 projetos ganha o titulo de “pacificador”… coisas assim (quem nunca ficou se matando em um joguinho por causa dessas coisas), se tornar a “briga real” em uma brincadeira, aos poucos tudo vai mudar.

Bem, espero que você não esteja num lugar onde precise dessas dicas..mas se tiver espero que ajude 😉

Um plano “infalível”

Olá!

Se eu aprendi uma coisa na minha infância é que não existem planos infalíveis… quem me ensinou isso foi um garoto de roupa verde e trocava a letra “R” por “L”.

E em testes eu descobri que isso é verdade, mas que podemos montar um planejamento que cubra uma boa parte do software, e que ele também não vai ser infalível.

Tendo isso em mente, antes dos testes começarem…como montar o plano de testes? Por que montar? O que considerar importante? Vamos ignorar alguma coisa já que não dá para cobrir tudo?

Continue lendo

Oracle / Oráculo

Olá!

Depois do Coaching que tive com o James Bach, coloquei como próximo tema de estudo o Oracle… apesar de pesqusiar bastante, posso dizer que o melhor resumo que vi foi o comentário do Stefan Teixeira (indico darem uma olhada no site dele também) :

” Basicamente, o oráculo é no que você vai se basear para saber se um teste passou ou não. Pode ser uma especificação, documentação, um outro sistema, etc.”

Partindo disso nós sabemos que um oráculo é uma base “comparativa” (vamos trabalhar melhor o uso dessa palavra no decorrer do post), aonde vê o resultado do teste efetuado e compara ele com alguma outra coisa… Mas com o que exatamente?

Essa é a parte legal da história, de acordo com diversas opiniões que coletei, o oráculo pode ser um documento, um sistema, uma versão anterior do sistema sendo testado… e até mesmo algo abstrato, como o conhecimento do tester, ou considerar o público alvo da ferramenta…

Continue lendo

“O que é um Tester?”

Um dia desses um amigo me perguntou pelo Facebook “Como virar um analista de testes?”, a resposta foi meio confusa (já que ele me perguntou do nada, e também pelas informalidades de uma conversa com um amigo), mas dei uma re-pensada sobre o tema… Eu não respondi como se tornar, mas sim o que é/faz um analista de teste, e vou tentar redigir esse texto de uma forma um pouco mais clara, para mim e para vocês.

O analista de teste pode ter várias funções (dependendo muito de sua experiência e da empresa em que ele trabalha), mas o intuito final é basicamente se esforçar para que o software tenha a menor quantidade de bugs possíveis, que o usuário final tenha a melhor experiência possível com o software, achamos os bugs, os desenvolvedores consertam, testamos de novo….testamos mais…. até o momento em que o software esteja pronto para ser entregue para o cliente com uma qualidade satisfatória.

Se você for atento, pode ter percebido que em nenhum momento utilizei frases como “garantir que o software não tenha erros” ou “entregar um software perfeito”, mas baseado nos “Sete princípios do teste” (ao meu ver a parte mais valiosa do do Syllabus) o teste apresenta defeitos,  não a ausência deles e o teste exaustivo é impossível… logo não tem como garantir que aquele software esteja 100%, que ele NUNCA vai travar… mas podemos fazer com que esses problemas sejam pouco frequentes, ou quase nulos…

Continue lendo

Teoria X Prática

Olá!

Pessoal, o que vou falar agora provavelmente já é do conhecimento de muitos, até por que o assunto não é relacionado apenas com testes.

Mas vamos ser sincero, por mais que você leia, estude pesquise… tem boas chances de na hora que for efetuar um teste dentro de uma empresa você fique com aquela sensação de “e agora?”, e isso é bem normal.

Até por que o material que temos pra estudo não tem exatamente exercícios para praticarmos, não vou dizer que iriamos nos tornar gênios da área de QA só por temos treinado um pouco com alguns exercícios (mas convenhamos que ia dar uma base um pouco melhor), e as vezes temos a sorte de achar algum blog que tenha exemplos bem detalhados, um passo-a-passo com imagens e legendas, e isso ajuda bastante…mas ainda assim é um caso ou outro, e não botamos a mão na massa, só temos a foto do bolo e de como ele foi feito.

Continue lendo

“Mas eu já sei a resposta…”

Olá!

Lá estava eu assistindo mais uma palestra do James Bach (sim, assisti mais de uma), e em um determinado momento ele apresenta um exemplo (que vou adaptar para facilitar a explicação) de um produto X, que faz Y, e deve ser ligado em 220 Volts , e questiona para a platéia se eles testariam o produto em 110 Volts. Quando a platéia diz que sim, ele começa a questiona-los sobre o por que, afinal de contas todos já sabemos que o produto NÃO vai funcionar, e se funcionar…bem maravilha, uma vantagem para ele. Posteriormente ele explica o porque testar esses casos em que já sabemos a resposta , e eu gostaria de conversar com vocês não só os motivos apresentados lá…mas alguns outros exemplos que eu acredito possam ser relevantes durante alguma reflexão futura.

No caso acima sabemos que o produto não vai funcionar, mas o que isso significa exatamente? Será que o produto vai quebrar, será que o usuário corre algum risco? Digamos que você coloque o produto na Voltagem errada e ele começa a pegar fogo! Acredito que testar essa possibilidade vale a pena né?

Continue lendo

“Pensar dentro ou fora da caixa?”

Olá! Vamos falar de alguns termos hoje?

Você provavelmente já ouvi falar de caixa-branca e caixa-preta, certo? Bem capaz de ter ouvido até sobre a caixa cinza…

Em alguns lugares você vai achar explicações imensas sobre o conceito de cada uma, que mais vão te confundir do que te fazer entender… então vou explicar primeiramente de uma forma bem simples, direta e “tosca”:

Caixa-branca –  testa a estrutura (código) do software

Caixa-preta- testa sem saber nada sobre o código (ou ignorando o que se sabe)

Caixa-cinza –Um teste tendo um acesso limitado a estrutura do código.

Pronto, com esses conceitos acima bem fixados nós já podemos seguir em frente de uma forma mais detalhada, vamos pensar no programa como uma caixa, dentro dele nós temos o código da aplicação, e fora dele é a interface do usuário (IU):

Continue lendo