Assistant Professor

Computer Science

Govt. First Grade College

Aurad (B).  Karnataka, India 

Abstract

Ad-hoc software testing is sometimes seen as a wasteful strategy. On the other hand, a lot of knowledgeable software testers believe that the exploratory approach is one of the finest methods for locating specific kinds of defects. As more and more businesses recognize the critical role that software testing plays in the creation of high-quality software, it has found a position in the software industry. The pressure on IT organisations to deliver more products with less resources, in less time, and with good quality increases as business requirements climb. Assuring the deployment of error-free systems is a crucial component of any IT strategy. Ad-hoc testing, among other advantages, greatly lowers the total cost of ownership of programmes.

Introduction

Ad-hoc testing, which is often used to describe software testing without preparation or documentation, can also refer to early experimental scientific experiments. Unless an error is found, the tests are only supposed to be run once. The least formal testing approach is ad hoc testing. Because it is not structured and there are no written test cases, defects discovered using this method may be more difficult to reproduce. Ad-hoc testing's strength, on the other hand, is its ability to swiftly identify significant defects.

Ad hoc means that something is neither organised or methodical. Black box or behavioural testing that is conducted on an as-needed basis is known as ad-hoc testing. Having the required paperwork, such as requirement documents, test plans, test cases, and proper test planning in terms of the scheduling and sequencing of the tests that will be executed, is what is meant by the formal process in this situation. Additionally, actions taken during testing are often not documented. This is mostly done to try and find errors or faults that can't be detected by conventional or formal procedures used during the testing cycle. The key to this testing is the lack of a formal or structured testing process. It is clear when such random testing procedures are used that the testers are trying to break the system without having any specific use cases in mind. Therefore, it is even more evident that such intuitive or creative testing methodologies call for the tester to be exceptionally experienced, capable, and possess a thorough understanding of the system. Ad-hoc testing makes sure that the testing is done completely and is very helpful in figuring out how effective the test bucket is.

A little youngster fiddling with a car's controls and unintentionally pressing the engine start button is an example of ad-hoc testing. Although the child is not yet old enough to drive, he has accidentally tested the engine start button without any prior planning. An additional illustration may be an email id software developer. There is a restriction that the ID cannot contain any special characters, even though an ID is successfully formed when a blank space is entered. This ad hoc test was used to determine whether the software's code was correct.
Comparison between  Ad-hoc Testing and Exploratory Testing

Ad-hoc Testing	Exploratory Testing
Application learning is the first step in ad-hoc testing, which is followed by practise with the actual testing process.	Exploratory testing starts with a learning process that involves examining the application.
Not a fundamental requirement for this kind of testing is documentation. Without specific documentation, the QA team always participates in the testing.	Exploratory testing requires documentation as a requirement. It's essential to record every aspect of the testing in order to guarantee quality.
Ad-hoc is concerned with the accuracy of the tests.	Exploratory testing focuses more on the application's learning process.
Ad-hoc testing is compatible with test execution. The person testing the application needs to be knowledgeable about the sequence.	Exploratory testing will assist in gaining more insight into the test results as the learning environment evolves.
Ad-hoc testing is an approach to application testing that contributes significantly to the creation of software.	First, testers need to understand how the software works. Exploratory testing is useful in addressing that. Engineers must become familiar with it through exploratory testing before evaluating the final programme or application.
Only one executable was tested in this exercise. Engineers do tests only once, but if a fault is discovered, the test is repeated.	This method of testing combines the outcomes of learning tests to produce a novel solution.
It mostly addresses commercial issues and broadens knowledge of the application.	It classifies the issues and contrasts them with those discovered in the past. This shortens the time commitment.
Ad-hoc testing aids in the discovery of original research ideas.	It aids in the application's development.
Ad-hoc only cares about the results; it doesn't bother with the test case issues.	In test cases, there are always challenging circumstances; exploratory testing aids in sorting them out.
For it to begin and continue, some preparation is required.	Exploratory Testing may get going quickly.
Workflow is not compatible with it.	From the very beginning, exploratory testing follows a procedure. It begins with the fundamental goals and gathers accurate data regarding them.

Ad-hoc Testing is not structured                                                  

Ad-hoc testing is performed at random on any component of the programme and does not adhere to any standardised testing methodology. This testing's primary goal is to identify defects through random testing. Ad-hoc testing can make advantage of the testing technique known as error guessing. People who are sufficiently familiar with the system can "guess" the error source by undertaking error guessing.

Ad-hoc tests versus Regression tests

