Exploratory Testing – How to Think Beyond Traditional Testing Boundaries?

“I really appreciate your concern for the product and making us helpful in understanding end user perspective. It’s going to be very helpful. Thanks for the good work and keep it up!!!”

This was the last e-mail of 21 e-mails long chain, from our client. It was midnight and our product release was delayed due to a critical bug reported by us. You might think, what is new in that? It may happen for many times. But this was really different as the critical bug we reported was not a result of any documented test case.

After completing regression testing for the last time on that evening, I was just playing with product. And what does that mean? You are free to do what you are not supposed to do.  Based on my experience and project knowledge I had some ideas to test the product apart from our test repository. But that’s what called Exploratory Testing.  And that exploratory testing found a critical bug which was related to server hang issue while doing something unexpected.

Being a fan of exploratory testing, I love to explore the product in different ways. For me, the definition of software is:

“It should do what it is supposed to do and it should not do what it is not supposed to do.”

Exploratory testing process

Limiting testing boundaries to check whether supposed to work things are working or not makes you incomplete tester. In fact, tester’s life starts when documented regression testing ends and results are updated. Looking product from different perspectives and understanding end user requirements in different scenarios make the whole lot of difference, so today; let’s understand together, how that difference can be made:

How to look product from different perspectives?

exploratory testing

#1. Understand customer / end user

Software testing is all about checking quality of product in terms of customer satisfaction. How do you know customer’s view point? Answer is simple – you have to be customer. OK, let me correct. Being customer will not be enough. You need to understand how the customer wants to handle the product. No two customers who bought same raw materials will prepare same recipe. Yes, the product we develop / deliver is a raw material for customer’s business and they have different mindset about using it.

Being a software tester, we need to check purpose of product and not the object or aspect of it.

Let me give you some real life practical examples about it:

  • Scissor was never limited to cut paper only. Cutting is the purpose and not the paper (object).
  • Cell phone was never limited to calling only but “able to call” is always the basic purpose.
  • Storage boxes are used to store but safety of material stored is as important as storage.

Understanding stake holders and wide range of their expectations should be the baseline of exploratory testing.

#2.  A mindset

While looking for (let’s say) job requirement ad, do you see that jackpot ad in between the page with bold font? Most of us do not (believe me, it’s true). Because we have instructed our mind to look for what is useful or to be checked. Anything else is of no use and so mind denies recognizing.

Open your mind and do not set any expectation when you start exploring product. Always remember, it’s not OK if the product is doing what it is supposed to do. It is also important that it should not do what it is not supposed to do.

I remember one classic example about it:

------------

In Linux, ‘cat’ command is used to check content of file and ‘ls’ command is to check content of directory. Working with Linux and that too in software testing for five years, I never thought to do cat <dir name> because my mind was set that for dir content I need to use ‘ls’. True I was. But the reverse side of expectation where product was not supposed to behave the way it was not supposed to be was wrong. One of our customers, who did not know Linux well, did cat <dir name> by mistake and the system crashed. We paid for the mindset.

Be always ready to make mistakes with the software because that is what end user is going to do. To test the software, you have been trained but the end user will not be as trained as you or he/she will not be technically as expert as you. Also, he/she will do anything with the software when they are in trouble. Think about those scenarios and provide testing feedback. Life of the software and yours (as a tester) will rock.

#3. Know the competitors

While testing any software application for your client, did you ever care to know and understand other software with same purpose? Did you ever care to suggest some useful functionality you observed in competitor’s product? It does not fall in our job profile, is the answer most of the time. But do you know the benefit of doing it?

Here are few real life examples to make you understand the point:

  • Don’t you like that designer most that just not stitches your dress but provides you input about matching accessories?
  • Don’t you like that pizza brand most who just not make great pizzas but home delivers on time?
  • Don’t you like the photographer who just not takes good photographs but suggests about different kind of frames for the photo print?

