[airza]

Ahh, this is the kind of thinking that frustrated me in my time as a software tester.

From a functionality perspective: maybe, but if the developer needs to explain the intended functionality of the application to the business end of the product then something has gone horribly wrong.

From a sheer "finding bugs" perspective: If you knew what would actually expose buggy functionality to the extent that you could write it down, you wouldn't have written that in the first place!

I encourage you to teach him the way that your specific language makes things happen on the machine and the way that software in general works (boundary conditions, etc). But I don't think that the above way of doing things, ESPECIALLY for a 2 man outfit, is a good idea.

[stingraycharles]

I think we are talking about different goals. If the goal of the test is for sheer fun "bug hunting", a more pragmatic approach should indeed be taken. If, as I interpreted it, the "business guy" is going to do some kind of acceptance testing, and you want to be able to perform this test multiple times, you want the tests to be specific and well documented.

In other words: OP, start with telling us what you want to achieve with your manual tests!