Ankush, do you have a test coverage map you can supply for critique? Why do I ask? Let us say you have 100 "concurrency" tests already that we are unaware of. Then we post 100 and they turn out to be the same as what you already have. What then has been accomplished? [img]/images/graemlins/smile.gif[/img] Other possibilities exist since you stated, "We are working on a banking application." This implies a team. What does this team already have?
1. Also, it may help for you to define "concurrency test cases" such that any help you receive here is more likely to be on target.
2. Is this actual work or a class project?
Thanks for showing the interest. Actually I(Since I am assigned with this job to bring out some cases) have derived some cases like
1. Checking the Credit scoring process from say 10 concurrent users.
Another example would be
2. A party getting deleted when another user is creating a new application with the same party.
To put more precisely what techniques should I follow to derive my cases. Okay we are aware and known to functionality but there must be some standardized set of cases that are applicable to almost all types of applications.
Thanks Ankush. I think more clarification would help.
1. For the "Checking the Credit scoring process from say 10 concurrent users" piece, what are your objectives?
1.2 Ensure the scoring engine will function and perform properly?
2. For the "A party getting deleted when another user is creating a new application with the same party" piece; are you also categorizing this as "concurrency testing"?
This is a tall order! [img]/images/graemlins/smile.gif[/img] Part of this clearly requires categorization which you seem to have addressed with ""concurrency". Do you have a test coverage or traceability matrix in place? I recommend one or both for which each can be categorized.
Here is the start of a high-level test requirements which others may wish to add to:
Concurrency 1.1: Checking the Credit scoring process from say 10 concurrent users.
Concurrency 1.2: A party getting deleted when another user is creating a new application with the same party.
Concurrency 1.3: During user-application process - kill the browser.
The point number 2 in my previous post can be put into a race condition set I guess. Generally people tend to mix race conditions with concurrency(I am one of them).
Also here our objective would be to test that scoring engine works correctly without any deadlock.
Also for this currently I dont have formally documented cases. I am right now just figuring out that what could be the expected scenarios in a rather informal way before making them formal and sending them to my manager
Maybe others here will help grow the list above?
Clearly you ultimately want performance testing and security testing among so many others. It might help if you propagate forward that starter list above in subsequent posts, and reorganize it as necessary.