Todo mundo tem medo de Teste (até você!).
Isso… você não leu errado. Quase todo mundo (para não generalizar) que trabalha com software (ou hardware) tem medo de teste, seja ele seu gestor de qualidade de software, os desenvolvedores do projeto que entende que “teste é importante”, o gerente do projeto e até VOCÊ (pasme) tem medo de teste.
Primeiro vamos para a definição do que seria teste de software.
“O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.”
Peguei essa definição do wikipédia, que não é a fonte mais segura de conhecimento, mas se você ler alguma literatura de engenharia de software e qualidade de software, verá que essa é uma definição mais ou menos resumida da coisa ( fique a vontade para discordar 
).
Com esta visão de teste de software, o trabalho do tester (independente do cargo, se é executor, analista ou arquiteto) é de fornecer dados a respeito do estado atual do software para aqueles responsáveis por ele, definir se o mesmo esta com qualidade satisfatória para fazer a entrega, correto?
Para fornecer esses dados ele vai precisar executar “testes” no sistema correto? em partes.
Hoje em dia quase todo profissional de teste executa teste baseado em que? casos de teste.
Um caso de teste nada mais é que um script, um roteiro a ser seguido para fazer o que? Uma verificação.
Ora se você está fazendo uma verificação, muito provavelmente você está verificando se algo esta funcionando / continua funcionando e com esse propósito em mente, você não está testando, mas sim validando aquela informação, já que teste é a investigação e o modo que você aborda a aplicação.
Não entendeu? tem um post excelente do michal bolton sobre Testar vs Checar (em inglês) , post o qual motivou este post que você esta lendo 
.
Agora por que estou falando que todo mundo tem medo de teste? Posso traduzir esse medo em apenas uma palavra: “ESCOPO“.
Sim, todo mundo que trabalha com desenvolvimento e teste conhece muito bem este termo.
O escopo de teste é a definição de qual vai ser o range do trabalho da equipe de teste e isso fica mais forte quando você trabalha em uma fábrica de teste.
Seja a fábrica de teste ou responsável de teste do projeto, é elaborado um Plano de Teste que vai definir o que será testado e o que não será testado (escopo e não escopo) de acordo com o escopo do projeto.
EPA! PARA TUDO!
Como é que você pode definir um escopo de teste e determinar o que vai ser testado e o que não vai ser testado? se teste é investigação, você deve ter um norte para começar os testes e pode usar o escopo de projeto para guiar o seu trabalho mas ele não deveria LIMITAR o seu trabalho, correto?
É aqui que seu medo como profissional entra
O Escopo de teste como é feito hoje, para uma fabrica ou até para a equipe de teste é o escudo protetor de todos os problemas. Se der algum problema em produção ou o cliente achar um defeito que não esteja relacionado ao escopo do projeto, a primeira coisa feita é mencionar o escopo:
Analista: “Isso não estava no escopo do projeto, logo não é escopo de teste”.
ou Fábrica: “Isso estava no escopo do projeto porém vocês não compraram este teste sendo assim nós não o fizemos”.
Isso não quer dizer o teste não foi realizado corretamente.. é que não foi feito teste nenhum!
Foi realizado apenas verificações para confirmar as afirmações presentes nos requisitos / use cases / etc!
Teste não garante a ausência de bugs, blablabla mas não é isso que estou falando aqui.
Acredito que se trata muito mais de postura do que outra coisa.
Ex.: Se seu usuário faz a homologação do projeto e encontra erros que não estavam no escopo, converse com ele para saber o que é importante para ele e converse com a gerência uma forma de incluir aquilo no escopo.. ache um meio termo para sair da área de medo e evitar que seu cliente aponte o dedo para você dizendo que não testou direito ; )
…
Bom, você conquistou seu medo de acharem bugs em produção, você tem mais confiança no seu trabalho, você abre um defeito sobre algo que não estava especificado no escopo de desenvolvimento e PAM, a equipe de desenvolvimento devolve o defeito afirmando que o mesmo está relacionado a algo que não foi “alterado” e com isso não será corrigido.
Agora entra o medo do resto da galera
Uma bateria de teste bem feita machuca… machuca muito. Na sua investigação para testar, você VAI / DEVE fazer muitos questionamentos, desde fluxo de navegação, performace, padrões, ortografia, segurança.. etc.. e isso não é bom, por que teoricamente não é “você” que tem que ver isso, certo?
“Voarão porcos” quando você apresentar uma falha grave de especificação para um gestor de projeto que incentiva qualidade de software e ele de fato aceitar isso e parar o projeto para reestruturação.
Tudo é muito bonito e lindo quando não pisam no seu calo ou quando mexe no seu bolso.
Teste de software deve ser duro, deve ser implacável.. tem que mostrar que o software TEM problemas sim, seja ele de codificação, especificação, segurança, etc. Porém o que vemos por muitos lugares é a conivência das pessoas que deveriam zelar pela qualidade do produto.
Agora por que gestores e desenvolvedores jogam para debaixo do tapete bugs e bugs? por que não há tempo nem dinheiro para bancar.
Enquanto houver clientes que priorizam custo ao invés de qualidade, ou pior… preço baixo e com “qualidade”, esse medo de expor problemas vai continuar a ser alimentado e ninguem vai conseguir fazer o seu trabalho direito.
Uma solução? eu particularmente não sei… se você souber, da um pitaco nos comentários
–
http://www.developsense.com/blog/2009/08/testing-vs-checking/
http://pt.wikipedia.org/wiki/Teste_de_software
experiência de campo
Thks Ishigue
Felipe da Silva
93 dias ago
@Leonardo
Acho que consegui seguir o seu raciocínio. Mas talvez eu nunca tenha nascido com esse medo, eu sempre reportei defeito que não estavam baseados em documentação, quando não na bug tracking tool através de email. E lógico, acumulo “bla bla blas” que já me falaram por isso, mas não ligo, sempre me coloco como usuário, eu (como usuário) “QUERO um sistema sem erros de gramática e sem alguns erros que “só cego não vê” que o requisito está errado e todo mundo foi seguindo só porque estava escrito lá, não importa se eu assinei o requisito em baixo “sem ter feito a revisão profunda” e visto aquilo, meu gosto não muda porque eu assinei ou não”, é assim que vejo o pensamento do cliente, também não sou muito a favor de fazer o cliente engolir a seco certos tipos de erros só porque está assinado, tem coisas que sim, o cliente está querendo melhorias que não tem nada a ver com defeito, ele só mudou de ideia, mas também o que vejo é produtores muito extremistas, cobrando por 110% das mudanças, tirou uma vírgula de lugar (que não muda o sentido do texto) já estão cobrando, MAS voltando ao assunto principal, é verdade até nós temos medo de testes, já achei muito erro em funcionalidade que era um outro colega que estava testando e falava pra ele “olha isso aqui, você viu? está errado oh…”, ai vinha a resposta que odeio “eu to fora, vou abrir isso não, não tem base em documentação, se quiser abre você”, quer dizer, o cara viu o problema (ou não), mas tem MEDO de relatar o problema, e sim, quando eu ouvia isso eu explodia de raiva, sentava na minha baia, e gastava “meu tempo” que eu deveria estar relatando bug na “minha própria funcionalidade” pra reportar “erro dos outros”, triste né? Sabe, tem métricas que só atrapalham… por que estou falando isso tão de repente? Porque os indivíduos (muitos) deixam fazer o seu trabalho tão bem quanto poderiam por MEDO de se “queimarem” em algumas métricas, chegando ao extremo de “na dúvida, não abrirei o defeito, porque se eu levar ‘retorno’ depois meu gestor vai apontar o dedo na minha cara que eu tenho mais de 10% de retornos…”, quando eu iniciei na carreira meu primeiro tutor, meu amigo, o Guilherme Britto, disse bem claro pra nós “na dúvida, abra o defeito. Pois é melhor errar e levar um retorno do que não arriscar e deixar passar um defeito”, pensando nisso eu não sei que é que está mais ERRADO, se é o testador com medo de levar retorno ou se é o gestor que usa a métrica de forma errada pra apontar o dedo e colocar medo nas pessoas, o que vejam que impacta diretamente na qualidade do trabalho da equipe, SIM, se o gestor ai não fizesse esse tipo de coisa esse tal testador não iria ter medo, iria sim levar um retorno ou outro a mais, porém a qualidade do software iria crescer pouco a pouco a cada “chute” que ele acertasse.
Resumindo: As pessoas tem medo não é dos testes, mas sim de uma reação negativa daquele que está acima dele, seja seu líder, seu gestor ou seu cliente. Um defeito não estraga só um software, pode estragar a imagem de alguém, neste caso as pessoas, protegendo essa imagem, dão outros nomes aos defeitos para minimizarem tal risco.
Agradecido e Atenciosamente / Thanks and Regards,
- Felipe da Silva
“Loucura é continuar fazendo o mesmo e esperar resultados diferentes” (Albert Einstein)
Luis
93 dias ago
Convivi por um bom tempo com essa questão da conivência. Até eu era cumplice disso.
O time de testes tinha a necessidade de colocar um finish date nos bugs abertos, ou seja, tinhamos que dizer até quando o bug deveria ser corrigido. Com isso, a pressão era imensa antes mesmo do bug ser registrado:
- Isso é realmente necessário para essa data?
- É impeditivo para a entrega?
- Estava escrito que deveria ser assim?
Acabava acontecendo que, muitas, vezes o bug ficava “engavetado” em alguma planilha de controle que ninguém olhava (em função dos milhões de itens prioritários). Aí só corrigiam bugs encontrados em produção ou que realmente estavam relacionados com a entrega em questão.
Enfim, desanimava bastante. Até que resolvemos parar entregar coisas novas até que todo nosso backlog de bug fosse corrigido. Para nós foi ótimo, já para os gestores que controlavam prazo e custo… hehe
Hoje registro e grito para qualquer bug encontrado. Se vão corrigir ou não, é outra discussão.
AMQ
93 dias ago
Vim trabalhar com testes a pouco tempo e admito que tinha outras perspectivas nesses aspecto. Achei que seria uma caçadora de bugs, que seria algo mais “independente” e sem roteiros. Em contrapartida, entendo a importância de fazer certas limitações, caso o contrário trabalhar com testes seria uma história sem fim e com custos enormes.
O posto o Bolton, e o seu, me faz pensar que teste de verificação (que parece ser a prática mais comum), nada mais é do que um retrabalho.
Ou seja, o teste de verificação tende a seguir o mesmo escopo de quem desenvolve, pra verificar parâmetros que deveriam chegar na fase de testes já funcionando (sabemos que isso não ocorre com frequência).
Não sei se viajei muito, mas penso que trabalhar com testes, é o mesmo que chegar para um revisor de textos, que domina a língua portuguesa, e pedir pra revisar SOMENTE se os tempos verbais de um texto estão corretos.
Acredito eu, que quem faz a diferença nessa área é o profissional ousado e questionador.
Israel Ramos
13 dias ago
Essa história é uma velha conhecida de quem está na linha de frente testando softwares.
Dá pra relatar alguns perfis de testadores baseando-se nesse problema do “Apontar ou não apontar? Eis a questão!!”
Há os que dão a cara pra bater, que apelido de “Rambo Tester”, e saem apontando “TUDO” e depois não conseguem acompanhar o ciclo de vida de todos esses defeitos até o fim, além de causar inimizade com toda equipe.
Já outros que ponderam se deveriam abrir ou não aquele defeito baseado no tempo restante para entrega, que apelido de “Money Tester”, já que o objetivo dele é ver o gestor com sorriso aberto por entregar na data.
Há também aquele que cola na orelha do desenvolvedor e não abre o defeito na ferramenta para não se responsabilizar mais tarde por acompanhar o defeito ou ser acusado por atrasar a entrega, esse eu chamo carinhosamente de “Friendly Tester”, já que não cria problemas nem pra ele nem pras métricas.
Enfim, creio que todo testador já participou de todos esses filmes. Eu mesmo já fui protagonista de todas essas situações, não por achar correto, mas porque fui forçado a isso.
A verdade é que cada Bug novo é um filho novo que o testador põe no mundo, e depois tem que cuidar pro resto da vida. E ninguém vai querer ficar trocando fralda suja de 50 filhos sozinho.
Os Sprints vão começar, vão acabar e vão ficar um monte de fraldas sujas para trás. O fato é que 99% dos gestores, antes de se tornarem gestores, foram desenvolvedores. E por esse motivo, eles não vão dar bola se testador tem um monte de filho, porque pra eles vale mais uma funcionalidade entregue mal implementada do que nada. Quando eles estimam o tempo de projeto não levam em conta o tempo para trocar as fradas. Gestor não quer errar nas suas estimativas, e entregar o produto fora do tempo planejado por conta de um monte de fraldas à serem trocadas, definitivamente acaba com a credibilidade perante a Diretoria.
O que o seu gestor quer é chegar na reunião da diretoria falando que conseguiu entregar 100% dos requisitos pro cliente X dentro do tempo “planejado”. Certamente o diretor não vai perguntar e nem estará preocupado se o produto tem defeito, já que o mesmo pensa assim: “Temos Analistas de Testes = Temos Produtos sem defeitos”. Resultado: Diretoria feliz, Gestor gratificado, e se dai pra frente algo der errado e o cliente começar sentir cheiro de merda, o gestor tira o dele da reta e bota a culpa no testador. Simples não é mesmo????
O testador no meio dessa brincadeira é “CAFÉ COM LEITE”. Para o gestor(ex-desenvolvedor), o testador só está ali pra cumprir tabela e muitas vezes só porque a Diretoria acha bonitinho dizer que seu produto “supostamente” tem qualidade. E o principal: usar isso como argumento pra vender mais e agregar valor ao produto. É questão de marketing, meu amigo.
É por esse e outros motivos que, nós testadores, ganhamos em média 30% menos que desenvolvedores, e estão faltando profissionais nesse mercado.
Claro que não estou querendo generalizar, cada caso é um caso. Pois existem empresas “inteligentes” que realmente dão importância e prioridade para testes. Empresas essas que ao meu ver estão evoluídas anos à frente das outras.
Já passamos pela era do “Como fazer?” e estamos vivendo a era do “Como fazer com qualidade?”. O mercado de Testes, aqui no Brasil, ainda está engatinhando, infelizmente.
Por enquanto temos que ser firmes e relevar a história do “CAFÉ COM LEITE”. Daqui à alguns anos a coisa estará mais evoluída e as cabeças vão pensar diferente. Será nessa hora que o título desse post vai mudar de “Todo mundo tem medo de Teste (até você!).” para “Todo mundo AMA Teste (principalmente você!)”.
OBS: Lembrando que ninguem é dono da verdade, muito menos eu. rsrsrs