Case: the ad hoc testing

Published Jul 13, 2017Last updated Sep 26, 2017
Case: the ad hoc testing

The term “ad hoc” brings with it negative connotations of the work done carelessly and shoddily. For this very reason, the ad hoc testing technique was changed to more trustworthy “exploratory testing” by Context-Driven School back in the 1990s. Not only the change purified the name of approach, but also provided some clarity.

The ad hoc testing or exploratory testing implies unscripted software testing. And probably the most concise definition of it was outlined by James Bash:

“Exploratory testing is simultaneous learning, test design, and test execution.”

The merit of the ad hoc testing is that a QA-technician can be flexible enough to derive from the initial assumptions about a test structure depending on situational solutions and assumptions. Basically, scripted testing in repetitive sessions is likely to show the similar results, whereas the ad hoc approach allows a tester to improve his/her practise as exploration unravels more specifics of a product.

Today the ad hoc testing faces much of criticism from both technicians and stakeholders as being an unreliable way to eliminate flaws and vulnerabilities. However, if done right, it can be beneficial as a part of the overall assessment framework.

Read our case study on applying the ad hoc testing for the system which has just undergone PHP/Symfony update: http://ddi-dev.com/blog/case/ad-hoc-testing-admin-panel-after-framework-upgrade-when-ad-hoc-meets-needs/

Please share your ideas on ad hoc testing in the comments section below.

Discover and read more posts from DDI Development
get started
Enjoy this post?

Leave a like and comment for DDI

Be the first to share your opinion

Get curated posts in your inbox

Read more posts to become a better developer