I was taught by a coding master to always design software in the beginning to log its own activities, and even better to allow for automated entry of test scripts (often in XML form these days). Doing so can make the life of everyone easier.

It is especially critical in production when something goes wrong and a precise log can replicate the problem and data, back on the test machine, where it can be single stepped. Then those “production down” problems can be shortened from days to hours.

The problem is that it takes a good ability to think abstractly and in strong Object Oriented fashion, to set up a system where either the normal client or a test client can be interchanged. And finding programmers with that kind of skill is rare to my experience.

Similarly finding testers who can think abstractly is a joy to me as a developer. They do an excellent job of categorizing problems and recognizing the commonalities in test cases. The #1 gripe of all programmers about testing teams is getting 17 versions of the exact same problem. Having strong domain knowledge is very beneficial to testing, but doesn’t seem to help on this issue.

“I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.”
- Albert Einstein

Influenced by the reading of Mary and Tom Poppendieck’s book “Implementing Lean Software Development”
I will say the following:

The job of QA is not to find defect but to prevent defect and both developers and testers contribute.

Defined this way, the QA team has a different position in the all process.
You cannot hire QA people that have no clue about preventing defects in a software.
The QA team members must be involved from day 1 in the design and development cycles making them equal with the developers.

On one side automated classes unit tests, automated user interfaces unit tests and automated end to end testing are required.
Test Drivent Development is even better if you can do it. (FIT is also very interesting http://fit.c2.com).

On the other side because you may not be able to prevent all defect, early manual (exploratory) testing will do.

But in the end it is the management (CEO, VP and director) that will behave as courageous and open leader or
will just play the political game of their company.

Frederic Torres
http://www.InCisif.net
Web Testing with C# or VB.NET

I will also attest to the fact that testing requires its own skillset and most developers need to be trained in basic testing skills. I hope we can continue to breakdown walls based on roles and share skills across team members.

>> Within five minutes I found the problem and sent back the new code that worked.

I’ve did that twice.

Once I wrote code to fix a problem that the biggest single customer was griping about. Development was thrilled that I helped and shipped my code.

Another time I wrote simple code to fix a long-standing bug in search code that resulted in complete word matches not showing up in results when partial matches were displayed. Everyone seemed to like the simplicity of my fix but some in development decided that it wasn’t my role to write code — it was the developers job. Last I heard, that bug was still in the code. (And that was many years ago.)

I agree that it really wasn’t my job to be writing code for developers. However, in both cases, I was involved in testing the application and data and had a better view of how it all fit together than the realtively new development team that inherited the products. I worked with developers in both cases. I believe the difference was my relationship with the developers of the two appilcations. I had a good relationship built on trust and respect with one of the developers and a not so good relationship with the other.

Developers often look down on testers as being less capable and don’t see testing as a skill independent of development. Testers often look down on developers as being incapable of writing good code. Rather than point fingers, we need to work together towards our shared goal of delivering good software on time.

It is very important that developers and testers respect each other.

I had someone submit code to me that didn’t work. After three rounds of sending it back with detailed descriptions of the problem — and each new submission was broken in a different way — I looked at the code and the stored procedures behind it. Within five minutes I found the problem and sent back the new code that worked.

He decided to redesign the whole report. My solution was clearly wrong, and only worked in the context of a “bad specification”. A specification that had been approved by the client. The response from the IT director was that I shouldn’t be “getting down in the weeds looking at code”; I should be submitting bug reports and letting the developers work it out. Then my DB access was revoked.

It only takes a few poorly written and incorrectly logged defects to put a tester behind the eight ball. Apathy towards the developer’s plight and demonstrated ignorance about software and systems is the nail in the coffin.