Everyone wants to have something extra for what they pay for. Our analysis of competitive software can work the same way for us. The customer always likes to hear valuable suggestions – mainly comparative suggestions to make the product more useful or marketable.

Also this kind of comparison and analysis of same range of products make our analysis more powerful and eventually we create a treasure to which we can go back at any moment and find something useful always.

Over to you

Ending this post here, knowing it is incomplete.  Do you want to add something or want to wait for continued part in next post? I welcome your suggestion and inputs to make software testing community make more effective and productive.

Thank you for reading and sharing appreciation and views. We are overwhelmed with the positive response from the readers.

About the Author: This is a guest post by Bhumika Mehta. She is a project lead, carrying 7 years of experience in software testing. She appreciates good ideas and innovations and risks too. And of course hates monotonic work, people and environment.



The Best Software Testing Training You'll Ever Get!

software testing QA training

59 comments ↓

#1 Nikita Jain on 01.20.14 at 10:53 am

Thanks for sharing this post……….really helpful !!!!!!!!!

#2 Harish on 01.20.14 at 11:04 am

Hi,
Well first I want to thank Bhumika Mehta first for such an wonderful Article. Best Lines that impressed me in the article was “The Tester need to know rather than Objective of the product”.

QA Lead

#3 Sid on 01.20.14 at 11:08 am

Hello Bhumika,
Nice article on ET. User stories (Understand customer / end user) are most important to derive ET cases. Tester should always ask Business Analyst /Functional Designer for user stories. Then, it will be easy for a tester to understand the functionality, its purpose and can think more effectively about ET cases.
Regarding your another point – “Know the competitors”, I have a habit of visiting competitors’ websites when I have some free-time. However, it never helped me to understand or compare their module’s functionality with ours. May be, this is specific in my case :-)

#4 Kalyan on 01.20.14 at 11:41 am

nice article..thanks

#5 Gaurav Khurana on 01.20.14 at 11:47 am

Nice post, it is motivating, Really liked the real life examples shared.

Regards
gaurav khurana

#6 Ravi on 01.20.14 at 11:58 am

Very nice and useful article. Can you also write an article on system integration testing?

#7 Jafar on 01.20.14 at 12:13 pm

It was again, wonderful article. I always like to come out of Testing cycles and that takes me to play around application. I love to play around application without setting up any test case expected result and that helps. For example: I try to login with multiple users in same application and try to access the single entity with multiple users. Try to play with special characters while input data which might take DB down. I have witnessed that at Production level where one of customer name is migrated in new DB with some kind of special characters and when access using our system, it crash the whole DB. Exploratory testing shows the attitude of Tester. Following the test cases somehow set the mindset too. Need to comeout on cycle to cycle basis to keep system alive !!!

#8 Ajay Sanodaria on 01.20.14 at 12:43 pm

Great post Bhumika…
I read the article and got the new way for ET.

Thanks. Keep Posting…. :-)

#9 sathish on 01.20.14 at 1:43 pm

Very useful post..

Can anyone give me Regression Testing Testcase template?

#10 Gaurav satyawali on 01.20.14 at 2:39 pm

???? ????? ??? ???? ?? !

#11 Rajneesh kaundal on 01.20.14 at 3:22 pm

Wonderful article Bhumika

#12 Anuradha on 01.20.14 at 4:34 pm

Very good real time scenario to understand very well.
Thanks

#13 Bhumika Mehta on 01.20.14 at 5:12 pm

@Harish,

Thanks for those kind words and appreciation..

#14 Bhumika Mehta on 01.20.14 at 5:13 pm

@Nikita, @Ravi, @Kalyan, @Gaurav,

Thanks a lot for your readership and glad to know that you liked the post.

#15 Bhumika Mehta on 01.20.14 at 5:14 pm

@Ajay, @Satish, @Rajneesh, @Anuradha

Thanks a lot for your support in terms of appreciation and it is really encouraging.

#16 Bhumika Mehta on 01.20.14 at 5:19 pm

