7

In traditional testing follow a fairly simple model in which there are test cases written beforehand for all the possible use cases and then after the test cases are final, they are executed & raise bugs for fail one until they all pass this is one of the traditional model works very well. In the same way, there should be some most effective model or process for Exploratory Testing so here my question is What is the best process to start & perform Exploratory Testing in the most effective way?

5

Exploratory testing is an experience based testing technique, so it mostly depends on whoever executes the test.

Having said that, James Bach outlines a few good points that we can potentially benefit from:

  • An exploratory test session often begins with a charter, which states the mission and perhaps some of the tactics to be used. From my personal experiences, this test charter should be as vague as possible, this way, it does not limit the testers' imagination in anyway.
  • Explore and analyze the subject under test, break it down into elements, produce a test coverage based on the elements.
  • Identify and test all claims from the subject under test's manual / specification, test every single one of them.
  • Define workflows through the subject under test and try each one, each workflow should represent realistic scenarios of use. In my personal experiences, occasionally we need to test unrealistic scenarios too, as it is possible for an end-user to do so.
  • Start testing with a normal scenario, and scale it up in terms of number of options and factors until the subject under test breaks down.
  • Test all fields that allow data entries, including both valid and invalid data types.
  • When the subject under test breaks down, analyze its error-handing capabilities.
  • Check user-interface against windows interface standards or iOS interface standards, depending on the context.
  • Is there any way to corrupt a configuration file? A data file? How does the subject under test tell if a file is corrupted? How does it handle this corrupted file?
  • Integration-test this subject under test with external applications.
  • My personal recommendation: time-box exploratory tests. Say, 2 hours per session.
  • Provide detailed test reports when test concludes.
2

"written beforehand for all the possible use cases"

"that you can think of before getting your hands on the product" would complement the statement.

And since one cannot know everything beforehand, one would start ~exploring~ the product for possible risks, trying to uncover places where one should investigate for things that should not be.

"what is the best process to start & perform Exploratory Testing"

You will not find this answer anywhere; and if you could find it, it would not be the best process right after, because of ~context~. Given your domain, your resources, your knowledge of the product, the risks that you are investigating, and your general experience with testing and any given time, you would come up with a different strategy.

A better question would be: "How to improve myself as a tester?"

The basic trident for personal improvement, on my view is (no order is implied here):

1 - Try; -> Gain experience

2 - Read; -> Know other's experiences

3 - Write. -> Share your experiences and get feedback

How to do it in practice?

1 - Open source projects on a specific domain/technology (LibreOffice is a great pick);

2 - RSS feeds, books, Slack channels, forums;

3 - Blog and speaking - begin with in your company and local communities and expand from there.

If you are new to the field, it's good to have some vocabulary:

  • The ISTQB Guide can help you with that. I recommend reading the Chapter 1.
  • If you are not familiar with the agile approach, a fast reading for the is also the ISTQB Agile Guide. But for a deep dive, the Agile Testing book is excellent.

Now, about testing engineering, I recommend the following blog posts and videos:

Test Engineering:

1

In traditional testing the test cases written beforehand for all the possible use cases

In Agile you try to build the simplest thing that might work. We use Test-First and TDD instead of writing ALL test use cases upfront, which greatly differs from requirements design and waterfall.

The idea is to implement ONE test/use-case, learn from it and decide what the next one will be.

Continue that cycle until the team has delivered something working. Now they can start exploring it. I think exploratory testing should result in indicating gaps in your test automation and give you an idea of the usability from a user-centric view.

Some other questions that cover Exploratory Testing in more detail:

  • Thanks, @Niels van Reijmersdal for correction me Michael Durrant edited "Traditional Testing" to "Agile Testing" sorry man for the confusion, I will change it. thank you once again. – Nitin Rastogi Dec 10 '17 at 12:24
  • 1
    I see, seems to make my answer a bit awkward, but still has some good reference to exploratory testing. – Niels van Reijmersdal Dec 10 '17 at 12:43
  • 1
    Apologies for any mess up. yeah it said traditional but then described agile. Traditional to most folks means waterfall which is different. I generally go by the details if the details and title don't match. But I have no strong preference here if preferred differently cc @nitinr – Michael Durrant Dec 10 '17 at 14:52
  • It's ok man @MichaelDurrant everything is fine now. if I would be at your place I would do the same mistake no issue now everything is fine thanks – Nitin Rastogi Dec 10 '17 at 15:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.