TDC2014 Floripa: como foi

26 05 2014

E mais um TDC passou! O evento está crescendo a cada ano e isso mostra como as pessoas estão ansiosas por conhecimento e inovação. Vou falar um pouco mais especificamente da trilha a qual coordeno, a de Testes.

Este ano tivemos cerca de 200 inscrições, 100% a mais do que no ano passado! Já agradeci no evento e volto a agradecer novamente por aqui: MUITO OBRIGADA! Sinto que a responsabilidade é muito grande, escolher palestras interessantes para este público tão crítico e sedento de qualidade não é fácil. E por isso vou falar um pouco sobre a composição da trilha deste ano.

Eu tive a oportunidade de ler algumas críticas realizadas no formulário entregue e a maioria só avaliou as primeiras palestras. Uma pena, mas foi um erro nosso. Deveríamos ter entregue ao final do evento, dessa forma teríamos mais críticas a respeito de todas as apresentações. Mas ok, anotado para o próximo ano.

As críticas giraram em torno do mesmo assunto praticamente: palestras com o mesmo assunto. Levando em consideração que as pessoas não avaliaram todas as apresentações, apenas as 3 primeiras da manhã, elas têm razão. Mas isso foi proposital. A organização da trilha ficou separada por assuntos, um bom observador teria entendido a distribuição das palestras.

1. Automação de testes para não programadores com o método Keyword-driven – Cristiano Caetano

Esta palestra serviu como uma introdução à trilha. Foi escolhida por ser um case – proposto por um palestrante renomado –  e utilizar um método de automação para não programadores.

2. Seja um tester ágil! – Daniel Ricardo de Amorim e Raquel Liedke

3. Chaos in test – Carlos Tadeu Panato Junior e Fausto Siqueira

Essas duas palestras tinham o mesmo tema: o papel do testador, do QA em um time ágil. Mas percebam que apesar de falaram sobre o mesmo assunto, os personagens trabalham de formas distintas. Essa era a intenção: mostrar aos ouvintes que o papel de um testador ou do QA em um time ágil na maioria das vezes se difere de acordo com as características das equipes. A responsabilidade pode ser a mesma, porém o modo de agir pode diferir. Conhecer as formas de interação dentro da equipe pode auxiliar um novo testador a entender o seu papel dentro do time.

4. Quando meus testes terminam, se os ‘bugs’ não acabam? – Welington Costa Monteiro

Outro estudo de caso mas que abordou assuntos como diagramas de atividades, casos de uso, matriz de rastreabilidade, UML, gestão de defeitos e como tudo isso junto colabora com a qualidade do sistema. Este é um assunto pouco abordado nos blogs mas que é a realidade de muitos colegas por ai.

5. Melhorando sua Estratégia de Testes Automatizados – Stefan Teixeira

6. Protractor – Testando aplicações AngularJS – Daniel Ricardo de Amorim

7. Espremendo Melancia: Watir+PageObject – Carlos Tadeu Panato Junior, Alex Warmling e Fausto Siqueira

8. Como testar sua aplicação Android e iOS – uma abordagem prática – Elias Nogueira

Inevitavelmente, as últimas palestras giraram em torno do tema que é tendência e veio pra ficar: automação de testes. Embora as empresas não estejam ainda tão maduras em seus processos para que possam aplicar de uma vez a automação de seus testes, alguns QAs por iniciativa própria já praticam ou começaram a realizar “pilotos de automação” em seus projetos. A intenção aqui era apresentar a gama de ferramentas e técnicas que podem auxiliar as equipes na definição e escolha da melhor ferramenta para o desenvolvimento de automação de testes de acordo com as características do seu projeto.

Algumas imagens:

Este slideshow necessita de JavaScript.

Mais imagens na fanpage do TDC.

 

