Just because you have tested a specific piece of functionality doesn't mean you know how it will behave when its operating in concert with another piece of functionality. Data Flows through a system are not always covered by functional testing, but if your cases are good enough to work through all the various conditions then you should be able to reuse them.
What I like to get away from in doing System and Integration Testing is the stubs you use for Functional Tests (which can operate like Unit Tests). I also like to develope Scenarios, much like a Customer would do, to exercise the System so I can do a workflow - which is not always going to be covered by Functional Tests.
Think of them as different tools, and each one has a specific purpose, you won't need all tools for every project but you'll need some.
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
In software architecture each component is a piece of puzzle which when put together result in fully functional software. By testing each components using functional test we assures that components are working as per specs. But the bigger question is how we make sure that all pieces together will result in what we desire. It is where integration testing comes into picture.
User acceptance testing is essential to verify the business logic and is also an essential part of testing.
According to the classical V model approach, we have to perform certain tests (not only V model, other standards are there). But what for?..the answer may not be too simple or perceivable in a paragraph. One has to apply a sort of reasoning to untie the knot.
User acceptance testing is better to be executed by business people / users as they have the knowhow of the business and they act without thinking on the technical aspect of the application.
If a tester who performed functional system testing of the application will also perform the user acceptance testing, there's a high chance he will miss things like:
- he usually doesn't have the same knowledge as a user / business person
- he assumes things are correct, which he learned during his test analysis (based on the functional spec) / test execution
- he will most likely not be able to take off his system testing head completely to put on his user acceptance testing head
Same applies to the test cases being used. By reusing the system testing test cases for user acceptance testing, you assume that those test cases exactly match the business but that's not always the case. You might have been given wrong information or you might have interpreted the specifications incorrectly or the specifications might not be completely in line with the business needs etcetera...
By having business people executing tests with their own business scenario (test cases) there's a cross check which ensures a much better coverage. The better the coverage, the better the application fits the business needs.
I agree with JMG on the idea of spending far too much time coming up with test cases that match the types of tests. Is this for a school project or perhaps to please a boss who's asking for specific test case types to meet some sort of quota?
Spend time reading your requirements and functional specification documents. If you have the oppty to read the design documentation, that might help give you more a deeper understanding of what the application should and should not do. Also talk to the users directly or business analysts. If you only have paying customers, ask sales people for contacts you can directly speak with to further learn how someone uses the application on a daily basis. One of the best tutorials I had when I first started doing SQA professionally was spending time with a customer service rep and watched her use the client/server applications that I was about to spend the next 5yrs testing. That one day gave me a great perspective of THE WHOLE PICTURE rather than pieces we sometimes get.
Now I break down my testing into pieces, and like that puzzle analogy above (great example) I put the pieces back together again. But now I'll throw something else in this analogy... imagine 5 puzzles on different tables stacked on each other or side by side. How do all those work together? How do they NOT work together?
Going out of your comfort zone requires failure. True genius is measured by your recovery.