The statement "for the particular end or case at hand without consideration of wider application" is a frequent definition for the term "ad-hoc." You only want to run an ad-hoc test once as an exploratory scenario, unless it finds a bug. Finding problems in brand-new products is the major goal of ad-hoc testing. In the hands of an experienced tester, it can be quite useful in identifying such problems. Formal regression testing can increase confidence more effectively than ad-hoc testing, particularly if the breadth and depth of the coverage are clearly high. Regression testing is the practise of testing updates to computer programmes, and it is used to check whether the previous programming still works after the new changes. Experts in code testing provide regression testing, a common step in the development of programmes, for larger corporations. For the purpose of testing newly written bits of code, the test department's programmers design scenarios and exercises. The test bucket is made up of these test cases. Prior test cases are run against a new version of software before it is released to ensure that all previous features are still functional. Since code in a programme that is not meant to be updated is prone to faults when changed or added to, they might not function.

Where does Ad-hoc testing fit in the testing cycle?

Ad-hoc testing is applied during the entire testing procedure. Ad-hoc testing broadens testers' comprehension of your programme early on in the project, assisting in discovery. The knowledge acquired helps determine priorities and schedules halfway through the project. Ad-hoc testing can be used to more thoroughly analyse problem patches as a project gets closer to completion.

Can Ad-hoc Testing Be Automated?

Comparatively to ad-hoc testing, regression testing typically adapts to automated approaches better. However, there are automated testing techniques that allow for arbitrary test execution. The tester's capacity to execute impromptu processes and assess the accuracy of the results is one of the key benefits of ad-hoc testing. The last step of ad hoc testing, results verification, is exceedingly challenging to automate.

Strengths of Ad-hoc Testing

Ad hoc testing is among the most effective discovery techniques. Rarely do you obtain a clear understanding of how a programme operates from reading the requirements or specifications, provided they even exist. Even user guides occasionally fall short of capturing the "look and feel" of a programme. Your testing strategy's flaws and previously unrecognised links between subsystems may be found via ad-hoc testing. This means that it can be used as a tool to verify the thoroughness of your tests. You can locate missing cases and add them to your library of test cases.

When execute Ad-hoc Testing?

Testing teams are frequently overburdened with too many features to test in the allowed time. Additionally, a lot of testing activities that are produced as a result of the formal process must be finished in that brief period of time. Ad-hoc testing is unlikely to be included in the testing under these conditions. According to my experience, however, a single round of ad hoc testing can greatly enhance the quality of the finished product and reveal a variety of design flaws. Only if the tester is familiar with the system being tested can ad-hoc testing be successful.

Types of Ad-hoc Testing

i)Buddy testing: The developer and tester collaborate on the module to acquire new insights. This testing's goal is to give both members access to a wider range of functions.

ii)Pair Testing: In this type of testing, two testers collaborate on a module using a common test environment. The purpose of this type of testing is to increase the amount of defects by having the two testers brainstorm ideas and approaches. Both parties can split the task of conducting tests and creating the appropriate records of all observations.

The majority of this testing is done at the unit testing level

(iii). To make sure the system can resist any crashes, the tester randomly parses data or runs tests.

Ad-hoc testing tips

i) Altering the browser's text size and/or display resolution, as well as checking the site's UI elements.

ii) Using special characters when filling out forms and search forms.  You'll be astonished to learn that certain of these characters, such as!@#$%&*()_+[]|;':">?,./, might cause issues when displayed on the UI.

iii) Trying to enter and save data that exceeds the maximum allowed by the rules and/or contains negative values in fields like dates, ages, etc.

iv) Testing across browsers.  What might function on Firefox might not function on Internet Explorer or specific IE versions.  There are more opportunities to uncover flaws the more browsers and operating systems we cover. 

v) Modify the browser's settings to conduct regression testing by removing all or some of the session-related cookies and/or the browser cache.  When a session is idle, the system should also gracefully handle session timeouts.

vi) Double-saving the same activity on a form.  If you were to register a user on a website, for instance, after filling out the necessary details, you might click the Register link several times before checking the database to see if multiple records or just one are created.

vii) Moving through the workflow and using the "Back" button on the browser to check if the user is being directed to the right page after leaving one.

Conclusion

Ad-hoc testing's main objective is to find new flaws in the product or specification. It can be very effective in finding such issues in the hands of a skilled tester. The advantages and disadvantages of ad hoc testing methods were covered in detail, as well as their strengths and limitations. One testing method in particular ensures that a tester's inventiveness will be fully satiated. Finding ways to capitalise on Ad-hoc testing's advantages and make it valuable additions to the overall testing process and product quality is important.

References

1. Manual testing - Wikipedia, the free encyclopedia available at http://en.wikipedia.org/wiki/manual testing

2. Roger S. Pressman (2005)," Software engineering a practioner's approach 6/e"

3. Pankaj Jalote, An Integrated Approach to Software Engineering, Narosa Publishing House

4. Aditya P.Mathur.,"Foundation of Software testing",Pearson Education 1st edition.

5. Shivprasad Koirala , “Software Testing”, BPB Pulications.

6. Ian Sommerville “Software Engineering” Pearson Education.