Algumas considerações:

  • O atraso na abertura não prejudicou o tempo das palestras da manhã. Respeitamos o tempo proposto para a apresentação e para as perguntas. Infelizmente por termos um tempo apertado, não foi possível realizar um maior debate entre as palestas, mas todos os palestrantes ficaram até o final do evento.
  • Nós realmente gostaríamos de ter uma gama maior de assuntos na trilha, mas somos reféns das submissões de vocês leitores! 85% das submissões são sobre utilização de ferramentas, já pensou que chato seria se todas as palestras fossem assim tão técnicas? Quem sabe ano que vem aparecem mais temas como MPS.Br, CMMI, processo de testes, ferramentas de gerenciamento de erros… #ficaadica.
  • O TDC não é um evento acadêmico, por isso não esperem profissionais com perfil de professores. O TDC é uma oportunidade para qualquer pessoa apresentar um assunto que considere relevante para a comunidade. Não importa se é um palestrante profissional ou apenas um bom profissional da área. A intenção é compartilhar experiências. Se você está esperando por um mini-curso-relâmpago, a trilha não vai lhe proporcionar isso.

Infelizmente não há como agradarmos a todos, alguns reclamaram dos palestrantes, temas repetidos, sanduíche do almoço frio, localização do evento longe, áudio ruim, sala gelada, sala quente e por ai vai! Acha que é fácil?

Sabe de nada, inocente!

Sabe de nada, inocente!

 

Sabe de nada, inocente!! Mas o resultado final foi bem positivo, e vou guardar as críticas construtivas para o ano que vem, afinal, é errando que se aprende, não é?

Obrigada a todos os que participaram!

Anúncios




Revizáo de testo praquê?

4 04 2014

Não, eu não estou assassinando a língua portuguesa. Sim, o título deste post está escrito erroneamente de propósito. Dói a vista não é? Você pode se perguntar, mas qual a relação disso com qualidade de software? Eu respondo: tudo a ver. A qualidade do seu software começa na escrita dos requisitos. Requisitos mal escritos podem gerar ambiguidade, dúvida e confusão na hora do desenvolvimento. Eu já peguei algumas documentações tão mal escritas que fiquei com “vergonha alheia”. Outro dia tava vendo uma apresentação no Slideshare, onde estava escrito no título de váaaaarios slides: ANDRIOD e não Android. Se você vai publicar sua apresentação na web (leia-se: TODO MUNDO VAI VER), pelamordedeus, revise!! Agora, veja esta imagem e me conte a sua opinião (clique na imagem para aumentá-la):

Muita preção!!

Muita preção!!

Achou o erro? E de quem você acha que foi o erro? Do analista de requisitos, do desenvolvedor, do testador ou do estagiário? Eu respondo: de nenhum deles! O erro está na falta de um processo de revisão. Eu já tive a oportunidade de trabalhar em projetos com a equipe era bem multidisciplinar. Tínhamos doutores e mestres em engenharia do conhecimento, administradores, especialistas em BI, desenvolvedores seniores, engenheiros de software E revisoras de texto! Sim, eram elas as responsáveis por revisar todos os documentos, desde contratos até essas mensagens de feedback para o usuário. Sentavam ao lado do desenvolvedor e faziam um trabalho de formiguinha, analisando cada mensagem de acordo com o contexto da tela. Aprendi com elas que a qualidade está nesses detalhes (saudade delas!!). E é o tipo de coisa que ninguém dá valor até encontrar um erro, como este ali de cima.

Daí você pode pensar: “ah mas eu não tenho um revisor na minha equipe e nem tenho dinheiro para investir nisso”. OK, acredito que isso possa sim acontecer, mas você tem os pares, você tem outros membros no time que podem fazer uma revisão com olhar mais crítico, o próprio QA tem a obrigação de primar pelos detalhes. Eu tive que fazer uma graduação em letras inglês pra descobrir que não sou fluente na minha própria língua mãe.

