Talk:Equivalence partitioning

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).

Any suggestions about what to improve here? It was tagged, but why?

Critique[edit]

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)[reply]

External Link[edit]

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)[reply]

White box vs Grey box[edit]

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)[reply]

I would like to see some reference that shows that some people look at partition testing as black box testing. I disagree and if a claim like that is made it should be sufficiently backed up by references.137.132.239.66 (talk) 02:53, 19 December 2016 (UTC)[reply]

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)

Is it any good?[edit]

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)[reply]

Month = 3 in that case wouldn't be equivalent to Month = 4; by that I mean the application wouldn't treat these values in the same way. Month = 3 would be a 'dirty' partition (an invalid partition). —Preceding unsigned comment added by 82.9.198.251 (talk) 21:00, 24 March 2009 (UTC)[reply]

If you do your analysis properly then yes it's good. The point is that if you'd wrote that algorithm and documented it (this is essential), then I suppose the Tester would make 3 a special equivalence class to check for... Furthermore, remember that it's blackbox and we trust in the developers to have tested their code previously -Tprosser (talk) 10:00, 13 August 2009 (UTC)[reply]

I sincerely doubt that this way defining ECP is of any value, there is not a single reference to relationships! Nmondal (talk) 16:33, 2 May 2012 (UTC)[reply]

Don't Merge - The Distinction is Useful[edit]

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)[reply]

But they can't be explained without referencing each other. --Walter Görlitz (talk) 19:07, 19 February 2010 (UTC)[reply]

This is abstract algebra - this saddens me to see how simply common arguments are used to destroy the scientific portions of system testing. Nmondal (talk) 16:34, 2 May 2012 (UTC)[reply]

Underflow reference[edit]

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)[reply]

Undefined behavior in example[edit]

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)[reply]