Exploratory test techniques

Ad Hoc

            Ad Hoc tests are executed without any plan or structure. Tester just open the application and going through, browsing according to his creative.  Bugs are found by accidentally and it is hard to reproduce, due to Ad Hoc doesn’t follow any structure. 

If you take a look only in the word "exploratory", it might be acceptable to say that the tester are performing a kind of exploratory testing, but defini tivelyit can not be classified as exploratory tests at all!! It happens because this test is performed without any plan, design or structure.

So, the question arises: Is there any scenario to apply Ad Hoc tests?

The answer is yes, there are!! It will depend of the strategy defined before testing. Following is some examples that this tests might be a good solution:

•  Software’s stability: During code freeze phase or as part of regression tests, Ad Hoc might be a good practice to help on get software’s stability due to task force and browsing in the software without plan or pre-requirement.
• Get knowledge about new software: When new person is joined to the team, in this case find a bug is "plus" of learning process.
• Hands on by leader/manager: Test leaders/Manager tend to don’t test software in details due others tasks, Ad Hoc test could be applied to get feeling about the software which he is responsible.

Also can be exist others situations to apply Ad Hoc tests, once more, it will depend of the strategy defined. Testing software is a creative area, these examples are just to give you some ideas to define the best strategy for your project.

Checklist as guidance

An checklist with highlights about software to be tested, is created before performing tests. It means only main function without details.

Let’s suppose that it is software to use SMS function from your mobile device. There are options to send, receive, delete, save as draft, based on these main functions, an checklist is created. Take a look below:

Checkpoint	Test result
Send SMS
Receive SMS
Delete SMS
Save as Draft

The checklist is used as guidance, during exploratory testing. The tester can also use his creativity to explore each situation, see below.

Checkpoint	Examples of scenarios to be explored
Send SMS	concatenated, not concatenated, in roaming, not roaming and so on
Receive SMS	connected to phone, not connected, during a calling or not and so on
Delete SMS	delete saved SMS, not saved, in inbox, sent box and so on
Save as draft	when receive a call, when leave the screen and so on

Note that is important, the setup and clean environment for each checklist line, to garantee the traceability and bug reproducible.

Session Based Testing & Charter

Session based testing was created by James and his brother Jonathan Bach as a need to track the testing they were performing. Since Exploratory testing is a king of a ad hoc processing, not restricted to pre-defined test steps or test procedures with mission of  finding bugs without previous noticed and find them fast sessions-based testing were created.

Session based test management provide a way for the testers to make orderly reports and organize their work without obstruction the flexibility that makes exploratory testing useful.

As definition of what is a session, sessions are time-boxes within which the testing occurs. Each session has a charter (a little mission) and results in a session report.

Basically, each test session (charter) can be composed of the following sections (but not restricted to):

• Mission statement: What you're going to test (Scenario)
• Areas to be tested: The functionalities from the mission
• Tester names
• Date and time used for the session. That can be a previous planning of a minimum time and a maximum time.
• Test Notes: Where the scripted part is created
• Issues: questions or problems that not necessary is a bug
• Bugs: The bugs found into the areas tested