Testers are necesary in the same way as peer reviewers are. The authors of software are always biased towards their own work and blind for the flaws. And developers come from a rather small population of highly trained computer experts, while users usually come from a much broader audience. Software should be tested by a sample of the target audience or at least by a different social group than developers.

The role of tester is always needed to assure that your development fits your requirements. The question could be: who is in charge to define and run tests?

How automated are these tests? Could continuous integration systems get the role of testers?

There is quite a lot of discussion around this topic on in the "Agile testing" community.

Given the amount of people working that role and the amount of conferences on that subject (f.e. the http://www.agiletestingdays.com/ ) the role still has merit. Its focus just shifted.

Ten years ago you would develop a product or website, finish it, throw testers against it for a month, fix all the issues, deploy it and you where pretty much done. If the product was successful you'd schedule a version 2 to arrive in half a year and the testing team would move on to another project in your company.

Nowadays in the wake of continuous deployment and fast iterations the roles of testers changed a lot. It's not a "thing" you do once and then leave it but something that also has to be done continuously.

That means that testers need to be integrated a lot closer because it is just not feasible to meaningfully test a complete product every week, if for nothing else than the fact that there is no static "spec" to test against any more as behaviors change.

Without automated "testing" keeping a software maintainable is a very hard test so the question is if one should have people dedicated to the task.

So let's look at the role of an " Agile Tester"

> We define an agile tester this way: a professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development.

(Source: http://agile.dzone.com/articles/agile-testing-principles )

One workable approach for this is to make developers full this role, one is to have dedicated testers and I've seen people make their product owners write test cases / specs (cucumber) for features.

The decision on which approach to take, i think, depends heavily on the organizational structure of the company and how features are defined.

If you have completely defined and thought out features before you hand them over to the developers it's easy to have separate testers but the more work developers to in fleshing out the features while building them the harder it will become to communicate all the changes. Even so the added value (as in documenting what was build) also increases.

Nice answer, Volker. I only tend to disagree a bit on that 10 years ago testers were that isolated ("throw testers against it for a month"). I saw teams that had testers that would continuously test stuff along with feature development.

hi folks,

This is a good discussion with a lot of good points. Testing and assurance have certainly evolved from a less glamorous role to a pretty important one. As we automate the software development process, utilize incremental process such as Agile, reuse pre-fabricated components, etc. the role of assuring software product and the quality aspects of that integrated software becomes tightly connected to its success in the market place. Moreover, as customers' demand on quality increases, especially in mission critical or life critical situations, the role of assurance and testing becomes more than a technical role but a business critical role. Future testers and assurance personnel must understand what needs to be the "appropriate" level of quality before a software product can be released to customers and what are the risks and liabilities in releasing less desirable products.Thus, the testing assurance experts will also need to specialize in terms of testing skills, integratin skills, measurement and risk analysis skills, etc.in the future.

testing is the most important phase in software development , recalling software engineering life cycle , testing is the final phase .Software testing will be designed to ensure whether the system requirements that defined in the first phase are satisfied or not .

Test is a role. It doesn't matter whether you have the same people doing dev and test, but unless there is an objective measure of correctness (e.g., a mechanical verifier), you generally don't want the same person doing both roles for the same piece of code, because few people are disciplined enough to play the test role for their own code in an objective way. Moreover, these roles are usually kept separate because they call for different skills and temperament; a tester is supposed to be skeptical about correctness of code and its documentation, whereas developers are usually satisfied if they they understand the code and it smells right.

I second Ernie. :)

Addition,

1st. Isn't this the very reason pair programming methods born?

2nd. Sometimes we forgot that testing actually consist of 3 parts.

- Verification, Is this the right software? Basically we don't need specialized tester for this one.

- Validation, Are requirement / feature implemented right?Now the apps are deployed part by part, so responses can be localized per parts. For part level, sometimes you need expertise, and that is where specialized tester came in. For system level, may be you need a log tracer role for big project.

- Performance Measurement. For cloud web project, sometimes this already taken care off by provider, e.g., Azure

In summary, tester always needed, just the form are much more diverse. :)

I don't have the reference with me but it had been found having someone else read the code before is committed is the most efficient way to avoid bugs. It was also found effectiveness of this reading dropped off after one hour, suggesting an optimal amount of code for one commit is under 300 lines

Yes, no one can promise 100% error free software because of traditional risk assessment /risk-benefit analysis. However, it is critical that system performance is assessed by developing test cases that can match user requirements with systems functionality to validate how much of user requirments has been met by the software.

Testers are asking a different question than developers. Developers want to know "How can I make this work?" Testers are asking "How can I know this works?" As a result we can consider that developers are working on problems of 1st and 2nd order ignorance but testers are working on questions of 2nd and 3rd order ignorance. The testing job is quite difficult and often underestimated.

The "orders of ignorance" is an idea from Philip Armour (an ACM Communications contributor).

Here is my wording of the "orders of ignorance".

0th: I know something. I can do statistical analysis. I can speak French.

