Most of the Test Managers say, "Testing without test plans is a crime." The testers should know what is being built and should analyze the way to proceed. He/she will have to prepare the test plans based upon that to proceed with testing the application. Good knowledge of Exploratory Testing is necessary for reading this article. For those who don't have much idea about Exploratory Testing, a small intro is given here.
Most of the Test Managers says, "Testing without Test Plans is a crime". The Testers should know what is being built and he should analyse the way to proceed. He/She will have to prepare the Test Plans based upon that to proceed with Testing the Application. Good knowledge of Exploratory Testing is necessary for reading this article. For those who dont have much idea about Exploratory Testing, a small intro is given here.
"The plainest definition of exploratory testing is test design and test execution at the same time. Exploratory software testing is a powerful and fun approach to testing. In some situations, it can be orders of magnitude more productive than scripted testing. I haven’t found a tester yet who didn't, at least unconsciously, perform exploratory testing at one time or another. Yet few of us study this approach, and it doesn't get much respect in our field. It's high time we stop the denial, and publicly recognize the exploratory approach for what it is: scientific thinking in real time. Friends, that's a good thing."–James Bach
There are lots of myths that is behind the Exploratory Testing and the objective of this writing is to expose them. There are lots of proofs which tells that Exploratory Testing is the best among the other testing techniques. The user of this article is recommended to have some idea about the advantages of Exploratory Testing. If the user is a beginner then he can gather information about what are all the circumstances, one can go for an Exploratory Testing, without knowing the reason behind it.
"A test that reveals a problem is a success. A test that did not reveal a problem was a waste of time"–Cem Kaner
In this Internet arena, in an organization with no Software Configuration Management, Projects are built without any kind of Documentations. If they are available also, they are not going to get updated, as and when the modifications from the client is received. The Project Manager conveys the modifications to his/her team by word of mouth and gets the modifications done without getting them updated in the documentation. It is inevitable for him to get the modifications updated in the documentation, but at the same time, when he prioritizes to get the changes implemented in the code, the former gains low priorities serially and that goes out of his mind, if the code is done. This is going to have a direct impact on the Testing Process. If you are deriving the Test Cases out of the documentations, your Test Cases are going to get aged soon. It is not worth to look back at them. We cannot use them as it has no relevance with the Code. The time invested in preparing the Test Cases is wasted, here.
Let us consider that the requirement is going to get changed frequently, say 4-5 modifications per day. It is the tendency of the people to forget about the documentions and to concentrate more on the implementation part. These are all happening because of the time and cost associated with that. Though they are all inevitable from the angle of LAW, the need of rigor and to satisfy the customer at time pushes the Project Manager to forego this activity, as he/she considers it as a overhead. Finally, they got approval for doing this from the Top Management also. The project life travels in a planned undocumented way and how we can expect the testing should happen in a planned documented, properly scripted WAY?
"If you think you can fully test a program without testing its response to every possible input, fine. Give us a list of your test cases. We can write a program that will pass all your tests but still fail spectacularly on an input you missed. If we can do this deliberately, our contention is that we or other programmers can do it accidentally"–Cem Kaner
A well documented Test Scripts can also miss bugs. Unplanned Adhoc Testing can also miss bugs. For the former, Time + Money is invested for finding the bugs. As every process is having its own entropy associated with that, this is not an odd process. This have its own entropy, leaving some bugs, covered. The same applies for the latter too. In an organization with no Software Configuration Management, experience proves that the number of bugs covered by well planned Test Scripts is less than the Unplanned Adhoc Testing. But when tried to put a Cost Benefit analysis, the Test Manager is pushed to follow an Unplanned Adhoc Testing approach. Instead of going to an Unplanned Adhoc Testing, why not Exploratory Testing?
"Myers described a much simpler program in 1979. It was just a loop and a few IF statements. In most languages, you could write it in 20 lines of code. This program has 100 trillion paths; a fast tester could test them all in a billion years."–Cem Kaner
Testing cannot be claimed that it is completed. Testers cannot claim that the program is 100% error free. 20 lines of code is having 100 trillion paths. We normally deal with Klocs, that gives a very big figure, when extrapolated. If we wanna uncover most of the bugs, we have to select Test Cases from the Test Cases for trillion paths, which is trillion*n in number. Planning these type of tests requires more time, which we cannot think if we are in Web Time. If no time is available, then the tests become Uplanned and Adhoc. Started with a good plan, morphed to Unplanned and Adhoc at the end. Instead of welcoming this, Why not Exploratory Testing?
"If you want and expect a program to work, you will be more likely to see a working program – you will miss failures. If you expect it to fail, you'll more likely to see the problems. If you are punished for reporting failures, you will miss failures. You won't only fail to report them–you will not notice them."–Cem Kaner
Testing relies on the mindset of the testers. It is an art. Most of them says that tests have to be well planned and executed. Let us take a case that we are well planning 100 tests for a program which is going to leave, say 20 bugs covered. Testing is a creative work. It the testers have to go by these well planned 100 tests, they will not be exploratory while executing them. Instead they are required to be more exploratory, while they are executing the tests. They have to be exploratory to find the remaining 20 bugs. If that 20 bugs are going to be very major ones and these 100 tests are going to give only very little number of minor bugs, then what is the advantage in investing a huge amount of money in designing those 100 tests. Instead of this strategy, why not exploratory testing?
Testing is creative work. Agreed, the exploratory nature of the tester is needed very much while designing the tests. At the same time, it is needed very much more than while designing the tests. We cannot deny the fact that exploration is not needed while executing the tests and we cannot categorize that under Unplanned Adhoc testing. This world has got its electric light because of the exploration of Thomas Alwa Edison. This world has got its Air Traffic because of the exploration of Right Brothers. Exploration is the one which is going to fetch good results and remarkable results at the end. Exploration at the time of designing the tests is very much needed for a complex application to plan for the areas which is new for the tester and the areas which are old to him need not to be planned for test as he is good enough with finding bugs with Exploratory Testing for those areas. Even if the tests for that complex parts of the application are not planned also, they can be done at the time of execution if the tester is having expertise in testing and that too in Exploratory Testing, very much.
Designing the tests is also an art and it also involves creativity in itself. It is the different ways of thinking of the tester as an individual which is put into papers and termed as Test Plan. Testing is a mindset. The interpretation of the information differs from people to people. If this is the case then coverage of testing can be achieved by more than one people testing the same piece of code. Thus with the different ways of exploration, we can achieve the coverage.
Summary
If the exploration is done on Test Application for testing that, then that is termed as Exploratory Testing. If the exploration is done on Test Application for designing the tests then that is termed as Test Planning. Whatever the terms used, Exploration in testing is very much in need.
