Todo mundo odeia os bugs!

Por que todo mundo odeia os bugs? 

Ao contrário do que muitos pensam, alguns QAs também detestam eles! A metodologia ágil nos ensinou que fazemos parte da equipe e que a qualidade e sucesso do software é mérito de todos nós. Ás vezes encontrar bugs pode ser extremamente desmotivador pra todos e acabamos nos sentindo mal por esse papel, porém, ele é necessário.

Primeiro, vamos entender isso do ponto de vista do programador: você passou um bom tempo desenvolvendo aquele sistema, passou por bons e maus momentos e criou uma relação tão forte pelo seu código que você poderia casar com ele. 
Então, o seu programa cai nas mãos QA e com o primeiro bug encontrado vem a primeira grande decepção, depois essa decepção vai se transformando em raiva após cada erro apontado. O problema é: essa raiva é de você mesmo por ter errado ou do QA?

"O QA é tipo aquela tia chata que você encontra nas festas de família que gosta de apontar todos os seus erros, você já sente desânimo em encontrar ela e ouvir novamente que você está ficando gordo, careca e que ainda não se casou."

O ponto de vista do tester: aguardamos ansiosamente a nova versão do sistema, e como na maioria dos projetos ela atrasou um pouco durante o desenvolvimento, agora faltam poucos dias para os testes. Você começa a testar e a rezar para que não encontre nenhum bug e possa ir cedo pra casa. Mas aí vem a vida e diz "Não!". Você encontra o dito cujo, anuncia a descoberta, sente o rancor de todo o resto da equipe, abre um novo ciclo de testes e se prepara para passar a noite toda testando o sistema.

"O programador é tipo aquele amigo chato que atrasa em todos os compromissos. Você sempre acaba esperando muito tempo até ele chegar, e quando ele chega está tão tarde que você vai ter que engolir a comida/perder o começo do filme/chegar atrasado na festa. Se você reclamar, provavelmente vai ouvir um monte de desculpas esfarrapadas porque ele nunca assume os erros."

Por que isso acontece? Talvez porque a interpretação do que deveria ser o teste de software não seja feita da melhor maneira.

Veja alguns (maus) exemplos:

- Testes só servem pra encontrar bugs.
Testes devem ajudar a agregar valor, aumentar a qualidade e a confiabilidade do sistema. Encontrar erros não diminui a qualidade do sistema, mas deixar que eles continuem lá, sim!

- Meu programa está 100% livre de bugs.
Aceite que o programa pode conter erros, ele não é perfeito, e nem você. Não leve pro lado pessoal.
Além disso, é preciso considerar, o erro existe quando o sistema não faz aquilo que deveria fazer e também quando ele faz aquilo que não deveria fazer. Nem sempre os erros são encontrados testando exatamente o que está especificado na documentação.

- Este programa foi 100% testado.
No mundo ideal nós queremos testar o sistema inteiro com todas as combinações possíveis, mas na maioria das vezes isso é impossível e inviável. Então saia dessa paranóia e foque nos testes que realmente importam. Estamos mais interessados em qualidade e não quantidade.
É preciso tomar cuidado também com o foco dos testes. Como eu disse no começo, não é a coisa mais legal do mundo achar um bug quando você já estava pronto pra ir embora. Mas você faz os testes com a intenção de encontrar bugs ou de mostrar que o sistema está funcionando corretamente? Essa pergunta parece não fazer sentido, mas pense que, quanto mais cansado e com pressa de terminar os testes, maior a chance de você apenas querer mostrar que o sistema está funcionando e pular testes importantes. 
Quanto maior a vontade de encontrar bugs, maior a vontade de "destruir" o sistema antes que ele seja liberado. E essa é uma das razões do porque o tester encontra muito mais erros no sistema do que o programador, que não se importa em "destruir" o sistema.