Tenho visto muitos blogs onde as pessoas apenas vomitam o que pensam, não se dão o trabalho de reler o que escrevem. Os pensamentos ficam soltos, sem coesão, sem conexão. Vão escrevendo como falam, não usam pontuação (eu já falei sobre isso em outro post), muito menos o corretor ortográfico. Gente, não custa nada você pedir pra alguém ler seu texto antes de publicar! Outro motivo que você pode pensar em me dizer é: “meu desenvolvimento é ágil, não tenho tempo pra revisão”. Helloooo, ágil não é sinônimo de desleixo!! Desleixo é deixar passar um “precione” na produção. Põe lá como tarefa da sprint: revisar mensagens de feedback; revisar escrita de histórias de usuário, revisar label dos botões. Faça da revisão uma tarefa!

E olha o que eu achei no jornal de hoje!

Precione!!

Precione!!

Outro exemplo de mensagem ambígua: Sim ou não O contexto da mensagem é o seguinte: um spam típico onde eu cliquei em descadastrar o e-mail. O meu desejo inicial era o de remover meu e-mail da lista, ou seja, cancelar o recebimento deles. Em momento algum eu cliquei em alterar configurações. Na mensagem de feedback eles misturaram as duas ações que eu poderia fazer e me deram duas opções: SIM ou NÃO. Daí eu fiquei pensando onde clicar: SIM, eu quero cancelar. NÃO, eu não quero alterar as configurações. Apesar da dúvida, cliquei no SIM, e para a minha surpresa, nova página com outras informações apareceram, para que eu então confirmasse o cancelamento. Gente, não tenho que dar satisfação do motivo pelo qual eu não quero receber algum e-mail, ainda mais quando é publicitário! Mas acreditem, eu tive que informar!! Mas penso que aqui essa enrolação é estratégica, pra fazer o usuário desistir do descadastramento. Mas eu fui até o fim!!

É aquele negócio, seja o exemplo, comece por você! Quem trabalha com qualidade deve ser exigente em todos os sentidos. Errar é humano, claro, mas seja humilde o suficiente para pedir ajuda, não há nada de errado nisso. Pra finalizar, um exemplo de mensagem de feedback para o usuário muito bem bolada. Era isso que as meninas da revisão faziam com as mensagens dos nossos produtos, tornando-as amigáveis e significativas!

Cool!!

Cool!!

Pense antes de escrever e revise o que escreveu! Isso serve pra qualquer área da sua vida: um e-mail, um recado, um post no blog ou até mesmo nas redes sociais, um caso de teste, um caso de uso, uma história de usuário. Lembre-se que o objetivo da comunicação é passar uma mensagem. Cabe a você garantir que o seu significado seja recebido pelo outro sem ruídos e interferências.

Agora, vou “precionar” vocês pra me darem uma opinião!





Lançamento do TDC Florianópolis 2010

28 10 2010

Neste ano, o TDC Florianópolis, repetindo o imenso sucesso do TDC São Paulo, traz um modelo bastante diferenciado dos anos anteriores, organizado por trilhas, e com palestras específicas por tecnologia. A inscrição é realizada por trilha com um custo extremamente acessível.

Trilhas Stadium

As trilhas Stadium Sábado e Stadium Domingo não são restritas a um tema específico e apresentam uma grade diferenciada com apresentações de diversos temas como Arduino, Spring, Mobile, Ruby, SOA, PHP e Testes, realizando uma forte integração entre as comunidades.

Inscrições

programação está disponível e as inscrições já estão abertas.





Fundamentos do Teste de Software

28 09 2009

Há algum tempo venho pensando em escrever algo mais fundamentado aqui no blog. Hoje parei pra pensar, arrumei um tempo e resolvi falar sobre o capítulo 1 do Foundation Level Syllabus, material base pra certificação do ISTQB e BSTQB. É quase um resumão, às vezes com algumas considerações minhas imbutidas conforme minha experiência na área.

Este capítulo fala sobre os Fundamentos do Teste de Software.

Erro ao tentar finalizar uma transação importante!

