A while ago I answered the following question on SearchSoftwareQuality.com’s Ask The Software Quality Expert: Questions & Answers.

The project that I'm working on is to create regression test scripts for applications which are migrating from another location. This test team has mainly functional (system test) scripts and there are many applications that we are taking over. How would you approach the regression scripting considering we have many applications and limited resources?

Here is a clip from my answer:

I follow the same basic steps when I think about regression testing as I do for any other type of testing. I try to force myself to think about coverage, risk and cost. I'm always looking to evaluate what tests can best address my most important risks with the most coverage given the time, tools and resources I have.

Understanding what you have to cover
I would encourage you to start off by making an outline of all the things you could potentially cover in your regression testing. [...]

Understanding your risks
After you have a list of what you might want to cover in your regression testing, start thinking about the specific risks that you're concerned about. [...]

Putting your risks and coverage together (chartering your work)
Once you know what you want to test (coverage) and why you want to test it (risk) you're ready to charter your work. Chartering is the activity where you put it all together in meaningful terms. [...]

Prioritize the work and figure out what you can do
Once you've chartered your work, you should have some idea of how much work might be in front of you if you wanted to test it all (or everything you could think of at least). [...]

At the end of all this, you'll have a list of charters for each application that you should be able to execute given the resources you have. Following some sort of schedule that makes sense for your team, get in the habit of incrementally reviewing the coverage, risk, charters and priority you have for each application. You'll find that what you want to test and why you want to test it will change over time.

You can find the full posting here.

A while ago I answered the following question on SearchSoftwareQuality.com’s Ask The Software Quality Expert: Questions & Answers.

I like JUnit from what I hear. I do not know how to use it. Please kindly advise me how to use it.

Here is a clip from my answer:

Given that you asked specifically about JUnit, I would also recommend the JUnit documentation on SourceForge. A great example which walks you through specific tests (follow along in JUnit as you read it) is JUnit Test Infected: Programmers Love Writing Tests. Once you've read a bit about it, the best way to learn is to start doing it. Just start. The more you do it, the easier it gets.

You can find the full posting here.

Since writing that post, I've had the pleasure to hear Anthony Panozzo share his experience on getting started with Test Driven Development. While not a JUnit story, it's a wonderful read for someone just getting started and I'd add it to my list of references.