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.