What are the priorities when introducing QA, except testing?


Re-formulating my question "Can QA be efficient without Unit-testing (TDD)?"

What are the first priority issues and in which order to consider by fresh created QA department

Really, for me, it is the same question as:
What are in QA except testing? Is it really synonym of test* ?

May I beg to avoid writing on testing in this thread?
Or this is NOT viable pleading?
What I asked is related to metrics, requirements management, standards and policies establishment, model-based automation tools, planning, project management, etc.

Update: The QA staff is being hired, first the head then others, they are new and do not know either code or product. The first task formulated is to start with testing GUI/API and the head of QA department should organize the process for other QA members to implement.

My question is more about organizational issues. Also I specifically want to know about (introductory) references on QA besides testing because whenever I search on QA, I bump into testing

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

Quality Assurance is an independent verification that the development team delivered a good product. They key word here is "independent" - in other words, you want people that are not involved in the development.

Unit tests on the other hand, are written by the developers, as a sanity verification of their work. As such, unit tests are not owned by the QA department.

But, what the QA team does is testing of:

  • all assumptions during design phase - QA should be involved as a for of audit of the design sanity.
  • all functionality being delivered - unit tests cover only sile unit, but QA has to verify (manually or with automation) all main end-to-end scenarios for the product.
  • deployment and configuration of the product - devs machines are all messed up, with all kinds for tools, hacks, latest patches, betas and so on. QA has to verify that the product can bepropely deployed and configured on a clean machine, along with all necessary dependencies, and it will function as expected.
  • performance, stability, reliability and security of the product - QA has to verify that the product does not hose the machine, can do it's work within a perfect boundaries, is stable and can deliver the expected uptime.
  • product meets the requirements for all markets - globalization, localization, marketization.

So, while QA indeed is synonym of "test", the way you phrased your question it sounds like test is something simple and easy to do. Which, if you think about all the work involved in the above list (and I have missed some of the things our test team also owns), is about as far from reality as Santa.

Proper testing requires as much understanding of the product, the technology, the platform and the target users, as the proper development of the product. In addition, the test team has to have the knowledge and the expertise of system administrators, security hackers, usability and privacy experts.

Btw, if you want your investment in that QA team to be worth it, give them power. Work with them to set a well-known set of criteria for the product, and then leave the team to determine how to measure the product against that criteria, without dev team intervention. Ask them to sign off on that criteria, which will make them true owners of the product and make the feel responsible. And then don't ship, until they have really signed off. The worst thing you can do is build QA team, and then ship against their recommendation, or pressure them to let the product out the door, or change the exit criteria at the last minute because the product does not meet it.