Talk:Equivalence partitioning

message: James Bach just gave a hevy dose of critique of this page  I belive that this should be looked into.
http://www.satisfice.com/blog/archives/1669  — Preceding unsigned comment added by 195.216.46.27 (talk) 07:43, 28 November 2016 (UTC)
thread_title:  Critique 

message: The external link appears to go to a site that does not appear to fulfill the Wikipedia guide on external links. As such (and as it doesn't seem to add anything to this article), I am going to remove it.
Any objections?
Jtowler 18:55, 26 November 2006 (UTC)
thread_title:  External Link 

message: IMHO the second example (using EP for "white box testing") specifically describes a case which would be called "grey box testing". In the example you use the knowledge of the internal behaviors to create the specific EPs. But after that you would use the EPs you found to test one value out of every partition at the interface level. No internal data structures are tested. The internal behavior is just examined to construct the test cases which is a pure example of grey-box testing. 78.54.16.163 (talk) 17:35, 20 July 2008 (UTC)
replies: text: ALl one must do is read a book on it. Either of Kaner's books would suffice. Beizer's book. Almost all of agile black box testing uses the concept (see SFDPOT for example). 04:47, 19 December 2016 (UTC)
thread_title:  White box vs Grey box 

message: Are there any references that evaluate whether the theory of Equivalence Partitioning holds any merit?  It seems fundamentally flawed to me.  What if I wrote an algorithm that caused divide-by-zero error when the month was 3?  Equivalence Partitioning seems to say that there's no point testing month = 3 if I've already tested month = 4.  It would seem dangerous to use this principle for Black Box testing, less so for Grey/Gray Box testing.
Hmmm... am I supposed to be able to edit this discussion directly like this?  Looks like I have way too much power, eg. could delete previous discussion ??  —Preceding unsigned comment added by 210.128.102.155 (talk) 07:04, 6 September 2008 (UTC)
thread_title:  Is it any good? 

message: Instead of merging, I believe refinement might be in order as the distinction between them seems to be unclear.  I see Partition Testing and Boundary Testing as each being distinctly valuable in its own right.  The simplicity of Partition Testing is useful in covering not only "dirty" cases at minimum expense, it also allows coverage of implied problem areas at a higher level.  I also find it useful for organizing and augmenting the Boundary Checking test effort, allowing a quick method to count potential cases for effort estimates.  My favorite use is "shot-gunning" through test cases not in the formal specification, but implied by the environment, interfaces, or construction of the unit under test.   A real-world case I can cite where this came in handy was an input field value conversion that had not been properly protected.
  
The SCADA system on which this was found could easily have provided values anywhere within the 32 bit integer range.  Somewhere along the way, the program's author had jammed rather than properly cast a 32 bit integer input into a type suitable for a 16 bit integer calculation.  The calculation was protected for a certain sub-range of values, but unfortunately the input field from which those values came was not.  This resulted in there being many ranges of values accepted by the program above the intended valid range as the 16 bit integer rolled over within the 32 bit integer space.  
This was detected with Partition Testing using partition values implied by the comparison of the calculation 16 bit integer output range and the 32 bit integer input field data type.  Once we found one of the invalid accepted ranges using a non-boundary value within the suspected problem range, it was easy to predict the rest, and quickly hand the author an informative problem report.
In contrast, Boundary checking based on the specification did not find this since it was not looking for it.  However there is no substitute for the comparatively myopic view boundary testing takes when determining the accuracy of well, boundaries.  To me, each of these test approaches has a unique purpose, and the programs developed using them can have remarkably different, yet valuable target areas.  Instead of eliminating the distinction by merging, I would like to see it refined to embrace the differences of focus and application.
J. Seabrook (talk) 18:14, 19 February 2010 (UTC)
replies: text: But they can't be explained without referencing each other. --Walter Görlitz (talk) 19:07, 19 February 2010 (UTC)
thread_title:  Don't Merge - The Distinction is Useful 

message: In the sample C code, shouldn't the reference to "Underflow" really be "Negative Overflow"? Underflow is a separate (although related) problem for floating points:  http://en.wikipedia.org/wiki/Arithmetic_underflow  — Preceding unsigned comment added by 72.43.224.234 (talk) 20:36, 27 November 2013 (UTC)
thread_title:  Underflow reference 

message: Overflow of signed integer addition is undefined behavior in C.
Also, the figure "Demonstrating Equivalence Class Partitioning" is incorrect for signed integer addition. The valid zone includes negative x and y values, and is hexagonal.
71.87.186.22 (talk) 16:05, 27 December 2018 (UTC)
thread_title:  Undefined behavior in example