- Este sistema fracassou na fase de testes.
Outro problema de ponto de vista. O que é fracasso pra você? Achar 10 bugs na fase de testes ou 5 clientes reclamarem de bugs em produção? (Dica: os bugs em produção são os piores).
Quando executamos um teste e um bug é encontrado, a execução é apontada como "mal sucedida", como se fosse algo indesejada. Mas para o QA deveria ser exatamente o contrário. Afinal, se o objetivo era encontrar erros o quanto antes, esse teste não deveria ter sido "bem sucedido".

O livro "The art of software testing" (Glenford J. Myers), faz um analogia muito boa sobre fracasso e sucesso dos testes: imagine uma pessoa indo ao médico por estar com mal-estar a dias. O médico pede alguns exames e o laboratório não encontra nada. Esse exame foi bem sucedido ou mal sucedido? O paciente pagou pelos exames, continua doente e o médico não sabe como diagnosticar. Porém, se o exame do laboratório acusar que este paciente tem dengue, o exame pode ser considerado como bem-sucedido, já que agora o médico pode tratar o paciente da forma correta e antes que ele piore. Nesse caso, considere que o paciente é o nosso programa a ser testado. =D


Por que não consigo um emprego?

Nos últimos tempos a palavra mais ouvida por quem está procurando emprego é CRISE. Jornal, revista, TV, LinkedIn, qualquer lugar! 
Você começa a ficar desesperado. Se não está procurando emprego, acha que vai ser demitido. E se está, acha que nunca vai ser contratado.

dez meses atrás eu voltava de um intercâmbio + viagem pelos EUA. Minha intenção era melhorar o inglês e ter uma experiência diferente. Além disso, não estava nada satisfeita com meu antigo trabalho e achava que seria fácil encontrar outro quando voltar.
Quando cheguei aqui, apesar de poder contar com um inglês avançado, a situação das vagas estava muito diferente da última vez que eu havia procurado emprego. Em 2013 a situação estava bem favorável, chovia vaga de QA na Apinfo, e eu não demorei mais que duas semanas pra encontrar um emprego novo.
Em 2015 a situação que encontrei já era outra:

  • Não haviam mais tantas vagas na Apinfo, e no Linkedin (que estava dominando o mercado) também não;
  • As poucas vagas que apareciam exigiam muito e pagavam a mesma coisa que outras vagas que, a tempos atrás, não exigiam quase nada;
  • 90% das vagas exigiam inglês avançado e automação no currículo.

Eu, que tinha largado tudo pra fazer um intercâmbio e melhorar meu currículo, achava um absurdo aceitar a primeira vaga que aparecesse. Afinal eu tinha investido tempo e dinheiro em um curso caro e não queria voltar a trabalhar em um lugar que não valorizasse isso.
Você não tem que ser louco pra trabalhar aqui. Nós vamos te treinar.
Coloquei na minha cabeça que só ia aceitar uma vaga que seguisse minhas três regrinhas de ouro:
  • Não fosse uma consultoria: passei anos pulando de cliente em cliente dentro das consultorias, e odiava isso. É muito difícil conseguir reconhecimento do seu chefe (da consultoria) se você está longe dele o ano todo, e o cliente raramente vai se envolver na sua avaliação no final do ano. Além disso, sempre que eu começava a gostar de um projeto e me sentia parte dele.. eu era transferida pra outro cliente. A incerteza de saber se você vai ter emprego ou pra qual lugar você vai ser transferido a cada término de projeto é angustiante;
  • Não fosse nada além de CLT FULL: Cooperado, PJ, CLT Flex e outras opções de contratação nem pensar;
  • Não fosse em Alphaville: Essa vale para qualquer lugar que fosse longe da minha casa. O estresse causado pelas horas que perdi no trânsito indo trabalhar tão longe não valem um salário mais alto.

E pra conseguir uma boa vaga eu teria que investir no meu currículo, então:

  • Tentei manter meu inglês o mais afinado possível, mesmo em casa procurava ler, assistir seriados em inglês e treinar o que falar nas entrevistas;
  • Me matriculei em uma pós-graduação. Fiquei quase 10 anos após o término da faculdade para fazer uma pós, nessa hora senti que ela era mais que necessária;
  • Comecei a estudar automação. Nunca tinha trabalhado com isso antes mas 99% das vagas boas exigiam e se eu não soubesse o mínimo de automação eu iria morrer nos empregos chatos que eu já havia passado antes.

