Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm a junior developer joining a QA team at my company. The QA team I had been interacting with while working as a developer was very solid and the business had been very good about encouraging and funding good, solid automated testing techniques and hiring people who were good at it.

However, this new team I am joining looks like it might be a little more reactive in nature, blending some of the testing responsibilities (as I understand them) with ops work and not doing a lot of proactive regression testing. I'm hoping dearly that I am wrong, but the fact is I could be right as well.

Does anyone have any good advice for promoting automated testing? Bear in mind that I'm not a manager or lead, and also not even an experienced tester. But on some level, it feels like some of these principles should fall into common sense. Am I wrong for thinking that? If not, what should I do?

share|improve this question

closed as not constructive by Robert Harvey, Yannis Rizos, Josh K Jan 21 '12 at 18:32

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
+1 because this is a perfectly valid question for a practicing professional programmer, can't see why it was -2. –  Ross Patterson Jan 20 '12 at 23:36
    
+1 from me too, although it's a bit not constructive. But that's what close votes are for... –  Yannis Rizos Jan 20 '12 at 23:57
1  
Thanks for the +1s, I was a little confused too. I admit that it's not a pure developers' question, but I am transitioning from being a developer and I'm trying to integrate some of those ideas into the QA role, just like QA is always begging developers to think more like them and write higher quality code from the get-go. –  Platinum Azure Jan 21 '12 at 16:54
add comment

2 Answers

Tell your manager you'd like to automate some of the tests that you're responsible for, work the extra hours and do it. Use an open source tool (there are a bazillion of them here) Then demonstrate the value of them to the team.

Nothing wins arguments better than demonstrated success.

share|improve this answer
    
Roger that. Nothing wins like winning. But you don't necessarily need to use your own time to do it, lots of managers like to see their folks try new things, and encourage experimentation. –  Ross Patterson Jan 20 '12 at 23:37
3  
Absolutely. However, do not do it to the exclusion of learning the way your new company does do its work. If you want to make a convincing presentation, you need to be more than competent in both approaches. –  Wesley Long Jan 20 '12 at 23:45
    
Absolutely again. I suggested the extra hours because I didn't want to suggest the OP ignore his or her regularly assigned duties. –  Matthew Flynn Jan 21 '12 at 0:58
    
Thanks, that makes a lot of sense. Probably better to do at least a good amount of it in spare time. +1 –  Platinum Azure Jan 21 '12 at 16:55
add comment

I have to agree with Matthew Flynn. Generally your best bet here is to just go and start dealing with the problem either in your spare time or during regular work hours if it significantly reduces your workload.

At a minimum boosting automation is going to save your own personnel time in the long run and hopefully prevent a few 12 am calls.

I'll add in though that how you present your project to the rest of the team can be tricky. Especially if you work for a larger organization where politics, and peer perception plays a large unfortunate role in career longevity.

I've shot myself in the foot this way a few times in my current role. I'd recommend skimming over something like terrance ryan's "Driving Technical Change" on safari books or your local book store to give yourself some good insight on how to effectively pitch some great process improvment out to the rest of your team.

share|improve this answer
    
You're right about presentation probably being key-- that's what I was really driving at in my question. I figured that part would be the trickiest. Thanks for the book recommendation. +1 –  Platinum Azure Jan 21 '12 at 16:56
add comment

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