Erro ao tentar finalizar uma transação importante!

Muitas pessoas devem se perguntar por que se faz necessário testes em software. Ora, devemos levar em consideração o contexto de cada software em desenvolvimento. Atualmente todos temos acesso a diferentes softwares diariamente. Em menor ou maior grau de dificuldade de uso, como por exemplo, aplicações bancárias, sejam elas acessadas pela web, celular ou caixa eletrônico. Você poderia imaginar o desastre se essas aplicações não fossem muito bem testadas? Você se sentiria seguro em realizar uma transação pela web? Bom, eu com certeza não. Outra aplicação que nos serve como exemplo, é o nosso querido Gmail. Bom, eu não vivo mais sem ele, e diferentemente do sistema bancário, eu não me preocupo muito em perder informações ali contidas (minha opinião tá, tem gente que tem muita coisa armazenada ali!!). Uma outra aplicação que considero importante de ser testada, são os sistemas de lojas e supermercados. Até hoje eu tenho o hábito de verificar os valores dos itens que estou comprando, porque não me sinto segura no sistema de barramento x valor do produto. Enfim, ema ema ema, cada um com seus problemas!! Esses exemplos servem pra mostrar que softwares que não funcionam corretamente podem trazer diversos prejuízos e grandes impactos para as pessoas e empresas que os utilizam.

Algumas causas dos problemas de software podem ser causadas por erros (enganos) humanos. O erro gera um defeito (bug) no software. E esse bug, gera uma falha no sistema. É atrás dessa falha que os testadores correm atrás (imaginei uma corrida de cachorros, onde eles correm em busca de um coelho, ou A recompensa).

Testadores atrás de um bug

Testadores atrás de um bug

Falhas podem ocorrer também, por eventos externos ao software, como quedas de luz, radiação, calor, poluição, campos magnéticos ou eletrônicos. Conheço um caso onde os servidores ficavam na mesma sala com 8 desenvolvedores, onde o ar condicionado no verão mal dava pra refrescar as pessoas. A temperatura da sala girava em torno dos 24 graus diariamente. Resultado disso: queda frequente do sistema, devido ao aquecimento das máquinas no ambiente.

Os testes têm funções específicas em cada fase do desenvolvimento e manutenção do software, e servem para reduzir os riscos de ocorrências de problemas no ambiente operacional, quando os defeitos encontrados são corrigidos em fase anterior a implantação na produção.

Qualidade em software implica em testes em todas as fases do desenvolvimento, desde o planejamento, através de testes na documentação, até a fase final do aceite do cliente. O teste ajuda a medir a qualidade em termos de defeitos encontrados por características e requisitos funcionais ou não funcionais do sistema. Os resultados da execução dos testes bem projetados pode representar a confiabilidade do software, quando poucos são os erros encontrados ou quando os mesmos são encontrados e corrigidos de forma efetiva.

Testes finalizados!

Testes finalizados!

E a pergunta que não quer calar é: quando devemos parar com os testes?

Bom, não se tem uma resposta padrão pra essa pergunta, porque tudo depende de cada projeto. Diversos são os fatores que podem definir quando parar-se de testar, como por exemplo: prazo, orçamento e riscos. É nesse sentido que os testes devem trazer informações suficientes para a tomada de decisão pelos stakeholders. Seus interesses são fundamentados nas limitações do projeto e, acredito eu, no grau de maturidade e qualidade do software desenvolvido. Para isso é que temos as versões beta, não é mesmo?





Qualidade do software

19 05 2009

Dando continuidade aos posts dos estagiários, agora é a vez do Marcello Caon (vulgo DJ Jogadi Apaixonado). Ele possui pouco tempo de experiência na área, mas já mostra que captou a essência da importância dos testes dentro da empresa.

