09 Técnicas para Trollar a Equipe de Testes

Descubra como Trollar o(s) Responsável(eis) por Testes de Software com 09 Dicas Infalíveis! - Série Checklists 2

Validações, testes e verificações são atividades essenciais para a qualidade dos sistemas de informação entregues e devem ser aplicadas de forma contínua, durante todo o clico de desenvolvimento. 

É notável, porém, que polêmicas, mal entendidos e certas limitações insistam em sobreviver dentro da cultura de provedores de serviços de TI quando se trata desse assunto.

Para falar sobre isso eu não vou propor uma descrição do processo de testes, mas fazer uma sugestão diferente: que tal experimentarmos uma brincadeira? 

Pregue uma peça na equipe/profissional responsável pelos testes da sua empresa: conheça 09 dicas com quais você facilmente irá trollar o processo de validação e testes.

Para quem topar participar, peço que leia cuidadosamente os 09 itens. São técnicas infalíveis que deixo para você aplicar com analistas de testes / testers, e deixá-los de cabelo em pé! 

Confira a seguir...

01) Deixe para Testar no Final

Este é o primeiro passo para Trollar o(s) profissional(ais) responsável pelos testes: é indispensável que você envolva-o(s) somente no fim do ciclo de Desenvolvimento do Software. 

Logo irá notar que os primeiros ciclos de testes serão extremamente trabalhosos e demorados, pois irão gerar uma imensa pilha de falhas, muitas que poderiam ter sido descobertas nas fases anteriores. Tudo isso deixará sua equipe com uma carga de trabalho que parecerá nunca chegar ao fim! 
Mas a melhor parte ainda está por vir: o fato de ter envolvido o responsável por executar os testes tardiamente o deixará totalmente "baratinado" no primeiro ciclo de testes. Afinal, ele chegou de para quedas no último instante sem conhecer coisa alguma sobre os requisitos. 

Em grandes projetos, essa técnica se torna ainda mais eficaz. 

02) Esconda Requisitos!

Quer aprontar de verdade com o profissional / a equipe de testes? Então não esqueça desta dica clássica: deixe ele(a) acessar apenas alguns dos documentos de requisitos do sistema e esconda outros. O coitado vai achar que está sabendo de tudo! Nem imagina ele que estará elaborando um Plano de Testes incompleto, senão falho. 

Mas se você está realmente determinado a trollar o responsável pela execução dos testes, faça melhor: esqueça essa história de especificação, disponibilize somente o sistema e peça que eleinicie sua atividade sem que exista ao menos um Plano de Testes! 

No primeiro ciclo de testes, vale a pena ficar do lado do sujeito para apreciar a fisionomia de interrogação em seu semblante enquanto estiver tentando fazer seu trabalho. 

03) Mude os Requisitos!

Esta é uma boa dica para complementar a anterior: aproveite o ciclo de correções das falhas encontradas para mudar requisitos e assegure-se de que o responsável pelos testes não terá conhecimento das alterações. De preferência, nem atualize-as nos documentos de especificação de requisitos. 

Será muito divertido jogar essa "casca de banana" na qual provavelmente mais cedo ou mais tarde ele irá escorregar!

04) Reduza o Tempo do Ciclo de Testes

É uma prática simples e bem conhecida, mas que não posso deixar de citar: compacte o cronograma dos testes o quanto for possível. Por mais que pareça inviável a execução de testes em um período tão curto, não ceda! 

Se for questionado, coloque a culpa no orçamento ou na pressão do cliente para entrega. 

05) Interrompa o Ciclo de Correções Precocemente  

Uma das minhas técnicas prediletas: de surpresa, chegue num belo dia ao trabalho e simplesmente diga a sua equipe que acabou o tempo de corrigir, autorizando o início de um novo ciclo de testes. 

Ao repetir os scripts, os responsáveis por testar encontrarão exatamente as mesmas falhas, o que os deixarão completamente desmotivados. No próximo ciclo, repita esta decisão! 

06) Autorize a Implantação Logo Após o Ciclo de Correções

Essa é para quem quer pegar pesado! Se for o seu caso, tente isso: aguarde as correções das falhas encontradas no ciclo de testes anterior e determine a implantação do sistema exatamente após o término destas correções. 

