Every person can have unlimited conversations and unlimited messages
in a conversation.
These are two use cases:
Every person can have unlimited conversations
Every conversation can have unlimited messages.
As one of the testing principle is :
Exhaustive testing is not possible .meaning you cannot test all the possibility for a system as the combination ...
Firstly, I would be careful when communicating this type of relationship between test cases and your testing, because, test cases are not testing. Promoting otherwise may cause issues both for the stakeholders who won't understand what is happening and for the tester who will have less leverage to promote deep testing.
Testing is the process of evaluating a ...
unlimited conversations and unlimited messages
something works for an unlimited amount of data, in this case, infinite messages
These two statements may mean different things.
There is no such thing as an infinite number of entities in a computer system because computers have physical limitations, in terms of memory, storage, processing.
What you can do is ...
There could be hundreds of examples, to name just a few:
automated releases to test and other environments
test data generation
performance tests (hardly possible without tools that automate some load)
text parsing, e.g. I need to create a JSON out of XML, so I use tools for that, I need to change a newline character from CRLF to LF, so I use some tools for ...
I see this as a question which should introduce performance / stress tests to determine the number of conversations / messages which still allows user to use the application and number of conversations / messages which the system can actually handle.
Execution condition is actually the context of your tests (in common terms and in terms of specific frameworks like Spring, etc.). You can control it using so called Test Doubles (thanks to João Farias since I was not aware of such term) which could be for example Fakes, Stubs or Mocks.
Execution procedure is simply the logic of your test.
Equivalence Class Partitioning is usually demonstrated using numerical values since it is easier to understand and apply, but I don't see any reason not to extend it further to any values that are related in any way. ECP can work great on variable that has a "type" or Belonging, for example type of a car- you can group micro and super mini's and ...
Some common estimation techniques can help.
Having historical data can help. For each test case, measure the time it takes to complete. Given a large enough body of test cases, you can determine how long it takes to run a test case. You may be able to extrapolate how long it takes to run an average test step, as well. However, the time it takes to run a test ...
Tag it on feature level
If all obsolete test cases belong to same functionality, tag it on top level (feature/epic) as obsolete or something.
By having tagged on top level , it then can be easily filtered in any queries on TMT level.
You can create a folder in you test management tool which should be named; "Future use(Don't delete the folder)" OR "Archived Test case" where you can move your unwanted test cases into that folder and later when you need it, you can easily retrieve them as per your requirement.
This way you don't need to delete the unwanted test cases ...
Ive come across this a lot with testers setting test cases to failed because there wasn't enough data to complete the test.
Test case - Clicking "View receipt button" should render 10 most recent receipts.
Step 1: Go to Page > Economy > Reports (expected: Receipts page is loaded)
Step 2: Click "View receipt button"(expect: ...
for anyone coming here, I wanted to add, that ISTQB & ISO/IEC/IEEE 29119 actually do have a definition for both of them and in case you go with this definition the distinction is very clear and also why you need both:
sequence of test cases in execution order, associated actions to set
up the initial preconditions, and wrap-up activities ...