What can project managers do to establish and enforce QA-driven development? In our company, QA/test is given a short amount of time at the end of iterations, and it has been hard to change that.
I haven't heard the term "QA-driven development," though it's an interesting phrase. The term test-driven development (TDD) is a technique originating from Extreme Programming in which test code is written, typically by the developer, before application code is written. This method of testing first helps ensure the code is tested with automated unit tests, which can be run with each build.
You mention that QA/test is allotted a short amount of time at the end of iterations which suggests that you would like to involve QA/test personnel earlier in the iteration. Even if the team is practicing TDD, it is typically the developer, not the traditional "QA/test" engineer who is writing the test code.
In Agile environments, there should be no distinction between developers and testers, and no separate phases for coding and a testing. Rather, the whole team works together to do both the coding and the testing, and everyone is equally responsible for quality. Operating in separate coding and testing phases is often called the "mini-Waterfall" approach. Though the "whole-team" approach is ideal, it is often difficult for teams to operate in this way if they have transitioned from a more traditional approach in which developers were responsible for coding and then the code was delivered to the testers who did the testing. Project managers (or Scrum masters in Scrum environments) can help foster the whole-team approach by assigning tasks to "team members" instead of to "developers" or "QA."
Though transition won't happen overnight, as the team members work more closely together the distinction between coders and testers will begin to fade, and every team member will share responsibility for quality.
This was first published in September 2012