Testers as Developers?

Reflecting on this discussion...I started wondering about the reverse.

I've recently been brushing off my VB, and learning Java, both for the purpose of higher-level test automation and mucking in earlier - getting involved in unit testing.

It seems that with increasing uptake in automation, and methodologies that emphasize team over role, that many of us are crossing the divide.

What are the benefits? What are the costs?

Does an improved understanding of the code base and the underlying technology outweigh the risk of increased author bias? Can it blur, or sharped, our perspective on risk?

How can we use dev skills to improve our testing?

Is it really possible to mentally flip/flop between make-it mode and break-it mode?

What does it for the developer/tester dynamic?

Thoughts?

▶ Reply to This

Replies to This Discussion

Permalink Reply by phil kirkham on November 4, 2009 at 9:22pm: well I'm a developer turned tester...

Looking back with what I have learned as a tester I'm embarrassed about how bad my code was and how little I did to test it.
If I was to go back to being a dev then I'm sure I'd be doing better to make my code testable and be learning all about unit testing. Trouble might come from the bosses wanting code developed quicker ( yeh I know, it's only quicker in the very short term )
The best dev I ever worked with pretty much had a tester mentality - he would throughly test every function he wrote .Defects in his code were rare events though of course there were still problems of misinterpreted requirements and usabilty but his code was rock solid; ▶ Reply to This

Permalink Reply by phil kirkham on November 4, 2009 at 9:26pm: Coincedentally there's a discussion on this at the moment on the agile testing group; ▶ Reply to This

Permalink Reply by Iain McCowatt on November 8, 2009 at 3:54pm: The lead dev I'm working with at the moment started out as a tester. It shows.

Personally, I've no plans to cross over on a permanent basis. The tool development at work is purely to lead by example and demonstrate how the framework needs to hang together - and I'm gradually backing out as other team members pick it up. The Java/Selenium stuff I'm doing at home is just for kicks for now.

Why won't I cross over? Well, development turns me into a monster; I become totally focused and can spend days without talking to a soul. I need to come for air and get some human time. I find testing gives me a better balance. Plus, whilst development can be satisfying in a creative sense, it doesn't give me the same thrill that tracking down, replicating and isolating a gnarly bug does.; ▶ Reply to This

Permalink Reply by ShaneMacLaughlin on November 8, 2009 at 6:19pm: Development will do this to you ok. Many years in, and I sometimes feel more like Gollum than the happy go lucky bloke that enjoyed computers so much in the eighties. One of the reasons I frequent testing forums is to remind myself, among other things, that code isn't precious.; ▶ Reply to This

Permalink Reply by Iain McCowatt on November 8, 2009 at 6:22pm: Gollum! I like that. Explains many developers I've met...

Manual regression testing can have the same effect though.; ▶ Reply to This

Permalink Reply by Joel Montvelisky on November 5, 2009 at 4:03am: Great topic and approach!

Back when we started our company I took some development tasks on my self. Since I didn't know anything on the subject I had to learn it from scratch, it took a long time and I need to confess that I really don't see what these guys (the developers) see in their jobs... Testing is so much fun and less frustrating!!!!

But to your points/questions:

The Benefit I see is that you get a more conscious developer that knows he needs to test the code thoroughly and how to do this. The Cost (and I think that this is a psychological issue so it might be a personal one as well) is that since you wrote the code and you did it based on a defined positive scenario all of a sudden you are blinded to find the negative ones that will bring your code down (like looking for imperfections in your kids)

The most difficult thing is to do the "mental flip/flop" you described above (loved the term so I may use it in the future, hope you don't mind). For me, it usually takes about a day before I can test the code I wrote myself, this is the time my mind needs to break with the previous mind-set and reach a level of objectivity that is needed to be a good tester.

I think that overall it helps to know the structure of the product in order to test better, but you don't really need to get to the resolution of knowing the structure of the code itself. In certain occasions it helps, but I think these are relatively few cases and for this you can sit and do some impact/risk analysis with the developer.

Overall, there is a good side from having code experience and specially so if it is in the same product you are testing. It gives you a deeper level understanding, the question is if you really need it, and also if this is the only way to get it? I don't think it is, but it is a faster way than the traditional way of working with the same product a couple of years and getting to know all the small corners by finding bugs in them.

Still, making the switch is hard, and most importantly it shows you that the skills required from a tester are completely different from the ones required to be a developer (and vice-versa).; ▶ Reply to This

Permalink Reply by Iain McCowatt on November 8, 2009 at 3:18pm: Great points, thanks.

Funnily enough, the single biggest challenge I'm facing is not that I'm blinded to the faults - quite the reverse. I'm finding myself struggling to reach code complete because I can dream up endless ways of breaking it, particularly in the stuff I'm doing outside of the work context...I need to back off a bit to figure out what constitutes good enough.

No problems ref the "mental flip/flop" term - though I'm not 100% convinced this is an original term in relation to the concept. I too am finding that taking a few days between development and testing helps - forgetting some of the finer implementation details is a real asset.; ▶ Reply to This

Permalink Reply by ShaneMacLaughlin on November 5, 2009 at 8:43am: First off, I'm a developer with a keen interest in testing, but don't shoot me just yet! I think for most testers, being able to automate using scripting languages, shell and batch files, and even small compiled programs is a huge bonus. You simply encounter so many repetitive tasks, that are slow and painful to do manually. There are risks, typically getting so caught up in your own code that you forget the main task in hand. This is akin to the DIY guy that falls in love with his power tools, spends all the time in the tool store, and doesn't actually do much DIY. Technology is seductve, and learning new technology (or anything new) particularly so. Once you get competent at coding and a bit bored with it, you're back in the driving seat. Programming intensively now for three decades, I don't find coding to be the interesting part of software development any more. For me its about design, which includes designing robust tests.

The flip/flop analogy is a good one, but I'd make a clear distinction between testing your own code, and testing someone elses. The latter is easier; breaking someone elses stuff is fun and challenging. Testing your own code is extremely difficult. Pride aside, the errors you made coding something that led to bugs are probably going to be repeated during testing. This goes from UI design all the way through to algorithm implementation. Testing software, like any testing in the scientific world, is best done blind. In this case, blind not only to the code, but also to the thought processes that generated that code. Pretty hard call unless you're a bit schizo, and yeah, I can already hear the cat calls saying that most devs you know are ;)

For me, if I have to test my own work, which does happen, the best I've come up with so far is to design the tests as I'm designing the software, and having those tests reviewed by a peer. Far from perfect, but the best I've managed to come up with so far.

I think in many ways, being involved in convergent thought processes such as those in coding, and divergent thought processes such as exploratory testing and initial design, is mentally very stimulating, and as such beneficial. Nobody wants to get stuck in a rut.; ▶ Reply to This

Permalink Reply by Iain McCowatt on November 8, 2009 at 3:43pm: Hey Shane,

No shooting here. I'm beginning to think that switching roles can benefit testers and developers alike - if nothing more than to foster greater respect for the challenges of the other profession.

Ref scripting etc, absolutely. There's plenty of opportunity on a project to get stuck in repetitive and non value added tasks. Even simple things such as SQL based comparators for doing data reconciliation, or Excel Macros for easing the project reporting burden can buy you extra time doing real testing. You are also spot on with the risk of getting hung up on perfecting the tool over doing the work - I've got caught in the trap before. I try (at least in the work context) to stick with good enough.

Ref exploratory testing, I find that it cycles rather nicely through divergent and convergent processes, don't you?; ▶ Reply to This

Permalink Reply by Dave Whalen on November 9, 2009 at 11:09pm: It's good to know the code or have someone on the team that knows the code. Not to be negative, but mostly so developers can't blow smoke up my $%%!

I used to teach computer programming and Web development at the local community college. A fact that I typically try to keep quiet. Mostly because I don't want any part of being a developer. But once development tries to push a bogus fix or tell me they can't fix something or make it work like the requirements state, I will typically mention it. The whole developer/tester relationship seems to change at that point. Sometimes, not for the good.

Personally, I'd much rather have testers come from the customer side of the company. Some developers have no concept of the customer's or their needs. They tend to focus on doing things right not doing the right thing. Notice I said "some" NOT "all"!

FYI - I am so NOT an Agile fan. Agile, in my opinion, is a cult of which I have absolutely no desire to join. Which explains my garlic necklace. :o); ▶ Reply to This

