More than a year ago, I went for an interview for a medical project. I was given some kind of a layout design and a product technical specification. The task was: "Describe your approach to the product testing, make use of Equivalence Classes Partitioning." I must admit that the layout design and specification prepared were very good for the purpose of a tester interview.
Although I knew what are "equivalence classes", and even had taught some theory to novice testers, the task made me stuck for a bit. After a pause (long enough to spoil the interview), I said:
- What should I break into Equivalence Classes? - Watching my competence decreases in the eyes of the interviewing Test Lead.
- The interface, of course. - She replied. - What fields from the layout may be combined into equivalence classes?
Then I realized something nasty is going on, and I probably need to get my knowledge of Software Testing Theory to some "generally recognized standards" or so ...
- All the input fields according to the spec must have certain purposes. - I began cautiously - The ECP is used when we don't want to perform tests that we consider the same. But when I get this product for testing, I would test each of these fields at least once, because I do not know how much "equivalent" are these fields. The specification is good, but so many things could go other way when programmers took over the implementation. And I as someone who was not present during their work, can not even guess those ways. So the only thing I can apply ECP here is "user input data types", which I will use to test each of these fields. - After these words my interviewer already looked like I won't be invited to work here, but I continued - To start, regardless of the spec, for every field I'll try to input: nothing, symbolic string (of 1, 5, many characters, a lot of characters, special characters, brackets/parenthesis, line breakers for different systems, different numeric types). Data from these initial tests I'll compare with the requirements, and perhaps for some fields already make conclusions about the discrepancy. Then I will continue testing on other data and functional scenarios, given the results to find as many boundary conditions as I can, and then I'll probably have some conclusions about the "equivalence" or "non-equivalence" of the input fields.
After this task there were another few issues with test automation, which I was not quite ready to.
Either because of this or maybe because of something else, they did not send me an offer. But it does not matter. What I got was I had a question to study!
Going back to my office I read on Wikipedia about '''Equivalence_partitioning'''.
And having read other "commonly used definitions and explanations", I realized that I will not give this to my students as the training references, and explained it in my own words:
For me it is much more logical to think on "Equivalence Classes Partitioning" on this level. And it was easier to explain to others what is that without even mentioning Wikipedia.
Finally, I am very pleased now to have someone besides me, especially someone as respectable as James Bach to drew attention of this issue. Here is his article that reminded me this case: Rethinking Equivalence Class Partitioning, Part 1
Although I knew what are "equivalence classes", and even had taught some theory to novice testers, the task made me stuck for a bit. After a pause (long enough to spoil the interview), I said:
- What should I break into Equivalence Classes? - Watching my competence decreases in the eyes of the interviewing Test Lead.
- The interface, of course. - She replied. - What fields from the layout may be combined into equivalence classes?
Then I realized something nasty is going on, and I probably need to get my knowledge of Software Testing Theory to some "generally recognized standards" or so ...
- All the input fields according to the spec must have certain purposes. - I began cautiously - The ECP is used when we don't want to perform tests that we consider the same. But when I get this product for testing, I would test each of these fields at least once, because I do not know how much "equivalent" are these fields. The specification is good, but so many things could go other way when programmers took over the implementation. And I as someone who was not present during their work, can not even guess those ways. So the only thing I can apply ECP here is "user input data types", which I will use to test each of these fields. - After these words my interviewer already looked like I won't be invited to work here, but I continued - To start, regardless of the spec, for every field I'll try to input: nothing, symbolic string (of 1, 5, many characters, a lot of characters, special characters, brackets/parenthesis, line breakers for different systems, different numeric types). Data from these initial tests I'll compare with the requirements, and perhaps for some fields already make conclusions about the discrepancy. Then I will continue testing on other data and functional scenarios, given the results to find as many boundary conditions as I can, and then I'll probably have some conclusions about the "equivalence" or "non-equivalence" of the input fields.
After this task there were another few issues with test automation, which I was not quite ready to.
Either because of this or maybe because of something else, they did not send me an offer. But it does not matter. What I got was I had a question to study!
Going back to my office I read on Wikipedia about '''Equivalence_partitioning'''.
And having read other "commonly used definitions and explanations", I realized that I will not give this to my students as the training references, and explained it in my own words:
- Anything may be broken into Equivalent Classes: requirements, test steps, data, data sets, test results, test suites and even testers and programmers themselves.
- A breakdown into classes is closely related to the Boundary Conditions (perhaps if we talk about a value of continuous type, such as a number, character string, size, etc.).
- Blending different equivalent classes creates a new partition into equivalence classes.
- Equivalence classes (and boundary conditions) of a variable should be used to determine the equivalence classes (and boundary conditions) of other related variables. For example, if in a numeric field your input of 'Hello' and 'Hi!!!!1111' leads to two different error messages (even slightly different) then these strings (and tests that use them) can not be considered equivalent.
For me it is much more logical to think on "Equivalence Classes Partitioning" on this level. And it was easier to explain to others what is that without even mentioning Wikipedia.
Finally, I am very pleased now to have someone besides me, especially someone as respectable as James Bach to drew attention of this issue. Here is his article that reminded me this case: Rethinking Equivalence Class Partitioning, Part 1
Немає коментарів:
Дописати коментар