Minhas exigências não eram muitas, mas, depois de dois meses procurando emprego e ouvindo a palavra CRISE em todo lugar, cedi para uma empresa que não era um sonho, mas iria pagar minhas contas.
Lá vou eu pra uma consultoria, pelo menos era perto de casa e pelo menos era CLT FULL. Pra minha surpresa, eu amei o cliente! Mas, apenas dois meses depois, a consultoria mostra porque ela não é uma boa opção pra mim: o projeto do cliente acaba, a consultoria não tem outro cliente pra me colocar e lá estou eu de novo em casa procurando emprego. =/

F***-se isso, estou "cozinhando" metanfetamina
Voltei pra casa mais determinada ainda a seguir minhas 3 regrinhas! Não queria correr o risco de passar por isso de novo.
Passados três meses ouvindo a palavra CRISE, fazendo milhões de entrevistas por Skype, presenciais, testes e provas psicotécnicas, mais uma vez consegui uma vaga de emprego, mas que dessa vez cumpria as três regras. E estou nela até agora, ufa!

Por que diabos estou contando essa história toda?

Nos últimos dias estive analisando currículos para umas vagas de QA na minha empresa e como o Wagner Marcondes já disse no post "Contratar...": contratar é sempre um stress... e é mesmo! Como eu estava procurando emprego a pouco tempo atrás, sei como são as aflições de quem está procurando emprego, e queria compartilhar algumas dicas e impressões que tive durante esse tempo. Tanto como desempregada à procura, quanto contratante.
Então, se você está procurando emprego e está injuriado com a vida porque nenhuma empresa te quer, leia os tópicos a seguir e veja se você não está fazendo algo de errado.

Atitude
Pra mim essa é a primeira e principal coisa que você deve mudar. Durante esse tempo todo participei de um grupo ativo no Telegram que divulga vagas de QA, e algumas atitudes me cansam e com certeza afastam qualquer empregador:

  • Reclamar sem parar o dia todo e de tudo: gente negativa afasta todo mundo em volta, inclusive vagas. Pare de falar mal do presidente, do vice, do golpe, do preço da gasolina e do preço do feijão o tempo todo, ninguém quer ter um chato por perto;
  • Falar mal de pessoas que você já trabalhou: o mundo dá voltas e eu sempre reencontro alguém que já trabalhei ou é amigo dessa pessoa, fica a dica;
  • Pedir ajuda e vagas todos os dias, e quando arranjar emprego, não ajudar mais ninguém;
  • Reclamar que o mercado mudou e que não querer automatizar: essa é bem importante. O mercado mudou sim, automação virou um pré-requisito obrigatório no currículo. Se você quer continuar na área de testes você tem que se adaptar, reclamar no Facebook/LinkedIn não vai mudar nada. Aceite a mudança e estude o que o mercado está pedindo, se adapte, não fique parado. Se você não gosta de programar/automatizar (sei que este conselho irá machucar seu coração) talvez a área de QA não seja mais pra você e não tem problema nenhum nisso, mas pense: se você gosta mais de análise do que programação, porque não considerar trabalhar com documentação?

