I also agree that there is a lack of education and understanding about the testing profession, and I’ve also wondered if the solution will come once we start seeing respectable degrees on software testing on some colleges and universities (somehow my gut feeling is that this is still too far away).

I also share your conclusion that (1) we are definitely not out of the woods, and (2) we are lagging behind our development counterparts.
On the other hand, it might be my blind optimism (about which I posted on one of my earlier blogs) but I think the par is closing, not so much because devs are getting stuck but because there is a positive and constructive momentum around testing.

The problem is that we will need perspective and time to judge, and for now we can only talk about subjective impressions

The main problem still to this day is a misunderstanding & misconception of what it is we do as part of this work. This occurs by both people within testing and outside of it. There is still a stigma and mystery associated with Testing.

The problem stems from both an academic and industrial line of thought that is faulty. Meaning tesitng is not very well taught in Colleges, or at all in some instances. Thus you have an ignorance by the new breed. Also, because of that same ignorance a lot of older people in industry do not fully understand the testing function. Unfortunately Software is one industry that hasn’t caught the clue like others have. I know, I’ve seen it many many times. That is why I consider part of my job as being an educator for my line of work.

Now a lot of the techniques that Agile uses (Unit Testing, ET, collaboration, sprints/iterations, etc.) are really nothing new and were in use to some effect before 2000 (actually some of it dates back to the 50’s/60’s). It was just not practiced often or forgotten (especially by the Cowboy programming style on the PC in the late 80’s), and now we are having to “relearn”. Also, this is a give me, the tooling to support the tasks were not there. So the last 10 years has shown improvements from a technology implementation standpoint.

But process and methods have remained relatively the same. Keyword Driven Automation (known originally as Action Word based automation) was invented in the early 90’s by Hans Bulwalda. The first object recognition methods were in place in tools in the early 90’s, but the idea of a GUI Map or Object Repository didn’t show up until about 1994 or 1995 with Winrunner. In 1992 I was using an automation tool for OS/2 GUI tesitng that talked to the objects (or controls as we called them then) on the window form via its Control ID or Name. There was still R/P, but for those of us who caught on early we were doing things at the object level and building automation functions/frameworks that drove the application and our testing. There was the problem of the R/P snake oil that a lot of us dealt with, but we learned valuable lessons we still call on today.

So, have there been advances? Yes, but there is still recurring problems from the last 20+ years that we deal with. We are not out of the woods and on the same playing field as our counterparts in Development. That is what will be interesting to see how it advances in the next 10 years.

Awesome stuff. Thanks for the sticky. I must admit I also enjoy the interaction with customers. One thing I missed off my sticky note.

Rob..

I am sure you are not one of those, and the greater good you talk about also helps you to step forward after testing a well written app and say out loud that the dev team did a Superb Job!

Trying to agree with Sandi I will add a small addendum saying that a good optimistic tester can have a believe that an application will work out fine by the end of the day, but when she puts her “testing globes” she look for bugs in the places where she would expect to find them.

I differentiate between my personal optimism and my testing professionalism.

Hmm, that worries me a bit.

We usually find what we are seeking. Thus, if you are expecting everything to work, it often does. If you are expecting things to break, they usually do.

Wouldn’t you want the people charged with finding the breakages to expect to find them?

Difference between optomist tester and pessimist tester – the first one comes to work believing today is the day everything will work and the other comes to work knowing today everything will be broken. Which would you rather be? Optomist for me.

Few folks would call me an optimist, yet believing in “the greater good of his team, his friends, and his company” is what brings me here every day.

http://www.sqablogs.com/jstrazzere/1819/Optimistic+Developers%2C+Pessimistic+Testers.html

-joel