@Jafar,
Yes, I do agree that Exploratory Testing is totally depends on tester’s attitude and I must admit that with time, everyone can set the right attitude if willing to do so.

Most of the time, testers think that their duty is over if regression testing is done and bugs reported. But I want to say that – it is the moment when tester’s real job starts :-)

Thanks again for your readership.

#17 Irfan on 01.20.14 at 6:28 pm

Nice article as always on this site:)

I would like to add something to it
Exploratory testing is an iterative process of learning, test design, and test execution. It is a context-driven adaptive approach to software testing. When delivered by skilled testers it will detect a substantial number of defects in a short period of time, arguably more than any other testing approach, especially during the first couple of rounds of testing.

Let me know if anyone has any questions on how to manage and how to perform ET.

Thanks!

#18 Shirley on 01.20.14 at 9:49 pm

Nice to see testers thinking creatively! Thanks Bhumika. I’d add that Exploratory Testing needn’t happen after regression or other testing is done. It can be really useful to set aside exploratory testing time as part of the daily testing schedule. When testers are given freedom they can find some amazing things!
There’s more on Exploratory Testing here http://www.satisfice.com/articles/what_is_et.shtml

As James Bach says, “exploratory testing is called for any time the next test you should perform is not obvious, or when you want to go beyond the obvious. In my experience, that’s most of the time.”

#19 Hema on 01.20.14 at 11:36 pm

Wonderful job as usual. This article s very helpful for testers.
Thank you so much Bhumika and Vijay

#20 bhavesh on 01.21.14 at 5:08 am

Thanks for such a nice article. It is always helpful from business perspective too, “exploratory testing is must for every tester”

#21 Pradeep on 01.21.14 at 5:43 am

Hey, thanks for the wonderful article. Real time examples are nice.

#22 Sachin on 01.21.14 at 5:50 am

Prodigious !!!!

Its really Great article. I specially like the example you used.

Nice Job Miss Bhumika.
.
.
.
.
When I think about ET, I can not give priority to this kind of Testing , Below are some reason –

1. It is very much rare that we can find Bug with High Severity and High Priority with the help of ET, as the most critical path (User Flow) we cover in the Scripted (Manual/Automatic) Testing.

2. There is no limit (Exit Criteria) for ET, so how long you will do it ? and hence some time it reduce your confident (if you don’t find any thing)

3. We know that The user activity should be related to critical and most important functionality of the application, and ET does not deals with this (So it is less Important )

4. I must say Everybody who know something about the Application/Project can do ET (No need to be Tester) then why you think that Tester Role Starts here…?

5. ET is most of the Time Critical for Testers because it is not structured and hence defects found using this method may be harder to reproduce (since there are no written test cases).

If above 5 points even a bit of Sense then why this ET is that much IMP for Tester ?

Let me know if I am Wrong/Misunderstand something.
Please elaborate your Opinions.

Thanks,
Sachin

#23 Rajeev Harikar on 01.21.14 at 6:47 am

HI,
It was a very helpful article,in my all projects i always prefer exploratory and adhoc testing and it has given me a very awesome results..!!

#24 Laxmi on 01.21.14 at 7:35 am

Nice Article Bhumika, Thanks for sharing wonderful information.

As per my experience with ET. I feel it is most important part of test life cycle. We cover test scripts using the requirement ( traceability matrix) but there some situation where we cannot document each and every small Business scenario in that case ET helps . Using ET not only help to find defect it is also provides confidence about the product quality. It also improves Tester’s analysis skills and tester to become more innovative..

Thanks and Regards
Laxmi

#25 Bhumika Mehta on 01.21.14 at 7:44 am

@Laxmi, @Rajeev, @Hema, @Bhavesh, @Pradeep,

Thanks a lot for your readership and I am really glad that you liked the post and it was helpful.

#26 Bhumika Mehta on 01.21.14 at 8:12 am

