QA is not just another place to cut costs

In every professional development job I've had QA is the bastard child of software development, perhaps in all development.
For software development there's a particularly harmful trend to the role of QA. QA is treated like the proving grounds for developers. Software development shops will bring in inexperienced software developers and have them 'pay their dues' in QA until they prove themselves worthy of getting a development role. I think you're better off getting a bunch of people off the street to do your QA testing than you are having people who want to develop perform the testing. Reasons:

• People who lack specialized computer training are going to reflect the actual users of a system better than people who spend 10 or more hours on a computer a day.
• People who lack specialized skills are going to appreciate the role of a QA tester more than a person who has the training and ability to contribute as a software developer.
• People who have gone through the effort of earning a degree in computer science with the intention of programming, will take the first opportunity to get a programming job. It may be outside your organization.
• Along the same vein, why waste someone's development abilities? Are you having a developer test code directly?
• Lastly, in the same way that Bruce Schneier describes The Security Mindset people who want to create software don't necessarily have the ability to test software for flaws. There are people who are better suited for finding flaws.

The only thing I really like about the approach of having software developers pay their dues in QA is it provides an opportunity to learn the products and it gives soon to be developers the opportunity to see the flaws in a system before they work on it.
With that said, having people regularly rotate into QA roles may actually be a healthy activity. If the worst side of the product is apparent to the entire organization, then it's difficult to ignore it. This can work especially well if the people who have the ability to make changes are exposed to the correctable pain points of QA testing.
That's not the practice in most places. In reality, QA has a role ranging from a speed bump to actually reducing the number of defects that get propagated to production. Unfortunately, most QA departments trend toward the former. The purpose of organizing people into QA departments is to prevent defects from reaching the customers. I think that everyone can agree that customers seeing defects is bad.
There are a few reasons that I believe QA departments become ineffective.

• Gaps between QA and production environments. Production equipment can be expensive. Many organizations do not believe that having an identical, or sufficiently similar test environment justifies the expense. If you aren't going to replicate production as closely as can reasonably be done, why bother with having a QA environment? It would be far quicker to go from dev to prod. If you're interested in having a place where defects can be found and deleted, then build a QA environment that's like production.
• QA environments that are like production, but still have gaps. If there are cron jobs on prod, have the same jobs on QA. If prod is behind a firewall, put QA behind the same one. If you can safely replicate prod's data into QA, do it. Every difference between QA and prod is an opportunity for someone to dismiss a defect as an environmental issue.
• Productivity initiatives. Managers who want to get the most out of their QA resources will encourage them to script and streamline their work. That's good, take it a step further and have a computer do that. Use Selenium. Seriously, anything that can be scripted for a human to do can be scripted for a computer. Humans don't like that kind of work, let them focus on things that humans are good at, like exploring.
• Let me restate the last point, people who use software don't use that software according to a script. Even when they do, they won't stick to it for long. They also don't use software consistently. Users forget what they should be doing, or they play around with the interface to discover functionality. If the actual users are going to use the software that way, shouldn't the testers test software to accommodate the users?

