Cheese is moving again!

Landscape of world around is changing drastically with innovations like Sixth Sense, Project Natal , and multi-touch man-machine interfaces. Software is opening up new frontiers in collaboration. What is more, Cloud computing is changing the deployment and usage model of software taking it more towards a service paradigm.

I believe, these augurs well for the world at large as it brings technology closer to people. For me? I have different hats. Good for most hats but not so good for others

It is fascinating for the curious onlooker in me. It is good for my business as it provides new possibilities in improving my customers’ business. It is good for software developer in as I get to work with something new, different and probably even unique. It is a new challenge for the architect in me, as I grapple with the unknown.

It alarms the tester in me. I know, I will be in the middle of it in no time at all; even before the world comes to terms with it. The world understand the need for architect, developer and user to learn and adapt but the tester is expected to get into the situation and has to come to terms with it on their own. For instance, what are the techniques that hold good? Where are my tools?

Well, we like it or not, the cheese is moving. I am diving in…. better to be proactive than reactive, right?

Some observations on software testing and test automation practices

Following are my comments on “What do you think about the future of Software Testing?” in International Association of Software Architects group in Linkedin

Software testing was undervalued but no longer. Yes, there are people who undervalue software testing .

There is a tendency to overlook important of testing in immature software development environments. This typically happens in organizations or projects in a reactive (or worse, firefighting) mode. Immediacy of business imperatives in such cases being to churn out code (as if quality is of someone else’s concern….. An interesting thought in this line http://www.ibm.com/developerworks/rational/library/2800.html ).

Testing is an integral part of any development activity, and hence an integral part of software development as well.

Test driven development is a great way forward, it brings focus on testing quite upfront and makes it almost inescapable

I agree with the bottom line from Stephen with a minor refinement: Adherence to craftsmanship and good coding practices, plus the use of a good automation tool. I would also like to add agile values and principles to the list.

Refinement being “good automation” rather than “good automation tool”. What we need is automation, and tool is incidental. Purpose could also be served by in-house automation effort. In-house automation could also result in a tool. I am making refinement as purchase of tool generally comes with expectation of a “silver bullet”

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

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!