Hi Sachin,
Thanks for your response and first of all appreciation. I would love to discuss those points in detail.
1. It is very much rare that we can find Bug with High Severity and High Priority with the help of ET, as the most critical path (User Flow) we cover in the Scripted (Manual/Automatic) Testing
I completely disagree with this statement because with scripted testing we cover all the known scenarios. And yes, for those known scenarios we must have taken care of all the critical scenarios. But what about the unknown / unexpected scenarios? I want to present it as – With a knife, you can definitely cut vegetables and fruits but if you try to cut a thick cardboard, what do you expect?
This is what we are supposed to do with product, i.e. how the product is going to be used in different life time cases.

2. There is no limit (Exit Criteria) for ET, so how long you will do it ? and hence some time it reduce your confident (if you don’t find anything)
Yes, ET does not have exit criteria and so it totally depends upon tester’s experience and understanding about how long he/she wants to carry out ET. But at the same time, I would like to mention that in the busy days like today when we are struggling to achieve completion of scripted testing, do we have that much long duration of free time where we have to think of exit criteria of ET. If you can find a little time for ET or if you have done ET till your satisfaction level…both are enough.
As a tester, it’s not our only responsibility to find bug. Our focus should be to make the product qualitative. So even if we cannot find something, we can definitely suggest something to make the product better.
3. We know that The user activity should be related to critical and most important functionality of the application, and ET does not deals with this (So it is less Important )
What does ET deals with if its not dealing with critical functionality?
4. I must say Everybody who know something about the Application/Project can do ET (No need to be Tester) then why you think that Tester Role Starts here…?
Yes, everyone can do ET but everyone does not see the product until its delivered or announced. And as a tester, we know it very well, the bug fixing cost is lower when found in primary level testing.
Also, software testing is something, which has been neglected most of the time – or has been addressed as thankless job. It’s only because we, the software testers, sometimes limit our jobs/ responsibilities. Any tester can do scripted/documented regression testing, but ET is really about creativity and constant brain storming. So, once tester is finished with scripted testing, his real role starts.
5. ET is most of the Time Critical for Testers because it is not structured and hence defects found using this method may be harder to reproduce (since there are no written test cases).
Non-reproducible bugs are always a headache but in today’s time, when there are 100s of recorders and reporter tools available, where you can take a note and screenshot and do video recording of each and every thing you do as part of ET, how difficult it is to reproduce?
I really enjoyed this discussion and I am happy to share my opinion but at the same time. Thanks for your readership, Sachin.
Happy Testing.

Bhumika

#27 Bhumika Mehta on 01.21.14 at 8:16 am

@Shirley,

I do not say ET should happen only after regression testing. I wanted to make a point that a tester needs to think beyond regression testing.
Thanks a lot for that URL and sharing James Bach’s statement. He is a master of ET.

#28 Pari on 01.21.14 at 12:44 pm

Article is awesome. Describes about innovation. Thinking on different way instead of moving on the same path ..
Pointing about negative scenario..

#29 Veda on 01.21.14 at 3:50 pm

Thanks for the artical, I have few questions about exploratory testing can you please explain me clearly
1)when are we going to do exploratory testing in real time.
2) is end to end testing and exploratory are same.
3)is it mandatory that we are going to do for all the projects?
4) Can you please explain me with real time example.
5) what is adhoc testing? When we are going to do in real time??

#30 Arun Kumar on 01.21.14 at 5:47 pm

There is time period to do ET. After completing functional and regression testing, if time permits we can do ET.

We should not start testing initially with Exploratory testing, then it would be big mistake.

#31 Harry on 01.22.14 at 12:09 pm

I agree that ET is an approach to software testing for simultaneous learning,test execution and test design. Through this individual tester optimize the quality of his work. It can be advantage to find important new errors but this is disadvantage in the case when it is more important to repeat specific details of the earlier tests.

#32 Hari on 01.22.14 at 2:39 pm

Useful Article.

#33 austinslik on 01.22.14 at 5:29 pm

Great experience shared, thanx.

