I think as te
sters we should try to deliver a project with at least no bugs in live-environment, in other words there should not be customer identified bugs. As I believe there are some facts which help to minimize customer identified bug count. In most of the customer testing periods they are testing the scenarios which can happen in live-environment (There can be positive or negative test scenarios). So if we want to hunt down the bugs before they do, we should be customer-minded.
In my point of view there are three main reasons which help us for this kind of testing.
1. Expertise the Domain knowledge.
2. Some knowledge in Combination & Arrangements.
3. Some knowledge in Probability.
Expertise the domain knowledge.
Tester should have a deep knowledge of the domain because they are the people who keep the solution as customer expected. (How much a tester expertise the domain knowledge he can get that much of success in testing). Most of all, tester must know how the business happen in practically, then the tester can identify the scenarios which can happen in live-environment.
Combination & Arrangements.
If tester knows the business logic well then he can list down all the possible combinations with in very short time period. Because of understanding about Combination & Arrangements, tester can list down most of the test scenarios and tester can prevent from testing the same scenario twice. This will be very efficient for tight time-lined projects.
Probability.
After list down the possible testing combinations, tester can give a probability value to every testing scenario by considering the probability that gets in live-environment. And then tester can prioritize the test scenarios according to probability value. For an example suppose that there are two paths of submitting an order. According to business happened in real time, 7 users are following path1 (P1=0.7), 3 users are following path2 (P2=0.3). And assume that tester have 100minuts to test those two paths. By considering probability values I suggest it’s more effective if tester can give 70mins for testing path1 and 30mins for testing path2.
And also if test team can do parallel testing with above method I hope we can deliver projects with no customer identified bugs in live-environment.
sters we should try to deliver a project with at least no bugs in live-environment, in other words there should not be customer identified bugs. As I believe there are some facts which help to minimize customer identified bug count. In most of the customer testing periods they are testing the scenarios which can happen in live-environment (There can be positive or negative test scenarios). So if we want to hunt down the bugs before they do, we should be customer-minded.In my point of view there are three main reasons which help us for this kind of testing.
1. Expertise the Domain knowledge.
2. Some knowledge in Combination & Arrangements.
3. Some knowledge in Probability.
Expertise the domain knowledge.
Tester should have a deep knowledge of the domain because they are the people who keep the solution as customer expected. (How much a tester expertise the domain knowledge he can get that much of success in testing). Most of all, tester must know how the business happen in practically, then the tester can identify the scenarios which can happen in live-environment.
Combination & Arrangements.
If tester knows the business logic well then he can list down all the possible combinations with in very short time period. Because of understanding about Combination & Arrangements, tester can list down most of the test scenarios and tester can prevent from testing the same scenario twice. This will be very efficient for tight time-lined projects.
Probability.
After list down the possible testing combinations, tester can give a probability value to every testing scenario by considering the probability that gets in live-environment. And then tester can prioritize the test scenarios according to probability value. For an example suppose that there are two paths of submitting an order. According to business happened in real time, 7 users are following path1 (P1=0.7), 3 users are following path2 (P2=0.3). And assume that tester have 100minuts to test those two paths. By considering probability values I suggest it’s more effective if tester can give 70mins for testing path1 and 30mins for testing path2.
And also if test team can do parallel testing with above method I hope we can deliver projects with no customer identified bugs in live-environment.
Overall good article, keep it up Charith.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteAgreed. Probability is one of the most important factors that we should consider as Testers. This is perfectly aligned with the 'Risk Based Testing'. We should priorotize testing based on risk. As you correctly mensioned in your example, having a issue in path1 involves more risk than having it on path2.
ReplyDelete