All About Agile | Agile Development Made Easy!
If a QA Tech has skills to code should they be allowed to on a project or should they only test?
In Agile part of being an effective team is blurring the line between titles. For instance just because you have the title of "Developer" doesn't mean that you can't test. So does it work the other way as well? Just because you're a QA Tech doesn't mean you can't code if you have the skills needed. From what I understand of Agile the team owns their commitment and if there are members on the team that can get the job done it doesn't matter what their title is. I'd like to hear other thoughts on this. Time and time again I hear about Developers contributing to the testing effort but never QA contributing to the code effort if they can.
What are others thoughts on this?
What are others thoughts on this?
Views: 7
Replies to This Discussion
-
Permalink Reply by Simon Kiteley on -
If it gets the job gone... what's the issue! Have the best person for the job doing it to gain the best benefit to the company. I'd like to think it was possible to drop titles completely and have your position based on where your skills/interests are.
Maybe pair the tester [really don't like calling testers QA] with a developer for an benefit from the focus they both have.
-
Permalink Reply by Duncan Campbell on -
Have the tester write test scripts! Or unit tests.
-
Permalink Reply by Marco Werner on -
I am a member of the QA team and i am able to code.
If I am a member of a agile team i am equal to everyone in the team.
In this team there is no room for titles like 'developer' or 'tester'.
Everybody should do as much as possible to reach the iteration goal (all together).
If anybody in the team is not able to code someone should try to show him an entry in "the art of coding".
Pairprogramming/Pairworking is essential.
The team has to try to reach a level on which (in best case) everybody could do everything.
In most cases there are still specialists in the team but you should realy try to support a consequent knowlege transfer.
I think that it is verry dangerous to say something like "this guy does the testing/scripting, this one produces the sourcecode ..."
team is team and that´s all you need! ;-)
With best regards,
Marco
-
Permalink Reply by John Reber on -
In theory everyone in an agile team is a 'generalist' - so why not let a tester with the right skills go ahead and code. In practice I've never seen it happen and I don't expect to.
Yes a tester could do some programming but outside of coding for testing automation they are never going to be as good as a full time developer at coding Java, C etc. Actually, let me re-phrase that. They are never going to know the codebase as well as the full time developers.
Yes a developer can test. Not just unit tests but functionally too. But are they going to have the skills and experience, the nous and intuition of a full time tester? Will they take the time to really explore, interrogate and exercise the application in the same way an experienced tester will. It's not likely.
-
Permalink Reply by Marco Werner on
-
A tester is the specialist on test task the developer the specialist on coding tasks.
Nevertheless they should help each other and cooperate.
If the developer is ill, on holiday or just has no time left to do the devtask the tester in the team should be able to do at least the easy developer stuff.
The other way is the same; the developer can also make tests which are not devtests like JUnit.
In the end a complete stable increment is the goal.
Collaboration and teamwork is the key.
For me it´s not the question if the developer should do test tasks or the tester should do coding tasks.
Just try to pair devs and QAs and see what happens.
Maybe you´ll be surpised...
© 2012 Created by Kelly Waters.
