Smoke tests Smoke tests are sometimes called basic acceptance tests (BATs). Smoke test comes from hardware where the first test was plug it in and see if it smokes. In either case, the goal is to prevent SQA from wasting time testing software that is fundamentally broken.

Sometimes they are executed by developement, sometimes by release, sometimes by QA and sometimes by more than 1 group.

They should not remain static over the life of the product. As new features are stabilized, tests should be added for them to the BATs, especially if that feature is a building block for other features. If you have good automation, you can actually make every test that passed yesterday part of the BATs for tomorrow. That way (theoretically) QA should never have to deal with a regression. This is a good goal, but there are many reasons why this is not often done, such as, the inability of anyone except SQA to seperate minor failures from major bugs, the amount of hardware or time required to run them all, etc.

I don't know what type of SW you're testing. If it has a GUI that tends to evolve over time, you'll need to have a basic GUI test just to see if the GUI changed enough to confuse the tests. Then once you've adapted to the new UI, then you can run the real BATs, and when those pass, you start on the real testing.

This is especially important if you are committed to a high degree of automation. You don't want all of the people that are doing automation thrashing about because of one or two GUI changes or regressions. Get a good source control system, make those kinds of things one person's job (perhaps ona rotation basis) and keep everyone else writing automation, even if against a build that is a getting old.