Fractional distillation and software testing...

Fractional distillation is a technique that separates the various constituents in a mixture utilizing the differential boiling points(BP) of the individual constituents. As the mixture is heated, low BP constituent  is removed from the top of the distillation column while the high BP constituent  is removed from the bottom. 

Very similarly, the software under development has  a “mixture of various types of defects”. Our job is remove the each specific instance of the various defect types from the software. Akin to how we see a fractional distillation column consisting of multiple filtration levels, visualize test cases as a column segregated into various quality levels, where each quality level denotes a point where certain types of defects(aka constituents) are removed. Quality levels are like milestone markers in the final destination of software-under-development to the "good-enough quality" destination.

A clear organization of test cases by specific quality level allows us be purposeful and enables us to see the quality growth of the system under test. It allows to optimize test effort by ensuring that we minimize back-tracking. 

have a great day!

Ashok

Normal and Special occasion - A matter of time.

Yesterday my younger son who is attending a summer camp had an overnight stay at the campsite. The organizers organized a pot-luck dinner and the parents too were invited for the dinner. The children were having a blast, and it was wonderful to see the energy in each child late in the evening! The children sang songs, danced and then finally sat around in a big circle to have dinner. Each child took turn to go around the circle sharing his/her food with each one seated in the great big circle -  it was indeed a beautiful sight. For the parents, it was a wonderful dinner, with a variety of dishes from all over India.

All the children were enjoying the dinner, it looked like an extended family. A friend of mine keenly observing the proceedings commented:

 "When we were young, we  went back to our hometown for holidays and occasions like these were a pretty normal affair as all relatives landed up at the hometown too. In the urban setting, eating with a large group of friends is a special occasion. On the contrary, what is normal for the today's child was indeed special for us! Buying new clothes, going to a movie, getting new toys,  were tied to special occasions in the past."

An interesting observation! As we urbanize/modernize, simple things that we used to take for granted in the earlier days are becoming special, and what was special then is becoming normal. As we complicate things now (though we like to believe that we are making things better with new technology!), the most simple things fade way and become memories to cherish. Alas, the newer generation never encounters some of the simple pleasures!

In a conference in US that I attended last year, the conference person after outlining the agenda for the day, said they have designed special breakout sessions to enable the participants to network. He said "Do not use SMS, Email, Facebook, Twitter...", the audience had a perplexed look on their faces. He sensed that,  and keeping a straight-face, said slowly & loudly "Walk up to a person and say H-E-L-L-O. It is called talking".  Everybody had a hearty laugh!

Enjoy the simple things of life.
Have a great day.
Ashok

New technology, open platforms and mediocrity.

I had an interesting discussion with a good friend of mine on the state of programming and programmers yesterday. The discussion started with him showing me his new Android phone, and then the applications on Android. This friend of mine is a seasoned software engineer, he develops code for communication systems (stuff that is expected to run correctly always), he believes in thinking deeply first and then coding. He started by lamenting on the code quality being churned out now, by stating that quite a few applications on his Android phone shutdown midway. He was critical, that now anyone is able to write applications and able to deploy this on open platforms like Android, fostering mediocrity. 

The last decade has seen a sea change in technology, languages and application development platforms. The languages and technology allows us to do more and powerful things now, and the development platforms seems to make this easier. This is allowing more people to develop applications individually. The flip side is that the rigor of good code is being lost, as we have anybody with a smattering knowledge of programming, churning out an application. My friend was wondering what would happen if these kind of people get to program large scale non-stop programs like telecom switches. My comment was "Intent of good technology is to make stuff simple i.e. allow ordinary people to do more". This is happening. Now the question is "Where is the boundary - How far can this 'ordinary' person be allowed to go?' . My take is that we need to careful here.

Think about this: Long ago, long distance transportation was by ships and required skilled sea-farers to steer the ship. Then came the personal transportation - automobiles. This allowed anybody to go anywhere (on land!). Also, air planes allowed us to get a distant place quickly, but this requires skillful pilots. What am I hinting? As transportation technology evolved, it allowed ordinary people to drive and transport themselves, but they cannot "drive" the airplanes or ships.

We understand philosophically that scale and quality are more often inversely related i.e with scale, quality degrades. Of course, one can argue otherwise. What is important to note is that our expectations on quality of a product has changed over the years. If a product is cheap, we do not expect much them and therefore are tolerant to crap. In the past however, quality was a "intrinsic" notion and not necessarily linked to the price of the product. Guess the producers had pride in producing the product, which I believe now is not very common. 

"Pride of work", "Passion for excellence" are key ingredients for producing good stuff. No technology can compensate for this. We live interesting times, new stuff happens everyday. Our expectations are shifting  from  "intrinsic goodness" to "economically acceptable good-enough" . This scares me, will we accept mediocrity as a way of life? - More features and stuff, it is OK if some do not work!

Have a great day.

Ashok

Seven consecutive errors = A Catastrophe.. (Improving testing)

"A typical accident takes seven consecutive errors" quoted Malcolm Gladwell in his book "The Outliers". As always Malcolm's books are a fascinating read. In the chapter on "The theory of plane crashes" , he analyses the airplane disasters and states that it is a series of small errors that results in a catastrophe. " Plane crashes are much more likely to be a result of an accumulation of minor difficulties and seemingly trivial malfunctions" says Gladwell. The other example he quotes is the famous accident - "Three Mile Island" (nuclear station disaster in 1979).  It came near meltdown, the result of seven consecutive errors - (1) blockage in a giant water filter causes (2)moisture to leak into plant's air system (3) inadvertently trips two valves (4) shuts down flow of cold water into generator (5) backup system's cooling valves are closed - a human mistake (6) indicator in the control room showing that they are closed is blocked by a repair tag (7) another backup system, a relief valve was not working.

This notion is reflected in the book "Ubiquity" by Mark Buchanan too. He states that systems have a natural tendency to organize themselves into what is called the "critical state" in what Buchanan states as the "knife-edge of stability". When the system reaches the "critical state", all it takes is a small nudge to create a catastrophe.

Now as a person interested in breaking software and uncovering defects, I am curious to understand how I can test better. When we test a software/system, we look forward to uncovering "critical" defects. When an error is injected to system and it propagates all the way, it results in a failure. All failures are not critical, some are irritating deviations, while some can be catastrophic. If a  simple error injected results in a critical failure, we are lucky! How the heck do we know that similar catastrophes will not surface over time. Should we not think using the above reasoning? i.e. occurrence of consecutive errors each resulting in a minor failure, ultimately culminating in a critical failure. Should we not have a variant strategy for uncovering such "potential catastrophes" ? Do we outline the strategy that is indeed different for simple failures versus potential critical failures? When can we apply it? Not necessarily only when testing... This thought process can be applied in the earlier stage of design/code... Using the notion of sequence of errors and understanding what can happen.. 

If your drive in India you know what I mean ... the potential accident due to a dog chasing a cow, which is charging into the guy driving the motorbike, who is talking on the cell phone, driving on the wrong side of road, encounters a "speed bump" , and screech *@^%... You avoid him if you are a defensive driver. Alas we do not always apply the same defensive logic to other disciplines like software engineering commonly enough...

Happy weekend. Be safe.

Ashok