Defect quantity estimation

There are some indicators of the quantity of defects a certain areea of the product might have.

Some say that testing is asking the product the important questions. Well I think that when a certain area raises too many questions about the expected product behaviour, it will probably have proportionally many defects. I guess this is based on these principles:

• what's hard for me (user) to understand, is also hard for the developer to implement.
• the more complex an area is, the more dificult it is to be self-explanatory, the more questions it will raise for the user, and themore defects it might have (because it is complex)
• bug quantity grows exponentioally with product complexity, or, which is the same,
• bug quantity grows exponentially with product size, if we count for product size areas of the product are connected
  

Other things that make me suspect of defects abundance:

• when same operation/feature/information is presented on different places in different ways. More generally, usually Redundance leads either to incorrectness or mis-information, because when a user sees apparently same information on different places, he might think it is not the same.

testar é...

Reina um grande desconhecimento e equívoco sobre o que é testar. Vulgarmente confundido com "verificar", é considerado uma tarefa monótona, que não exige criatividade ou raciocínio e tomadas de decisões na hora. A definição que actualmente adopto é a seguinte: "testing is this: helping our clients to ask and answer their most important questions. (M. Bolton)". O cliente pode ser quem faz o código, quem diz as specs, quem "manda" na empresa, ou o cliente própriamente dito. Testar é essencialmente aprender, aprender o que faz o produto, o que devia fazer, o que querem que ele faça, o que pode eventualmente fazer inadvertidamente. Testar é experimentação científica, colecção de estatísticas, investigação criminal (encontrar um bug, persegui-lo, determinar as provas necessárias ou circunstanciais, etc) e não é de todo monótono. A parte da verificação, ou confirmação propriamente dita é apenas uma pequena percentagem da nossa actividade, e tendencialmente candidata a automatização. Testar é também comunicar, advogar, intermediar.

Isto vem ao encontro do meu segundo comentário: A engenharia de software, dum modo geral, é uma ciência social. Ao contrário do que se pensou durante décadas, não é uma ciência exacta, nem sequer é comparável a outras engenharias como a mecânica ou construção civil. É um campo em que o factor humano está presente ao longo de todo o processo: nos requisitos e na constante adaptação ás transformações, no compromisso entre funcionalidade idealizada, funcionalidade real e funcionalidade execuível. Se analisarmos a ocupação do nosso tempo, chegamos à conclusão que apenas uma parte é utilizada na "produção" de software, propriamente dita. A negociação, a aprendizagem, a experimentação, o debate, a passagem de conhecimentos, etc, ditam que este domínio em que nós trabalhamos seja, como todas as ciencias sociais, imprevísivel. Não existem projectos sem imprevistos de toda a espécie, e só o mais ingénuo dos estudantes pode acreditar que os requisitos não vão mudar, que o código vai funcionar à primeira, que as tecnologias não vão mudar...

Não é "defeito" das empresas, é "feitio" da área onde se movem!