Tuesday, January 12, 2010

QA with Zero BUGS is possible?

I think as testers 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.