#34 Bamidele on 01.23.14 at 1:25 am

A very encouraging articulate.Kudos!!!!!!

#35 Bamidele on 01.23.14 at 1:26 am

A very encouraging article.Kudos!!!!!!

#36 Siddhant raut on 01.23.14 at 7:47 am

Its really glad to read this article as same situation i had during my product testing & i understand after the mistake which can be avoided before release as not in documented test case.

To ignore all this type of situations, i also think this can be avoided by concentrating on “purpose of product and not the object or aspect of it” as you already said.

#37 Bhumika Mehta on 01.23.14 at 8:12 am

@Siddhant, @Bamidele, @austinsilk, @hari,

Thanks for appreciation and glad to know that it was useful.

#38 kishore on 01.23.14 at 10:03 am

Good explanation.
But, I would like to know the scenario where we can use it. Is there any model where such testing is given importance/priority. Except for the one when you do not have requirement or clarification of the product.
Do we document ET in our test plan? IS there a common mandate among stakeholders as what does ET mean?
Whats the test closure in ET?
How can we make sure that testing is done following ET?
I find it very helpful but than logging bug on the basis of ET gives developer an opportunity to raise question as on what basis such bugs are valid.. and so on.

#39 Sachin on 01.23.14 at 10:12 am

@Bhumika

Excellent Answers !

Thank you so very much for such a wide clarification.

I must say again that i like the way you explain with the help of relevant examples.

Looking forward to see some more articles from You about Testing.

Congratulation for the best work Bhumika !!!

Thanks,
Sachin

#40 sudheer on 01.23.14 at 2:16 pm

Nice article. Thanks for sharing.

#41 Deepu Rajagopal on 01.24.14 at 7:11 am

Nice article..Valuable information’s about Exploratory testing and which is the best testing approach we can use for the nowadays ways of using the products.

One thing i have to mention is that about the suggestions to the Dev. team to make the product much more better than the competitor. It’s very good that if a QA guy can do some kind of a suggestion like that but , is it possible for all kind of product hierarchies?.
Will it be appreciated in all the companies?
Is it possible in the companies where QA don’t have the voice for raising this kind of suggestions which makes a huge Dev. effort?
If we pointing out some good suggestions we might have to show the ROI of the product due to that suggestion , ryt?

#42 Bhumika Mehta on 01.24.14 at 8:50 am

@Deepu Rajagopal,

Thanks for your readership and questions. My points-

is it possible for all kind of product hierarchies?.
I think I did not understand the question. Can you please elaborate?

Will it be appreciated in all the companies?
Depends on company culture but most of the time yes. If company is really willing to deliver a useful product, it will be.

Is it possible in the companies where QA don’t have the voice for raising this kind of suggestions which makes a huge Dev. effort?
If QA does not have right to raise the voice, why QA exist?

If we pointing out some good suggestions we might have to show the ROI of the product due to that suggestion , ryt?
Yes, what is wrong in it

I am enjoying this discussion and please let me know if you have further queries.

Thanks,
Bhumika

#43 Bhumika Mehta on 01.24.14 at 8:51 am

@Kishore,

Here are the answers of your questions :

Do we document ET in our test plan?
Depends upon company culture but as per me it should be documented. Although ET is always about less documentation and more exploration. So after mentioning scope and approach in the test plan, if only scenarios are documented briefly, it should be enough. No formal documentation of testcases is needed.

IS there a common mandate among stakeholders as what does ET mean?
I am not sure about it. Although for a common group of stakeholders it can be defined with specific terms.

Whats the test closure in ET?
When you feel that you understood all the functionalities as end user and you explored the product from all practical perspectives…you can end ET. Formally there is no exit criteria.

How can we make sure that testing is done following ET?
I find it very helpful but than logging bug on the basis of ET gives developer an opportunity to raise question as on what basis such bugs are valid.. and so on.
As a tester, it is our responsiblity to explain the bug to developer if they have such a question. Also, if taken into confidence the group of stake holders, most of the time, dev team do not such questions. Also, if you think the bug is valid and worth attention and fix, does it matter whether you followed ET or scripted testing?

