From the site, http://www.softwareqatest.com/qatfaq2.html, I came across this statement. There are many forms of software testing. What I am discussing herein is related to white-box testing, automation and framework development, performance, and security testing

What makes a good Software Test engineer?

“A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk or critical areas of an application on which to focus testing efforts when time is limited.”

In my opinion, more emphasis should be placed on the statement italicized above. Taking it a step further, I would say a developer with previous development knowledge of the product under test is even more valuable. Obviously domain knowledge is what increases this value. From previous experiences with organizations, the development skills of the tester are often largely ignored.

“Writing code? That’s what our developers do, not our testers.”

If we are not placing a greater emphasis on the development skills of the tester, we are missing opportunities to fully test the product. Testers with a development background are more familiar with the developer's perspective. They know the tricks developers do when writing code, they know their shortcuts and tendencies. These testers can also provide developers with insight into defensive coding, adding hooks to make automation easier, securing the product from attacks, ect.

I would argue the inverse is true as well, that having previous testing experience of the product would add value to the transition of a tester into development. A developer with a testing background should improve the testability and security of the product, because they, too, understand the importance and impact of test.

To me, test and development should be shared responsibilities. If a developer is out sick, on vacation, or the team needs a resource, a tester should be able to fill in, developing product code. If a tester is needed for similar reasons, a developer should be able to switch gears and fulfill that need as well. Neither should be more exciting nor glamorous. The organization should respect both disciplines equally. Testing is the last line of defense.  

The software engineer should have two personae, constructive and destructive. Perhaps this is similar to Dr. Jekyll and Mr. Hyde, where we replace the “evil” in Mr. Hyde with “destructive product testing.”