This post is really a response to the post written by Pradeep on Traditional Software Testing Process
I saw that post as one where a tester proclaiming himself as an alternate to all those companies that have been cheating (by taking traditional testing approach) their clients and slamming the script based testing
I believe any tester who has experienced exploratory testing, enjoyed the freedom and witnessed results will accept ET as one good handy test methodology. As many ET tester do, I would love to read and hear a tester who practices and advocates testing on the lines of pre written test cases ONLY.
When I say that, I donot blame the testers entirely for readily nominating themselves to be caged by the traditional approach because I work with such testers day in and day out.
That’s exactly why I particularly felt relieved on reading his post because he seemed to have moved on with scripted testers to scripted testing and the reasons why testers its been widely used at the risk of clients not being served – see through the obvious.
Something that I try in everything I do, see thru why its happening. “Testers follow scripted testing methodology and further they advocate the same”, why would a tester do that? In my little experience, ignorance is largely the reason besides the business model we are in.
To elaborate more about the irony many of us share; lets keep ET out of equation for sometime.
Irony:
Even though the testers feel bored to run the test cases again and again, even though they like spending whatever time possible to play with the application (exploratory testing) which offers lot of challenges, learning, opportunity to find defects they continue running those test cases release over release.
Obvious:
Atleast with the small number of testers whom I interact with on a daily basis go thruthe above irony and I can safely presume that this would be echoed by all the services based organizations of all size.
See thru the obvious:
This is something that I attempt and expect the likes of you as well.
If a tester (whoz running the scripts) gets the freedom to do heuristics testing, I bet he will gallop this. The reason why they continue with the traditional approach is I guess not because of the awareness about the benefits of exploratory testing
Even though they know ET can help them unearth lot of defects, they don’t do it because the organization they work mandate them to do so ??
Lets RCA this
Do you really think the clients are blind and not capable to realize that they pay $9000 (even more as well) to have not even a single defect?
I saw that post as one where a tester proclaiming himself as an alternate to all those companies that have been cheating (by taking traditional testing approach) their clients and slamming the script based testing
I believe any tester who has experienced exploratory testing, enjoyed the freedom and witnessed results will accept ET as one good handy test methodology. As many ET tester do, I would love to read and hear a tester who practices and advocates testing on the lines of pre written test cases ONLY.
When I say that, I donot blame the testers entirely for readily nominating themselves to be caged by the traditional approach because I work with such testers day in and day out.
That’s exactly why I particularly felt relieved on reading his post because he seemed to have moved on with scripted testers to scripted testing and the reasons why testers its been widely used at the risk of clients not being served – see through the obvious.
Something that I try in everything I do, see thru why its happening. “Testers follow scripted testing methodology and further they advocate the same”, why would a tester do that? In my little experience, ignorance is largely the reason besides the business model we are in.
To elaborate more about the irony many of us share; lets keep ET out of equation for sometime.
Irony:
Even though the testers feel bored to run the test cases again and again, even though they like spending whatever time possible to play with the application (exploratory testing) which offers lot of challenges, learning, opportunity to find defects they continue running those test cases release over release.
Obvious:
Atleast with the small number of testers whom I interact with on a daily basis go thruthe above irony and I can safely presume that this would be echoed by all the services based organizations of all size.
See thru the obvious:
This is something that I attempt and expect the likes of you as well.
If a tester (whoz running the scripts) gets the freedom to do heuristics testing, I bet he will gallop this. The reason why they continue with the traditional approach is I guess not because of the awareness about the benefits of exploratory testing
Even though they know ET can help them unearth lot of defects, they don’t do it because the organization they work mandate them to do so ??
Lets RCA this
Do you really think the clients are blind and not capable to realize that they pay $9000 (even more as well) to have not even a single defect?
As I understand, the very human behavior pattern is to avoid risk.
By outsourcing, that’s exactly what we do. As an organization, I want to pass on the risk to someone else that can do my work with labels like “Cost”, “Operational reasons” and many more hopping to get a product of better quality then I can.
This challenge is in my opinion, comparatively less on the rest of the activities (except testing) in a software building process. We have a lot of tools, methodologies with very high percentage of repeatability is available. More than any other tool, “google” does magic there.
All these can not work with testing, because no matter how hard we try to with the likes of process, tools, re-usage (most misunderstood and misrepresented), testing is all about human intelligence (common guys, this is a gift after all).
When an activity like “testing” is turned over to a second party, especially third party companies, because of the very service outsourced model, it becomes imperative for the outsorucee to establish confidence in the client that they have the capabilities that are called to do the job.
Now it’s a two way situation; go with the abilities or competency of people (tester) or the organization (process)
It’s the practical difficult that a company cannot have expert testers ONLY in their payroll working across all the projects that are on flight. Even if an organization claim to have expert testers in their payroll, all the testers will not be internationally acclaimed or atleast have footprints outside the organization.
Alaaaas, now how do I convince my client that I can do this work?
Now the other way around is on the Process and this where the argument begins !!
Here is where the organizations, testers take the easy way out or probably the only way they think is available ie going behind certification, going Six Sigma, ISO standards and so on.
Processes naturally introduces the documents and hence the testers end up spending 9000 hours
I do not believe the clients that we are talking about are so blind to be made
intentionally bind . I know projects where the vendors end up loosing the contract on such instances (intentional blinding) and worst, had to pay the contract money.
So clients are the businessmen who have the caliber to see if they are going to be made blind so lets not shame them by labeling Ignorant
Either they get eventually get what they want or this is exactly what they want (the documents and process). This is exactly the challenge that testers of my kind face.
In that sense, I would label the likes of Pradeep, lucky because you have the luxury of saying “this is my approach and the best” and your clients must have been either buying or they don’t care about your approach but the results.
This naturally brings me to the approach that I could devise in my own little world with all the constrains a typical tester face.
I give what my clients what they want. Yes, you read exactly right, but I do in my way.
I give them test cases but I test my application based on the scenarios that I make out of the understanding I have about the application.
The basis of my approach involves a lot of discussion with the all the people involved in the evolution of the application;
and questions, questions and more questions.
I take the traditional script based testing to service by client with what they want and I mix that with conglomerate of scenario based testing (in other words behavior based testing), ET
By outsourcing, that’s exactly what we do. As an organization, I want to pass on the risk to someone else that can do my work with labels like “Cost”, “Operational reasons” and many more hopping to get a product of better quality then I can.
This challenge is in my opinion, comparatively less on the rest of the activities (except testing) in a software building process. We have a lot of tools, methodologies with very high percentage of repeatability is available. More than any other tool, “google” does magic there.
All these can not work with testing, because no matter how hard we try to with the likes of process, tools, re-usage (most misunderstood and misrepresented), testing is all about human intelligence (common guys, this is a gift after all).
When an activity like “testing” is turned over to a second party, especially third party companies, because of the very service outsourced model, it becomes imperative for the outsorucee to establish confidence in the client that they have the capabilities that are called to do the job.
Now it’s a two way situation; go with the abilities or competency of people (tester) or the organization (process)
It’s the practical difficult that a company cannot have expert testers ONLY in their payroll working across all the projects that are on flight. Even if an organization claim to have expert testers in their payroll, all the testers will not be internationally acclaimed or atleast have footprints outside the organization.
Alaaaas, now how do I convince my client that I can do this work?
Now the other way around is on the Process and this where the argument begins !!
Here is where the organizations, testers take the easy way out or probably the only way they think is available ie going behind certification, going Six Sigma, ISO standards and so on.
Processes naturally introduces the documents and hence the testers end up spending 9000 hours
I do not believe the clients that we are talking about are so blind to be made
intentionally bind . I know projects where the vendors end up loosing the contract on such instances (intentional blinding) and worst, had to pay the contract money.
So clients are the businessmen who have the caliber to see if they are going to be made blind so lets not shame them by labeling Ignorant
Either they get eventually get what they want or this is exactly what they want (the documents and process). This is exactly the challenge that testers of my kind face.
In that sense, I would label the likes of Pradeep, lucky because you have the luxury of saying “this is my approach and the best” and your clients must have been either buying or they don’t care about your approach but the results.
This naturally brings me to the approach that I could devise in my own little world with all the constrains a typical tester face.
I give what my clients what they want. Yes, you read exactly right, but I do in my way.
I give them test cases but I test my application based on the scenarios that I make out of the understanding I have about the application.
The basis of my approach involves a lot of discussion with the all the people involved in the evolution of the application;
and questions, questions and more questions.
I take the traditional script based testing to service by client with what they want and I mix that with conglomerate of scenario based testing (in other words behavior based testing), ET
