Should I implement both possible and negative test cases for this scenario?

Question

I am testing a web-based application. One feature of this application is to accommodate customizable elements in a given region.

There are several regions:

• Top
• Top-left
• Top-right
• Items
• Right
• Bottom
• Bottom-left
• Bottom-right
• Menu

There are a number of interactive elements that can be placed in some or all of the regions mentioned above, depending on their specifications. For example, some elements, like a timer element, can be placed in all regions, while others, like a calculator button, can only be placed in specific regions.

To test this feature comprehensively, I am considering a brute-force approach:

• Place all applicable elements in a region and verify if they appear as expected. This would be a positive test scenario.

What about a negative test scenario?

• Attempt to place all non-applicable elements in a region where they are not supposed to appear and verify that they do not appear.

Since this is for an end-to-end (E2E) test suite, I am contemplating whether having a negative scenario is truly necessary.

Any suggestions?

Answer 1

Since this is for an end-to-end (E2E) test suite

Do you mean through the UI with everything else built and set up? Is this really necessary?

Most probably the different elements are represented by a class. You can simply have a suite of checks for the behavior of each object/class, verifying the placement error is raised for each bad placement (e.g. trying to place the calculator button outside the specified regions).

Then on the few places where you handle the generic placement error , e.g. in the UI, you can have checks.

The "E2E" approach grows by this formula:

(number of generic placement error points) * (number of elements) * (number of errors for each element)

While the above proposal grows by this formula:

(number of generic placement error points) + ((number of elements) * (number of errors for each element))

Meaning that it tends to take longer to run and require more coding.

Additionally, the proposal gives you more precise checks, where check fails will be raised by changes in a specific element or in the generic error handling. On the "E2E" approach, a check can fail by either changes in a specific element or in the generic error handling - thus increasing fragility and debugging time.