1st: I don't know something. I cannot speak Russian. I don't know how to operate a dental X-ray machine.

2nd: I don't know what I don't know. I don't know what bugs your product contains.

3rd: I don't know how to find out what I don't know. I've never tested a product for use on the cloud. I've never tested a product written in Ada.

4th: I don't know the orders of ignorance.

The answer is simple.. Why do we need exams ? ;)

It is the independence of testers that is important - if i cannot explain my program to somebody else who will walk away to test it, then i do not understand it - it is far too common for programmers to retain incorrect assumptions about their code that lead to seriously inadequate testing

the code should be delivered to the testets along with the definition of what it is supposed to do under nominal, off-nominal, and seriously weird conditions

if the testers can verify that all of those delivered definitions are sufficiently correct, then that code is properly understood and ready to be disseminated (and not otherwise, since the purpose of those definitions is to be shared with other developers)

In software development, Simplicity-of-Purpose and Top-Down technique are of great importance. This discussion about software program testers is just one of those HR attempts at defining who-is and who-is-not important in an organization. There are two areas of testing done on any software program. This first is Functionality Tests and the second is Operational Tests. Of what need is there to operationally test a software program that cannot do (FUNCTION) what it has been designed to do. So, Functionality Tests are normally carried on by developers, while Operational Tests are left for testers. Consider this case: a car engine must function optimally, otherwise there is no need in operating (using) it in the design of a car. The sad story is that developers and testers really don't know the different MYRIAD USES to which thousands of users put thier software products.

Do we need testers?

Executive Summary: Yes.

I have never seen a comprehensive test plan that did not find errors. The less the team thinks they need testing, the more likely it is that they need it.

A surprising amount of the world's software is unable to install and run at all. I just recently tested a code quality tester. Ironically, the code testing software was unable to run any of its own test cases. All it could do is display its usage screen. It trapped out (on Windows 7-64) immediately upon startup. I was aiming to test some code with it, but its obvious fragility did not give me confidence that the software code would give useful metrics. It could not even save itself.

Programmers test along pathways they expect will be followed. They typically do this in their own development environment. Code only tested under those circumstances invariably fails in the wild. The programmers least likely to release untested code are the ones most likely to be able to pull of releasing untested code, but they know better. That means the code that makes into the wild is typically of a lower quality overall and near guaranteed to fail.

A good test protocol that gives full functional coverage has a reasonable probability of succeeding (to an extent) on first release. Software that is tested as 'known good' along a certain pathway is likely to continue to operate on that pathway. It is my normal operating assumption that untested pathways are more likely to fail than they are to succeed.

Code that I released in 2001 (http://base64.sourceforge.net/b64.c) has been in production use all over the world for more than a decade. I was able to build, test and release without functional errors upon release and since that time no functional errors have been found. I had, at that time, been programming for more than twenty years, was modifying code from an existing research code base written by me and validated the code extensively, many times over with eighteen test cases giving complete functional coverage. It was a small utility to do Base64 coding, for which there is a complete function specification published (rfc1113).

Despite all the above advantages, the source code as released was imperfect in more than one place. Every one of those was an untested pathway. The issues were somewhat cosmetic, but there was an outright mistake in the initial documentation: The last correction to the file was done nearly ten years after its release.

VERSION HISTORY:

Bob Trower 08/04/01 -- Create Version 0.00.00B

Bob Trower 08/17/01 -- Correct documentation, messages.

-- Correct help for linesize syntax.

-- Force error on too many arguments.

Bob Trower 08/19/01 -- Add sourceforge.net reference to

help screen prior to release.

Bob Trower 10/22/04 -- Cosmetics for package/release.

Bob Trower 02/28/08 -- More Cosmetics for package/release.

Bob Trower 02/14/11 -- Cast altered to fix warning in VS6.

It is reasonably safe to say that you can never release a first time right source code file for non-trivial code. However, as can be seen from the above, it is at least possible to release code that is functionally correct, but only if you test thoroughly. Professional testers, by virtue of being professionals at testing, are likely to be better at testing than most programmers.

Yes, we do need testers to test the products developed.

Developers always build a program from their point of view, of course aligned with the customers specifications. But a tester when use the software uses it from the perspective of the end user and the work is not biased. And during this testing phase, comes the various intricacies of the product - may be in terms of functions, features, reliability, durability, load capability etc. which are either not conforming to Customer specifications or not at all incorporated. So, a tester actually is helping the developer to incorporate these in the product before it is being finally rolled out.

Now to have a perfect product, we refer to one with almost zero defects or minimum defect density or with some minor non-functional errors. This can be achieved only if we have a strategic Test Plan in place with real time test data and test cases. This is extremely possble as far as my experience goes. The test manager must prepare the Test Plan as per the Specifications or Requirement document and must be in full consensus for every details with the Project Manager or the development team.

And also after every incorporation, the tester must ensure to perform an iterative testing until, what we say, a perfect product is attained.

Yes, of Course, we do need testers to do testing, whether manual or automatic that depends on the requirements, resourses and many other factors