14
Conto erótico multimídia sobre teste de software – Episódio 02 – Por que planejar testes
Filed Under (Teste de software) by Antonio Passos on 14-04-2009
Tagged Under : Atributos de qualidade de software, Características de qualidade de software, critérios de teste, Plano de teste, Qualidade de software, Teste de software
Cena 01 – Continuação…
O episódio anterior terminou com Alex tendo que decidir entre a compra de camisinhas sabor framboesa sem selo do INMETRO e caminhas sem sabor com selo do INMETRO. Se você o perdeu, leia AQUI pra saber como essa história começou.
Para a escolha de Alex, foi decisiva a lembrança de um vídeo que recebeu tempos atrás. Nele, um jovem como o Alex testa até onde vai a resistência de uma camisinha.
Será, pensou ele, que as camisinhas sabor framboesa sem o selo do INMETRO eram confiáveis assim também?
Preferiu não arriscar. Agradeceu ao balconista, entrou no carro e seguiu para a rua das farmácias. Era visível sua frustração. Mas achava que não devia correr o risco de passar o resto da vida chorando caso, na hora H, a camisinha estourasse ou tivesse um furo.
Chegando à rua das farmácias (CLS 102), mal estacionou o carro, correu para a drogaria.
- Boa noite. Vocês têm camisinhas sabor framboesa com selo do INMETRO?
- Sim. Temos estas aqui. A mais cara afirma que testa eletrônicamente cada uma das camisinhas. As demais, por amostragem.
Alex escolheu as camisinhas testadas indivualmente. Mesmo sendo mais caras. No caixa, não quis esperar pelo troco. Muito menos pela embalagem das camisinhas.
Correu de volta ao carro, entregou as camisinhas à garota, deu uma tremenda arrancada e partiu em alta velocidade para seu apê.
A garota olhou para as camisinhas e exclamou:
- Alex, safado, você comprou camisinhas com vibrador da Blowtex?
E os dois se foram sorrindo. Não era pra menos. Afinal o fim de semana estava só começando! E com segurança! No carro, a música com que ela fez streap tease na boate.
Cena 2 – Continuação…
No post anterior, deixamos Alex de cabeça baixa, rabiscando um pedaço de papel. A posição poderia sugerir que ele pensava em O QUE FAZER. Mas não. Ele pensava em COMO FAZER. A decisão de dispensar aquela software house já estava tomada. Restava comunicar a decisão.
Passados alguns minutos, Alex levantou a cabeça, recostou-se na cadeira e disse ao representante da software house que precisaria analisar melhor sua proposta. Alex era tímido. Para ele, dizer não de imediato, assim, na cara do representante, era quase impossível. Melhor fazê-lo por e-mail.
A caminho de sua baia, Alex lembrou-se do jovem testando a resistência da camisinha. Seria possível testarmos software da mesma forma? Haveria como submeter os softwares a condições extremas de uso e assim descobrir o quão confiáveis são?
- O que você acha, Greg? Podemos testar softwares como testamos camisinhas?, perguntou ao seu colega.
- Como que é? Alex, seu fim de semana deve ter sido demais, não?, respondeu Greg balançando a cabeça em sinal de reprovação.
- Falo sério, Greg. Se camisinhas, antes de serem liberadas para comercialização, são submetidas a ensaios em laboratórios que atestam sua resistência, por que, antes de liberarmos os softwares para produção, não os submetemos a testes a fim de nos assegurarmos de sua confiabilidade?
- Alex, você pode não ter perdido a cabeça, mas é certo que está com um parafuso dela solto. Desde quando colocamos softwares em produção sem antes ser testado?
- Greg, existem testes e testes. Veja do que estou falando.
Alex mostrou o vídeo em que o rapaz demonstra a resistência da camisinha.
- E então, Greg? Será que nossos softwares passariam num teste como este? Usados, digamos, fora das condições normais de temperatura e pressão eles se mantêm confiáveis?
Alex convencera-se que os testes até então realizados não garantiam a confiabilidade que se deveria esperar dos softwares. Convencera-se também que deveria haver um meio de demonstrar que o software fora testado e que passara nos testes. Ou seja, para ele, a confiabilidade do software deveria estar apoiada em evidências de testes, não em fios de bigode de quem quer que fosse. Você acha que ele estava certo?
Recentemente Alex havia participado de um simpósio internacional sobre qualidade e confiabilidade de software, no qual conheceu Margareth. Ela proferiu uma palestra em que abordou as características de qualidade dos softwares. Como haviam trocado cartões durante o coffee-break, foi fácil para ele contactá-la para combinar um happy hour.
Alex chegara ao barzinho bem antes do horário combinado, e já havia tomado uns dois chopps quando Margareth chegou.
- Oi, Alex! Muito atrasada?
- Claro que não. Me acompanha no chopp?
- Não. Vou de martini.
Os dois jogaram conversa fora durante um tempo, e então Alex perguntou:
- Margareth, como vocês avaliam a qualidade dos aplicativos que desenvolvem? Melhor: como vocês garantem a qualidade dos aplicativos que desenvolvem?
- Há diversos critérios ou atributos de qualidade, Alex. A norma ISO 9126-1 estabelece os seguintes.
Margareth tirou da bolsa o mapa mental abaixo e mostrou para ele.
- Caracas! E eu pensava que para o software ter qualidade bastava fazer o que se esperava que fizesse!
- É o que os desenvolvedores normalmente pensam, Alex. Os DE-SEN-VOL-VE-DO-RES. Será que os clientes não esperam receber um software com interface atrativa, que respondem aos comandos rapidamente e trate seus erros de forma adequada? Certamente que sim, ainda que não expressem isso.
- Tenho aqui comigo o mapa mental da FURPS. Dê só uma olhada.
E mostrou-lhe esse outro mapa.
Neste, vemos sugestões de testes associadas a cada um dos atributos de qualidade.
- Estranho! Não encontro no mapa da FURPS os testes de unidade, integração, sistema e aceitação.
- Porque testes de unidade, integração, sistema e aceitação são fases ou estágios do teste funcional. O que você me diz, Alex, da confiabilidade dos softwares submetidos apenas aos testes de aceitação? Àqueles "testes" que comumente realizamos com dados aleatórios quando o software já está construído para demonstrar que ele funciona?
- Olha, depois que vi esses mapas, creio que a probabilidade desses softwares terem defeitos é muito grande. Se é verdade que os testes de aceitação são apenas um estágio do teste funcional – que por sua vez é um dos muitos testes existentes para se verificar a qualidade de um software -, diria que esses softwares não apresentam evidências de que são robustos, de que são confiáveis.
Alex não tirava os olhos dos mapas. Comparava-os na tentativa de encontrar semelhanças e diferenças.
- Desista, Alex. Não há correspondência entre os atributos de qualidade desses dois mapas.
- Margareth, estou pensando no tempo que seria necessário para se verificar todos esses atributos de qualidade. Vocês realizam realmente todos esses testes? Os testes que realizam são exaustivos e conclusivos?
- O que você que dizer com "exaustivos" e "conclusivos"? Se for testar todas as possibilidades, tanto as corretas quanto as incorretas, de uso do software, rodando nos mais diversos ambientes… esqueça. Elas seriam infinitas, logo impossíveis de serem todas testadas!
- Peraí! Você está me dizendo que testam os softwares apenas parcialmente?
- Sim, isso mesmo.
- Então vocês não podem concluir que o software não possui defeitos, mesmo tendo passado por uma bateria de testes?
- De novo, Alex, você acertou. O custo dos testes para garantir que um software tenha zero defeitos pode superar o custo do defeito para o negócio. Daí que há um momento em que devemos interromper os testes. Que momento é esse, você me pergunta? Depende do software. Roberto Murillo escreveu para a Administradores um artigo que aborda essa questão. Tome, leve para ler quando chegar em casa.
Margareth tirou da bolsa o artigo Testes de software: qual a duração e abragência ideias?, e entregou para o Alex.
- Como testes exigem recursos – sempre limitados! -, temos que planejar o que testar. Ou seja, não podemos sair por aí com uma câmera na mão e uma idéia na cabeça, digo, um teclado na mão e uma massa de dados na cabeça, testando o que der na telha! Nossos alvos devem ser os pontos críticos, aqueles mais vulneráveis, mais susceptíveis a defeitos, que oferecem maior risco para o negócio. Quanto mais limitados forem os recursos para testes, melhor devemos planejar o que testar!
- OK, acho que compreendi. Só não saberia como selecionar esses alvos.
- Alex, o papo tá bom, sua companhia, melhor ainda, mas preciso ir. Softwares me esperam para serem testados.
- Você tem compromisso para Sábado à noite? Tenho convites para o espetáculo do Grupo Corpo no Teatro Nacional.
- Vou pensar. Combinamos durante a semana por telefone.
Alex acompanhou Margareth até o carro. Depois voltou, pagou a conta, chamou um táxi e foi para seu apartamento. Ao chegar no apartamento, tomou um banho e deitou-se para dormir. Mas, apesar do cansaço, teve dificuldades em pegar no sono. Não era pra menos. Haveria de levar um tempo até que aquela conversa com Margareth decantasse. Sua mente agora girava tentando descobrir que critérios deveriam ser usados para selecionar o que testar. Você saberia alguns?
Cena 01 – Alex tem que optar entre camisinhas com e sem selo do INMETRO
Alex vira a cabeça e volta a olhar para a felina que o aguarda. Ela pisca-lhe o olho, enquanto, sensualmente, percorre com a língua seus lábios carnudos como que a dizer… Cuida, venha logo! Estranhamente, porém, o que ele viu não foi a Deusa que conheceu horas antes na boate, mas, sim, um escorpião gigante com quem, se a camisinha sabor framboesa estourasse, teria que dividir seu Audi A4 novinho, seu apê no bairro nobre da cidade e seu salário de gerente de projeto de TI, cargo para o qual fora promovido recentemente.
Nesse instante, um homem jovem que vinha também de uma balada e escutava a conversa, dirigiu-se ao Alex:
- Você pode esperar aplicativos com interfaces modernas, aderentes ao novo conceito web 2.0, e bases de dados de alta perfomance, atributos que só a nossa empresa pode entregar.
O representante da fábrica de projetos, não se saber o porquê, engasgou-se com a água. Foi preciso o Alex dar um murro na costa do homem para que ele se recuperasse. 
