Test introduction of Ad-hoc Test

Ad-hoc Test
Basic knowledge about Ad-hoc Testing

"Ad-Hoc" is intended to refer to "specific, one-time", which specifically refers to "random, free" testing. In addition to testing according to the test samples and instructions, random testing (Ad-hoc testing) is also required in software testing ), the function and performance of the software are checked based on the tester's experience. Random testing is an important supplementary means to execute the sample test according to the test manual. It is an effective way and process to ensure the test coverage integrity.

The random test mainly involves a retest of some important functions of the software under test, and also includes the tests that are not covered by the current test example (TestCase. In addition, software updates and new functions should be tested. Focuses on some special points, special use environments, concurrency, and inspection. In particular, the major bugs found in previous tests can be re-tested in conjunction with the Regression testing.

In theory, random testing is required for each software version to be tested, especially for the final version to be released. Random testing is best performed by testers who are familiar with the software under test with rich testing experience. The more familiar the software to be tested, the easier it is to perform random tests. Only by accumulating test experience, including test execution and Analysis of defect tracking records, can we continue to summarize the results.

Short Q & A about Ad-hoc Testing

Q: What is a "specific" test? Or "exploratory" testing?

This is a test for a specific purpose. This test will not be repeated in the future. In the practice of software engineering, most of "ad hoc" refers to random and Exploratory tests. For example, when A tester got A new Build, he planned to test the function of module A, but he wanted to see how another function B was doing, or you may want to see what happens to module A under certain boundary conditions, so he just "ad hoc" and found many bugs in this function module.

"Ad hoc" also means testing is tentative. "Let me try it. In this dialog box, press it in disorder and change the window size at will to see what will happen ...", If there is no problem, it will not be done in the future.

Generally, testers do not spend a lot of time performing specific tests, but in some teams that lack management, testers often do not know what they should do at this time, we had to perform some seemingly "ad hoc" tests, such as random testing of various functional aspects. In theory, the test management personnel should plan the test cases of each functional module.

In a team, too many "ad hoc" is a sign of poor management, because "ad hoc" refers to the testing plans that are expected to be done at the moment but are not planned to be repeated frequently in the future.

Q: I have heard that someone is a master of the "ad hoc" test. What does this mean?

A: Many testers perform tests step by step. However, some testers are more flexible in mind and prefer to develop new approaches to test some scenarios that most people will not think, these people often find more bugs. Developers love and hate such "ad hoc" Masters.

Q: At the same time, the problem can be divided into two aspects. Some bugs found in "ad hoc" are hardly detected in normal software use. Do we need to spend time on "ad hoc "?

A: At present, there are millions of successful general-purpose software users, and it is difficult to carry out a step-by-step test plan to cover many practical scenarios. At this time, "ad hoc" testing can detect important problems; in other fields with great risks, such as security, once a problem occurs, the threat will be quite large. In this case, we should encourage some "ad hoc" tests to make up for the shortcomings of Common tests. In this sense, the "ad hoc" test can be used to measure the completeness of the current test case. If you have been exploring for half a day, you have not found any problems beyond the existing test cases, this shows that the existing test cases are complete.

The test process of the "ad hoc" test cannot be repeated because it is a "specific" test and cannot be repeated. For this reason, the "ad hoc" test cannot be automated. In this case, it cannot reach the level 2-Repeatable Level of CMM.

As a manager, if too many bugs come out of "ad hoc", we should check whether the test plan is based on actual scenarios, whether the developer's code logic is complete, and so on. At the same time, we should be good at abstracting seemingly "ad hoc" test cases, including them into future test plans.

Q: What are the tips for "ad hoc" testing?

Some tips for random testing can help testers discover bugs more effectively.

Tip 1: More bugs can be found when many bugs are found. When we perform random tests, we often first make statistics on which modules were found to have the most bugs last week, so we have to find them in that module this Monday.

Tip 2: Know Yourself And know yourself. Confidant is to know which aspects they have expertise and to give full play to these strengths. Zhihe is mainly responsible for understanding the two aspects. First, what aspects of the program itself are the most complex and weakest, what errors are most likely to occur in these areas, and where programmers are most likely to make mistakes. The former can be well mastered through familiarity with the program, and the latter can be obtained through CQ (BUG Management Tool) analysis.

Tip 3: communicate with programmers. In the process of communicating with programmers, you can know many things you have never known before. You can verify these things to discover unknown bugs, in addition, it can inspire you to use more testing methods for testing.

 

This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/wayne_ran/archive/2008/01/08/2030915.aspx