Perceba que na prática, você terá uma nova versão do sistema não testada em produção, o que deixará o(s) responsável(eis) pelos testes plenamente aflito(s)! 

Ah, e não esqueça de colocar a culpa na equipe de testes quando os erros forem encontrados pelo cliente, afinal como é possível haver inúmeros bugs depois deles terem testado o sistema por tantas vezes, não é mesmo!?

07) Seja Vago em Relação a Critérios e Objetivos

Ignore questões como estratégia de testes, níveis de riscos aceitos, prioridades, critérios de qualidade e aceitação, até porque estes aspectos são muito teóricos. 

Quando for questionado sobre questões como estas seja vago em sua resposta. Diga apenas que "Devemos testar o essencial!".

O profissional de testes irá se sentir como quem acabou de receber um conselho do Mestre dos Magos e irá se torturar a respeito das prioridades e níveis de exigência que serão usados para compor os seus planos de testes. 

08) Forneça um Ambiente Inadequado

Mais uma dica simples de implementar, super eficaz, baseada numa técnica que tem sido aprimorada ao longo de décadas por equipes de TI e que vai te ajudar a trollar principalmentequem executa os testes.

O objetivo é produzir um ambiente de testes no qual a configuração seja totalmente distinta daquela em que o sistema será implantado. Garantindo isso, existirá uma grande probabilidade de que erros que acontecem(rão) com o sistema em produção não possam ser reproduzidos no ambiente de testes. 

O resultado é surpreendente! O processo de testes simplesmente não será capaz de detectar determinados erros, o que deixará sua equipe confusa ou revoltada (o segundo sentimento é o mais provável, mas a variação entre os dois vai depender do fato da equipe ter ou não ciência da distinção entre os ambientes). 

09) Assuma algumas falhas, mas esconda-as do cliente!

Para finalizar o troll, coloque esta cereja no bolo: determine que algumas das falhas não devem ser corrigidas, mas peça que a equipe guarde esse segredo. 

Quando os bugs forem encontrados por clientes ou outras partes interessadas, eles irão ficar chateados, provocando um desânimo ainda maior na equipe de testes!

Fernando, você está falando sério?

É claro que não. Afinal, quem faria uma brincadeira de mau gosto como esta com colegas de trabalho, não é verdade ?  :)

O objetivo deste artigo foi eleger alguns pontos de checklist que podem ser usados para avaliar o Processo de Validação e Testes de um Provedor de TI. 

Como foi citado no subtítulo, este é o segundo capítulo da minha série sobre Checklists que eu inciei com este outro artigo: 09 Peguntas para o Gerente de Transição de Serviços.

09 Perguntas para Avaliar o Processo de Validação e Testes

Pois bem, com base em boas práticas de mercado, podemos transformar estes 09 Itens que descrevi em 09 perguntas para serem feitas na avaliação do processo de Validação e Testes. Quanto mais positivas são as respostas, maior o nível percebido de maturidade / capacidade do processo avaliado. 

São elas: 

01) O Processo de Validação e Testes é considerado durante todo o ciclo de vida?

02) Os Requisitos do serviço novo ou alterado são revertidos em modelos, scripts, checklistse planos de testes?

03) A Gestão de Mudanças considera adequadamente o Processo de Testes?

04) O cronograma para atividades de testes é planejado adequadamente, considerandoescopo, riscos, histórico e quaisquer outros fatores influenciadores?

05) Existem critérios bem definidos para validar o fim do tratamento de falhas?

06) O controle de mudanças garante que um ciclo de testes será executado novamente sempre que alterações são submetidas (testes de regressão) ?

07) Existem Políticas de Validação e Testes bem definidas que direcionem os critérios de qualidade e controle de riscos adequados? 

08) Existem normas e procedimentos formalizados e seguidos para garantir que o ambiente de testes reflete o ambiente operacional?

09) Todas as partes interessadas estão envolvidas nas decisões sobre aceitação de riscos, incluindo aqueles derivados de erros conhecidos não tratados?

Lembrando que, assim como demais artigos desta série, a ideia não é findar itens de Checklists, mas usar de liberdade para elencar alguns quais considero trazer boas reflexões.