To many of those who manage QA departments, the previous four points cost more money than they need to. They see exploratory testing as inconstant and wasteful. They prefer to have detailed standardized test plans that anyone can follow. I say they don't 'get it' when it comes to Quality assurance.
I would argue that if you're going to go through the trouble of writing those test plans, why not write them in Selenium and have computers run them as JUnit tests. Better yet, integrate them into a continuous build server.
Why not keep a QA environment that is as close to production as reasonably possible? If the worst were to happen, it could serve as a failover, or act as an emergency production server.
The thing that probably bothers me the most is when a tester is encouraged to get through their test cases as quickly as possible and discourage them from looking into anomalies.
A big part of this comes from bad scheduling. Testers tend to get stuck under a time crunch because their allotted QA time is cut short because the rest of the schedule fell behind.
QA analysts are often put under the gun to finish their testing as quickly as possible. If you aren't going to give QA time to find the defects, why even go through the motions of having QA? As crazy as that sounds, I believe that most QA departments are sadly adding negative value. If QA only slows the project without finding defects, then they aren't adding value.
We can all agree that even the best of us make mistakes. Those of us who are married can attest that when we make mistakes it will only be a matter of how long, before someone notices. Let's call it the when. In software development the sooner you can make that when, the better. If the when is when the customer is depending on your product, it will cost you much more than if the when occurs when you're designing the application. Testers and developers should strive to make that when now.
To achieve this you need to get the testers involved as soon as possible. Provide them something to test and give them the freedom to get creative in their testing. Have testers of varying levels of experience with the product. Have testers with no experience with the product and let them loose on it. You're going to have untrained users, why not have untrained testers?
The biggest expense with untrained testers is the draw it takes on developers when their defects are allowed to reach developers untriaged. There's a simple way to prevent this, have someone with experience act as the point person for development and QA. That person can find duplicates and can build a relationship with the developers.
Although, this may appear to be expensive, it's cheaper in the long run to invest in quality. Defects are expenses that cost more than can be clearly quantified. They cost in terms of credibility and reputation, which does turn into real money.
Think of it this way:
My first two cars were a Chrysler and a Chevy. Neither one of those vehicles would run for more than six weeks without breaking down.
My third car, was a 1987 Toyota Camry. The Camry lasted me four years without a single breakdown. Even the year when I didn't change the oil.
Since then I've owned another Toyota and a Subaru. Both of them have provided me with a perfect record of reliable transportation.
The next time I buy a car, do you think I'm even going to consider a GMC or Chrysler?

DRY with Selenium--how to cheat the torture of wet corporate applications

I can't say enough good things about Selenium. Second only to Firebug, I'd say Selenium is one of the best add ons for Firefox. It also has a really cool hidden talent, it can do your repetitive busy work for you.
What is Selenium? Selenium was designed as a way to create test cases through a browser(Firefox). The Selenium IDE is an addon to the Firefox browser. It's very intuitive to start recording and playing back use cases. There's a red button in the upper right. If the button is pushed, it's recording. You'll see your actions get added to the table in the action table. Once you are done creating your use case. You can play the use case back by pressing the green go arrow. To make use cases really helpful, you can make assertions of values. Just select an element and right click, you'll see a set of options, e.g., verify text present, wait for text present, etc.
You can export the Selenium tests into Java, and other, unit tests also. That's awesome!
I've found this tool to be very helpful for a number of scenarios. It has a very rich command set that has support for DOM lookups, variable assignments, and regular expression matching. What that basically does is allow for creating static tests that can run on dynamic content.
Selenium is easy for just about anyone to use. I had a business user whose comfort zone with computers ended somewhere near Excel, sit down with Selenium and reproduce a complicated issue that he had trouble describing. I also asked him to go through a typical day of work with Selenium recording. He sat at my workstation and put a good hour in performing his typical tasks. Once he was done I saved the test cases and turned them into use cases that were later made into JMeter load tests.
That's invaluable information to a developer. You're recording every keystroke and mouseclick that your users are performing. Instead of guessing how your tool is used, you're knowing how it is used.
Ok, that's not what this is about.
Selenium, got its name because selenium is a treatment for Mercury poisoning. Selenium doesn't cure my personal case of Mercury poisoning, but it helps with a lot of its friends. The thing I hate about my company's corporate applications is that I am constantly forced to repeat a very similar ritual every time I want to get something done. The ritual is like this: find the link to the application, find my password to that application, log in to that application, try to remember where to go in that application, go a few links deep into the application to get to the interface I want to use, then do whatever it is that I want to do. Everything up to that last step is a waste of my time. The only thing that is performed up to there is verifying my identity and letting me wander to the page that is useful to my task. It's a ceremonious mess. For a personality like mine, it's a mentally draining torture to accomplish a simple task. In terms of DRYness it's a soaking wet towel. It's horrible.
Selenium IDE is a kiln to your corporate applications' wetness. Instead of trying to remember the ceremonies, why not let Selenium do the remembering for you?
For example, my team now needs to fill out a help desk ticket to promote code from the development environment to the QA environment. This is an action that takes approximately sixty seconds to perform, front to end. The act of filling out the help desk software request takes about ten to fifteen minutes. It will also take another ten minutes or so for the team that promotes the code to get the request from the application. That's 25 minutes of ceremony to perform 1 minute of work. What a waste, even from our end we're spending 10 minutes of our time trying to communicate a simple request. A disruptive 10 minutes that only serves to record the request for the sake of our auditors.
I hate that kind of waste.
Fortunately, Selenium is the cure for this. All you need to do, is record the ceremony around your task in Selenium. It might take a little tweaking--keep looping through the actions until it runs without failure. You can add wait commands and change some commands to look for DOM elements or links with regexes. Once you have your case, congratulations.
You have just dried up a sopping mess.
Use this knowledge well.