#44 Bhumika Mehta on 01.24.14 at 8:52 am

@Veda,

Thanks for reading and appreciating. I would love to answer your queries.

1)when are we going to do exploratory testing in real time.
Totally depends upon priority of testing, company culture, deadlines, tester’s experience and maturity level.

2) is end to end testing and exploratory are same.
No. Exploratory and end-to-end testing are different because
— ET is done while exploring and learning the product simlutaneously. End-to-end testing is most of the time done to check whether product satisfies the requirement criterias.

3)is it mandatory that we are going to do for all the projects?
Again depends upon company culture, deadlines, type of client and purpose of product.

4) Can you please explain me with real time example.
The article describes at least 2 real time example about ET.

5) what is adhoc testing? When we are going to do in real time??
As per my knowledge, Adhoc testing is something you test adhocally the product without specific plan / objective / goal.

#45 Siddhartha on 01.25.14 at 5:19 pm

Appreciable, Good job bhumika
I just want to know that is this Exploratory testing limited to functionality aspects only, mean can i explore my application in Non Functional aspects like performance or security measures, if yes what all can i do.

#46 Rajasekaran on 01.25.14 at 6:53 pm

Excellent article Bhumika, especially I loved much about the examples narrated for each item (say scissor with apple, linux with cat/ls, designer with stitching etc.,). Keep rock and all the best for your upcoming articles (expecting).

#47 Sachin on 01.27.14 at 6:51 am

Hi Bumika,

Can you differentiate between Adhoc Testing and ET Testing ?

I think these two are almost same, but as we have two different Nomenclature (name) there may be a thin layer between the concept of both of these ?

Please explain in your style (with appropriate examples).

Thanks.

#48 Bhumika Mehta on 01.27.14 at 11:04 am

Hi Sachin,

As per me AdHoc testing and Exploratory testing are totally different. How? Read on :-)

AdHoc testing
— is done with a perspective that you know the product and its functionality and you are randomly checking its functionality
— is done by testers only because they know the product and its workflow.

Exploratory testing
— is done with an intention to explore and learn the product while testing the same.
— Can be done by anyone including testers and end users.

In simple words,
If a participant in car race is checking his car randomly, by applying full accelerator and break simultaneously, its called AdHoc testing as he is somehow aware about end result and is known, how the car works.

If a person who never drove a car, tries to check racer car randomly and he learns while exploring that what is accelerator and which is break and then tries to apply both simultaneously, its called Exploratory testing.

I hope, I was able to make my point clear.

Thanks,
Bhumika

#49 Sachin on 01.28.14 at 6:24 am

@Bhumika #48.

Great…. Thank you !

I really like the way you respond to everyone, I read all the Queries by other even though I know some answer, I read your answers also and I learned something new obviously in some interesting way.

Nice One!

Thank You !

#50 Bhumika Mehta on 01.28.14 at 6:46 am

@Siddhartha , @Rajasekaran,

Thanks a lot for appreciating efforts.

@Siddhartha : ET is not limited to functionality as main purpose of ET is you learn the product while you explore it and test it.

#51 kishore on 01.30.14 at 8:48 am

Hi Bhumika,
Thanks for your reply.
Also I would like to clarify “when I mention about mentioning it in the test plan” Here, I mean how do I estimate on the basis of ET?
…..
I know bug is valid and requires attention but Dev team oversee it saying we do not have clear requirement and needed client approval/discussion/mandate.
…………………..
I do stress on writing test case while ET. those test case might not be so detail but must cover high level conditions/scenarios.

#52 Karthik Arulmani on 02.05.14 at 7:31 am

Hi Bhumika,

Great Article on Exploratory Testing.

I have a couple of questions on your details on Ad Hoc Testing and Exploratory Testing Comparison.

