Comments on: Casting Data Types and Testing Boundaries http://www.testingmentor.com/imtesty/2009/11/13/casting-data-types-and-testing-boundaries/ Treatises on the practice of software testing Mon, 06 Sep 2010 15:27:05 -0400 http://wordpress.org/?v=2.9.2 hourly 1 By: testingmentor http://www.testingmentor.com/imtesty/2009/11/13/casting-data-types-and-testing-boundaries/comment-page-1/#comment-133 testingmentor Sat, 14 Nov 2009 04:23:12 +0000 http://testingmentor.com/imtesty/2009/11/13/casting-data-types-and-testing-boundaries/#comment-133 Hi Dennis, Sorry, I struck a nerve. A strongly typed language is relative to what it is being compared. As you point out C is more strongly typed than some languages, but less than others. I very much agree with your statement about design and usability issues and the "silent, over-generous acceptance of inputs." Over-generous allowance of inputs coupled with implicit casting is a classic example where boundary type defects can occur. This bug is not caused by a flaw in the programming language per se, but a flaw in the design and implementation. The more a tester understands fundamental programming concepts (and the specifics of a particular programming language) the better he/she will be at identifying areas of high risk, and generating a rich set of tests that have a higher probability of exposing an error or demonstrating correctness and limit redundancy. - Bj - Wednesday, September 05, 2007 2:54 PM by I.M.Testy Hi Dennis,

Sorry, I struck a nerve. A strongly typed language is relative to what it is being compared. As you point out C is more strongly typed than some languages, but less than others.

I very much agree with your statement about design and usability issues and the “silent, over-generous acceptance of inputs.” Over-generous allowance of inputs coupled with implicit casting is a classic example where boundary type defects can occur.

This bug is not caused by a flaw in the programming language per se, but a flaw in the design and implementation. The more a tester understands fundamental programming concepts (and the specifics of a particular programming language) the better he/she will be at identifying areas of high risk, and generating a rich set of tests that have a higher probability of exposing an error or demonstrating correctness and limit redundancy.

- Bj -

Wednesday, September 05, 2007 2:54 PM by I.M.Testy

]]> By: testingmentor http://www.testingmentor.com/imtesty/2009/11/13/casting-data-types-and-testing-boundaries/comment-page-1/#comment-132 testingmentor Sat, 14 Nov 2009 04:23:02 +0000 http://testingmentor.com/imtesty/2009/11/13/casting-data-types-and-testing-boundaries/#comment-132 Sorry, I drove off the rails when I saw "programming languages that are not strongly typed (such as C)." C Language is strongly-typed of course. I think the confusion has to do with the fact that C allows types to be implicitly determined (usually int) in the absence of explicit declaration. That and the ability to cast a pointer to anything means you can (1) be confused and (2) create a lot of mischief. The language is still strongly-typed, just not the way Java or C# are (where the ability to cast references is constrained and storage representation is not exposed). Having gotten that off of my chest, I think the article is on point concerning boundary testing. My suspicion is that the "casting" in the MSPaint example is between strings and desired value format, although the model for fractional pixels (there are such things on some occasions). The silent, over-generous acceptance of inputs raises a whole set of usability issues and design considerations. I am not surprised that this is left to resolution by user trial-and-error discovery. Because it has become fodder for your example, I wager this MSPaint dialog interface is neither well-specified nor well-documented if it raises testing issues now. It is not a programming-language problem as such. Wednesday, September 05, 2007 2:19 PM by Dennis E. Hamilton Sorry, I drove off the rails when I saw “programming languages that are not strongly typed (such as C).” C Language is strongly-typed of course. I think the confusion has to do with the fact that C allows types to be implicitly determined (usually int) in the absence of explicit declaration. That and the ability to cast a pointer to anything means you can (1) be confused and (2) create a lot of mischief.

The language is still strongly-typed, just not the way Java or C# are (where the ability to cast references is constrained and storage representation is not exposed).

Having gotten that off of my chest, I think the article is on point concerning boundary testing.

My suspicion is that the “casting” in the MSPaint example is between strings and desired value format, although the model for fractional pixels (there are such things on some occasions). The silent, over-generous acceptance of inputs raises a whole set of usability issues and design considerations. I am not surprised that this is left to resolution by user trial-and-error discovery.

Because it has become fodder for your example, I wager this MSPaint dialog interface is neither well-specified nor well-documented if it raises testing issues now. It is not a programming-language problem as such.

Wednesday, September 05, 2007 2:19 PM by Dennis E. Hamilton

]]>