Permalink Reply by Iain McCowatt on November 10, 2009 at 12:10am: Dave,

That rated a big grin.

It does help to have some basics, if only to protect against any wool pulling. I've always tried to be as technical as I needed to be on any given project, the end result being a mixed bag of half forgotten technical skills - although I'm originally from the business side of the house.

Ref Agile, I've generally been skeptical - having had a bad experience in the past. However now I find myself on a project that has more right to call itself agile, I'm liking what I see. Apart from anything, having an enlightened lead dev who is really bought into testing helps. But then, that isn't necessarily unique to agile.; ▶ Reply to This

Permalink Reply by Leslie Crandall on November 10, 2009 at 9:02pm: Oh, Dave, come on in...drink the Agile Kool-Aid! Come to the dark side. We have cookies!!!! >: )

In all seriousness, as a tester who came from the business side when I first started down this path, I see the value of having testers who understand how the overall product works. As a developer-tester, I almost feel sometimes that I lose the forest because I'm too busy staring at individual trees. However, because of the popularity of Agile and the rise of Test Driven Development, it's imperative in my opinion for testers to learn at least one programming language (other than SQL.) They don't necessarily need to be craftsmen in that language, but have a basic understanding of how Java works, how .Net works, etc.

I like the team I'm currently working with. We're Agile-ish, and I'm working in a pair programming setup building Fitnesse tests for the existing QA team to use (the current QA team is really more a traditional, business-side test team). My partner in crime here is very fluent in Java, so he usually takes on the role of the fixture writer while I focus on building cases out in FitNesse and looking for new cases to add. We share opinions on how the product we support works - or is supposed to work, and we review each other's work both as a learning opportunity and to check for gaps, mistakes....and dangerous assumptions.

Your mileage may vary, but for me, it's a positive experience. :); ▶ Reply to This