That menas the test plans should be very undetailed as you ahve said does the SW do A, B and C and not as how do we get A, B and C.
I think it depends on what you're testing as to whether you need to say how it is tested. Essentially, you would be testing it by using it like a 'user' would use it. If there is a specific way of doing something in the software and that's what you're testing, then the 'how to do it' is important. In saying that though, your tester should be familiar with using the product and is likely to know the 'how' for a lot of the things being tested. It is my understanding is that the tester isn't there to test the way they feel.. they are to test what the developer has designed to ensure their design works.
However.. (see below)..
The problem we are facing is that several tetsters say that they have new ways of testing and that is not highlighted in the test plans.
To test something, it needs to be in the test plans. Bear with me, I'll try and explain below..
What they argue is to have a live test plan which could be changed as the testers change the way they test the product. They also argue that the testers become more experienced with the product as it eveolves. Any thoughts on this ? Would be a great help.
I agree that the testers will become more experienced as they use the product. In fact, I'd hope they do! The more you use it, the more you learn
However, I don't think that means they can just test as they see fit.. their testing must still fit with the testing requirements stipulated earlier during the planning.
If, as you said in your example, you add more modules and fix more bugs, then you would definitely need to add test cases to test with because you've got more things to test. You want to make sure they're all working. The changes in what to test are not done as a reactive thing though - you don't change the tests when you're up to testing. The test plans are put in place early on to say what to test for and then your testing is simply carrying out those tests to check it works. If you want to add more modules and functions, then you write test cases for these and, when ready for testing, then you use those test cases to test.
I'm not 100%, but I think what you're missing is that you write the test cases earlier.. not during testing.
If there's no test case, you don't test for it... Perhaps your testers are trying to create your test cases during the testing phase? If they are, then you want to look at why they have a need to do that. If the predefined test cases are thorough enough, they shouldn't need to change anything during the testing; they just execute the tests. If things are being missed so they feel they need to change the test cases (plans), then it should be 'back to the drawing board' to write the test cases before you do another round of testing.
So, essentially, you change test plans BEFORE you test, not DURING the testing.
I may have gone far off track and if so, let me know and I'll try and answer your question again
