> 1. If any software boom is down first the Companies fire Testers.

Not always. I have been through two downturns. In one, the testers were downsized because the company was purchased by a company that wanted to implement more unit testing and so they eliminated all of the testing positions until they realized what a bad idea that was. They also released about half of the development staff, but they hired back about half the number that they released. They also hired back about half of the testers, which showed that our developers were doing a bad job of testing their own code. In another downsizing, the testers, who were doing a good job, were kept on to ensure that the product was still stable. So it depends on the company, and the testers.

> 3. In future comfortable tools are coming.

Really? I first heard that in 1989 when I started in the software industry. So I can finally focus on tools. When that day arrives be sure to tell me.
 

+++++++++++++++++++++++++++++++++++++++++++++++++++

Chris

Developers make lousy testers. While it is true that testing is undervalued in many development shops, shops that ignore the test process are doomed to pay for it in dissatisfied customers. It's a lot cheaper to find defects earlier rather than later.

Regarding test tools, they are improving, but they're not at a point where they'll replace testers. They are tools for testers. Test tools like the ones discussed on this forum require investment in training and staff to be used effectively.

It's your job to understand the role of testers in the development process and make sure that management understands your value. When you do that, your job is much more secure.

And in another post in the same thread, Chris gives answer on why developers can not be great testers

Developers 1) tend to be uninterested in testing - the good ones test as they go, but will feel it's fully tested when they turn it over for testing (i.e. they wouldn't have turned it over if they didn't think it was done and read) 2) They tend to be defensive about their own code 3) Developers tend to focus on positive tests rather than negative tests. They tend to focus on the basic functionality (nothing strange about that) but when faced with an unexpected user action they don't say, "Oh, I should have accounted for that, write a ticket." Instead they tend to say, "Why would the user do that?" and malign the stupidity of said imaginary user. It's not that
they're incapable of testing, it's that developer and tester are really two different roles.

It is anecdotal, but as others have asked, why have testers at all if developers are great testers?

+++++++++++++++++++++++++++++++++++++++++++++++++++

Vladimir

> Developers make lousy testers.

Really? I think opposite. Developers are best testers. The number of defects they find doing unit testing is bigger than the number of defects a tester can find on a system level. Besides the function, developers know the structure that helps them to design more tests for more inner cases (code branches, data structures, etc).

I will agree with you if you meant that developers, being biased, are not as good at verifying the quality of their own code, which is actually the case.

Another post in same thread

Just ask your friend how long he has been in the industry and how long the history of observation that he used in the analysis. The judgment he provided is so superficial that I would not even bother to argue ;) Anyway...

In the beginning there were no testers. Once the companies found out that people as not as good to find the issues in their own code or to judge on the quality of own creation, they started independent testing teams. In order to make those teams obsolete we need to somehow fix the minds of developers. I wonder how many generation and gene engineering experiments are required in order to foster such a breed of developers ;)

Tools are not and will not, in the nearest future, be a silver bullet. There will be robots generating simple tests, but any new application with new unknown structure or features will make those obsolete. So, there will always be people who will teach those robots on new things.

Testing is a mental activity. We experiment with the software as scientists experiment with things. Until it cannot be formalized, automated tools must have an artificial intelligence that is a much to that of a human. When such robots come to play not only testers, but developers will no longer needed too, because those things will be capable of writing the software ;)

+++++++++++++++++++++++++++++++++++++++++++++++++++

Mark

Developers make lousy testers;

* Because it's a seperate area of professional practice that takes practice, study and adherence to become good at
* Because thier thinking is 'keyed' to the items they've developed and not to switching gear and breaking it
* Because it's like proff reading your own documents, you miss something, usually the bleedin' obvious
* Becuase you can't solve a problem from the same logical level it was created
* Becuase developers want to develop not test
* Becuase there's 37.5 hours in a day and dev and testing to do, so it'll end up someone devs and someone tests

I'll be even more specific - Non-testers make lousy testers, in comparison to professional testers.

I'll buy the beer the day testers are fully automated, it'll be about the same time those development tools that eliminate developers come about.

What we do is more than observe the product remember, we test it, that's an active not passive tasks. It's also a slightly subjective, exploratory activity that doesn't lend itself fully to automagic tools.

We also have the ace card of Quality up our sleeve, which I would suggest is where our testing should be leading us. Delivering quality through the insight that testing provides is like watching a chess game. We can see the options but those playing are too focused on their perspective and 'keyed' thinking.

And in another post in same thread

To answer your question in succinct form, the future for software testing has never been better, the future is brighter than perhaps we suppose, it's brighter than we can suppose. Why?

1) If any software boom is down first the Companies fire Testers. Wrong. This assumes the situation as it is now or was in the past, as it is in this transitional state, but you're talking about what the future holds. So this statement is wrong. The ones at risk are development, probably more like Technical Authors or Support Desk. The value the business derives from testing is eminently improved the more difficult the economic situation becomes. The logic for this is because there is a need to maintain a share of a shrinking market where the differentiator would be price and quality. Testers are far cheaper than developers generally and in safeguarding quality are essential. Safeguarding quality ensures the total cost of ownership is reduced meaning a well tested product is a better investment. A product with higher quality means a reduced need for Support Staff there by bringing a greater saving to the business.

2, Developers can do our job + Coding.  Wrong. A simple reflection on the Division of Labour, Specialisation of Work theories will tell you that there will at some point be enough work and enough need for focus of effort by individuals who are particularly experienced in testing, to need people who's specialisation is testing. Turn this around, can testers also code as  well as developers? We would always say No to this, we understand their specialisation, experience, etc. lend themselves to being developers who can test, just as it does us being testers who can develop. But the two professions are not fully inclusive.

3. In future comfortable tools are comming.  Wrong. This has been spoken of for many years and even the best of the Record and Playback tools fail at encountering the simplest of issues. This is the same logic as for the robots running their AI cleaning my house and making me a cup of tea as I type... I still don't have one. Even if we accept the suggestion that these tools become so all powerful they are acting like a tester, who's going to configure, run,
maintain, mature what they do? Is this person by definition not a tester?

4. No investments on the Testing more?  Wrong. The very act of investing in the above in a desire to eliminate the tester is by its nature investing in testing. If we accept that the paradigm of how we currently define 'tester' will shift then you'll not get rid of testers. Again, what will happen is the boundaries between tester and developer will blur. I maintain it's the
developers who are at risk in many areas.

All of the above statements your Team mate made are based on the current paradigm of what a tester is. They are looking at what they understand the tester of today to be and in doing so are making statements about testers that were essentially existing yesterday. Being in the profession we're aware that the days of just hitting keys and clicking the mouse are for the greater part over. Today's and tomorrows tester is a much more technically savvy professional. They can develop test harnesses, stubs and drivers written in and interacting with a variety of programmatic languages, author complex data sets, work in an integrated manner with Agile teams on a level that blurs the boundary between tester and developer, use highly complex tool sets testing across the many components of the global  system architecture and much more. Today's and tomorrows tester is a professionally educated, examined and accredited professional, including but beyond that of a general computer science degree and some courses that a developer may typically have and soon potentially a member of a Chartered Institute. Putting them at the same level as Architects, Lawyers or HR
professionals.

The key hitting monkey of yester year now uses techniques grounded in complex statistical and analytical mathematics, cognitive psychology and some of the best scientific research covering everything from computer technology to human logic.

As I said, the future for software testing has never been better, the future is brighter than perhaps we suppose, it's brighter than we can suppose.