"Scripts" as is called by many and more commonly known as Test Cases are seen as some kind of cage, rule, constrain by lot of software testing experts, especially the likes of Pradeep, James Bach and the list grows.
I like reading them and agree with them on lot of subjects, the likes of importance of exploratory testing, the importance of human intelligence. But one subject that I don’t agree with them as I do on lot of others is that of “test scripts make the tester dump”. With the very little time that I have spent testing applications, I believe “Test Scripts/Cases (going forward will address as Scripts) are one of the important artifacts of a testing process.
This is how I understand why scripts are important.
Testing as a process, a project should have a goal. The goals can be to find as much defects as possible in the software. I concur with Pradeep & Co (would like to call them the D-gang, and of course I am part of it as well but differences of opinion) that doing an exploratory testing (basically questioning everything that we see in a software) does help finding those issues. Here the goal is to find the things the software doing that it’s not supposed to do.
One of the test managers with whom I worked in the past used to tell me that there can not be a test case without an expected result. When I hear that, I used to ask myself “Why the hell not?” Of course I couldn’t ask them as I was a fresher and the person telling me this was one of the reputed Test Mangers of the organization that I was working for.
I do not agree with the statement of that test manager as the same way I do not agree with Pradeep when he says scripts cage him. Testing can have other goals as well. The context drives goals as well. “Finding if the software does everything that it supposed to do in all different scenarios or situations”; how about this as a goal?
In this context, as a tester it’s imperative for me to understand that as a user what exactly is expected from the software that am going to test. This is a guide for me to check the conformity of the software with the user’s expectations from the software. I call this as scripts or test cases and someone else can call this as a check list or may be anything else. After all, we live in a free country and everyone as freedom to express.
When I go a step above and see this test scripts, I see them as a tool. The utility of it is going to depend on the person uses this. As always, now the problem is with the unwise thought process that a person has while looking at test cases. It’s certainly not testing if the aim is to have all the test cases “Pass”. This is thought process is something that cages a lot of minds and not the test cases.
I like reading them and agree with them on lot of subjects, the likes of importance of exploratory testing, the importance of human intelligence. But one subject that I don’t agree with them as I do on lot of others is that of “test scripts make the tester dump”. With the very little time that I have spent testing applications, I believe “Test Scripts/Cases (going forward will address as Scripts) are one of the important artifacts of a testing process.
This is how I understand why scripts are important.
Testing as a process, a project should have a goal. The goals can be to find as much defects as possible in the software. I concur with Pradeep & Co (would like to call them the D-gang, and of course I am part of it as well but differences of opinion) that doing an exploratory testing (basically questioning everything that we see in a software) does help finding those issues. Here the goal is to find the things the software doing that it’s not supposed to do.
One of the test managers with whom I worked in the past used to tell me that there can not be a test case without an expected result. When I hear that, I used to ask myself “Why the hell not?” Of course I couldn’t ask them as I was a fresher and the person telling me this was one of the reputed Test Mangers of the organization that I was working for.
I do not agree with the statement of that test manager as the same way I do not agree with Pradeep when he says scripts cage him. Testing can have other goals as well. The context drives goals as well. “Finding if the software does everything that it supposed to do in all different scenarios or situations”; how about this as a goal?
In this context, as a tester it’s imperative for me to understand that as a user what exactly is expected from the software that am going to test. This is a guide for me to check the conformity of the software with the user’s expectations from the software. I call this as scripts or test cases and someone else can call this as a check list or may be anything else. After all, we live in a free country and everyone as freedom to express.
When I go a step above and see this test scripts, I see them as a tool. The utility of it is going to depend on the person uses this. As always, now the problem is with the unwise thought process that a person has while looking at test cases. It’s certainly not testing if the aim is to have all the test cases “Pass”. This is thought process is something that cages a lot of minds and not the test cases.
2 comments:
@Parthiban,
Welcome to testers blogosphere. I wish you a good time here and hope many others get inspired by you in future.
Through this post, you have had a good start by posting your opinions than copy pasting some stuff. I hope to see you learn through this experience of blogging and from your readers.
Testing is all about 'Attitude'. Attitude to question everything and intelligence (aptitude) to see through the obvious
What's obvious to you is not so obvious to others and hence you might want to think about it.
Scripts" as is called by many and more commonly known as Test Cases are seen as some kind of cage, rule, constrain by lot of software testing experts, especially the likes of Pradeep, James Bach and the list grows.
Please disassociate the term expert to me. I am just a tester like any other.
I am not yet tired talking about and against scripts and I hope I would never get tired because there would always be a need for it.
I do not agree with the statement of that test manager as the same way I do not agree with Pradeep when he says scripts cage him.
Well, let me expand that a little bit - Scripts cage me as much as those who want me to execute scripts cage me.
If testing by following scripts was great fun, I wish to see some tester before I die who spent his entire career in testing executing scripts. However, I take an open bet that I would keep testing till I die with the kind of exploratory approach that I practice.
Scripts as you know seperates test design from test execution. It is similar to designing what Sachin should play for the first ball and second ball, third ball, fourth, fifth and sixth in a given over and following it. I see there is extreme value in having simultaneous test design and test execution just like how Sachin decides how to hit the ball when it is about to arrive at him.
Well, it requires skills and those of us who love cricket just merely admire him and continue to play the bad way we usually do.
When I go a step above and see this test scripts, I see them as a tool. The utility of it is going to depend on the person uses this. As always, now the problem is with the unwise thought process that a person has while looking at test cases.
Test cases comes from humans and to be more specific their brain. While you trust the test case tool - I trust the tool that spitted them out. That's like seeing through the obvious, right?
“Finding if the software does everything that it supposed to do in all different scenarios or situations”; how about this as a goal?
Do you really know what the software is doing? How do you know that?
Do you really know all scenarios and situations that users of software are going to put it into?
If you knew that already why are people curious after every release made to a customer?
A software is mostly invisible and volatile. It sits over another software and hence it is volatility square that we experience. There is no way we can ensure something works. We may test, make conjectures that it appears to work.
I am encouraging you to see through the obvious, please.
Hi Pradeep,
Thanks for your thoughts
What's obvious to you is not so obvious to others and hence you might want to think about it.
That’s correct, and that’s exactly why “testing” calls in so many different thoughts and hence very interesting and offers lot of room to learn. Leave behind different people, for the same person what seems obvious today may not be so tomorrow hence. That’s exactly why its very important to have a test log and defect log.
Well, let me expand that a little bit - Scripts cage me as much as those who want me to execute scripts cage me.
Scripts as you know seperates test design from test execution. It is similar to designing what Sachin should play for the first ball and second ball, third ball, fourth, fifth and sixth in a given over and following it. I see there is extreme value in having simultaneous test design and test execution just like how Sachin decides how to hit the ball when it is about to arrive at him.
Well, it requires skills and those of us who love cricket just merely admire him and continue to play the bad way we usually do.
You couldn’t have put it better with the illustration on Sachin.
Having test cases written is seen as entry criteria to being test execution by a whole lot of people. What they don’t understand is the cage they create well before the tester even begins.
As am working with lot of such people I wouldn’t blame them as well, Pradeep because I understand their thought on this and perhaps that is echoed around all the service based companies which obviously stands to be corrected. This is more an operational issue the managers face and how they try to mitigate is to cage the testers
Let me expand that a little bit. The clients need a confirmation on the understanding that the oursourcees’ have on their application. Most often, the Test Managers choose the short cut, ie writing test cases to evidence their knowledge on the application.
I think we need a paradigm shift. Am sure you could convince your clients that exploratory testing is effective, but am also sure it took sweet time.
It needs a lot of education about “testing” and more importantly the “conviction”; that’s our play ground.
Test cases come from humans and to be more specific their brain. While you trust the test case tool - I trust the tool that spitted them out. That's like seeing through the obvious, right?
I believe in having a checklist with me before I start testing. And I believe in the checklist I prepared because I believe the tool that created that check list- My brain. That’s Obvious to me. Right?
Do you really know what the software is doing? How do you know that?
I test to answer the above question. Of course as a tester I understand that the results I provide or contextual and not perpetual.
Do you really know all scenarios and situations that users of software are going to put it into?
Certainly NOT, and I don’t wish to be an Oracle as well. But as a tester, its my primary responsibility to understand the possible contexts (I know am tying to be an Oracle here) a software might be put thro and I document then to evidence that when necessary. That’s what I call it as my test scripts.
I am encouraging you to see through the obvious, please.
This has been my constant attempt (see through obvious) and thanks for your help in helping me in this Journey
Post a Comment