“Uma área essencial: A qualidade do software é um dos tópicos mais valorizados pelo cliente na escolha de uma empresa para desenvolver seu sistema. O cliente quer resultado, não adianta ter um projeto pronto, com telas bem elaboradas, botões personalizados e menus interativos se nada disso funcionar direito! Não adianta ter um software assim se ele aceitar “ç” no campo data, ou aceitar um cadastro de usuário sem o campo “nome” estar preenchido, ou ainda uma visualização de notícia que exiba nomes de variáveis ao invés de seu conteúdo. E esses erros, acredite ou não, são comuns no campo da programação. E para captar esses erros que podem gerar desconforto na hora da apresentação do software para o cliente, surge o setor de “teste de software”.

Cada vez mais as empresas, sejam elas pequenas, médias ou grandes, observam o constante crescimento dos testes de software, e acabam se adaptando a esta nova “mania” que acaba se tornando essencial em algumas empresas, pois pode prevenir gastos enormes com manutenções futuras, de um simples bug que poderia ter sido detectado ainda na fase de programação do projeto se a empresa tivesse pensado em ter uma equipe de testes desde o início do mesmo.

Os benefícios dos testes de software não são observados apenas pela empresa, pois primando pela qualidade do software, além de evitar gastos com manutenções desnecessárias, o cliente pode ter em suas mãos um software mais estável e pouco suscetível a erros.

O ganho de agilidade durante a elaboração de um projeto também é grande, pois libera os programadores dos testes, que podem ser realizados por uma equipe especializada, que encontra erros, falhas e vícios de programação enquanto os programadores continuam no desenvolvimento do projeto.

Os benefícios trazidos por uma boa equipe de testes, com sua própria estrutura, seus próprios casos de teste, sua própria “independência” são incontáveis. É notório que as empresas que se adequam a esta “novidade” estão muito satisfeitas com os resultados e investem cada vez mais neste setor, primando sempre pela qualidade de seus softwares.”

O mais legal disso tudo é ver como esses meninos estão aprendendo a importância da qualidade no desenvolvimento de um produto. Nem todos seguirão a trilha de encontrar erros, acredito que muitos tem o dom de programar mesmo, mas serão desenvolvedores muito melhores, pelo simples fato de saberem que devem fazer o seu melhor a todo instante. Tô ficando orgulhosa 🙂





Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste

10 04 2009

Atualmente, a maioria das empresas de software enfrenta problemas relacionados à necessidade de melhorar a
qualidade do produto e a satisfação do cliente mantendo custo baixo e cumprindo prazos. O artigo anexo relata a
experiência de uma organização que utiliza a análise dos indicadores de teste como ferramenta para a melhoria
do processo de desenvolvimento e a garantia da qualidade do produto.

Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste





Um conto… nada real

11 03 2009

Inicio minhas atividades neste blog com um conto de autoria de um autor renomado na área de testes no Brasil: Leonardo Molinari.
Emprestei o seu último livro pro meu estagiário, e ele me veio com este conto, trocando os nomes dos personagens. Qualquer semelhança com nomes e acontecimentos, É SIM, mera coincidência. A coincidência maior foi eu ter assistido o filme Tropa de Elite no final de semana passado. Tomei a liberdade de fazer umas adaptações pra tornar o texto mais parecido com o filme que deu base ao conto.
O que tem haver com testes afinal? Bom, esta é a maneira incorreta de tratar qualquer pessoa da sua equipe, seja ela seu testador ou o desenvolvedor. E eu sou muito agradecida por não trabalhar num ambiente assim. Ao contrário: aqui testadores e analistas fazem parte da mesma equipe, e trabalham em conjunto para um objetivo maior: entregarmos um software com qualidade de acordo com os requisitos do nosso cliente.
Deliciem-se com a paródia, e sejam bem-vindos a nova casa!

Conto tecnológico: Tropa de Testadores de Elite

