I have noticed in the last few years that employers are now looking for QA/Developers (QA engineers that have been skilled developers).

I would like to know what others believe are the actually additional activities that these QA/Devs bring to the project.

These are a few that come to mind:

  • Reading code while doing white box testing
  • Creating Unit tests along side the Developers
  • Creating Integration tests

This is not about how development experiences enhances the testers effectiveness in finding defects. But about understanding what those value added activities are, that this type of testing resource can bring to the developers and the project.

Thanks in advance for your feedback!

SQA Stack Exchange responses on value added activities:

  • Providing automation of routine testing, Alan
  • Explore possible software design choices for better code testability, Aruna
  • Perform white box testing, Bruce Mcleod
  • 1
    You could find more on this if you looked up SDET (Software Developer in Test), Microsoft uses them as Testers on many of their projects for many of the reasons noted below.
    – MichaelF
    Commented May 22, 2011 at 20:34

5 Answers 5


In my experience, the best developer/testers bring what I call the boredom herusitic to software testing. Inother words, they often automate rote tasks so they can focus on testing and analysis of the software.

An example I use often is the "add contact" feature in an instant messaging or email client. To test the feature, I'd need to try long names, localized names, blank names, etc. I'd also need to test adding and removing a contact. The matrix of test ideas could expand pretty quickly...and I'd get bored trying all of those things - and worse, I'd never try the perf / stress scenario of adding and deleting a contact 500 times (nor would I automatically check disk and memory status during the operations).

In short, good test developers look at the testing problem, then figure out how they can use a program or automation to help them solve the testing problem efficiently.

  • 1
    Great example! I think the value added activity you are describing is providing automation of routine testing, a test/developer would be motivated by the desire to have greater test coverage and probably more capable because of their programming background. I have added this to my question above. Thanks! Commented May 20, 2011 at 2:00
  • 7
    +1 for the boredom hueristic concept. In addition to automated testing, a developer/tester is more likely to see the opportunities to build helper tools -- a javascript favelet to reveal hidden information on a web page, or a SQL script to help validate back-end data.
    – TomG
    Commented May 20, 2011 at 2:48

Personally I find that tester who codes in addition to great testing skills is much more effective than the non-technical equivalent.

A techical tester can esentially bring more "weapons to bear" on testing problems than you could without those skill sets. Some examples:

  • Need to generate some test data? Write a tool to do it.

  • Need to check security access when logged in as certain users? Write some automation to do it.

  • Need to automate the deployment of your application? Write some scripts for that.

  • Need to influence the way developers perform their unit tests? Show them how or build them a unit test framework.

  • Need to perform white box testing? You have the skills to check out the code and start reading.

However, a word of caution. It is easy for testers who can code to only want to code. The real skill in being a QA Developer is knowing when it is appropriate to develop and when to put the tools down and just test it manually.

  • 4
    Good point on the need for the QA/Developer to realize that their job is first to be a great tester. Their development activities should be, just the extra help needed at the moment and no more. Commented May 20, 2011 at 3:39
  • Even if the task is mainly automating things for tests, the tester shall stay, first of all, a tester. Coding for the pleasure of coding distracts from the bug hunt.
    – gazzz0x2z
    Commented Jan 5, 2016 at 20:48

I've had success using tester/developers for code review of production code. I've found that developers review code thinking, "Will this work", while testers review code thinking "In what ways could this not work". I've also found that most testers discover new test ideas while reviewing production code.

I wrote a paper on the experiences of our team in this area.

  • 2
    That goes back to the question sqa.stackexchange.com/q/545/453 of how testers and developer mindsets differ. Again, a tester could have a developer mindset as well and vice versa. What this means is that BOTH mindsets are necessary to build good, robust, full-coverage tests. Commented May 20, 2011 at 20:45
  • Yes - I agree with this comment completely.
    – Alan
    Commented May 20, 2011 at 21:33
  • 1
    Also testers tend to perform code coverage analysis when they look at the code to check if they have reached the target test coverage and analyze if the uncovered code poses any risk to the end-customer
    – Aruna
    Commented May 21, 2011 at 0:23

A tester can add value to the product and development team by making/influencing key software design choices even before coding starts.

Testers with a programming background can understand and explore possible software design choices for better code testability and they can determine "if the code is fit for use?" Design choices like "Dependency Injection" and "Decoupling" can make the code robust and flexible enough to absorb future changes in customer requirements.

Code with lots of dependencies violates the "Law of Demeter" or the Hollywood principle. With dependency injection, the code becomes loosely coupled and there is an article explaining how test automation is connected with this here.


I think the primary benefit is that they can

Join the development conversation and help improve the product

with the developers and talk about technical terms and understand them when heard. Although I often prefer black-box testing (not knowing the internals), I find that understanding the tech setup is a key skill. When something breaks a tester with a technical background will be more equipped to:

  • find the transaction(s) in the log
  • understand the details of the log
  • be able to query the database for related data
  • join in code reviews for quality code and tests
  • be able to write new tests and update existing ones
  • know the concept of happy, sad and optional test cases
  • have the respect of the developers as a first class citizen
  • be able to read the code itself where the issue is occurring
  • be able to read the tests and understand what they are doing wrong
  • provide guidance on good coding practices and why they matter over time

fyi, I was a developer for 20 years then became a Quality Engineer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.