A discussion recently came up on my project about writing test scripts.

I’m not talking about TDD here, i’m talking about good old fashioned end-user test scripts – a list of steps to get from point A to point B with each hitting a piece of application functionality.

Some back-story:
As I’ve mentioned, my current project really has no requirements.  Yea, we have a couple use cases and a pretty large list of “issues/requirements” listed in our issue tracker, but nothing like Eric talked about in his article.

The Project Manager is also acting as the Business Analyst on this project (this isn’t something I necessarily agree with and I could write a couple of blog posts on that topic alone, but I digress).

Ok, so the PM has been meeting with the client for months and says he knows *exactly* what the customer wants, but he refuses to write anything down in a formal way.  As I mentioned in my previous post, I tend to get requests via email or IM, although I’ve become much more of a hardass about it and tell him if it’s not in the issue tracker, I’m not working on it.

Ok, so given all that, the PM/BA and I got into a slight disagreement about a week or two ago about test scripts.  His testing is always by the seat of his pants and there really is not repeatable sequence he uses when testing.  My request to him was to create test scripts so that someone else could run through the same tests without deviation.

The PM:
His argument is this: he can’t write test scripts without a *working* application.  He has said that whenever he starts writing test scripts and finds a bug, he can’t proceed with writing his scripts.  There are major pieces of the application that are working, although some areas are buggy.

The Tech Lead (me):
My argument is this: He doesn’t *need* a working application to write scripts. The scripts should be written based on what the app SHOULD do, not what it currently does.  He should have a script that lists steps A,B and C.  If for some reason, he can’t get to step C, then his test has failed and he needs to submit an issue back to the developers.

My second argument is that once he writes a series of test scripts, we can seriously look at automating some of them.

Neither of us has ever held a true “QA” position, so I’m not sure.  The books I’ve read say you should write your tests from the spec, but since we don’t have anything like that, he needs to use his extensive knowledge of what the system is supposed to be.

So, does it sound like I’m way off base here?