QUALIDADE DE SOFTWARE - VALIDAO E VERIFICAO

FATORES PSICOLGICOS Segundo Koscianski e Soares (Koscianski e Soares, 2007), h duas boas razes para que um programador no teste o prprio cdigo. O propsito de um caso teste de certa forma destruir o trabalho do programador revelando um defeito. Esse assunto foi comentado por Yourdon (1989);
O autor no possui nenhuma motivao psicolgica para inventar casos de teste que confundiro os delicados mecanismos dentro do cdigo. demonstrem que seu produto est com falhas ou errado... tratam seus programas como frgeis peas de porcelana chinesa e fornecero casos de teste que certamente no confundiro os delicados mecanismos dentro do cdigo.

Essa idia de destruio comentada tambm por Weinberg (1971): Como o cdigo resultado do trabalho intelectual do programador, procurar erros espcie de ataque as suas prprias convices. Essa situao provoca um fenmeno chamado dissonncia cognitiva, no qual o individuo resiste a cumprir a tarefa. Um programador que realmente v seu programa como uma extenso do prprio ego no tentar encontrar todos os erros. Ao contrrio, tentar provar que o programa est correto, mesmo que isto signifique ignorar erro que, para outras pessoas, so gravssimos. Ainda segundo Koscianski e Soares (Koscianski e Soares, 2007), um segundo motivo que dificilmente um programador consegue criar um caso de teste que rompa com a lgica de funcionamento de seu prprio cdigo. Entretanto, so justamente as situaes impossveis que devem ser verificadas. Um bom exemplo disso Comentado uma rotina que jamais receberia um parmetro nulo acabou falhando exatamente por causa disso. H dois tipos de casos de teste que revelam falhas com certa freqncia: escolher valores limites de parmetro ou combinaes de valores que violem as especificaes do software. Steve McConnell (McConnell, 2006) faz interessantes observaes acerca dos testes executados pelo desenvolvedor: Os testes do desenvolvedor tendem a ser testes limpos. Os desenvolvedores tendem a testar se o cdigo funciona (testes limpos) em vez de testar todas as maneiras pelas quais eles podem falhar (testes sujos). As empresas imaturas em testes chegam a dispor de aproximadamente cinco testes limpos para cada teste sujo. J as empresas mais experientes com testes tendem a dispor de aproximadamente cinco testes sujos para cada teste limpo. Essa relao no revertida pela reduo dos testes limpos; ela se apresenta assim pela criao de 25 vezes mais testes sujos. Os testes do desenvolvedor tendem a apresentar uma viso otimista da cobertura do teste. Os programadores de nvel mdio acreditam que esto atingindo 95% de cobertura do teste, mas normalmente esto obtendo algo em torno de 80% de cobertura no melhor caso, 30% no pior caso, e algo em torno de 50% a 60% em mdia. Os testes do desenvolvedor tendem a pular os tipos de cobertura de teste mais sofisticadas. A maioria dos desenvolvedores interpreta como adequada a cobertura de teste conhecida como Cobertura de 100% das instrues. Esse um bom comeo, mas dificilmente ser suficiente. Um padro melhor de cobertura atingir o que denominado Cobertura de 100% dos desvios, Com cada termo de predicado sendo testado para, pelo menos, um valor verdadeiro e um valor falso. Nenhum desses aspectos reduz o valor dos testes do desenvolvedor, mas ajudam a coloc-los na perspectiva correta. Por mais valiosos que sejam os testes do desenvolvedor, eles sozinhos no so suficientes para fornecer um controle de qualidade adequada, devendo ser complementados com outras prticas, como testes independentes e tcnicas de construo colaborativa.