Software Engineer’s Blog

Software Engineering weblog

Are Developers good testers… and can test better than a QA guy…??

Following are my comments on “Are Developers good testers… and can test better than a QA guy…??” in Software Testing & Quality Assurance group in Linkedin

I continue to be a designer, programmer, and tester. My experience is:

Coding as a mix of translation, derivation, and synthesis; essentially a creative and optimistic track. Testing is an act of what I call a “constructive destruction”.

Slips from development are not, typically, intentional. My code is my baby and I would like it be the best… this is also cause, at times, for developer-tester chasm; question on my baby is considered as question on me.

Human mind is at work and it has limitations. Human mind works best on terrain it is familiar with. You train it on coding; it will adapt to that. You train it on testing; it will adapt to that. It is difficult to be both at the same time.

Again, typically programmer works on smaller unit, whether he/she is aware of and involved in larger picture or not. Focus of testing, therefore, from developer is restricted to that unit (or a similar unit from peer). This is and needs to be done

Testing of the whole software is different from testing individual unit. Perspective now has to change to whole system and its desired business value. Typically difficult for a person to be both at the same time.

If trained well, one person can do both, in two different points in time but details, perspective and approach needs to change

Advertisements

January 8, 2009 Posted by | Agile, Agile testing, Software Testing, Testing, Uncategorized | Leave a comment

A Tester’s Observations in an Agile Environment

Following are my comments on ‘A Tester’s Observations in an Agile Environment’ in Software Testing & Quality Assurance group in Linkedin

I have seen successful and failed agile environments. Problems occur when fundamentals are compromised.

Agile approach has put focus back on individuals, rather than process/documentation; quite rightly so.

Therefore, success in agile approach depends on motivation (very critical) and skill levels of individuals involved, team synergy and agility, and very short feedback/correction cycles. Quite ironically though, I have seen in many such projects go on downward spiral with process (I do not mean documentation here) getting ritualistic and viscosity setting in the team (may be, a human tendency). This happens over time, as project complexity increases, defeating the very foundation on which agile approach is built. Given the above, I consider effect on testing is natural and incidental, though disastrous; meaning, root of the problem lies elsewhere. I consider this tendency fatal, unless immediate remedial steps are taken.

I had been asking a stock question to many agile teams that I have come across. Question is, does you testers ACTIVELY participate in the meetings. On probing (and, only on probing), it comes out that testers participate but participation is rather ritualistic. They do not dare to ask uncomfortable questions. It is important to ask uncomfortable questions, even if sugarcoated, and get answers to those questions. After all, no one else but only testers can claim to know the software as it is (rather than, what it should be/have been), its shortcomings/pitfalls, testability issues

It does not matter to me, as a tester, whether answers (to the uncomfortable questions that I ask) come to me as documents or it comes from discussions but if answers not coming from project team, irrespective of methodologies, project is running on dangerous track.

Then, it is time for a serious jolt; a jolt from above. If jolt does not occur naturally, it needs to be made to happen. In my experience, I find that someone, somewhere is always listening. But we need to set alarm bell ringing!

January 8, 2009 Posted by | Agile, Agile testing, Functional testing, software engineering, Software Testing, Testing | Leave a comment