Currículo
Sei que currículo parece uma coisa ultrapassada (e talvez seja)! Com o LinkedIn, Workable, Vagas e outras ferramentas web, parece ter ficado sem sentido fazer aquele documento chato e entediante. Mas a realidade é que, a maioria dos lugares ainda quer receber esse documento chato e entediante, então pare de reclamar e faça um currículo decente. Se você não sabe como elaborar um currículo, procure no Google "como elaborar um currículo" e use um modelo profissional. Sei que parece óbvio mas vocês não acreditam na quantidade de currículos que recebo que tem problemas com:

  • Formatação;
  • Erros ortográficos: MILHÕÕÕÕÕÕESSSS, pessoal atenção nisso! Pega muito, muito mal!!! Erros todo mundo comete (devo cometer vários aqui nos meus posts), mas pensem que aquele documento te representa, é a primeira impressão que o entrevistador terá de você. Quando o currículos está cheio de erros a única coisa que me passa pela cabeça é que a pessoa é tão desleixada que ela não pôde gastar dois minutos da vida pra passar um corretor ortográfico no currículo. E se mesmo depois do corretor você tiver dúvidas, peça pra um, dois, três ou quantos amigos forem possíveis revisarem pra você.
  • Foto: se você divulga LinkedIn, Github ou qualquer outro site que tenha foto uma de perfil, tenha cuidado de não colocar aquela foto na praia de biquíni ou na academia sem camisa (BIRLL!), isso não é nada profissional! Vamos deixar isso pro facebook, instagram, snapchat e outras redes sociais inúteis...
  • Carta de apresentação: se o site da empresa tem um campo que chama carta de apresentação ele não está lá a toa, eles realmente querem que você elabore uma. Não quero ser óbvia, mas a carta de apresentação é isso mesmo que você leu, uma carta para você se apresentar. Fale RESUMIDAMENTE das suas competências e da sua experiência. Explique porque você se interessou pela vaga, isso mostra pra empresa que você realmente tem interesse em trabalhar ali e procurou se informar a respeito da vaga e da empresa, e não está copiando e colando o mesmo discurso para todas.
  • Objetivo: Se você está se candidatando a uma vaga de "Analista de Testes Sênior" e coloca no objetivo "Analista de Sistemas/Desenvolvedor/Suporte Técnico" não cola. E também não coloque "Qualquer lugar".
  • Datas: Coloque data de nascimento, data de início e conclusão de todos os seus cursos e empregos anteriores.
  • Endereço: eu recomendo não colocar o endereço completo, pode ser que o seu currículo vá parar em outros lugares e ninguém quer ter seu próprio endereço circulando por aí. O nome do bairro já basta, principalmente porque a empresa pode ter interesse em saber quanto tempo você vai demorar pra chegar até o trabalho.
  • Experiências: Se você trabalhou aos 15 anos como caixa da locadora do seu bairro, talvez seja uma experiência desnecessária pra colocar no currículo, ainda mais se ela não tiver relação nenhuma com a vaga que você está se candidatando.
  • Quantidade de informações: Acho que não existe uma regra pra tamanho de currículo, mas se tiver mais de 3 folhas eu durmo. Sintetize já!

Entrevista
Muitas empresas que me candidatei começaram a adotar o Skype/Hangout como parte inicial do processo. Acho isso fantástico, facilita a vida de todos, principalmente do entrevistado que tem que ficar bancando ônibus, metrô, gasolina, estacionamento, Uber, Táxi etc. pra ir até o local da entrevista.
O problema é que algumas pessoas veem a entrevista no Skype como algo "informal". Pois é, mas a entrevista que você faz na sua casa é igual a que você faz na empresa, entendeu? Então, as regras pra entrevista presencial valem pra entrevista pelo Skype também:

  • Não atrase!! Você não tem a velha desculpa do trânsito ruim (que também não cola) pra atrasar em uma entrevista que você está fazendo da sua casa! Teste a sua conexão, câmera e microfone com antecedência.
  • Use roupas "apresentáveis": esteja com um visual legal. Se é costume da empresa usar roupa social, use social, se não for, não apareça todo esculhambado. Entrevistar uma pessoa de pijama, roupa de academia ou sem camisa é no mínimo estranho!
  • Vá para um ambiente organizado e calmo: Não deixe o entrevistador ver suas meias sujas no chão ou a bagunça do seu armário, procure um lugar tranquilo e visualmente agradável. Outra coisa importante, se você ainda está trabalhando, não faça a entrevista dentro da sua empresa atual, se não tiver como fazer de casa, reserve um lugar apropriado pra isso. Se você faz entrevistas no meio do seu expediente no seu trabalho atual, quem garante que você não vai fazer no novo?
  • Inglês: Se você colocou no seu currículo inglês avançado ou fluente, é bem possível que role uma entrevista em inglês. Pela minha experiência, a maioria pergunta coisas do seu cotidiano como o que você gosta de fazer no tempo livre. Treine em casa. Se você não consegue trocar ideia em inglês fuja do mico, diga ao entrevistador que você ainda não tem um nível de conversação bom.
  • Não seja mala! Muito subjetiva essa dica, mas o que eu quero dizer é: não interrompa o entrevistador quando ele estiver falando, não seja monossilábico, não fale que seu hobbie preferido é dormir, não use muitas gírias (nem todo mundo encara isso bem) e leve o bom senso sempre com você!

