Exploratory Testing can be justified when you explore what not to do by hand

I was reading this post titled "Convince my boss to let me do exploratory testing", while most of what is said in it makes direct sense, I want to add a small point through this post.

Let us say, a tester has to test a text field with the below cases:

1. It has to be tested with multiple languages like English, Hebrew, Arabic, Kannada and Devanagiri.

2. It has an upper limit for its length, say 40 characters, and the tester wants to prepare strings with 40 characters and 41 characters (and also need to know, if a string gets truncated, where it got truncated).

Naturally the tester may ask for a lot of time to prepare the inputs that drive these tests.

It could be a tester who does everything manually, or a tech-savvy tester who want to develop scripts to accomplish the same, it takes time; and I consider that as "non testing time".

So, there is a desperate need for a tool that can aid the tester to do that.

Today, http://www.testersdesk.com/ has a toolkit named "Common Test Data Generators" which help them on that aspect. It is free for the entire testing community.

As you can see, we named it as "common" test data generators instead of hyping the simple things it does.

No, this post is not about TestersDesk.com, because it does a lot more than what is written here.

Exploratory Testing can be justified when you explore what not to do; i.e., the right ways of saving (or escaping from) some time needed in scripted testing.

And of course, the mixing proportions of testing time have to rightly balance scripted and exploratory testing, and there is no "this" or "that" type of testing, by itself, that can reveal all the defects.

Enjoying and respecting the fact that we are human beings,
Ashwin.

My interactions with Pradeep Soundararajan and Shrini Kulkarni at Test2008

Having had met Pradeep and Shrini at Test2008 conference, I wanted to externalize a small extract from our conversations.

Firstly, I would say the readers of their blogs are lucky for getting the insights and influential thoughts so really needed to ensure value to the customers.

I had a quick overview from Shrini on the schools of thought in testing. I never knew the concept of Schools of thought in Testing, but having looked at the principles stated in http://www.context-driven-testing.com/, it made a lot of sense as to what I have been thinking/living all the time, and for a good thinker the word 'context' itself explains all about it.

I liked the way how Pradeep has explained the term "bug free software" -> software delivered with free bugs:-) I think there is a post on this topic in his blog too that I visited yesterday.

Overall, It brings me in to a deep introspection, as well as do some serious planning around how we can perform value-assurance (a synonym I use for the word 'testing') to testers through TestersDesk.com. Obviously, a testing product itself cannot have bugs and needs to serve as an example for having reasonable quality and deliver the value to testers. We exist to exploit technology in whatever ways possible, basically offloading the mundane tasks of a typical test engineer, and have now got more careful at what we build.

I am posting this to highlight the fact that it was an intellectually stimulating hour talking to Pradeep and Shrini, and I thank Pradeep for nominating TestersDesk.com for the Thought Leadership Award at Test2008.