Há muito tempo, numa empresa muito, muito distante… Existia um grupo diferente de testadores que passavam intermináveis horas descobrindo bugs.
– Seu incompetente! Burro! Estúpido! Se você descobriu uma falha no programa de faturamento, mostra o bug na cara deles. Quero ver os desenvolvedores encararem mais essa! Nunca serão!!!
– Mas chefe…
– “Chefe” é o Cacilda!! Eu sou a analista aqui @#%¨$#@! Testador burro! Sou analista Fernanda e quem manda nessa porra aqui sou eu.
– Sim chefe! Digo, sim senhora! Sim, analista Fernanda!

Ao falar e ainda tremendo, o jovem testador Márcio levantou-se e fez um leve sinal de reverência. A sanguinária Analista Fernanda fez um sinal de aprovação.
– Testador Márcio, o senhor está vendo o que está escrito na porta?
– Sim, senhora! Sim, analista Fernanda!
– E o que está escrito ali?
– BATE!

Neste momento, antes que o indefeso testador pudesse se defender, a analista levantou-se e deu-lhe um tapa na cara, daqueles de impor respeito até em mulher de malandro. Abalado, o testador não sabia o que fazer, além de sentir seu rosto formigar. Nesse momento o relógio marcava 18:00 em ponto.
– Burro! Pronuncia-se assim: Batalhão de Testadores Especiais, o “BATE”. Aprendeu idiota?
– Sim, senhora! Sim, analista Fernanda! (o medo da demissão era maior do que a revolta pelo tapa na cara, pois Márcio era novo e tinha casado há pouco mais de 15 dias.)
– Mostre-me o relatório de erros que você aprontou – disse a analista Fernanda com sangue nos olhos.
– Sim, senhora! Sim, analista Fernanda! Aqui está!

Nesse momento o franzino testador não conseguia parar de tremer. Fernanda analisou o relatório sem piscar, sua face demonstrava ira. Foi ai que o testador ficou confuso com uma cena bizarra que os seus olhos deslumbravam. Nesse momento a analista estava sorrindo. A analista ainda sorrindo pergunta:
– Quem fez esse programa?
Esperando ser castigado o testador responde:
– Foi… foi o Luiz – um programador novo que se aventurava o pouco na empresa.

– Acompanha-me até a sala de programação onde os desenvolvedores se amontoam – falou em voz alta a analista Fernanda.
– Sim, senhora! Sim, analista Fernanda!

Em pouco tempo estavam face a face com o desenvolvedor Luiz. Este que não sabia que seu fim poderia estar muito perto.

– Luiz, olhe para mim – disse Fernanda – Foi você que fez essa P@#$#*? – Falou apontando para o relatório onde estava o nome do programa com o bug.

– Você Luiz, você não é um programador. Você é um moleque. Você é um fanfarrão! – Finalizando a frase com um belo tapa na cara.

– Sim senhora, lá no Acre é comum ficar o dia todo na floresta tirando leite do pau e desenvolvendo assim. Mas qual é? Qual o pepino?

Nesse momento incrivelmente não se escuta nenhum passarinho cantando e com a rapidez de uma lebre a analista pegou o programador pelo colarinho, deu-lhe três tapas na cara o imobilizando. Seus olhos enchem de lágrimas, sua boca fica seca, ele até tenta reagir, mas o medo o deixa paralisado a beira dos portões do inferno e de cara a cara com o próprio diabo. Ele tentou reagir, mas Fernanda o pegou pelo pulso de forma que nada pudesse fazer. Ele chegou a contorcer de dor.
– Onde está o bug seu filho da #$%@#*&¨? Fala desgraçado!
Fernanda era violência pura. Nada a detinha.
– Não sei, não sei… ai ai ai ai… Eu não sei, eu juro!! Dizia Luiz.
– Você sabe sim, seu canalha! Diga-me ou você vai apanhar mais… Márcio, trás o saco! Trás o cabo de vassoura!!!

Em poucos segundos, como passe de mágica, o programador quase sem forças informa onde está o bug.
– Tá bom eu sei… Me larga, mas não bate na cara, na cara não! Por favor, na cara não…