I wanted to know whether Exploratory testing should be carried out by the experienced resource who knows the product from end to end or a candidate with average knowledge on the product. If a candidate knows the product thoroughly, how will I expect more unknown scenarios as he might be exhausted with all the known scripted scenarios (based on experience, he would have framed all known scenarios).

One problem If I allocate a moderate experienced person in doing ET because he might cover the known scenario in ET (not aware of the entire test case suite) and might not be sure of the results.

Whereas If I use the experienced resource, who knows the product end to end, should have the right intention and attitutude to test the product?

Thanks for your article and it is Thought Provoking!

Thanks
karthik A

#53 Bhumika Mehta on 02.05.14 at 9:27 am

@Kishore,

Hi Kishore,
Sorry for late reply as I could not visit this post since last couple of days.
ET in test plan : Sorry if I misinterpreted something previously. Most of the time, an experience tester (not only year wise), who has been doing ET since years can estimate the test plan correctly. But that does not mean that beginners are not good at estimation. Basically, for ET, you estimate based on test scenarios and your experience.

—-
if the bug is valid and if the dev team is not denying to accept that bug is valid, you have won half marathon :-). Client requirement understaing / discussion can be followed up. Rarely in my career, I have seen even a valid critical bug was not fixed because it was not client’s requirement. That should be fine. The stake holders should be aware that this bug exists or somewhere it should be documented as known bug.


I have never been in favor of writing testcases. I always prefer test scenarios and test data relevant to test scenarios.

Thanks,
Bhumika

#54 Bhumika Mehta on 02.05.14 at 9:44 am

@Karthik,

Hi Karthik,

Thanks for those words of appreciation and your readership.
As per me, Exploratory testing is more about perspective. Whether experienced (who has completed 100 rounds of regression testing for same product) or a trainee (who does not know the product and its functionalities), both can prove good Exploratory tester if they can see the product with different view (from end user perspective), if they can co-relate the product / application with real time usage and if they can make mistakes while learning and exploring the product. If the experience person is exhausted and can not think of any scenarios after doing exhaustive scripted testing, I think he needs training, to change the mindset and to test from end user perspective.
I hope I answered your question :-).

Thanks,
Bhumika

#55 Pranav on 02.10.14 at 11:56 pm

Miss Bhumika nice article :)
But i would like to bring your attention at point #48
AdHoc testing
– is done with a perspective that you know the product and its functionality and you are randomly checking its functionality
– is done by testers only because they know the product and its workflow.

Exploratory testing
– is done with an intention to explore and learn the product while testing the same.
– Can be done by anyone including testers and end users.

Now my opinion :
ET is hard to perform by end user , end user can do ad-hoc testing but exploratory testing is having very wide prospective.
In exploratory testing domain knowledge, objectivity, skill set should better and i believe tester is known for this otherwise no use of being a tester.
Ad-hoc- You mentioned that done by only tester .
Exploratory and Ad-hoc both are very important terms .
Now i have a example :
Ad-hoc – Ad-hoc is like a child who hardly know what is wrong and right but he do his things. Like a newbie tester who is no master of his field.
Exploratory- Exploratory testing is like parent who is well aware what to do with great skill set , objectivity, and domain knowledge that come by experience.

BTW i forget to mention i love the way sachin asked few questions and as miss bhumika replied. I leaned few things from article but by exploring all the comments and conversation of different people i really got to know so many things of exploratory.

Thanks,
Pranav

#56 ivan on 02.26.14 at 4:36 pm

very well written article. hats off..

#57 Hareesh on 03.15.14 at 11:25 am

Great article Miss Bhumika. Thanks a lot.

#58 Bhumika Mehta on 03.25.14 at 8:07 am

@ivan, @Hareesh,

Thanks for the kind words and your readership

#59 Vinod on 05.21.14 at 11:23 am

Excellent explanation….I was fighting for a long time to understand the exploratory test.After reading your article, I am more confident on this topic.

Leave a Comment