Thupakii Testing Style / Approach may be a value addition to Scripted Testing Approach...
I have been to a movie called Thupaaki good movie, There was pre-interval scene where Vijay Hero and his 11 associates close in on 12 sleeper cell terrorists. Those who have watched it can easily relate the what i am talking about the approach of Thupaaki testing... :-)
I say it was a good movie, b'cos during this particular scene, It just rang a bell in my mind, why can't the same approach can be followed in Software scripted testing approach. It will add a good value addition to the scripted testing approach and that too with a team...
Here it is, this is how the scene goes
Vijay (Indian army Intelligence officer) could manage to get hold of one terrorist (Bug), from him he could get a lead that there is 12 (Problem due to the 12 Bug) bomb blast planned around the city (Software) at the same time, but no clue who is the remaining 11 members (Bug), but has a clue where the 12 places are (Different modules of the software), so what he does is, He and his team of 11 associates Military officials (Software Testers) play a game by, letting one terrorist (Bug) which he got hold of to escape and who was suppose to pass on the information to others and from there the communication splits to the 12 terrorist to proceed with their own planned operation.....
Vijay and 11 associates were wired through mobile, follow the guy who escaped closely without his knowledge, and decided to split themselves each from there on to whom ever the terrorist communicated.. finally all the 12 associates including vijay were following individually 12 other people who where in the 12 different places where the bomb was suppose to be placed as per the clue... Then each associates were having a pistol with them and knock the 12 terrorist down.
Those who watched the movie can recollect the scene quickly,
Now... Why the same approach cant be done in Software testing while executing through the scripted testing. During the middle of the execution cycle (May be for a day or two, hour or two).. When you realize the script is limiting you from going further.... when you spot a trace of bigger issue/area where the scripted test has limitation due to various factor(Time, Cost, Skill etc)....
By this time you should be familiar with the system....
So take the lead of the trace.. Make a team at least 2 min up-to maximum (How many bugs that could possibly arise due to this trace) entire team should be aware of common goal and skilled enough.. Execute the same script and recreate a space... From where the limitation of scripts start explore the trace with the team, when ever you spot the instance of issue make one team member to work on from there individually on that particular instance and prepare a detail report on that, and rest of the team to proceed with the original trace for more until all the team member has individual instance for them to look on... Repeat the same exercise until
A) Deadline of this thuppaki testing approach May be for day or two/ Hour or two
B) You have enough traces or instances identified
C) You reach the scope of the project or product based on the given context
D) You see that you are misleading from the original trace or the area of the issue
E) Enough evidence to Prove / Justify that the trace of the instance to the real issue
One main precondition is spot of the trace if bigger issue / area should be valid and justifiable limitation of the scripted (Hope both of this should be easily provided)
Thanks to AR Murugadoss for having filming this, which also triggered my blogging after a long time... I hope to films could have lot more software testing in it... :-)
I have been to a movie called Thupaaki good movie, There was pre-interval scene where Vijay Hero and his 11 associates close in on 12 sleeper cell terrorists. Those who have watched it can easily relate the what i am talking about the approach of Thupaaki testing... :-)
I say it was a good movie, b'cos during this particular scene, It just rang a bell in my mind, why can't the same approach can be followed in Software scripted testing approach. It will add a good value addition to the scripted testing approach and that too with a team...
Here it is, this is how the scene goes
Vijay (Indian army Intelligence officer) could manage to get hold of one terrorist (Bug), from him he could get a lead that there is 12 (Problem due to the 12 Bug) bomb blast planned around the city (Software) at the same time, but no clue who is the remaining 11 members (Bug), but has a clue where the 12 places are (Different modules of the software), so what he does is, He and his team of 11 associates Military officials (Software Testers) play a game by, letting one terrorist (Bug) which he got hold of to escape and who was suppose to pass on the information to others and from there the communication splits to the 12 terrorist to proceed with their own planned operation.....
Vijay and 11 associates were wired through mobile, follow the guy who escaped closely without his knowledge, and decided to split themselves each from there on to whom ever the terrorist communicated.. finally all the 12 associates including vijay were following individually 12 other people who where in the 12 different places where the bomb was suppose to be placed as per the clue... Then each associates were having a pistol with them and knock the 12 terrorist down.
Those who watched the movie can recollect the scene quickly,
Now... Why the same approach cant be done in Software testing while executing through the scripted testing. During the middle of the execution cycle (May be for a day or two, hour or two).. When you realize the script is limiting you from going further.... when you spot a trace of bigger issue/area where the scripted test has limitation due to various factor(Time, Cost, Skill etc)....
By this time you should be familiar with the system....
So take the lead of the trace.. Make a team at least 2 min up-to maximum (How many bugs that could possibly arise due to this trace) entire team should be aware of common goal and skilled enough.. Execute the same script and recreate a space... From where the limitation of scripts start explore the trace with the team, when ever you spot the instance of issue make one team member to work on from there individually on that particular instance and prepare a detail report on that, and rest of the team to proceed with the original trace for more until all the team member has individual instance for them to look on... Repeat the same exercise until
A) Deadline of this thuppaki testing approach May be for day or two/ Hour or two
B) You have enough traces or instances identified
C) You reach the scope of the project or product based on the given context
D) You see that you are misleading from the original trace or the area of the issue
E) Enough evidence to Prove / Justify that the trace of the instance to the real issue
One main precondition is spot of the trace if bigger issue / area should be valid and justifiable limitation of the scripted (Hope both of this should be easily provided)
Thanks to AR Murugadoss for having filming this, which also triggered my blogging after a long time... I hope to films could have lot more software testing in it... :-)
Good post, thinking and comparison and also good visualization how it works in testing. Every tester has to think in a way to compare the defects with other modules and try to find the root cause of the defect. This adds more value to the testing and also it will earn you great respect from ur development peers. Testers who are in the product based companies has to take this on a serious note.
ReplyDelete