This question is the reason I prefer not to use "positive" and "negative" test case terminology.
There are some sources who maintain that testing expected error conditions is "negative" testing. Others claim that testing unexpected error conditions is "negative" testing.
a negative test is when product delivers an error when it should not
or not deliver an error when it should
I agree with you that this is an incorrect statement: when the software generates an error in a situation that should not produce errors, or fails to generate an error in a situation where an error should occur, you have a failed test.
My preferred terminology covers things like:
- Happy path/steel thread testing - tests that cover the essential functionality of a feature. In the case of an e-commerce app, this would be tests to add items to a cart and check them out.
- Other requirement testing - tests that cover the stated and implied requirements other than the essential functionality. Using the e-commerce app example, this might include tests like ensuring that all pages in the system share a consistent look and feel, or that new features don't interact poorly with existing features.
- Defined error testing - tests that cover any defined failure situations. Using the example above, a test that covers using an invalid credit card for a purchase would be an example of a defined error test. So would a test that attempts to purchase a quantity of -1 items.
- Failure testing - tests that explore the system's ability to recover from unexpected error conditions. In the e-commerce app example, this might include ensuring the app recovers from a network failure partway through a transaction, or that it doesn't crash when given textual input in fields expecting numeric input.
My opinion is that only failure testing should be considered negative testing, but there isn't a consensus, so if you discuss negative testing, you should be prepared to define which of the accepted meanings you are using.