<font face="Tahoma" color="purple">I am currently planning the automated testing strategy for the company I am working for based on my knowledge of the product. I have been here for 6 months and my knowledge is quite detailed and I am very familiar with every part of the product that is to be automated.
However it dawned on me that I was deviating from the usual process I employ when test planning, i.e. working from requirements/specifications.
Here is my question - should automated test planning use requirements or by the time tests are automated should the product be familiar enough to me that I can work without the original spec?
Going on the philosophy that automated is great for regression testing:
Since you're testing functionality that you've already tested manually and are checking that nothing new has broken, consider organizing your tests by functionality (assuming your app can be org'ed that way too).
The snag you'll hit is when a change in one functional group affects other functional groups (on purpose--like security functions). Then it'll get more complicated following the cascade of necessary testing, but if you have a well organized application, it should be doable.
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by davidc34: Here is my question - should automated test planning use requirements or by the time tests are automated should the product be familiar enough to me that I can work without the original spec? <HR></BLOCKQUOTE>
I think that all testing go against the spec. Esp with automated tests, this will help you focus on the problem that needs to be solved. Of course, before any code is written for the automated tests, a clear road map of what the goals of the tests should not only be well defined, but on paper so that everyone, including yourself, understands with abs. clarity, what is going to be tested by the suite.
Any software that is written off the top of your head will not be so easy to maintain in the future.