Should all programmers be testers also? And should all testers be programmers?
This question has been coming up a lot with the adoption of agile practices, and especially SCRUM.
I think the second part of the question is even more relevant now. What good are tests that aren't automated. And how much more effective of a tester is a tester who can write code that does the testing?
Heh - you'd think so sometimes. I presume mean "Should all programmers spend time testing, and should all testers know how to code?"
I figure more of more kinds of testing is generally a good thing.
The usual problem with programmers testing is that it's hard for us to avoid the fact that we know how it "should" work, so there are edge cases we don't come across.
Maybe we're better at coming up with new Unit Tests to automate.
This is actually something the other person can spend time doing when pair programming.
you need programmers to test low-level stuff (unit-tests, integration, interfaces, etc) But you also need testers with the business-domain knowledge to make sure the end result is what they were expecting.
Good programmers figure out how to make things work. Good testers figure out how to break things. You'd think those are the same skills, but they're not.
The answer to this in my opinion is yes
Programmers should definately be testers because I cant tell you how many times I get software to test that doesnt even work in its most basic funtion.
Testers dont have to be programmers but it doesnt hurt. Not all things can be automated but if it can be automated I believe it should. It makes regression testing a whole lot easier.
And yes I am a Tester that is also a Jr Dev.
no - programmers should not (and in many cases can not and have no interest in being) testers, and while it's good for testers to have 'conversational' programming skills, it's not necessary for them to be proficient.
The attention to detail and sort of perfectionist attitude required to be a good tester is something that certain people have a knack for - just like certain people have the problem-solving mindset required to be a good programmer. They're different types of people - you can't make them into each other.
Finally, even if you were hellbent on moving their job descriptions closer together, don't make the programmers who made the project be the ones to test it - they've seen it so many times during development that they've lost all perspective, and will easily overlook problems since they're so used to seeing things a certain way. This happened all the time at the last agency I worked at. Get some fresh eyes on the project.
Yes. If you haven't tested your code, even if it's only a tiny manual test, then you cannot say that you are actually complete. A developer who doesn't test his own code at all doesn't deserve the name.
Developers should at least be competent to write simple unit tests for the code they write. In a well-organized development shop, code will never be checked it without some kind of unit test to accompany it, even if that unit test is initially incomplete or doesn't cover all of the use cases. In this sense, it's absolutely essential that developers be testers.
That depends. There's a lot to be said for having at least some developer-testers, who can write automated tests or test suites. Having a developer who writes tests can save countless man-hours down the road by running tests faster and more consistently than a human, ensuring the quality of the product and the correctness of code in the code base. You definitely want your testers to be developers when doing the following kinds of tests:
However, in certain domains (especially web programming or UI work), there is a certain amount of testing that cannot reasonably be automated. This testing requires that human eyeballs look at the screen and work through the site or the program. It isn't necessary for these testers to be programmers--in fact, it might be better if they aren't programmers, since developers view the world differently than most people. You may want non-programmers for the following kinds of tests:
One thing to note is that programming skills are beneficial for many things other than writing automation. Testers who understand programming and computer science can write diagnostic tools, can debug complex issues, and can investigate failures to the root cause.
Programmers. Yes, programmers should have no trouble testing the code that they produce. The burden of testing should not rest solely on the developer, however. Code reviews with your colleagues can go a long way - the simple act of explaining your code often reveals edge cases you might not have anticipated otherwise.
Testers. I agree with others here - it depends. I think a blend of technical and end-user testers works best.
With regard to new, "agile," development methodologies in business, I think it depends on the business' structure and environment. Many agile processes claim that any member of the agile team should be able to pick up any task and run with it. However, since agile methodologies are relatively new, many businesses aren't suited for creating teams of developers that can perform all tasks sufficiently.
A lot of existing companies (who didn't start out as "agile shops") have had long-established QA and development departments, each containing specialists that do their job well and were hired because of it. When you combine members of both these teams into an "agile team" whose members are expected to be able to do everything, you can run into some problems. The people that were originally hired as QA can't be expected to write Java or .NET code, because they were hired for their expertise in testing and quality assurance. Likewise, a Java or .NET developer can write high-quality code, but may not be familiar with the best QA techniques.
When you try and cross-task these specialists, you can end up hurting yourself since it can take more time for those who aren't familiar with another skill to learn it. And even when they do learn it, can they learn it to the level and use it with the precision of one of the specialists, who have years of experience? They can't possibly learn everything they should know within the context of an agile iteration/sprint.
So if a business has intentionally hired an "agile shop" where all of its members are experienced and excellent at both developing and QA testing, sure, let everyone work on everything. But if not, let the specialists do what they do best. Let the code monkeys write the code and unit tests and the QA team find the bugs and run regression. It'll probably save time, money, and headaches in the long run.