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.

Greetings to any and all who might find their way here.

This blog is a last ditch attempt to glean particular information on software testing from those who visit. I suppose I am somwehat lost in the software testing jungle and am looking for guides.

Particular areas where I hunger for information are:

1. What are the best ways to implement test automation when you have an application where you can't use record, and you can't program directly to the business logic, but need to go through the UI. I recently spoke to an acquaintance of mine who is an ex-high-priced IT consultant who tells me that there are really two types of  automation:

a. UI tests - which simply exercise UI functionality - keystrokes, mouse-clicks, using all controls on particular screens, using different combinations of keystrokes/mouse clicks, etc

b. business logic tests, for which you would program directly to components that contain the business logic. As far as I understand it, .Net applications are particularly ripe for this kind of automation, as they make it relatively easy to program tests of business logic contained in .Net components.

The above makes a lot of sense to me. Even when writing manual test cases/scripts, typically the best approach is to write tests for the UI, and tests for the business rules, as separate exercises.

My difficulty with automating the app I work on, however, is that it's an old VB app where all the code is behind forms (not in components) so business rule tests have to be done through the UI. The app uses a lot of very old third party controls which are very often difficult to automate. So I'm wondering if anyone has any tips/advice, or can point me to helpful tips in this area?

It seems to me that because of the nature of the app, it may be practically impossible to automate regression testing of it to any useful extent. But I hope I might be wrong, and that someone out there can prove me wrong.

Another area where I seek information: methodologies for improving the quality of the end product by improving processes at each stage of the SDLC. At my company I see huge scope for improving the quality of sofware delivered to customer by improving the quality of:

a. requirements documents - often these are missing detail or are not clear on specific details

b. development - very often, I feel that developers are careless or lazy, ultimately resulting in problems with the software for our customers. Our developers tend to say stuff like: you should do the absolute minimum of work needed, or it's up to testers to find the bugs in the code (ie, 'I write code and it's up to you to find the bugs in it.' Not: 'I aim to write bug-free code.' Of course, all your code is never going to be bug-free, but of course, developers should have this as their aim.)

I'm interested in practical, proven, real-world methodologies that people have seen work. In the belief that tried, proven and mature methodologies are best, I've have done a little reading on Quality Circles  and TQM. In what I've read, I've seen examples given of industries where these methodologies could apply (eg manufacturing or services), but not software development. I wondered if there's a reason for this - are other methodologies more suitable to software development? Is that why there seem to be so many methodologies specifically for software development (eg, Agile)?

I could potentially spend an eternity elaborating on the above and asking further questions, but I think that is enough for now.

Thank you to anyone who reads this, and more thanks to anyone who replies.