Greetings to any and all that may view this page.

Though it may be optimistic to think that anyone will, but then it is really pessimistic to think that that no-one will. Am I an optimist or a pessimist? Interesting. I suppose one could apply this to the job of testing also - is it the activity of an optimist or a pessimist? Is it optimistic to think that you will find bugs, or pessimistic? Also: interesting.

Anyway, no-one has commented on my last (and first) entry (hence it is possible for something to be both first and last - seeming and actual paradoxes are an instance of many things which fascinate me. I hope they will also interest others who may find their way here, since I would like to have an audience, however small).

Very commonly when reading about the subject of testing (either in books or on the web), I just feel that the writer is not 'speaking' to me. That is, I feel that the things they write about do not seem very relevant to the everyday challenges I face as a tester. Perhaps they're writing about some technical area which is not relevant to me, or perhaps they're writing about some abstract, academic (or so it seems to me) testing methodology which is of little to no use with the practical, real-world problems I face.

I wonder if anyone else out there feels this way?

Some of the major challenges I face - off the top of my head:

- we use Test Director as the manual test tool. Very often it's difficult to come up with a logical structure for documenting test cases/test steps in TD. Eg:
            - you have set-up steps, which are not actually a test, merely preliminary steps) before you can actually do your test. What do people feel is the best way to flag in TD that particular set-up steps need to be done before carrying out other tests (which may be in other sets of Test Steps, or other folders).
            - very often, the logical way to structure your test cases/scenarios from a conceptual point of view, is not the way to structure them from an 'execution' point of view. It's best that I illustrate what I'm trying to say with an example. Suppose you have a number of transaction types, and you want to run the same test cases for each type. So the way to structure this in TD may be to have a set of Test Steps for each transaction type. But when actually using the application, you find that the sequence of steps/events is completely different to how they're structured in TD. How do you deal with this?
            - managers with little or no experience with testing trying to tell you how to write and structure test cases/scenarios. A common problem is that these people actually think that it is possible to write and maintain manual regression test cases for every combination of mouse clicks/keyboard entries that might be tried, which is clearly never going to work. My experience is that you're documented test cases should, basically, be a series of prompts to run higher-level scenarios than this. Eg, you have an order-taking web application (that stesp you through a series of web pages) and you can order apples or oranges. You can pay for them by cheque or credit card - so your test cases would be:

   - order apple using cheque
   - order apple using credit card
   - order orange using cheque
   - order orange using credit card

            Your test cases would not say, select to order apple, go to next page, go back to first page, reload, select apple again, etc. My point is that you don't in your test cases try to describe all sequences of events that a user might try, since this is very difficult, probably impossible and also of little or no value. Since a tester will naturally click around and try different things when they're testing anyway. If a tester needs a test script to tell them to do this, then in my view, they're a very bad tester. The trouble is though (as I've said) is that some managers seem to think that this is the way test cases/scripts should be written, and it's a huge waste of time. Has anyone else faced this problem. What do you do?

That's it for now, I have much to do, and have probably spent too long on this already.

May all who visit gain perfect happiness.