A analista agora agarrada nos cabelos do pobre coitado fala:
– Tá vendo esse relatório de bugs? Vocês é que financiam essa merda, é por causa de programadores que nem você que a empresa perde dinheiro.

Fernanda ainda com as mãos nos cabelos do acreano, puxa sua cabeça em sentido ao seu joelho e mancha sua calça holandesa com sangue mortal.
– Isso é para você aprender a fazer um programa decente. Desgraçado… Você tem meia hora pra colocar o código novo consertado em produção, ou então: Pede pra sair! Pede pra sair!

Não se precisa dizer mais nada. No dia seguinte estava tudo 100%.

O fato é que o analista estava treinando vários testadores novos para atuarem no BATE. Eles eram uma tropa de testadores de elite que merecia respeito. O quente não eram seus métodos de descobrir bugs. O quente eram seus métodos de resolução de bugs. A analista estava velha e ia se aposentar em 3 meses. Precisava achar alguém que ficasse em seu lugar. Ela viu em Márcio um forte candidato, pois se parecia com ela há alguns anos atrás.

O treinamento era exaustivo. Fernanda indicava o livro de testes ou qualidade que deveria ser lido de um dia para o outro, e cuja série de perguntas (ou problemas) iriam ser respondidas no dia seguinte. Era na realidade um teste por dia. Quem não lia não tinha chance alguma: ou era demitido sumariamente e se não passasse no teste era também demitido. Cerca de 50% da turma foi eliminada de cara. Eram livros em inglês, em espanhol e em português. Cada um com 300 páginas ou mais. Pauleira diária. Eles sempre gritavam todos juntos ao final de cada dia, tal como um hino:

– Bug bom é bug morto! Desenvolvedor bom é desenvolvedor sem bug!

Sempre uma vez por semana eles faziam testes reais e tinham de descobrir bugs. Eles foram devido a pressão se tornando opressores dos bugs. Uma fúria indomável surgia dentro de cada um quando descobriam um bug. Alguém tinha de pagar por aquilo.

O problema é Márcio se tornou uma cópia da analista Fernanda. Márcio se tornou mais que a Fernanda era: era tão violento e medonho quanto Fernanda, porém era mais sórdido. Começou a manipular os colegas e quem não era testador em sua visão era em pouco tempo demitido.

Márcio passou a querer mais e mais. “Fernanda tinha de ser eliminada” pensou ele.

Quinze dias da aposentadoria, Márcio mostrou um vídeo gravado por uma câmera de bolso para o diretor da empresa, ao mesmo tempo em que ele tinha descoberto vários podres do diretor. Não restava dúvida: Analista Fernanda foi demitida por justa causa. Márcio ficou em seu lugar.

Algum tempo depois quando um novo testador iniciou na empresa, Márcio se apresentou:
– Aqui meu filho é o BATE: Batalhão de testadores especiais. Aqui nesta sala quem manda é eu. Se você não entendeu é BURRO. Aqui é uma cova de leões. Matamos um leão por dia aqui. Aqui não há testadores, o que existe são sobreviventes. Boa Sorte. Eu sou o Testador Márcio. Escutou?

Caro Leitor, vejamos a não-qualidade apresentada:
1- trate todos com respeito;
2- desenvolvedor não é criminoso. Aparecer um bug não é ato de delito;
3- não adianta empurrar conhecimento goela abaixo. Ninguém é máquina. Cada um tem um modo de assimilação;
4- melhorar a qualidade de um código é muito mais que testar;
5- sempre existirá pressão no trabalho, mas alguns profissionais exageram e passa a ser uma pressão psicológica terrível. Tudo é um equilíbrio.

Texto original:
MOLINARI, Leornardo. Testes Funcionais de Software. Florianópolis: Visual Books, 2008. p166-169

Também em:
http://diariodaqualidade.blogspot.com/2007/10/contos-tecnolgicos-de-qualidade-08.html

Edição: testador Márcio e Robson B.