CAST 2015: How I’m Using Reason And Argument in My Testing

The debate-style “Should Testers Code?” presentation at CAST 2015 was one of the best attended talks of the conference. And with good reason: This question is everywhere. But after more than an hour of Henrik Andersson defending testers who don’t code and Jeff Morgan defending testers who do code, I was convinced. Everyone should stop asking this question.

Yes. Testers should know how to code.

At CAST, Jeff Morgan boiled it down to this: testers who can code are more flexible. There is a larger, more diverse market for their skills. Elizabeth Hendrickson found this by counting job descriptions. Testers who can code serve their teams in more ways and jump in to solve problems and ask questions that only a developer can. Rob Lambert argues that you need coding or some other niche to get a testing job. Paul Gerrard notes that adding more skills to your repertoire can only add to your knowledge, not subtract. A skilled tester can put on many hats — user, business analyst, client — and adding developer to that mix can help.

Testers who can code are treated with respect by their developers.

Marlena Compton worries that individuals with less power have been pushed into testing rather than development. Michael Bolton notes that a tester’s empathy grows when they are able to gain a greater insight into the software environment and the problems developers face.

Testers are constantly asking themselves if the task they’re performing is providing a higher value than some other task. A tester who can code has one more tool in their tool belt to help eliminate bottlenecks along the way. When a tester has the engineering skills to craft an automated suite of checks, they’re often able to provide more value to their team than a tester checking the same boxes manually.

For all these reasons, they make more money.

More interesting work, more respect, and more money: What more do you want?

Originally published at on September 23, 2015 and duplicated on Medium.