- Most code is rolled to production "dark" (not executing), then activated over time with the use of configuration flags.
- The company invests heavily in monitoring and branching infrastructure in order to catch problems quickly.
- The tools group makes up a large percentage of the developer team and has a great deal of infrastructure to sense, fix and push fixes to production quickly.
- Since Etsy is PCI complaint, code involving credit cards, money and customer data goes through a more formal process.
Timothy Western, a tester at Rackspace, says deploying features "dark" means the actual timing of the feature lets the team defer the decision on when to activate the feature-and to continue to debate what it will be or how it will work. For example, the team could move to a different database and deploy code to write to that database but not read from it, all while keeping the old code around. This lets the company do performance, even functional, testing in production with much less risk.
Responsible, reasonable engineers have dropped the tester-as-gatekeeper metaphor and are pushing code to production with every commit. Doing that requires a serious investment in infrastructure and discipline that many teams are unwilling, or unable, to make. That brings us back to testers as gatekeepers-only it turns out that even the test community rejects that approach.
2. The Software Tester as Tester, Not Gatekeeper
Bret Pettichord's 2007 Schools Of Software Testing talk split testers into different groups. According to Pettichord, the "quality" school views testing like manufacturers view mass inspection: Too expensive and too late. Instead of quality control, the quality school tends to focus on reviews, inspections, "getting the requirements right" and making sure a "quality process" is followed in order to ensure that quality software is delivered. (Pettichord himself aligns with the "context-driven" school that views testing as valuable and essential work that's unlikely to be eliminated or completely automated away.)
Meanwhile, Pettichord's 2002 article, Don't Become The Quality Police, advanced the argument that the process police role is confrontational. This degrades relationships among programmers and other technical staff and hurts the project.