I suggest we stop using Unit Testing

I suggest we stop using the term 'Unit Testing' and use the term testing instead.
The problem with the term 'Unit Testing' is it refers to a specific type of testing. To many people, it means to test a unit of a program. The smallest discrete piece that you can. In the Java world, that usually means that you have Unit Test class files that test a Java class file, and in each unit test class you'd test all of the methods in the class.
There are some who would create unit tests for each method and call the testing effort done. Some tests are better than none, but it's irresponsible and foolish to stop automated testing at this level. Unit tests are far too robust to catch the nuanced causes that can make a program function different than the intent of its creators.
First, let's get rid of Unit Testing as a term. It's already loaded and it means many things to different people. I think this type of testing is better described as isolation testing or micro testing. My preference is to have a set of method level tests that exercise the intent of those methods.
I prefer the term Isolation Testing because the tests are testing the elements of an application in isolation from their dependencies. In isolation testing, it's preferable to have tests that run on mocked data and stubbed services. They're only concerned with the isolated elements.
Beyond Isolation testing, I prefer to also have higher level integration and situational tests. Integration tests exercise how classes work together. They are more fragile than unit tests, but I would argue that they are more important. They will break earlier than unit tests. If it is feasible, use real data for these, mocking or nuke and pave is ok if situational tests are also in the suite.
Situational tests are a full end to end tests that outline scenarios and user use cases. I like using tools like Selenium to capture scenarios from the user's perspective with tons of assertions. If it's at all possible, I prefer that real data be used for these tests. The more fragile tests you have, the better.
The final automated testing piece is defect regression tests. For each defect that is reported against an application, one should try to create tests to replicate how the software fails and test against it happening again. Some Selenium tests could be very useful in doing this, but tests at the integration and isolation level are good too.
One thing to note with the fragile tests: they will break early. It is very important to have an automated build server like Cruisecontrol or Hudson running automated build scripts after each modification to the source repository. The role of the automated build server is to test the code and let the team know when it has failed. It is important that the continuous build server runs a set of tests that completes in a reasonable period of time for checkins.
For one project I had the server run tests that would take 5 minutes to run. It would run 5 minutes after a checkin. 10 minutes after a checkin, the team would get notified if a submission passed or not. This was helpful at the end of the day. A responsible person could check in their last submission of the day and wait 10 minutes to see if the smoke test passed.
The last component of my testing strategy is to include static code analytics and code coverage tools. I like Cobertura and Crap4j. Findbugs is also good. The role of static code analysis is to measure the complexity of the code and the amount of coverage in the unit tests. The more coverage, the better. The less complexity, the better.
The above is my proposal to replace the term Unit Testing and the practices that we've come to know as unit testing in software development. If it is at all possible, I would encourage developers to try and write tests first also.