Manual testing is not at all that different from, say, integration testing: you write a specification of a task that needs to be performed, you write down the expected output, and you compare it with the actual output.
What you end up with is a document containing dozens of pages full of small tables with test specifications, somewhat like .
So, to sum it up, it is you who should be doing the hard work of finding out what to test. You make a document full of tests which are as specific as possible, and let your partner walk through it. He doesn't understand what to do? Then you failed at being specific. He cannot find the functionality you ask for? Either a usability issue, or once again, not specific enough.
Hope this helps you somewhat!
Manual testing should be exploratory, it shouldn't be following a script. Computers are there to follow scripts.
Even exploratory has written tests that basically say "explore," and they are often assigned with a particular focus.
#1 Create a mock system that you can run automated tests against.
#2 Only do the manual tests.
Which one is the 'right' decision depends largely on the expense of creating that mock system, the complexity of the system under test, the nature of the bugs you're getting from customers and the frequency with which your software changes.
Simple, infrequently changing system? Expensive to set up a mock system? #2.
Complex, frequently changing system? #1 will help more than you realize.
>Even exploratory has written tests that basically say "explore," and they are often assigned with a particular focus.
Of course. However, exploratory shouldn't mean following a script and it shouldn't mean doing repetitive work.
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.
In other words: OP, start with telling us what you want to achieve with your manual tests!
Can iterate on the test spec/script, like anything else... and at the beginning the doc may even prove to be a great tool for contrasting baseline context between different people/roles/backgrounds.
Even silly things like whacking a single button loads really quickly to see what happens. Did you just order 100 tickets? Take down the site?
So telling someone to write better instructions seems a bizarre approach.
You just described my job. :)