Can QA be efficient without Unit-testing (TDD)?

Question

A company has small dev teams over a few countries.
During a few years it releases successfully a software product (client in MS Visual Studio 2008 C++, C# and server in Java) based on mathematic and cross-branch engineering fundamental sci (and high-tech) researches.
The software development is not based on TDD (test-driven development), there is no unit-tests, as well as QA department, etc.

This company initiates the introduction of QA group (department and, well, QA practices/policies) of 2-3 persons.

The first priority tasks are to establish (automated) testing practices of GUI and API.

Is introduction of unit (or mock) testing or TDD(test-driven development) essential and obligatory for success of QA?

Update:
Database storage is MS SQL Server.

Update2:
Thanks to all but I posted http://testing.stackexchange.com/questions/791/what-are-in-qa-besides-testing

I understand that after-the-fact unit-tests (or, rather, mock) probably should be incorporated for recurring bugs but should they be the first issue to introduce?
What are the possible first priority issues and their orders? Should after-the fact unit-tests introduced by developers or by "testers"?

Can QA be possibly efficient without Unit- (mock-) testing at all?

Update3:
Thanks for comment that TDD is not Unit-testing, I started to read:

• TDD vs. Unit testing (SO)
• Should I Use TDD?
• Test Driven Development vs "Plain Old Unit
• Disadvantages of Test Driven Development?
• TDD Tests are not Unit Tests

Asked after having read:

• Pro's and Con's of unit testing after the fact.
• A Unit Testing Walkthrough with Visual Studio Team Test
• Pro's and Con's of unit testing after the fact.
• When is it time to have a QA department?
• Unit tests by a QA Engineer
• Role of Testers in Agile?
• What is the single best open source automation tool for functional web testing
• open source Tool for stress testing, load testing and performance testing
• Tools for automated GUI testing (on Windows)?
• GUI Testing
• Automate Builds in .net
• Measuring Class Dependencies

Answer 1

As stated in the comment above, TDD is not the same as Unit testing.

My Advice:

Having been in a similar situation before (I was the founding QA-er at a company that up till that point had no formal QA methods), I would stress that you need to make sure that the QA process is non-invasive to the programming processes.

If the developers are already used to TDD methodologies then it might be easy to implement TDD, but based off the information it sounds like implementing TDD would probably slow down the development (at least till they got used to it).

If you are wanting to baby step things then I would suggest Unit testing. That's what I implemented when I was called to the same task, and then over time I introduced other things.

Answers:

QA can be effective without structured unit testing depending on the quality of persons performing the Qa duties. However QA is more efficient when there are structured unit tests that everyone can follow.

Answer 2

The problem with the names Test-driven development and unit-testing is that they imply they're about testing software. They are not. TDD and unit-testing are about design and they are the developers' responsibility.

The QA Analyst's role is still of the utmost importance on any team practicing TDD and it will be a long, long time before you find yourself out of work as a conscientious QA!

Take a look at Acceptance test driven development and consider getting involved more at the requirements stage by writing automated acceptance tests, perhaps using a tool such as FitNesse.

Manual, exploratory testing still has its place, of course. But you should consider repeating regression testing as a contravention of your basic human rights!

Answer 3

QA Efficiency/Productivity would definitely be higher with Layers of Unit-tests and Integration-tests. This ensures that fewer bugs escape into the acceptance test layer and reduce fix-build-test runs. Unit tests, TDD are more helpful/pertinent to developers than QA - they should be quick and highlight failures with minimal debugging.

If you're trying to retrofit tests to an existing application,

• start by automating the core scenarios as GUI acceptance tests (I'm assuming that your app is not testable under the skin, because it was designed to be that way. If it was, then API tests are faster and easier to write).
• Once you have the application behavior tied down by some tests (a safety net), you can now proceed with refactoring bits that you don't like. Get the devs to agree that all new code must be checked in with unit-tests.
• If you have a slack period and you've decided to use it for improving test coverage: find the most-freq-used core components and get them covered by a unit test suite. Work your way from the outside in.(Don't make the mistake of having QA write post-facto unit-tests for (existing/new) code that they don't know much about.) Unit testing / TDD isn't something you can pick up in a week, especially in a legacy code environment.

Over time, introduce TDD into the development cycle. That will ensure that bugs that can be caught at the lower levels are indeed caught and QA has time to test ad-hoc, usability, performance, etc.

Answer 4

Starting TDD right away might be very hard. You might want to go gradually. First introduce unit testing, then require high unit tests coverage, and then introduce TDD.

Answer 5

As questioner I'd like to provide the answer which I found satisfatory to me. They are obvious if to know them but seem like causing confusion not only to me.

They are annwers to question Black box vs White box Testing
The answer by cschol tells:

• "White Box Testing equals Software Unit Test. The developer or a development level tester (e.g. another developer) ensures that the code he has written is working properly according to the detailed level requirements before integrating it in the system.

  Black Box Testing equals Integration Testing. The tester ensures that the system works according to the requirements on a functional level.

  Both test approaches are equally important in my opinion.

Genn answers:

• "A thorough unit test will catch defects in the development stage and not after the software has been integrated into the system. A system level black box test will ensure all software modules behave correctly when integrated together. A unit test in the development stage would not catch these defects since modules are usually developed independent from each other"

So, the domain of QA is black box or integration testing. White box testing or unit testing is the domain of developers/development.
Even highly qualified testers-programmers cannot write unit tests or develop a-la-TDD instead of developers.

Update:
Well, may be I did not formulate the question well but I really was confused by the term QA group creation that was charged with unit test harnesses also.
I think I found my answer in [ 1 ] which gives comparative table of tasks by SDE/T or SDET (Software Development Engineer in Test or Software Design Engineer in Test ) and STE (SW Testing Engineer).
The term QA department (or Software Quality Engineers) should not have been used.
It is rather Software Test Engineering Dept or Software Design Dept

[ 1 ]
"How We Test Software at Microsoft"
by Alan Page, Ken Johnston, Bj Rollison PUBLISHED BY Microsoft Press A Division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyright © 2009 by Microsoft Corporation ISBN: 9780735624252