cases for use case X and Peter did for use case M, then John and Peter might be assigned to execute use cases M and X respectively. John is not assigned to execute test cases X and Peter is not assigned to execute test cases for use case M.
A strategy best suited to the situation should be adopted and followed. Even a mixed strategy, a combination of two strategies above, might be used in some situations.
Strategy 1: Test Case Authors Execute Test Cases Written by Them
Below are some of the factors which favor the use of this strategy:
a) Saves time
Team members executing the test cases know what needs to be tested as they are the author of the test cases. This saves time from issues or concerns which might arise while executing test cases written by someone else.
b) Ease of scheduling
This strategy saves scheduling nightmares, especially for big projects. Team members are aware of their test execution responsibilities in this scenario.
However, this strategy might not be the most efficient in all circumstances. Following are some of the factors which should also be considered together with the ones identified above:
a) Errors might be overlooked
This occurs quite frequently where the test case author fails to capture various possible scenarios. This includes missing test cases, test cases based on misunderstood requirements, and incorrect test case design(e.g., incorrect test case naming conventions). These errors might not be caught if test case authors are executing the scripts written by them. This becomes even more significant if there are no internal or external test case reviews where these errors might be detected before the start of test execution cycle.
b) Casual approach
Test cases might not be written with same considerations as when others would be executing them. Test cases, generally speaking, should be written with following considerations:
Write test cases such that even a lay man should be easily able to understand and execute them.
Replace yourself with the person who might be executing it. Think what you would expect from someone if you were executing their scripts. Make the test scripts unambiguous, self-contained, and self-explanatory.
Following is a conversation between two test team members, who are in the middle of a test case creation cycle:
"Use case XYZ seems pretty complex", Peter said.
"Yes, and this has been assigned to me. There are a lot of different possible scenarios for this use case", John replied.
"So, you might end up with a lot of test cases for this use case", Peter replied.
"Well...since I will be executing this use case, I will make sure to cover most of the scenarios while testing. However, I might not document all of them. I am very well familiar with this use case and don't think I need to document everything I test. More so, I can't spend too much time on this because of scheduling constraints. As long as I test it well, I think I am OK", John said.
If a team member is aware that he will be executing the scripts written by him, it might lead to a very casual effort in documenting scripts. Even though all possible scenarios might be tested, there might not be documentation for the same, as was the case with John in above conversation.
Strategy 2: Test Case Authors Execute Test Cases Written by Other Team Members
Below are some of the factors which favor the strategy of distributing use cases among team members for test execution:
a) Error detection
People executing others scripts might find errors which might