E boa sorte no seu novo emprego!

Automatizando com o Gauge... Que Gauge!? - Parte 1

 Ler em Português      Read in English
Hoje vou falar de uma ferramenta de automação que quase ninguém conhece, o Gauge.

Gauge? Que Gauge?
"Gauge é uma ferramenta de automação de testes multiplataforma. As especificações são escritas em Markdow de formato livre para que casos de teste possam ser escritos na linguagem de negócios, ao invés do formato mais comum, porém restritivo, "dado-quando-então". Suporte a linguagens e a IDEs são implementados como plugins, permitindo que analistas de teste usem as mesmas IDEs que o restante do time, com capacidades poderosas como autocompletar e refatoração. Essa ferramenta, desenvolvida com código aberto pela ThoughtWorks, também traz nativamente a execução paralela para todas as plataformas suportadas." (Fonte: ThoughtWorks - Technology Radar)
 
Resumindo, algumas qualidades do Gauge:
- Não te deixa preso no "given-when-then"; 
Obrigado
- Fácil de instalar;
- Permite que você escreva seus scripts em várias linguagens (Java, Ruby, C#, etc.);
- Open Source =D;
- Suporte a algumas IDEs (IntelliJ, Visual Studio e Eclipse);
- A sintaxe é bem simples de entender.

Vou fazer um mini-tutorial para mostrar como são executados os testes no Gauge e quais as principais features dele, mas como vou ter muito o que falar, vou dividir este post em algumas partes.
Hoje vou falar da instalação, execução e de como funciona a estrutura básica de um projeto no Gauge.

1 - Instale o Gauge
Verifique como instalar o Gauge em seu sistema operacional aqui.

Exemplo, se você usar o linux, você precisa:

  • Baixar o Gauge 32 bit ou 64 bit; 
  • Abrir o arquivo zipado pelo terminal, no meu caso, salvei o arquivo na home, então foi só executar esse comando:
$ unzip gauge-0.5.0-linux.x86_64.zip 
  • Agora, execute este comando para instalar:
$ ./install.sh

2. Instale o plugin da linguagem que você vai usar
Exemplo:

  • Se você usa Java: $ gauge --install java
  • Se você usa C#: $ gauge --install csharp
  • Se você usa Ruby: $ gauge --install ruby

3. Instale o plugin para gerar um relatório em HTML
O gauge tem um relatório em HTML. Na minha opinião, não é muito prático, mas pode ser útil quando você executa muitos testes de uma vez e não consegue acompanhar todos os resultados da execução no terminal.
 
Para instalar o plugin: $ gauge --install html-report

4. Verifique sua instalação
Execute $ gauge -v

Se tudo der certo, a resposta será parecida com essa:
Gauge version: 0.5.0

Plugins
-------
html-report (2.1.0)
ruby (0.2.0)


5. Inicie um projeto
Execute o comando de acordo com sua linguagem escolhida, no meu caso: 
$ gauge --init ruby

Quando você executa esse comando, o Gauge vai criar um projeto modelo para você utilizar como exemplo. Veja a estrutura do projeto criado:

6. Execute 
$ gauge specs pra ver se o projeto exemplo está rodando normalmente:
 
Specifications: 1 executed 1 passed 0 failed 0 skipped
Scenarios:     2 executed 2 passed 0 failed 0 skipped

Total time taken: 80ms
 
Sucesso total!
 

7. Entendendo a estrutura do Gauge

Você vai trabalhar basicamente com dois arquivos a maior parte do tempo, as especificações e os steps. 
 
Especificação
Exemplo de especificação
Nome da especificação - O nome que você vai dar para o grupo de cenários contidos nesse arquivo. Para especificar o nome é necessário "sublinhar" o título com "======" ou colocar uma # antes do nome. 
Exemplo: # Specification Heading.
Nome do cenário - A especificação deve conter no mínimo um cenário. Para especificar o nome do cenário é necessário sublinhar o título com "-------" ou colocar duas ## antes do nome. 
Exemplo: ## Vowel counts in single words.
Steps - Passos executáveis que podem ou não estar dentro do cenário. Para especificar o nome dos steps é necessário colocar um * antes do nome. Exemplo: * Almost all words have vowels.




Steps


Aqui ficarão os scripts dos testes. A implementação depende de cada linguagem, no caso do Ruby (exemplo acima), será sempre:
step 'Say <greeting> to <product name>' do |greeting, name|
 # Code for the step
end
Essa foi a primeira parte do post sobre Gauge. Na próxima, quero mostrar alguns recursos legais que utilizo no meu dia-a-dia.

Ficou com dúvidas? Mande sua pergunta aqui nos comentários!

The Developers Conference 2016 - Como foi a Trilha de Testes

 Ler em Português      Read in English

Olá! 
No dia 08/07/2016 aconteceu em São Paulo a Trilha de Testes do TDC 2016! Como os eventos da área de testes são muito raros, resolvi conferir as palestras e ver o que tinha de novo.




Achei interessante que havia muitos palestrantes que estão há pouco tempo na área de QA (até dois anos) e alguns desenvolvedores. Eu dou meus parabéns a todos, principalmente porque eu tenho horror a falar em público, e fazer uma palestra pra quase 200 pessoas (acho que era mais ou menos isso) não é fácil.

Alguns assuntos e angústias já eram esperados em eventos de testes como esse. Alguns foram abordados de maneira mais engraçada, mas a maioria ficou um pouco repetitiva. Eu não sei se é porque estou há muito tempo na área e já cansei de ouvir esse mimimi, ou porque certos assuntos realmente não morrem, como por exemplo:

A falta de ambiente de testes...
Eu vi você testar seu código em produção
Eu também gosto de viver perigosamente

 Falta de documentação...
Documentação??
Ninguém tem tempo pra isso

relacionamento Dev x QA difícil...
patolino.gif
- Erro crítico
- Não pode ser reproduzido

e Agile. (A bala de prata do momento. Às vezes essa palavra me cansa...)
Diga Agile
mais uma vez

Mas eu senti muita falta de novas ferramentas, e não acho que foi porque os palestrantes não falaram. É porque realmente não vejo nada de novo há muito tempo!

As únicas ferramentas que me chamaram a atenção foram o BrowserSync, que permite que você navegue em todos os browsers ao mesmo tempo, inclusive dispositivos móveis. Mas acredito que não seja nenhuma novidade, principalmente pra quem trabalha com front-end.


... e o Exploratory Testing da Microsoft, que funciona como uma extensão do Chrome e te ajuda a capturar os bugs enquanto navega no sistema, e a filmar o passo-a-passo dos testes exploratórios, assim nunca mais teríamos problema pra reproduzir um bug de teste exploratório de novo. Tudo muito lindo, muito bonito, mas como tudo que é bom nessa vida da Microsoft, não é de graça... Não sei se posso considerar como uma boa opção.

Em resumo, eu achei um evento muito bom pra conhecer pessoas, ver como as outras empresas estão trabalhando e entender que, após 6 anos na área, as angústias continuam as mesmas. 
Aí você irá me dizer que o QA é maltratado, que ninguém dá importância pra área e que nosso trabalho é menosprezado.
Mas, pense: será que as empresas não dão valor para a área de QA ou não estamos sabendo vender nosso peixe? Pense nisso, pequeno gafanhoto!

Que tester sou eu?

 Ler em Português      Read in English

Se você trabalha com testes há algum tempo, já percebeu que nós somos chamados de todo tipo de coisa. E não, não estou falando dos xingamentos dos desenvolvedores ou gerentes de projeto, mas sim de todos os nomes de cargo que inventaram pra essa área. Apenas alguns exemplos:
- Analista de Testes
- Engenheiro de QA (Quality Assurance)
- Automatizador
- Analista de QA
- Tester

Como eu vejo esses caras: 
Analista de Testes e Analista de QA
Uma pessoa que está mais focada em elaborar cenários. Precisa entender muito bem o negócio pra saber quando e onde pode dar problema. Utiliza muito a documentação do sistema e, quando ela não existe, o trabalho vira uma caça ao tesouro. Vai achar mais erros nos requisitos do que no sistema. Possivelmente um(a) analista de requisitos/negócios/sistemas frustrado.
REESCREVA todos os requisitos!
Engenheiro de QA e Automatizador
Uma pessoa mais técnica, não perde muito tempo com teste manual, o negócio dela é programar e rodar scripts. A vida dela é um teste de regressão. Os desenvolvedores não a consideram uma desenvolvedora e os analista de testes acham que ela traiu o movimento. Possivelmente um(a) programador(a) frustrado(a).
Eu sei TDD
Tester
Há um tempo atrás (não muito), chamávamos de tester (ou executor de testes) a pessoa que apenas executa os testes, ou seja, a pessoa era paga pra ler roteiro de testes e apertar botão. Ainda bem que hoje em dia raramente vejo uma vaga com essa função, mas vejo 2 possibilidades pra esse nome ainda ser tão comum:
1. É uma pessoa que faz de tudo, mas provavelmente ganha o salário de 1/2.
2. O RH não faz a mínima idéia de como chamar a pessoa que faz testes, falaram que era tester e a vaga foi colocada assim, o mais genérica possível.
Eu não tenho idéia do que estou fazendo
O que eu concluo com isso tudo:
Que se danem as nomenclaturas! Sério, não se preocupe com isso. A única coisa que você "tester" deve saber é:
- Elaborar planos, roteiros, estratégia, casos de teste, relatório de execução, aceite e outros 15 documentos que ninguém se importa e vão fazer você perder um tempão elaborando;
- Ter CTFL, CTAL, CBTS, QAI, CTEL e outras siglas que vão deixar sua assinatura enorme e seu currículo lindo, mas se alguém te perguntar na entrevista o que elas significam, você está ferrado!
- Ter 15 anos de experiência, curso superior, pós-graduação, mestrado, doutorado, inglês e espanhol fluentes mas não ter mais de 30 anos;
- Programar em Ruby, PHP, Java, Phyton, Javascript, C#, C++, Objective-C, Visual Basic, Perl, Go, Pascal, Brainfuck, e se souber Assembly será um diferencial;
- Ter experiência com TestNG, Cucumber, Selenium, RSpec, Gauge, Capybara, Appium, Loadrunner, etc. Mesmo que a empresa use só uma ferramenta, aprenda todas e use tudo ao mesmo tempo!
- Saber usar MySQL, Oracle, SQL Server, MongoDB, DB2, e o PostgreSQL. Todos! E, por favor, decore como fazer pelo menos um SELECT (nada de simples, com WHERE, ORDER BY e INNER JOIN, por favor!), INSERT, DELETE e um UPDATE em cada um deles. É muito importante que você não utilize o google pra lembrar como executar nenhum deles;
- Já ter usado Jira, Mantis, Bugzilla, Testlink, ALM e todas aquelas ferramentas que você não aguenta mais olhar pra tela;
- E, principalmente, estar preparado pra ser o culpado por todo o projeto atrasado. Se isso acontecer... 

PARABÉNS, você está fazendo seu trabalho! =)
Bugs
Bugs em todo o lugar