Testing the Testable

Just thinking ..... on a different note

2011-12-07T21:13:00.000+05:30

Was reading something on greats like Plato, Aristotle etc. today. It described about their lives, works and other aspects of their existence. There was so much of mention about how each aspect of their life is understood and interpretation of what proof led to this understanding.

Suddenly a thought came, how will people of this generation be understood few centuries later?
We, in this generation have moved away so much from paper. We love our small machines and prefer to do most things electronically. We also chat in our local languages using English to represent it.

I actually just do not remember when was it last in recent times since I have started working that I used a proper paper and pen to write something that I really want to represent as my individual thought. Whenever I feel like writing my first choice is type off and so I am sure do many more of us. So are we leaving any footprints for our future generations or just leaving a space for them to re-discover everything all over again.

Huh! something to worry for future?

As I type this post, I also get reminded to think about India's glorious past.
for example -

If you read Ramayana, there are instances like the 'vimana' in which Ravan took Sita away and later Ram and Sita returned to Ayodhya in. Was is anything different that modern technology planes or helicopters?
Both Ramayana and Mahabharata have so many 'astra's' and 'yantra's' used in war. How different are these from our modern day missiles?
'Muni-Rishi's' just taking some water in their hands from 'kamandals' and creating blessings or curses.
'Narada Muni' travelling across worlds in seconds. Was this not teleporting?
'Trishanku' hanging between stars of 'saptarishi mandal'. Was this not related to managing gravity?

And are we not re-discovering these all over again now coz the world did not have the technology transcripts?

Make a difference : Bring an edge to your project delivery ! [My Learning : #1]

2011-11-26T20:50:00.000+05:30

[My Learning : #1]

How can you do more efficient project delivery ??
There are many instances when projects go in crisis. Mostly the crisis situations fall into 2 categories

Either the client expectation is not met on time or
There are delivery quality issues - in other words client expectation is not met

A general observations that I have had around where slippages are mostly hapenning and can be easily corrected with more focus and attention are

Requirement Freeze - Ensure that the requirements for test are clearly defined and signed off from all stakeholders.
Code Freeze - Insist on a code freeze from Dev team and deployment to QA environment that is completely stable.
Dedicated QA Environment - Ensure that a dedicated QA environment is available with latest and stable build deployed for testing. During the period of a testing cycle, this code should not be updated. Have all the release notes available handy against each new code update deployed.
Risk Based Testing : The approach is one of the better ones to start testing on. It can be either used as a direct approach or can be used as a parallel approach to exhaustive testing that needs to be undertaken. It also helps to prioritize and build a strong traceability avoiding defect slippages.
People Dependencies : People are the biggest keys for successful project deliveries. Understand the key people in your project. Understand what they are involved with and what are they doing. Help them improve with your experience and do better.
People Competency - Invest in your people and their competencies. Give them space to develop their skills and create scenarios where they can upgrade and learn.
Reaction – only after crisis - Do not react only after crisis has hit you and you get into either multiple blame games or cover-up activities. Pay close attention to track deliverable against expectation matching for cleaner output in sync with desired client expectation.
Role of a Team Member as a 'TESTER' - As a tester, don't be a checker be a tester ! Try unconventional testing. Look for avenues to do the exploratory. Keep a keen eye open for critical defects. Bring in a thought process as end user. This will help you crack the hidden issues and potential defects.
Role of a Team Lead / Test Manager - Be innovative in building your test strategy. Gather your application / product details technically as well as functionally. Show your team members how to be innovative in test approach. Build your test oracles strong. Do not hesitate to ask questions. Neither hesitate to insist on logging an issue and not sweep it under carpet on behest of development team.
Role of a Manager - As a manager don't just sit there and watch. Only metrics numbers will not give you a better and cleaner tested product or app. Don't also just fall into the trap where you feel that few web apps and trackers that you maintain or the jazzy reports that you can stir up with MS office packages will take you and your teams to places with clients. Make your hands dirty along with your teams and lead from front to deliver a better tested deliverable.

Lessons of Learning : from leaves of experience

2011-11-26T20:22:00.001+05:30

I intend to start writing a series of posts that will be in the tag line "Lessons of Learning - My learning #".
These will mainly be focused around my experience in life as I have evolved through my journey of testing experiences.
These will primarily be short notes to start with and will slowly grow into bigger writing pieces.
Will look forward to comments from you to add on your experience leaves to the same :)

Experiential Learning

2011-05-15T11:33:00.002+05:30

I picked up a new mobile handset some weeks back but did not have time to configure it up due to free time unavailability ........ started to do it in bits and pieces....managed to set up a few basic accesses.... finally realized that there is an issue when I try to access mails. It just refused to open up any of my mbox ..... tried many approaches, mobile store and googling too but was just NOT getting the appropriate info to set it right..... I was so irritated at the user unfriendliness and was wondering if it was worth spending the bomb of currency notes on it ....

Then I remembered that AJ had a older version of a similar handset, and this weekend (14 May 2011) when I pinged him, I asked him if he could help me on....... and there started our virtual paired testing :)

We set onto identifying what he had on his handset over skype chat and I tried to see if I could replicate or find some near about alternative to what he was suggesting ........ he built up scenarios for me based on his user experience and I tried to see if I could replicate it over my new handset with new functionalities and modules..... visa-versa I told him of my user needs and he tried to initiate it on his cell and tell me the scenario which I again tried to replicate.
The first trap I unearthed was that I cannot access coz the software's pre-installed on my handset are old ones and the new apps don't support them any more. AJ suggested that I needed to set up an application that will help me access all that I needed from a single screen. AJ further suggested I use snaptu for it as he found that very comfortable. He sent me a link and I downloaded and installed it up.......it was an older version and after installation, I had to again upgrade it up...... but then started my series of unearthing multiple user unfriendly scenarios and setting each one of them up as per my need......

The worst of all traps was that my logical thinking and the way the mobile functionalities are mapped had no sync. For example : I assume gmail to be a social networking, but the system accepts it as 'utilities'.... with this experience, I expected hotmail also to be 'utilities'..... but found it is under 'entertainment' .....yahoo mail and You Tube was also found there .....
Also found that Yahoo and Hotmail were listed under 'news' too :(

Long and short of it ... had to really spend time looking for navigations that were not so logical in approach ....

And finally after 3 weeks of buying the handset I am operational in mobile over my required net access on the move :)

Does it help being / (posing) as ignorant ?

2010-10-02T20:01:00.000+05:30

Surprised to see the title ??

......the truth is "YES" it helps ...at least my experience says "YES" for me.....

Learning :

As I started growing up the career ladder, my responsibilities started to take new dimensions professionally..... and a very important lesson I learnt with this progression was to retain my urge to learn and learn more.

The day ego takes a higher place and you think that now you know most of all ....... you start your down fall on learning..... this also impacts on you holistically as a person as you are closed towards imbibing anything new coming your way.

One of the key approaches I take today towards new projects coming on my plate is to reuse my existing knowledge and experiential learning. The second is to improve on my existing knowledge.

Traps :

But much before I took to these approaches as practice, there were some attitudinal traps that I fell into. Some of them were

I know it all :
What new can I learn beyond this ?
Everything is similar in this field, what will be the new challenge ?
If I can do it one way, I can do the other too

Relating it practically as -

As soon as I see a work item-I think this is easy job and 'X' # of artifacts and learning's from my last project can be reused here. No considerable thought at start point was given to the rework involved in customization of these reusable artifacts
Oh! this is so easy and similar to what has been handled earlier by me
This is the same old technology what can be the challenge here ?

Believe me ...... once the project started and we started to get deep into work ...was when I realized that though things are similar; use same old technology but the implementation and the legacy system handling always makes it different. To add to the complexity is the system architecture which will define the complexity in its own way.
Many a times I also realized that reuse was futile and total waste of effort trying to re-engineer. Ultimately it was only my learning that helped me craft and structure things better in the new environment.

An approach of playing "ignorant" also helped me ask most of the wrong questions at the right places and hence helped me identify my roadblocks much in advance than I actually would have.

Now ....big or small ...new or old ......each time I get something on my plate.....
My approach is the same ......
Oh!! new work..........Let's EXPLORE !!

..............and I am still improving and working on sharpening my skill sets.

The Pear Tree & Testing !!

2010-09-30T20:10:00.001+05:30

An interesting story I read recently and it relates so much to the testing .........
If you are passionate about testing ....you can relate every word to some activity you do as a tester ....including the lessons learnt !!

The Pear tree!!

There was a man who had four sons. He wanted his sons to learn not to judge things too quickly. So he sent them each on a quest, in turn, to go and look at a pear tree that was a great distance away.

The first son went in the winter, the second in the spring, the third in summer, and the youngest son in the fall.

When they had all gone and come back, he called them together to describe what they had seen.
The first son said that the tree was ugly, bent, and twisted.
The second son said no it was covered with green buds and full of promise.
The third son disagreed; he said it was laden with blossoms that smelled so sweet and looked so beautiful, it was the most graceful thing he had ever seen.
The last son disagreed with all of them; he said it was ripe and drooping with fruit, full of life and fulfillment.

The man then explained to his sons that they were all right, because they had each seen but only one season in the tree's life.

He told them that you cannot judge a tree, or a person, by only one season, and that the essence of who they are and the pleasure, joy, and love that come from that life can only be Measured at the end,when all the seasons are up.

Lessons learnt :
If you give up when it's winter, you will miss the promise of your spring, the beauty of your summer, fulfillment of your fall!!

Don't let the pain of one season destroy the joy of all the rest!!

Don't judge life by one difficult season… don’t judge a person by one single incident!!

Managing Traceability - yes / no ?

2010-09-30T19:38:00.002+05:30

In my opinion, managing traceability is difficult especially if the product is very complex in architecture.

Though it is tough, I do not perceive it as impossible.

The only place this falls through the cracks is when the product starts to grow and people do not have time to maintain or reuse it efficiently and effectively.

One of the easiest ways to maintain it for the benefit of all groups in SDLC is to maintain it centrally. Have a few people team working very closely with architects who track each and every impact.

The methods to track can be either through something as simple as an xls or through various tools available in the market. BPM and BPT(Business Process Modeling and testing) can be one option.

A small tracker will need to be maintained further as a subset of traceability tracker to know proper coverage of: Positive tests, Negative Tests, Performance/Load/Stress, usability... etc ..etc based on your needs.

Learning's from Interview Board

2010-07-06T00:42:00.000+05:30

Read an interesting post from Pari http://curioustester.blogspot.com/2010_07_01_archive.html
it reminded me of many interview panels that I have been part of ........
It is always so easy to be on the other side of the table ....you can ask anything and pass off with it.......and that is the imagination with which many an interviewee walk in ....... (BTW - I usually interview people with 8+ yrs of experience only)

Just like Pari resorted to asking a potential employee (I prefer referring them so till I do not reject them officially post an interview :)) if he could test a marker ....... I have used many similar simple examples like a coffee vending machine; swipe in/out machines; login on a home page; etc

People are usually caught by surprise coz they come prepared for heavy questions with equally weighty answers :)

Where does it helps me ?

To identify a genuine testers and ensure not a checker is hired
Identify the concepts of the person
Identify the gaps that he brings to table as a heavy weight in his thought process

Few easy areas (read traps) where people get confused and easily get caught are -

Metrics and Measures - What are they collecting and reason to have them ?
Software Testability and Usability
Test Scenario and Test cases
Test Oracle and Test Heuristic
Why Automation ? - When and where to use it ? What is the thumb rule to decide on automation ?
What are they doing now in their current job profile and why are they doing so ? Why did they not use an 'XYZ' approach ?
Reliability of their test cases
..........

[You thought I'll leak my complete questioning skill here ;) ...who knows when I'll interview you next !!]

Long and short of it .......we seriously lack thinking testers amongst the community .......... there are also people who have achieved a lot but will still struggle when subjected to such questions ....

The testing community needs a lot of change in thought process and we need to be the change .....

Negative and Positive Test Cases

2010-07-05T17:02:00.000+05:30

It was interesting conversation between James Bach and Michael Bolton last week over twitter where the topic was focused around - Negative and Positive Test Cases.

One of Michael's comment "When you read a newspaper, do you *count* the stories? Count good news stories vs. bad news stories?" ....made me think why we as testers get swayed to the thought of classifying our test cases in such a manner .......

Yes, when I read a news paper ...I do not classify my stories nor count them but then what becomes so different when I write test cases ???

Putting my test manager's cap, the few immediate things / reasons that came up -

How do you ensure that you have your test scenarios totally covered ?
Can you maintain an exhaustive checklist ?
Or is it easier to classify them as negative and positive for the team to build easier understandability around what is expected from them ?
Does it take me away from micro management ?

In my opinion the completeness of test cases covering a scenario is bound by both the negative and positive aspects required to test. So based on my experience and assumptions I feel that it is the ease of tracking that has got these terms of negative and positive in the scene and somewhere the thought process got lost and it started to become more of a process meant for tracking and keeping a count rather than measuring the value add in totality.

Gracious Jon Bach

2010-06-26T18:28:00.000+05:30

How many people will have the courage to own up against their perception and post a blog titled " To India, an apology"............. This blog note from Jon Bach is a gracious post that explores his perception handling on Indian Testers and how he overcame it ...

Cudos Jon !! I appreciate !!

Proves only 1 thing ....If you want a solution to any problem, you'll always find one ..........If you want a change, be the change yourself.

Read the blog post at Jon's page at http://jonbox.wordpress.com/2009/12/17/to-india-an-apology/#comment-347

To India, an apology

By jbtestpilot

I’m back.

At the behest of a colleague named Lanette Creamer (a fantastic blogger worth following), I just went ahead and decided to just get busy, just get over myself, and just post an entry.

A few things went through my mind as to what to say after such a lapse, but the ideas seemed shallow — pet peeves, annoyances, ramblings, diary stuff. Nothing worthy.

Then I thought of Lanette’s reliable, refreshing honesty and openness in her blog, and the idea came out of nowhere.

An apology.

To testers in India.

And here’s why…

For years, I put you in a box and closed the lid. I labeled it “Indian Testers” and shelved it, thinking I knew everything I needed to know about you. It was easy to do this. For years when I worked for a local (Seattle) test lab, you were a competitor. I believed what others said about you because it made it easier to believe that the lab could compete with your testing companies despite being lower cost. Even though I left the lab last year for a bigger company with more challenges for me, I found out a few months later that you were replacing me and most of my staff, taking jobs away from my country when we most needed them.

Nevermind that it was not your fault, nor that the few Indian testers I had worked with in my 15 years of testing were pretty good. I dismissed that as an anomaly. Besides, those testers lived and worked in the United States. I considered them “American”, and let that other folklore rule my perceptions about testers who still lived in India.

Folklore said you had no passion or skill or curiosity or personality. Everywhere I went, people agreed. They said you were too compliant. You appeared to do only what you were told, and you always seemed to agree and understand, nodding your head and saying “yes, certainly sir.” You only wanted the software to work (not to fail) and your shallow tests only confirmed that.

So like the others, I tended to see you as commodities and machines. You were only good for running easy conformance tests that required no skill — good for tests that no one else wanted to do. I would see short, strange emails from you that said “Kindly send me a sample test plan for the testing, please.”

This was more evidence for me that Indian testers didn’t think outside the box or have much imagination. They were not critical thinkers. They stuck to the test procedure, even if it was badly written. They wrote bad procedures themselves. They didn’t ask questions. They didn’t take initiative. They said yes to everything and rarely lived up to promises. While very polite, they had the “no problem” syndrome. They did not push back when something was difficult, or impossible.

In May when I last wrote a blog in this space, the company I worked for announced layoffs and told us that we had to train our replacements for the next few months. In that time, the new Indian staff would have to be as good as we were even though most of my staff had many years of experience with the product.

As a trainer, manager, and coach, I had fun teaching technical skill and product domain knowledge. But what I CAN’T train is curiosity. I cannot train someone to have a hunger to learn and discover and explore. Either they have it or they don’t. After all, remember that the folklore told me that companies who went to India to outsource their testing were coming back because of the poor quality. The trend even had a name — “backshoring.”

When I was told about the layoff and told I had a few months to train my 3 teams before our exit from the company, I knew the transition was not going to go well. The Indian replacements would surely fail, and my career would go down with them, I was sure. It was not a good time to be a test manager. There had to be a way, but I couldn’t think of anything. Maybe by being a son-of-a-bitch boss, I could take these Indian folks and scare them into being good testers. It was against my nature to do that, but I had no choice. I didn’t know how else I could turn people who didn’t want to learn into those that did.

A month after the layoff announcement, I was right. The transition classes for one of my teams’ projects had started, and the Indian testers were mechanical and uninspired. They asked few if any questions despite the product being complicated. When asked if they had questions, they said no. It was going badly, right on schedule, just as I had predicted, just as the folklore said it would.

Just before the transition classes were about to start for another of my project teams (the biggest and most complicated), I learned about a class available for whoever on the team wanted to go. It was called “Doing Business in India”, taught by an outside firm. I was too depressed and burned out from training the previous day to do any real work, anyway, so I figured I go to the class and have an onsite “vacation day.” The class would surely be full of boring, useless platitudes – a great place to escape for awhile. It was a free day away from the rigors of transition of our work to India, at a time when my great staff would soon be out of a job.

I felt like a problem child in that class. I sat in the back row and defied the guy to teach me anything. This wasn’t like me at all, but on this subject, I thought I knew what I needed to know about Indian testers.

But he did a strange thing. He did not talk about platitudes. He explained that he had been a cultural anthropologist, having lived and worked in India for 25 years. He talked about why the generalities and perceptions of Indians were so pervasive. He validated my perceptions, talked about their history and why they seemed to be so complicit.

I went up to him at a break and told him more about my perceptions (listed above). I eventually said “Listen, I just want one thing from this class: tell me the key to unlock their souls.” I smiled when I said it, but he seemed to know that I wanted his help to break through the veneer of their politeness and complicity to expose if they had real personalities and talent like the few “American-Indian” testers I had worked with.

I was being glib, but he answered me plainly.

“Such a key does exist, Jon,” he said with a serious look. Then he looked away. “I’ll mention that when we reconvene.”

And true to his promise, when class reconvened, he said: “If American-cultured testers are 80% business and 20% personal, flip it when working with Indian testers. Focus a LOT more on the personal than you ever thought you could stand. You’ll get the productivity you want.”

He was talking right to me. He almost dared me to try it.

So in defiance, I did.

When transition started for that bigger, more complex product – ushering in a new group of Indian testers — I took them team to lunch. It was July 3, the day before Independence Day. I asked them about Indian independence. The talk quickly turned to ideas of freedom and culture and … well, marriage. After all, weren’t all marriages arranged over there? How could that be freedom?

Even though one of them was from an arranged marriage, another was from what they called a “love” marriage. That surprised me. I asked each of them to tell me more about that. The one in the arranged marriage said “You grow to love them.” Being married for 10 years, I had to admit that I understood that. There are things about my wife that I have grown to love over the years, even though it did not start out that way.

He later said that his wife was joining him the next day, and what he said next surprised me.

“From what you said about your Independence Day in the United States, when my wife arrives tomorrow, it will not be Independence Day for me.”

I didn’t understand at first, but then he smiled. Ah, a joke!

As a married man, I got it. And right there, I had my first success. I saw a personality under the veneer, and I liked him right away.

The next day I went to my other team, the one I was not having much success with. I decided I would start over. I gave one of them a task. I agreed to learn something I thought he might be interested in – cricket – in return for him learning our product – a database for attorneys and other legal professionals to store and review legal documents. I made him a deal: build me a database (using our product) of documents about cricket. He learns the product, I learn about cricket – same database. He said yes and that it was a fine idea and smiled.

I asked the other tester to do the same. He reacted flatly. Then I caught myself.

Ummm, maybe not ALL Indian testers like cricket…!

So I asked him. “That is, if you’re interested in cricket.”

He said he was not, but that he would do it anyway. As I walked away with the first guy (the one who complied), I said “I guess I blew it there. I should not assume everyone likes cricket.”

“Oh no,” he replied. “Anir loves cricket. He was messing with you.”

I couldn’t believe it. That little event was yet another key turned in a lock, showing me promise of a personality and productivity, and it happened in an instant.

That little idea started a chain of other small ideas.

I had a room full of Indian testers who had just flew in the day before. It was 8:00 am in a new time zone. It was hard for *me* to get up early, much less think about flying across the world the day before.

So I put a 3 ft x 3 ft map of India on the wall so they could each tell me where they were from. As the pushpins were going in, a magical thing happened. I realized India was a BIG country. Next to it, I put a map of Washington. Then it dawned on me – most of Washington they would never see. Yakima, Wenatchee, Bellingham, Long Beach, Spokane, Moses Lake, Orcas Island, Mt. St. Helens. Politically, Washington is mostly a “red” state, mostly Republican. The Seattle population, however, skews it so that Washington is almost always considered a “blue” state (Democrat) in national elections. They wouldn’t know that.

Then I thought of Seattle. There are parts of Seattle that are wealthier than others, that have different value systems. Capitol Hill tends to be liberal. Beacon Hill is conservative, and they are a mere 3 miles from each other.

It stands to reason then, I thought as I looked at the map, that India must be the same way. Maybe a tester from the south is not the same as a tester from the north. Tamil Nadu in the southeast is conservative. Coimbatore is less so. Maybe this collection of people and their personalities would come out in different ways, but maybe the key toward getting them to show that to me was the same – make it personal.

The next day in a training class I was hosting for them, I brought up Google Maps and projected it on the wall. I zoomed in on Coimbatore where they were from and asked each to show me on what street they lived. That way, maybe they’d be less homesick, and I’d learn about their city. No testing got done in that two-hour session. No training got done. Nothing business, nothing productive, nothing measurable. But all personal.

What really got done in that session was me getting over myself. I was building a team, accidentally, on purpose, and I was seeing smiles and jokes, and shyness fading. The next session when we got into learning the product, the jokes carried forth – not always by me. I set the tone that it was ok, and they slowly followed suit. It began to be fun.

At the next session, the walls melted a bit more and we played one of the testing-thinking games me and my brother are famous for.

A week of this, and none of them were machines. They were people just like me, just like my existing teams that were being replaced.

I saw them thinking more and more above and beyond my expectations. They were hungry and wanted to learn more. While still polite, the veneer dropped despite the jet lag and the homesickness. They learned on their own, as a team, after business hours. They took pictures of me with them, shared their family pictures with me, shared the pictures they took when they explored Seattle that past weekend. They went places (in MY city) that even I hadn’t gone yet.

We got down to business, but it was personal. That was the key. They dove into their feature assignments just like my team did. They loved exploring, were not shy, talked over each other, even gaggled like kindergarteners eager to show each other as if it was show-and-tell time. It was amazing, and it was as easy as a key being turned in a lock, just like the instructor said would happen.

And, you know, I suddenly realized that I was the same manager I was with my existing staff. This was me, my style. This is what I had done with my staff well before the Indians came in to be trained. The only difference was my perception that Indian testers were not as capable as my staff. For that, I was just plain wrong.

So, India, consider me schooled. I have some keys now that I didn’t have before and my perception is different. Like a good tester, I ran a different set of tests on you that revealed new data well beyond the folklore.

Still, let this be my apology.

My response to Jon ...........
Jon

A very nice post …I just chanced upon a link today while browsing and it led me here …..though this is an older post by you, I could not help writing a note

I have been working across borders for all my professional life and find every country and their people mesmerizing in multiple perspective.

Just like you had perceptions about Indians and their behavioral attitude ….. People in India have some too  …….from the ones that I have found amongst people when I interact with them, I’d like to share some key ones with you…….

I could take these learning’s and was able to see it visibly effective in non-US-UK…(non English speaking) countries to be similar in many respects …….

When initially people start interacting….. they face a few challenges like :

1. They are little unsure on how to maintain the cultural balance during discussion

2. The language and pronunciation at times are difficult to immediately pick up (Remember – English is still a foreign language)

3. They feel that if they ask questions, they might be considered ignorant and unskilled

The above 3 I significantly relate to as a barrier in European countries too where English is a foreign language.

For India there is a 4th one too

4. Cultural upbringing that says do not question your teacher upfront. You can initiate dialogues later. Indians strongly believe the saying ” Guru Govind dou khade, kake lagu paav…Balihari guru aapno Govind diyo milaye” that means…. “if both God and Teacher stand in front of me, whom should I bow first? …. It has to be the teacher coz it was he who taught how to understand and unite with God”.

Family – anyways rules as the first law in india !!

It is really nice to see that all of us are now trying to break these cross cultural barriers and trying to understand perspectives of others and in return learn something from them as well !!

….

Amazing Discussion

2010-06-08T05:28:00.000+05:30

I had the opportunity to have an amazing discussion with James Bach today which also involved mentoring on positioning oneself.

My take away's post discussion -

Believe in yourself
Understand your strengths
Position your flairs
Do not hesitate to ask for what is legitimate

Women in IT ? ....Why not ' Women and IT' ????

2010-06-08T05:24:00.000+05:30

Last few days there has been fire on twitter & Blog spaces ....... fiery remarks have been made to individuals and group of people.......is it justified ??
Few links for you to read around the same at Jon Bach's blog http://jonbox.wordpress.com/

I have but one question .....
Why is the world so worried about gender at work ?????
Why is everyone worried about "Women in IT/Agile/Testing /........." ?????????
Why is the focus on "Women in IT" ???

Why can't people think and realize ????

Why are you not emphasising on "Women and IT " ???

In my viewpoint, the later will make more sense for all those kids who are looking for pointers towards decision making.

Role model does not always help to follow blindly.

But a career guidance with what all you can do substantiated with examples of "Women achievers in IT" may help them better to make right choices towards their careers.

I also do not understand how to relate "diversity" and "Women in IT"....... for me "diversity" without a context is meaningless. In professional world diversity is linked to multitude of factors.
In this specific case also it is linked to thought process and individuals capabilities.

I also ask why do you think you should be treated differently ? In the professional environment

1. You do the same work

2. You get paid the same

3. You have similar skills

4. You spend similar amount of time at work

5.You get the same career graph

Thoughts to ponder :

What stops me to stand up and voice my thoughts and speak my mind in sync with the work I do ?

-----My internal fear of rejection / inhibition or my inability or something else

Can I not improve my skills as others (men included) ????

---------- The opportunities are sitting there, dont I just need a mindset to go and acquire it ?

2010-05-30T22:31:00.001+05:30

James Bach has something nice on heuristics posted on his blog http://www.satisfice.com/blog/archives/462 titled The Essence of Heuristics.

Very thought provoking simple read......the questions that he asks at the end are that I directly relate to being a good manager

Do they teach you how to tell if it’s working?
Do they teach you how to tell if it’s going wrong?
Do they teach you heuristics for stopping?
Do they teach you heuristics for knowing when to apply it?
Do they compare it to alternative heuristics?
Do they show you why it works?
Do they help you understand when it probably works best?
Do they help you know how to re-design it, if needed?
Do they let you own it?
Do they ask you to practice it?
Do they tell stories about how it has failed?
Do they listen to you when you question or challenge it?
Do they praise you for questioning and challenging it?

Give these questions a good thought and it will help you answer many confusion and unhide many unknown corners during testing.

few chapters from Jerry's book- 'mistress of molecules'

2010-05-30T17:56:00.004+05:30

http://www.geraldmweinberg.com/Site/Mistress_of_Molecules.html

above path is the source link

Home
eBOOKS
Books
Leadership
Quality
Thinking
Communication
Software
About Jerry

Chock full of clever ideas and wry wit, Gerald Weinberg's Mistress of Molecules
explores the forces that bind chemicals, societies--and people. A fun, thoughtful read. - Steven Mohan, Jr., Author
What I love most about the best science fiction is that it can be read on (at least) two levels: the surface story, and the underlying manifesto. Mistress of Molecules fulfills that definition of science fiction in spades. Recommended. - Michael Hunter, Blogger
MISTRESS OF MOLECULES: sample chapters
(You may print these pages for more convenient reading.)

Chapter 1.
Libra
Before the instant I launched my crocus-laden balloon plane, I had never doubted that I was my father's daughter. Now, parked in Clifton Plaza waiting for its return, my body, and my confidence, shook with fear. Nicolas Valois never feared anything. He had been solid as one of the Star Chamber's marble pillars, even as he'd stood before the Pope to receive his death sentence.
Although I was not yet born at the moment my father's molecules were disassembled and scattered, I know my father quite well. The vid of his show trial is part of the school curriculum. I have watched it hundreds of times.
Father was smarter than anybody in the Church. He must have known the Church would distribute the vid as moral lessons for the unfortunate inhabitants of our poisonous planet. So he used the trial, the vid, to communicate his own moral lessons, not to everyone, but only to me, his unborn daughter.
The Ministers caught Father with a kilo of crocus—less than my balloon plane now carried. They kept him out of public view for twenty-one days, no doubt torturing him until they placed him on public trial before our Pope. His Holiness served as judge, jury, and prosecutor. Sitting in full regalia—gold-trimmed purple chasuble over ivory alb and stole, a tall gold mitre decorated with seven purple crosses—he asked Father whether he had stolen the crocus.
Father stood tall and proud, though bruised, chained hand and foot, and dressed in baggy, wrinkled, orange prison clothing. "No, sir, I did not steal it."
After I had watched the vid a dozen times, I noticed the Pope flinching slightly when Father refused to address him as "Your Holiness," as was required of everyone in the court. I had seen a bailiff begin to move toward Father, probably to chastise him for this breach, but a wave of the Pope's finger motioned him away.
"Then you bought it?" asked the Pope.
"No, sir, I did not buy it."
"Then you smuggled it, perhaps from Earth?" The Pope looked down to check his console. "The record shows that you recently visited Earth."
"Yes, sir, I did. I was sent by my employer, the Telenergy Corporation."
"And upon returning from that trip, you smuggled the crocus from Earth?"
"No, sir, I did not. As far as I know, there is no crocus on Earth. Their air is not poisonous like ours, so Earthers have no need for it."
That statement, I knew, was a key part of his message to me.
The Pope continued. "So you know where all the crocus is in the galaxy?" He smiled knowingly for the audience, having put this arrogant criminal in his place.
"Everyone knows, sir, that crocus exists in only two places: here on Precursor, and on the Zgaarid home world, wherever that may be. I have never been there, nor has any other human, to my knowledge."
"And just how do you possess this vast knowledge of galactic affairs?"
"By logical deduction, sir. If the Zgaarid did not have a monopoly on crocus, and if the Church and the corporations could not use crocus to control our people, then we would not be held in docile slavery. But since we are no more than miserable slaves, the monopoly must exist. Why else would your church make it a crime to distribute a life-saving substance?"
"Hah." You could hear the smirk in the Pope's voice. "There, young man, you display even more ignorance. Even little children know that slavery is forbidden by the Church. That the Holy Church is your father protector, dedicated to your welfare and the welfare of your immortal soul."
"You would have to be a little child, sir, to believe that falsehood." Another message to me, I'm sure.
The Pope waved his hand dismissively. "Enough of your nonsense. If you did not steal the crocus, and you did not buy it, and you did not smuggle it, … " He rolled his eyes heavenward. " … then how did you obtain it?"
Father followed the Pope's gaze toward the ceiling. "God gave it to me, sir."
The Pope turned red and angrily banged his gavel on the bench. "That will be enough. Bailiff, gag the prisoner. And Clerk, you will now add blasphemy to the list of charges."
Before the bailiff could insert the gag, Father shrugged his shoulders and said, softly, "Fortunately, you can only murder me once."
Those were Father's last words before his body was disassembled into its component molecules. I know they were a message to me. They could only kill him once, but others would carry on his work. Others like me.
And what was that work? Again, that was clear from his testimony, though everybody else was too blind to see it. If he hadn't bought, stolen, or smuggled the crocus, he must have made it, which is what he meant when he said that God gave it to him. That is, God gave him the power to do chemistry, to make molecules. Molecules like crocus would free our world from both human and Zgaarid slavery.
Perhaps in another age, Father's ability to synthesize crocus would have been obvious to everyone. By now, however, humans had become so intimidated by Zgaarid technology that nobody even attempted to create things. Yes, there were people called chemists—my father was one, after all—but they were all simply technicians trained to operate pre-defined Zgaarid processes.
All, that is, except Father.
And, of course, me. The coward.
Chapter 2.
Libra
I shouldn't have been afraid, waiting for my balloon plane. I knew Minister Jackson of the Clifton ministers would probably show up on his usual beat and question why I was parked here, so there was no logical reason why my stomach clenched when he pulled up alongside my battered old Fargo. Perhaps I was nervous because after a lifetime of preparation, today's plane flight was to be the first step in carrying out Father's vision.
I knew Ben Jackson would ask what I was doing sitting there breathing the polluted outside air at six on a bright-morning. I was prepared, so this whole caper should have been much safer than making nitro in my lab, but I couldn't keep my hands from shaking. I hadn't figured on the shakes.
Though I was over sixteen and legally entitled to be out through the entire dark-day, I had dressed in a rather childish, pink party dress. I wanted to look like a more vulnerable girl out after a late dark-night date, looking for someone to father a child and earn her first birth-bonus. Minister Jackson had been Father's friend, and he hadn't renounced their friendship even after Father was disassembled. But he never believed Father was making his own chemicals, because nobody had done that for three generations since the Zgaarid showed up with their advanced technologies. Even back on Earth, and that was the only place where human-use chemicals were still manufactured. Everything we synthesized here on Precursor was for export to the Zgaarid, perhaps for sale to other species in their trading network, though some of the products could be used for human purposes, too.
Jackson had always been protective of me, maybe more because of snitch's guilt than ministerial duty, so I figured he'd cut me some slack. As he walked over, I did my best to look like a fatherless little girl, not ready to breed, and needing a minister's protection and consolation.
"Well," he said, with mock surprise in his voice. "Good morning, Libra. Or is it still good evening?"
"Hi, Ben," I sparkled at him, knowing I would have to satisfy his curiosity before he would move on. "It's still 'good evening'—though it wasn't as good as I hoped."
"Something wrong?"
"I'm okay," I said, trying to sound as if it wasn't quite true. "I was at a party in Center. A guy … " I could make myself blush, but I didn't think I needed to. "… well, you know how guys can be. So I wanted to sit here a while and think a bit before going home to take care of Mom."
Ben Jackson knew my mother, too. He had helped her settle in after she arrived here on precursor to find her husband no longer existed. Mentioning Ma was carefully calculated to remind him that it wasn't very nice for a young girl to be saddled with a widowed mother who everyone in Clifton knew to be an alcoholic 'tardy. And everyone said I would be better off if Marianne could only pull herself together, and wasn't it a shame that her brain had been damaged when she quilted over from Earth. And that I was too young to have to work all the time to support her—that I should be out having fun and looking for a man with suitable genes who still had viable sperm.
I could see that Minister Ben was likely to be thinking all those thoughts. How serious I was. How it was only natural that I wanted to be alone once in a while. Or have a little fun—but not like some of those other kids he had to deal with, messing around with psychems, getting in all kinds of trouble, then having their parents come down to Church and bail them out. So I gave him a few moments, then said, "It's all right, isn't it Reverend Jackson, to park here? I mean, it's not immoral to use the parking lot, is it? I was just a little afraid to park on the street all alone."
I motioned to the two other parked cars. "I mean, the bakers are inside working already, so I thought it would be safe."
"Sure, honey. You can just sit here as long as you like. And nobody's going to harm you as long as I'm around, you can count on that."
I knew this was true. Nobody in Clifton—not even gang members—would dare to face a Minister's firepower. But right now, I preferred to be alone. My balloon plane had enough fuel to circle for at least two hours. And it would be light even before then.
Chapter 3.
On Precursor
Alone in Boss's car, Manny was glad it was early, and dark—not that much light ever penetrated Precursor's cloud cover even during bright-noon. Dark or light, there was no way he would allow his boys to see how nervous he was as he wheeled his car across Bridge 214. If this slag dump island had a name, he couldn't think of it. Just "Bridge two-one-four," the only way on or off unless you were willing to risk a boat in the sludge Precursor called water.
But there was already more than enough risk for Manny. Ordinary missions—heists, intimidation, assassination—never made him feel this way. He wasn't afraid of killing, and never thought of the possibility of being killed. He was untouchable, but this job was different. Full of unknown quantities.
Manny was clever enough to imagine some of the possibilities, which was why Boss chose him as point man. He was proud of that, but even Boss hadn't been smart enough to know who had sent the package. That might be the hardest part of his job, finding out who was behind the package, but someone had to do it. Anyone who was cunning enough to lay his hands on that much pure crocus was someone to be reckoned with.
The plain package had contained a full kilo of the orange powder, enough to provide hope of long life for ten-thousand sick workers for a month. Wholesale, it was worth $100,000 cache—cache because it could never be sold for traceable money—cash. Retail, it would bring five times that much. Maybe more, because everybody knew crocus, like most human biologics, could not be manufactured on Precursor and had to be smuggled through the Quilt—which was not easy with the Zgaarid controlling the trade.
The note in the package had asked for $10,000 cache, a modest price indeed. Of course, Boss knew he could just keep the goods and chalk up a pure profit, but if this "Joe Green" really had a source, it wouldn't pay to settle for a mere kilo. Besides, Green might start dealing with someone else, which could cut into business. And so, Manny thought, as he patted the bundle of tens and twenties on the seat beside him, he had better come out of here knowing everything he could about this mysterious Joe Green. When he did, Boss would think the ten thou cache had been well spent, and Manny would be rewarded.
He pulled into the dump and watched the faint shadows for any movement in the dim light ahead of the car. Although he couldn't make out anybody else among the slag mounds, he knew that Jack and Randy had been discreetly parked near the dump entrance for the past twenty-two hours, ever since dark had begun. If anyone had arrived but departed, Jack and Randy would have reported it.
Later, as soon as Manny gave the electronic signal that the pickup had been made, his boys would tail the next vehicle that drove out. And, in case the first one was a decoy, Zig and Sammy had parked outside the dump an hour ago, to back them up.
Manny was a planner. He had covered all the bases. If Joe Green or his messenger arrived by boat, Cap and the rest of his crew were holding the launch just offshore, but out of sight. The potential here was too big to take chances. If Joe Green really had a wide open source, Boss had to control it.
Boss himself, of course, would be arriving at Mass just about this time. Joe Green had done his research, scheduling the drop early in the bright-morning. Boss liked to have at least two ministers and a gaggle of pious women to provide an alibi whenever anything risky was taking place elsewhere. It was a piece of professional courtesy for Joe Green to fit Boss's schedule. It showed respect. In this business, respect was important.
It also showed that Green was a pro, and a pro would expect to be tailed. And would make provisions to shake the tail. Manny's job was to follow instructions to the letter—both Green's and Boss's. He only hoped that they wouldn't be contradictory. Manny liked to think of himself as a pro, too, but he despised contradictions.
He reached the designated spot—the flattened mound of purplish lumps the size and shape of human ears—without seeing anyone else in the dump. Not that he expected to, at this hour on a bright-morning, but you never knew. Besides, there was an almost infinite number of hiding places among the poisonous slag mounds.
Manny scanned the mounds, not really expecting to see anything. He couldn't even make out the true colors of any that were more than ten meters away. It occurred to him, then, that Green might not try to take the money out at all, but just wait in the dump until there was enough traffic to cover his exit. If bright-morning had fully dawned by then, the cloud-penetrating satellite scans should show all the comings and goings. Still, Manny would remain alert on the ground. Any tiny clue might be as useful as following someone right out of the dump. There weren't that many possible Joe Greens to eliminate.
The note's instructions had been disturbingly simple.
Have the money securely tied up in a ration box—in tens and twenties cache.
Come alone.
Stop the car by this purple waste mound.
Get out of the car.
Wait for further instructions, exactly five meters north of the mound.
Manny checked his shoulder holster and his ankle backup just in case. If this whole thing was a minister trap and he was caught carrying, he was out of luck. But Boss couldn't imagine the Church sparing a full kilo of crocus for a trap, and Manny trusted Boss. Generally, the ministers kept one eye closed to the illicit crocus trade, as long as there was nothing too obvious or the price became too competitive. Too many people would stop working for the corporations if they could get their life-saving drugs elsewhere.
He checked the time on his implant, adjusted his nasal filters against any particularly noxious fumes, then lifted the box and popped open the side of the car. After making one inspection tour around the car, he checked the time again. Five minutes to six. Exactly on plan. He placed the box on the car's collision shield, popped a scrubber in his mouth, and activated it with saliva. He had a feeling that Joe Green would not be late. He wanted his mind perfectly clear.
At one minute to six, he sucked the scrubber one last time, then spit it out and circled the car once more. He felt that something had changed, but he couldn't pin down what it was. The sun's greenish light was beginning to crack the horizon, but he could see nothing in any direction. Still, the feeling grew. What had changed?
Chapter 4.
Libra
If everything went well, my plane could have been returning any time. I had to get rid of Ben Jackson. Quickly, but without arousing suspicion. Even fully loaded with $10,000 in small cache, it would be quiet, but maybe not quiet enough. It wouldn't land until I activated the command button hidden in my bra, but I wanted to get it down before the markets in the Plaza opened and too many people were milling around. The plane might be small enough, and perhaps silent enough, so it wouldn't be noticed by eager shoppers, but I didn't want to take any unnecessary chances. I needed to get rid of my self-appointed guardian, and quickly.
I decided a little embarrassment should do the trick, aided by my repellant pheromone. I dabbed my left pinkie with a drop of saliva to activate the scent, then waved it under his nose as I leaned out the window and gave him a daughterly kiss on the cheek. "Thank you, Reverend Jackson. Thank you for everything. Sometimes things are pretty difficult for a girl, you know."
The kiss and the chemical had the desired effect, as I knew they would. Most Ministers, popular though they might be as breeding studs, were prudes—in public anyway, in uniform. They were afraid of losing their jobs, which sure as heck beat slavishly following Zgaarid chemical procedures in one of the factories.
He shuffled backwards, quickly looking around to see if anybody had seen the kiss. It was still too dark to be sure, but I thought he was blushing. "That's all right, honey," he stammered. "I'm just doing my job, so you just stay here as long as you like. I've got some other people to protect and console. I'm sure you'd rather be alone anyway."
I decided to toy with him. I know I shouldn't do that, but I never can resist teasing men. They think they're so powerful, so in control, especially the ones with top gene scores, which most of the ministers had, given the protected environments of their churches. But that arrogance makes me so angry at the same time it makes them so easy and tempting to tease. "Oh, no. I'd love to have you stay and console me, as long as you'd like."
But he had already retreated to his patrol vehicle and opened the door. "I really have to go now. Say hello to your mother for me."
"I will. And say hello to everyone at Church for me." I knew he would certainly tell all his colleagues at Church about me, going over the story once more about how Father had been an irresponsible fool to think he could smuggle chemicals and not be caught. How he'd been one of those troublesome cases who couldn't withstand the reprogramming so had to be disassembled, and now his daughter was suffering for it. How maybe one of them should get busy and give me a baby, so I'd have some income to ease the suffering.
Well, it hadn't been all suffering, and I didn't need any birth-bonus. I had a paying job, even though it paid less than I would get for three babies. Better than that, the ministers had left Father's lab intact, not even believing such a place could exist. So, I had a playroom filled with equipment and a fair number of supposedly harmless precursors. It wasn't hard to convince 'tardy Ma not to sell any of it, and to stay out of the lab when she was home, so I had free rein for my own experiments. And the ministers needed no convincing that two mere women were no threat to the corporations.
Well, their blind spot was good cover for me, so I couldn't complain, but as I sat there waiting, I couldn't help reflect that maybe somewhere there's a man who didn't think he was master and commander of all women in the universe. No, I decided, not if he was raised on Precursor. There couldn't be a worse planet for women in the entire Zgaarid galaxy.
Chapter 5.
Andre
Though I was named for Brother Andre, the faith healer who encouraged his followers to accept their suffering, I could never accept mine. Much of my early boyhood on Gemariah is an undifferentiated fog, spent as it was in Perfective Solitude. The Lock, however, stands out clearly, for it was my first real teacher. My mind holds many sharp pictures of The Lock, arranged in the chronological order my developing brain constructed them. Earliest, of course, was the burnished gray metal interior faceplate. Only the faceplate was visible to the untrained eye of a three-year-old with nothing more interesting to do than study it. Not to study for purposes of escape. Not yet. Simply because The Lock anchored the doorway to the forbidden world outside my Perfective Solitude cell.
By age four, my passion to understand how things worked was already well developed, and I already knew every line and scratch of the faceplate. By five, I understood that though the lines and scratches contained innumerable patterns of interest, none provided the slightest clue to opening the forbidden door. I don't recall exactly when I understood, but by five, certainly, because by then I was already far advanced in my vocal mimicry, a skill that would later become one of my most useful tools.
Memorizing the key phrase was easy enough. It was, naturally, taken from the Holy Scriptures, which I had already memorized before I even knew how to read. Before I was even supposed to know there was even such a thing as reading. But I'm getting ahead of myself.
Although I was already a good mimic, I failed to realize that my juvenile voice could never hope to capture my father's bass pronunciation. Only on rare occasions did Mother control the lock, so I was perhaps six before I put aside my futile efforts to mimic my father's voice. Mother used a different key phrase—also Scriptural, of course—but her squeaky voice was well within my boyish range. Only a few months of incessant practice were required to put the lock under my control.
The first time I succeeded with my new skill, my father was unable to believe that a mere child could conquer the Perfective Solitude Interdictions placed by the Holy Church of Yahweh's Tender Touch. He assumed that Mother had neglected to lock my cell door, earning her Yahweh's tender touch with my father's cane—the worst beating I had yet been allowed to witness. For my own good, of course.
My own beating—for taking three tentative but forbidden steps into the hall—was much less severe, though severe enough that I made no further excursions unless my parents were away.
Fortunately for my education—as opposed to my schooling—they were often away on church business. Whole days, sometimes weeks, at a time. By age eight, when my own church responsibilities began, I knew every detail of every object in our tiny house. I knew exactly where it was placed, how it was oriented, and even the dust patterns that had to be restored when it was moved for my examination. Not that Mother would ever allow dust to accumulate on anything my father could see. She may not have been as devout as my father, but she was devout enough to avoid unnecessary torture for the sin of slovenly housekeeping.
She was also heretic enough to know which hidden nooks were unlikely ever to be examined with my father's white glove. To refurbish the undisturbed pattern for these areas, I collected my hidden cache of dust—always accumulating in my cell. Looking back, I wonder where the dust came from. Gemariah, at least where we lived, would have been a desert without irrigation from the mountain snows, but with no window and an always-locked door, how did the dust get inside?
Yet somehow the dust accumulated. No need for white gloves, either. With the only furnishings being a hard cot, a straight chair, and an extractor, any dust I missed was always visible grounds for punishment. So, the Lock taught me to be meticulous in my personal habits—not from the Holy Church's admonitions about cleanliness, but from Mother's sin of slovenliness. I was convinced that this slight taint on Mother's soul was the genetic origin of my own heresy. Certainly, there was no such taint on my father's side of the family. My father, like his father and his father's father, was a Minister.
Part of his duties as Minister, over and above enforcing the Law, were to maintain a collection of banned books so he could learn to recognize the various Heresies in their infinite forms. Opening the collection's physical lock was child's play, but since I'd never learned to read, the contents of the books remained locked to me for several years. The pictures, most of them, I grasped immediately, but the words, even the letters, were strings of mysterious, meaningless, patterns to my untrained mind.
My first break was the letter O. It reminded me of the glyph on my Console—Ouroboros, the snake eating its tail—meaning "repeat the lesson." Of course, Ouroboros was the embodiment of filth—not just touching its nether parts, but touching them with its mouth—but that was appropriate. Only the poor student—the filthy, unclean, unhealthy student—would lack the concentration and religious dedication to memorize the lesson in a single presentation. So, whenever I happened to touch the O, my Teacher would punish me by chanting, in that blaming tone Teachers do so well, "O-ro-bo-ros. O-ro-bo-ros." Mouthing the word, I could hardly miss the association of shape and sound.
Looking at my description, I realize that this learning process sounds too easy. It wasn't. Nothing on Gemariah was easy, even the things you were supposed to be doing.
"Labor is pure." Growing up, I heard this admonition a hundred times from Mother. A thousand times from my father. A million times from my Teacher, my virtual friend in the Console in my wall. More important, it was written in gray letters on the translucent white glass of the oculus above the altar in the Church. Eventually—I think it took months, but I had nothing but time—I figured out that the "bor" sound in "la-bor" was the same as the sound in "Orob-bor-us." I had strayed off the strait and narrow way to virtue, treading the crooked path to sin through reading.
The pictures and diagrams helped immensely, because I knew the names of things mentioned. "Bed" led me to isolating the "b" sound, which led me to "ball" (not that I had a ball to play with, but I often had to "follow Teacher's bouncing ball.") The difference between "ball" and "bed" provided the idea of vowel sounds, and "ball" and "hall" and "wall" taught me a couple of new consonants.
By the age of nine, I could make out the sounds of many new words, though irregularities in some of the old spelling led to embarrassing mispronunciations later in life. But, at the time, my reading was of necessity silent. Hence, I learned the physics of levers, fulcrums, and loads without knowing that "load" was a one-syllable word, with a silent "a."
But pronunciation didn't matter. I could actually test what the book said about mechanical advantage without knowing how to pronounce the "ch." And test I did. I could indeed move heavy objects—like my steel bed—by creating a class one lever with a short arm and a long arm separated by a fulcrum. With a class two, I could crack my hard nutritional biscuits without risking my teeth or soaking them in my water ration. Cracking them was essential if I wanted to avoid biting into an occasional burrowing mealworm.
The Holy Church of Yahweh's Tender Touch teaches its followers that all strength came from health, and all health came from faith and purity. But physics taught me that some strength came from thought, and faith had nothing to do with it. Physics had cracked my faith, just the way it had cracked my biscuits.
It was only a crack, though. Before I was ten years old, some articles of faith were so firmly set that they couldn't be cracked by books. I read about how babies were made, but I simply couldn't believe it. If women didn't have a "thing" down there, how could they use the extractor? Without the extractor, they would fill up with urine until they exploded and died. No, I wasn't to unlock the truth about women until much later, when I served my time in the seminary.
Unlock. Oh, yes, I was describing my father's locked collection. One of my greatest discoveries was a book on circuit theory and electronic systems. Studying this tome during long Church weekend retreats allowed me to form my third picture of the interior of The Lock—a circuit diagram. Actually, it was a collection of homeomorphic circuit diagrams—all logically equivalent to the black box observer that I, born in sin, was condemned to be.
But I keep getting ahead of myself. I've given a glimpse of my early education, the origin of some of my personal tools, but I haven't really explained why I needed these tools. For that, I will first have to explain about the uniquely human church disease that infected Gemariah, our isolated agricultural planet in our isolated arm of the galaxy.
TO BE CONTINUED (ORDER THE FULL STORY BELOW)
If you are a reviewer for a regular publication and would like a review copy of this novel, email me with your request for a reviewer copy.
To purchase the paperback version:
• Directly from the publisher:
https://www.createspace.com/3390916
• From Amazon.com:
http://www.amazon.com/Mistress-Molecules-Gerald-M-Weinberg/dp/1448638801/.

enjoy the game !

2010-05-30T17:55:00.000+05:30

http://www.members.shaw.ca/gf3/circle-the-cat.html

Preview : New Automation Tool - Automation Anywhere

2010-05-23T22:15:00.005+05:30

I recently had a chance to preview another automation tool in the market. It is relatively new and not much advertised.
I was impressed. Felt very comfortable navigating through it. It seems to be a combination of HP tools like BPT+ QTP + Sprinter (alias manual runner. Yet to be launched) + Web Testing Tool (Still under development). It has multiple features. They also have feature where the nuances of Object properties can be eliminated. Object properties are one of the biggest pain points of QTP.

I still need to do a PoC to realize the exact benefits this tool has over the ones existing otherwise. The first impression however at the macro level was very impressive.
The website is very easy to navigate and provides on line solution forums & user forums. Has availability to interact with fellow product users and their product team to learn from their experiences.
link to website http://www.automationanywhere.com/products/AAServer.htm
freedownloadable trial version of their tools available
check out demo at http://www.automationanywhere.com/lrn/learn.htm

From their website and the presentation given, collated the following info -
Automation Anywhere Server
It is an intelligent automation solution allowing users to automate business and IT processes easily, swiftly and intuitively. It centralizes the setup and maintenance of automation tasks, ensuring consistency, eliminating setup time and maintenance effort whether it be a single machine or multiple machines across a division or enterprise. A centralized server console allows for better control and lower costs. Easily edit automated tasks at any workstation, then upload or download the automated task onto multiple locations to seamlessly run automated tasks across users. Unparalleled performance and scalability leads to greater efficiencies in automation.
Automation Anywhere is a no-programming required, intuitive and intelligent software. Powerful, in-built features include
· a SMART Windows recorder,
· SMART Web recorder,
· job scheduling,
· 495+ actions,
· award winning drag and drop task editor,
· a Web data extraction tool,
· Excel integration,
· data transfer wizards, to name a few.

They claim that it is used by everyone, whether they are IT professionals or savvy business users, it is the software of choice for thousands of customers, Fortune 500 companies, small and medium sized businesses and individuals across industries, in over 90 countries.

Key Features Includes
ü Workflow Designer
Visually create business and IT process workflows. Flowchart entire processes for better deployment, communication and intra-company documentation
ü Visualize automation
Innovative 'Visualize' technology provides a screenshot visual of every step of an automated process. Storyboard the view of an entire task or capture images on-demand
ü Image recognition
Simulating the human eye, this powerful feature recognizes and captures images on any application screen, allowing for unparalleled automation
ü 3 recorders and editor
Task recorder, Web recorder, Windows Object recorder. Editor with 495+ actions and expert view for advanced users
ü App integrator
No-programming required integration using simple drag and drop. Integrate between any applications
ü User collaboration
Multiple users can upload / download automated tasks

Capabilities of the robust solution are
ü Scalability: add users as needed
ü Seamless information flow
ü Centralized systems: backup, security and resources
ü Save resources, time and cost
ü Better collaboration between employees and divisions
ü Reduce human error on repetitive, time consuming tasks
ü Streamlines setup and maintenance of automation tasks
ü Consistent practices across users
ü Knowledge capture – central repository to easily share/store automated tasks

Solutions Provided

As a testimony to its reliability, power and ease-of-use, Automation Anywhere is used for a variety of tasks, across industries.
1. Provides Ready Solutions for
ü Web automation
ü Windows automation
ü Network automation (LAN/WAN)
ü Excel automation
ü Database automation
ü ERP automation
ü Remote desktop automation

2. Manages Common Tasks like
ü Business process automation
ü IT automation
ü Web data extraction
ü Business intelligence
ü Screen scrape
ü Data integration / Data automation
ü Automated testing
ü Application Integration
ü Job scheduling
ü Batch processing
ü GUI automation
ü Email automation

3. Provides Industry Solutions towards
ü Finance / Insurance / Banking
ü Technology
ü Healthcare Government / Education

HP IGNITE at Goa - 19 May to 21 May 2010

2010-05-23T21:26:00.006+05:30

Attended HP IGNITE at Goa - 19 May to 21 May 2010.
beautiful venue, beautiful stay, well charted program..... Very good folks ....
This was a partner connect and met myriad of people across industry from India and HP in particular.

Was not so impressed by the tools and solutions they show cased as upcoming from HP. My own current employer has much better solutions that we are using for years now. HP has just started to think about them :(...........and I realized there are many more areas where they have not yet started thinking. ( Sat through sessions wondering .....WHERE IS THE LEADERSHIP THEY CLAIM)

Was not even impressed on the tools presentation side. Just a high level theory and probably a few snapshots (only for limited cases) did not satisfy my appetite. Would have loved if they had some trial versions or Kiosks available to immediately try out the tools and give a first hand feedback to the HP leadership present there.

The questions I had around ROI benefits from using some of the upcoming tools specially Agile testing ones, did not get me satisfactory answer. I directly spoke around these to Noam Sharon who heads their R&D and Roi Carmel who heads the architecture group.

The Agile testing solution proposed therein seemed more like 2 sections of testing where in first part a QA team works very closely with Dev team (my interpretation of this was a peer review. Could no where relate to QA activity) then a systems testing phase (where I perceive some testing will be done). But in any case no proof if this proposed development method with tool usage will bring any tangible ROI benefit on the table for the end user against usage of traditional development methods prevalent currently.

All in all event wise technical take away was not as per the expectation that I had from the program.

Preview on HP Manual Runner

2010-04-14T10:43:00.003+05:30

I had an opportunity to do a sneak preview of an upcoming HP Testing tool called Manual Runner this week.
The key USP's I liked of the tool were for Exploratory testing and for multi browser combo's & environment settings.
These would give a significantly good reusability and result in magnitude of saving leading to a considerable impact on ROI improvement.

Key Features -

Can work as stand alone as well as with QC. There are many other options on how it can be used
Record every activity you do as test on the fly
Creates manual test cases step wise as in linked to QC
Captures screen shots of every entry
Defects can be called out, separately captured and showcased with annotations
Perfect for unit testers as they explore and finalize the testcases towards functionality fitment
Very helpful for regression testers
Most usable - Can open mutiple virtual machines and run the same test from primary host to multiple secondary hosts having different environments simultaneously.
All results can be captured at the primary host level
Can link to QC same as any other HP Tool

There are multiple suggestions given on enhancement and now I wait to beta test it !!

Yet to see final version of it to take it to clients.......

Frustrations of testing a product where there are no validations built in

2010-04-14T07:59:00.005+05:30

Last Saturday (10 Apr 2010) I joined the EWT session to test a site. This was calculations around the parking meter for parking in the premises of his space.

My results are as below ....

Matt's Blog has one good write up on the same

http://blogs.stpcollaborative.com/matt/2010/04/13/parkcalc-review-and-discussion/

The new year .... to do or not to do !

2010-04-13T20:52:00.004+05:30

Opened the blogspot today and realize that no posts this whole year and a quarter gone !! Hah !!

So here I am ......Let me talk a little about the fear(s) I have faced as questions from fresher's setting feet into world of software testing ........

I aways wanted to be a programmer...they pushed me to do testing ....this is not what I want to do ....... when can I get a change from here

And mind you .......this guy as yet does not even know what is meant by the 'T' in testing !!

Do I really have a career in testing ?

Did he not know that all companies have an independent vertical on testing now ??

Will I really have an opportunity to do something nice as 'tester' ?

You need to taste the sweet before you can comment on degree of sweetness in the same.

Do you think this is a respectable job profile ?

Why do you think so ? Did you not read basic softare engineering while at tech school ?

I'll answer these in the next post ..... with my opinion around these qs !!

Testers and Newton's Laws !!

2010-03-15T05:19:00.006+05:30

Let me firstbegin by stating the 3 laws of motion of Newton. The below content about the Newton's Law was taken from "http://csep10.phys.utk.edu/astr161/lect/history/newton3laws.html"
Let us begin our explanation of how Newton changed our understanding of the Universe by enumerating his Three Laws of Motion.
Newton's First Law of Motion:
I. Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it.
This we recognize as essentially Galileo's concept of inertia, and this is often termed simply the "Law of Inertia".
Newton's Second Law of Motion:
II. The relationship between an object's mass m, its acceleration a, and the applied force F is F = ma. Acceleration and force are vectors (as indicated by their symbols being displayed in slant bold font); in this law the direction of the force vector is the same as the direction of the acceleration vector.
This is the most powerful of Newton's three Laws, because it allows quantitative calculations of dynamics: how do velocities change when forces are applied. Notice the fundamental difference between Newton's 2nd Law and the dynamics of Aristotle: according to Newton, a force causes only a change in velocity (an acceleration); it does not maintain the velocity as Aristotle held.
This is sometimes summarized by saying that under Newton, F = ma, but under Aristotle F = mv, where v is the velocity. Thus, according to Aristotle there is only a velocity if there is a force, but according to Newton an object with a certain velocity maintains that velocity unless a force acts on it to cause an acceleration (that is, a change in the velocity). As we have noted earlier in conjunction with the discussion of Galileo, Aristotle's view seems to be more in accord with common sense, but that is because of a failure to appreciate the role played by frictional forces. Once account is taken of all forces acting in a given situation it is the dynamics of Galileo and Newton, not of Aristotle, that are found to be in accord with the observations.
Newton's Third Law of Motion:
III. For every action there is an equal and opposite reaction.
This law is exemplified by what happens if we step off a boat onto the bank of a lake: as we move in the direction of the shore, the boat tends to move in the opposite direction (leaving us facedown in the water, if we aren't careful!).

Have you ever thought how these Laws impact our day today life as testers ? (Y/N)
Y- I would look forward to hear your philosophy around it
N-Try to relate these to your day today activities and let me know if you can see a relationship

I see multitudes in relation !! ..... will write about them shortly !

The Seven Basic Principles of the Context-Driven School

2009-12-16T04:48:00.002+05:30

While I was reading an interview of James, I found a quick link.
This can be very helpful for folks who are still trying to understand the thought process of conext driven schools.
You can directly read it on http://www.context-driven-testing.com/
For easy reference I have duplicated the whole write up below.
----------------------------------------------------------------------

The Seven Basic Principles of the Context-Driven School

1. The value of any practice depends on its context.
2. There are good practices in context, but there are no best practices.
3. People, working together, are the most important part of any project's context.
4. Projects unfold over time in ways that are often not predictable.
5. The product is a solution. If the problem isn't solved, the product doesn't work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Illustrations of the Principles in Action:
· Testing groups exist to provide testing-related services. They do not run the development project; they serve the project.
· Testing is done on behalf of stakeholders in the service of developing, qualifying, debugging, investigating, or selling a product. Entirely different testing strategies could be appropriate for these different objectives.
· It is entirely proper for different test groups to have different missions. A core practice in the service of one mission might be irrelevant or counter-productive in the service of another.
· Metrics that are not valid are dangerous.
· The essential value of any test case lies in its ability to provide information (i.e. to reduce uncertainty).
· All oracles are fallible. Even if the product appears to pass your test, it might well have failed it in ways that you (or the automated test program) were not monitoring.
· Automated testing is not automatic manual testing: it's nonsensical to talk about automated tests as if they were automated human testing.
· Different types of defects will be revealed by different types of tests--tests should become more challenging or should focus on different risks as the program becomes more stable.
· Test artifacts are worthwhile to the degree that they satisfy their stakeholders' relevant requirements.
An Example:
Consider two projects:
1. One is developing the control software for an airplane. What "correct behavior" means is a highly technical and mathematical subject. FAA regulations must be followed. Anything you do -- or don't do -- would be evidence in a lawsuit 20 years from now. The development staff share an engineering culture that values caution, precision, repeatability, and double-checking everyone's work.
2. Another project is developing a word processor that is to be used over the web. "Correct behavior" is whatever woos a vast and inarticulate audience of Microsoft Word users over to your software. There are no regulatory requirements that matter (other than those governing public stock offerings). Time to market matters -- 20 months from now, it will all be over, for good or ill. The development staff decidedly do not come from an engineering culture, and attempts to talk in a way normal for the first culture will cause them to refer to you as "damage to be routed around".
· Testing practices appropriate to the first project will fail in the second.
· Practices appropriate to the second project would be criminally negligent in the first.

Commentary
In the years since we first published the description, above, some people have found our definition too complex and have tried to simplify it, attempting to equate the approach with Agile development or Agile testing, or with the exploratory style of software testing. Here’s another crack at a definition:
Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment. The Context-Driven School of testing places this approach to testing within a humanistic social and ethical framework.
Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices (even different definitions of common testing terms) will work best under different circumstances.
Contrasting context-driven with context-aware testing.
Many testers think of their approach as context-driven because they take contextual factors into account as they do their work. Here are a few examples that might illustrate the differences between context-driven and context-aware:
Context-driven testers reject the notion of best practices, because they present certain practices as appropriate independent of context. Of course it is widely accepted that any “best practice” might be inapplicable under some circumstances. However, when someone looks to best practices first and to project-specific factors second, that may be context-aware, but not context-driven.
Similarly, some people create standards, like IEEE Standard 829 for test documentation, because they think that it is useful to have a standard to lay out what is generally the right thing to do. This is not unusual, nor disreputable, but it is not context-driven. Standard 829 starts with a vision of good documentation and encourages the tester to modify what is created based on the needs of the stakeholders. Context-driven testing starts with the requirements of the stakeholders and the practical constraints and opportunities of the project. To the context-driven tester, the standard provides implementation-level suggestions rather than prescriptions.
Contrasting context-driven with context-oblivious, context-specific, and context-imperial testing.
To say “context-driven” is to distinguish our approach to testing from context-oblivious, context-specific, or context-imperial approaches:
Context-oblivious testing is done without a thought for the match between testing practices and testing problems. This is common among testers who are just learning the craft, or are merely copying what they’ve seen other testers do.
Context-specific testing applies an approach that is optimized for a specific setting or problem, without room for adjustment in the event that the context changes. This is common in organizations with longstanding projects and teams, wherein the testers may not have worked in more than one organization. For example, one test group might develop expertise with military software, another group with games. In the specific situation, a context-specific tester and a context-driven tester might test their software in exactly the same way. However, the context-specific tester knows only how to work within her or his one development context (MilSpec) (or games), and s/he is not aware of the degree to which skilled testing will be different across contexts.
Context-imperial testing insists on changing the project or the business in order to fit the testers’ own standardized concept of “best” or “professional” practice, instead of designing or adapting practices to fit the project. The context-imperial approach is common among consultants who know testing primarily from reading books, or whose practical experience was context-specific, or who are trying to appeal to a market that believes its approach to development is the one true way.
Contrasting context-driven with agile testing.
Agile development models advocate for a customer-responsive, waste-minimizing, humanistic approach to software development and so does context-driven testing. However, context-driven testing is not inherently part of the Agile development movement.
For example, Agile development generally advocates for extensive use of unit tests. Context-driven testers will modify how they test if they know that unit testing was done well. Many (probably most) context-driven testers will recommend unit testing as a way to make later system testing much more efficient. However, if the development team doesn’t create reusable test suites, the context-driven tester will suggest testing approaches that don’t expect or rely on successful unit tests.
Similarly, Agile developers often recommend an evolutionary or spiral life cycle model with minimal documentation that is developed as needed. Many (perhaps most) context-driven testers would be particularly comfortable working within this life cycle, but it is no less context-driven to create extensively-documented tests within a waterfall project that creates big documentation up front.
Ultimately, context-driven testing is about doing the best we can with what we get. There might not be such a thing as Agile Testing (in the sense used by the agile development community) in the absence of effective unit testing, but there can certainly be context-driven testing.
Contrasting context-driven with standards-driven testing.
Some testers advocate favored life-cycle models, favored organizational models, or favored artifacts. Consider for example, the V-model, the mutually suspicious separation between programming and testing groups, and the demand that all code delivered to testers come with detailed specifications.
Context-driven testing has no room for this advocacy. Testers get what they get, and skilled context-driven testers must know how to cope with what comes their way. Of course, we can and should explain tradeoffs to people, make it clear what makes us more efficient and more effective, but ultimately, we see testing as a service to stakeholders who make the broader project management decisions.
Yes, of course, some demands are unreasonable and we should refuse them, such as demands that the tester falsify records, make false claims about the product or the testing, or work unreasonable hours. But this doesn’t mean that every stakeholder request is unreasonable, even some that we don’t like.
And yes, of course, some demands are absurd because they call for the impossible, such as assessing conformance of a product with contractually-specified characteristics without access to the contract or its specifications. But this doesn’t mean that every stakeholder request that we don’t like is absurd, or impossible.
And yes, of course, if our task is to assess conformance of the product with its specification, we need a specification. But that doesn’t mean we always need specifications or that it is always appropriate (or even usually appropriate) for us to insist on receiving them.
There are always constraints. Some of them are practical, others ethical. But within those constraints, we start from the project’s needs, not from our process preferences.
Context-driven techniques?
Context-driven testing is an approach, not a technique. Our task is to do the best testing we can under the circumstances–the more techniques we know, the more options we have available when considering how to cope with a new situation.
The set of techniques–or better put, the body of knowledge–that we need is not just a testing set. In this, we follow in Jerry Weinberg’s footsteps: Start to finish, we see a software development project as a creative, complex human activity. To know how to serve the project well, we have to understand the project, its stakeholders, and their interests. Many of our core skills come from psychology, economics, ethnography, and the other socials sciences.
Closing notes
Reasonable people can advocate for standards-driven testing. Or for the idea that testing activities should be routinized to the extent that they can be delegated to less expensive and less skilled people who apply the routine directions. Or for the idea that the biggest return on investment today lies in improving those testing practices intimately tied to writing the code. These are all widely espoused views. However, even if their proponents emphasize the need to tailor these views to the specific situation, these views reflect fundamentally different starting points from context-driven testing.
Cem Kaner, J.D., Ph.D.James Bach

Good Read on Scenario Testing

2009-12-14T04:54:00.003+05:30

Scenario Testing is one of the important activity most of us get into while doing our day today activities of a software tester. It is one of the important aspects that both functional as well as non functional testers should be considerate of. Important point emphasised by Cem "Scenario testers provide an early warning system for requirements problems that would otherwise haunt the project later." He also says "Scenario testing works best for complex transactions or events, for studying end-to-end delivery of the benefits of the program, for exploring how the program will work in the hands of an experienced user, and for developing more persuasive variations of bugs found using other approaches."

Some important key factors that are highlighted are -

balance of manual test cases
importance of identifying a bug and fixing it
exploring use of program at various user levels
importance of signed off requirement doc
stakeholder thought perspective
identification of key factors of scenario testing

Read more details below from the duplicated aticle. The easy beautifully worded document explains it all. It also suggests how practically the simple approaches can be seamleassly built into our daily testing work process.

...........................................................................................................................................................

An Introduction to Scenario Testing
Cem Kaner, Florida Tech, June 2003

A slightly less complete version of this was published in Software Testing & Quality Engineering (STQE) magazine, October, 2003, with the unfortunate title, "Cem Kaner on Scenario Testing: The Power of ''What If…'' and Nine Ways to Fuel Your Imagination."
This research was partially supported by NSF Grant EIA-0113539 ITR/SY+PE: "Improving the Education of Software Testers." Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation (NSF).
Once upon a time, a software company developed a desktop publishing program for the consumer market. During development, the testers found a bug: in a small zone near the upper right corner, you couldn’t paste a graphic. They called this the “postage stamp bug.” The programmers decided this wasn’t very important. You could work around it by resizing the graphic or placing it a bit differently. The code was fragile, so they decided not to fix it.
The testers felt the postage stamp bug should be fixed. To strengthen their case, they found someone who helped her children lay out their Girl Scout newsletter. The mother wanted to format the newsletter exactly like the one she mimeographed, but she could not, because the newsletter’s logo was positioned at the postage stamp.. The company still wouldn’t fix the bug. The marketing manager said the customer only had to change the document slightly, and the programmers insisted the risk was too high.
Being a tenacious bunch, these testers didn’t give up. The marketing manager often bragged that his program could do anything PageMaker could do, so the testers dug through PageMaker marketing materials and found a brochure with a graphic you-know-where. This bug report said the postage stamp bug made it impossible to duplicate PageMaker’s advertisement. That got the marketer’s attention. A week later, the bug was fixed.
This story (loosely based on real events) is a classic illustration of a scenario test.
A scenario is a hypothetical story, used to help a person think through a complex problem or system. "Scenarios" gained popularity in military planning in the United States in the 1950's. Scenario-based planning gained wide commercial popularity after a spectacular success at Royal Dutch/Shell in the early 1970's. (For some of the details, read Scenarios: The Art of Strategic Conversation by Kees van der Heijden, Royal Dutch/Shell’s former head of scenario planning.)
A scenario test is a test based on a scenario.
I think the ideal scenario test has several characteristics:
The test is based on a story about how the program is used, including information about the motivations of the people involved.
The story is motivating. A stakeholder with influence would push to fix a program that failed this test. (Anyone affected by a program is a stakeholder. A person who can influence development decisions is a stakeholder with influence.)
The story is credible. It not only could happen in the real world; stakeholders would believe that something like it probably will happen.
The story involves a complex use of the program or a complex environment or a complex set of data.
The test results are easy to evaluate. This is valuable for all tests, but is especially important for scenarios because they are complex.
The first postage-stamp report came from a typical feature test. Everyone agreed there was a bug, but it didn’t capture the imagination of any influential stakeholders.
The second report told a credible story about a genuine member of the target market, but that customer’s inconvenience wasn’t motivating enough to convince the marketing manager to override the programmers’ concerns.
The third report told a different story that limited the marketing manager’s sales claims. That hit the marketing manager where it hurt. He insisted the bug be fixed.
Why Use Scenario Tests?
The postage stamp bug illustrated one application of scenario testing: Make a bug report more motivating.
There are several other applications, including these:
§ Learn the product
§ Connect testing to documented requirements
§ Expose failures to deliver desired benefits
§ Explore expert use of the program
§ Bring requirements-related issues to the surface, which might involve reopening old requirements discussions (with new data) or surfacing not-yet-identified requirements.
Early in testing, use scenarios to learn the product. I used to believe that an excellent way to teach testers about a product was to have them work through the manual keystroke by keystroke. For years, I did this myself and required my staff to do it. I was repeatedly confused and frustrated that I didn’t learn much this way and annoyed with staff who treated the task as low value. Colleagues (James Bach, for example) have also told me they’ve been surprised that testing the product against the manual hasn’t taught them much. John Carroll tackled this issue in his book, The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill. People don’t learn well by following checklists or material that is organized for them. They learn by doing tasks that require them to investigate the product for themselves. (Another particularly useful way to teach testers the product while developing early scenarios is to pair a subject matter expert with an experienced tester and have them investigate together.)
Scenarios are also useful to connect to documented software requirements, especially requirements modeled with use cases. Within the Rational Unified Process, a scenario is an instantiation of a use case (take a specific path through the model, assigning specific values to each variable). More complex tests are built up by designing a test that runs through a series of use cases. Ross Collard described use case scenarios in “Developing test cases from use cases” (STQE, July, 1999; available at www.stickyminds.com).
You can use scenarios to expose failures to deliver desired benefits whether or not your company creates use cases or other requirements documentation. The scenario is a story about someone trying to accomplish something with the product under test. In our example scenario, the user tried to create a newsletter that matched her mimeographed newsletter. The ability to create a newsletter that looks the way you want is a key benefit of a desktop publishing program. The ability to place a graphic on the page is a single feature you can combine with other features to obtain the benefit you want. A scenario test provides an end-to-end check on a benefit the program is supposed to deliver. Tests of individual features and mechanical combination tests of related features or their input variables (using such techniques as combinatorial testing or orthogonal arrays) are not designed to provide this kind of check.
Scenarios are also useful for exploring expert use of a program. As Larry Constantine and Lucy Lockwood discuss in their book, Software for Use, people use the program differently as they gain experience with it. Initial reactions to the program are important, but so is the stability of the program in the hands of the expert user. You may have months to test a moderately complex program. This time provides opportunity to develop expertise and simulations of expert use. During this period, one or more testers can develop full-blown applications of the software under test. For example, testers of a database manager might build a database or two. Over the months, they will add data, generate reports, fix problems, gaining expertise themselves and pushing the database to handle ever more sophisticated tasks. Along the way, especially if you staff this work in a way that combines subject matter expertise and testing skill, these testers will find credible, serious problems that would have been hard to find (hard to imagine the tests to search for them) any other reasonable way.
Scenarios are especially interesting for surfacing requirements-related controversies. Even if there is a signed-off requirements document, this reflects the agreements that project stakeholders have reached. But there are also ongoing disagreements. As Tom DeMarco and Tim Lister point out, ambiguities in requirements documents are often not accidental; they are a way of papering over disagreements (“Both Sides Always Lose: Litigation of Software-Intensive Contracts”, Cutter IT Journal, Volume XI, No. 4; April 1998).
A project’s requirements can also change dramatically for reasons that are difficult to control early in the project:
§ Key people on the project come and go. Newcomers bring new views.
§ Stakeholders’ level of influence change over time.
§ Some stakeholders don't grasp the implications of a product until they use it, and they won’t (or can’t) use it until it’s far enough developed to be useful. This is not unreasonable—in a company that makes and sells products, relatively few employees are chosen for their ability as designers or abstract thinkers.
§ Some people whose opinion will become important aren’t even invited to early analysis and design meetings. For example, to protect trade secrets, some resellers or key customers might be kept in the dark until late in the project.
§ Finally, market conditions change, especially on a long project. Competitors bring out new products. So do makers of products that are to be interoperable with the product under development, and makers of products (I/O devices, operating system, etc.) that form the technical platform and environment for the product.
A tester who suspects that a particular stakeholder would be unhappy with some aspect of the program, creates a scenario test and shows the results to that stakeholder. By creating detailed examples of how the program works, or doesn’t work, the scenario tester forces issue after issue. As a project manager, I’ve seen this done on my projects and been frustrated and annoyed by it. Issues that I thought were settled were reopened at inconvenient times, sometimes resulting in unexpected late design changes. I had to remind myself that the testers didn’t create these issues. Genuine disagreements will have their effects. In-house stakeholders (such as salespeople or help desk staff) might support the product unenthusiastically; customers might be less willing to pay for it, end users might be less willing to adopt it. Scenario testers provide an early warning system for requirements problems that would otherwise haunt the project later.
Characteristics of Good Scenarios
A scenario test has five key characteristics. It is (a) a story that is (b) motivating, (c) credible, (d) complex, and (e) easy to evaluate.
These aren’t the only good characteristics a test can have. I describe several test techniques and their strengths in “What IS a Good Test Case?” at www.testingeducation.org/articles/what_is_a_good_test_case_star_2003_paper.pdf. Another important characteristic is power: One test is more powerful than another if it’s more likely to expose a bug. I’ll have more to say about power later. For now, let’s consider the criteria that I describe as the strengths of scenario tests.
Writing a scenario involves writing a story. That’s an art. I don’t know how to teach you to be a good storyteller. What I can do is suggest some things that might be useful to include in your stories and some ways to gather and develop the ideas and information that you’ll include.
A scenario test is motivating if a stakeholder with influence wants the program to pass the test. A dry recital of steps to replicate a problem doesn’t provide information that stirs emotions in people. To make the story more motivating, tell the reader why it is important, why the user is doing what she’s doing, what she wants, and what are the consequences of failure to her. This type of information is normally abstracted out of a use case (see Alistair Cockburn’s excellent book, Writing Effective Use Cases, p. 18 and John Carroll’s discussion of the human issues missing in use cases, in Making Use: Scenario-Based Design of Human-Computer Interaction, p. 236-37.) Along with impact on the user, a highly motivating bug report might consider the impact of failure on the user’s business or on your company (the software developer). For example, a bug that only modestly impacts the user but causes them to flood your company with phone calls would probably be considered serious. A scenario that brings out such effects would be influential.
A scenario is credible if a stakeholder with influence believes it will probably happen. Sometimes you can establish credibility simply by referring to a requirements specification. In many projects, though, you won’t have these specs or they won’t cover your situation. Each approach discussed below is useful for creating credible tests.
A complex story involves many features. You can create simplistic stories that involve only one feature, but why bother? Other techniques, such as domain testing, easy to apply to single features and more focused on developing power in these simple situations. The strength of the scenario is that it can help you discover problems in the relationships among the features.
This brings us to power. A technique (scenario testing) focused on developing credible, motivating tests is not as likely to bring quickly to mind the extreme cases that power-focused techniques (such as stress, risk-based, and domain testing) are so good for. They are the straightest lines to failures, but the failures they find are often dismissed as unrealistic, too extreme to be of interest. One way to increase a scenario’s power is to exaggerate slightly. When someone in your story does something that sets a variable’s value, make that value a bit more extreme. Make sequences of events more complicated; add a few more people or documents. Hans Buwalda is a master of this. He calls these types of scenario tests, “soap operas.” (See “Soap Opera Testing” at www.stickyminds.com.)
The final characteristic that I describe for scenario tests is ease of evaluation—that is, it should be easy to tell whether the program passed or failed. Of course, every test result should be easy to evaluate. However, the more complex the test, the more likely that the tester will accept a plausible-looking result as correct. Glen Myers discussed this in his classic, Art of Software Testing, and I’ve seen other expensive examples of bugs exposed by a test but not recognized by the tester.
Twelve Ways to Create Good Scenarios
Write life histories for objects in the system.
List possible users, analyze their interests and objectives.
Consider disfavored users: how do they want to abuse your system?
List “system events.” How does the system handle them?
List “special events.” What accommodations does the system make for these?
List benefits and create end-to-end tasks to check them.
Interview users about famous challenges and failures of the old system.
Work alongside users to see how they work and what they do.
Read about what systems like this are supposed to do.
Study complaints about the predecessor to this system or its competitors.
Create a mock business. Treat it as real and process its data.
Try converting real-life data from a competing or predecessor application.
Twelve Ways to Create Good Scenarios
Designing scenario tests is much like doing a requirements analysis, but is not requirements analysis. They rely on similar information but use it differently.
§ The requirements analyst tries to foster agreement about the system to be built. The tester exploits disagreements to predict problems with the system.
§ The tester doesn’t have to reach conclusions or make recommendations about how the product should work. Her task is to expose credible concerns to the stakeholders.
§ The tester doesn’t have to make the product design tradeoffs. She exposes the consequences of those tradeoffs, especially unanticipated or more serious consequences than expected.
§ The tester doesn’t have to respect prior agreements. (Caution: testers who belabor the wrong issues lose credibility.)
§ The scenario tester’s work need not be exhaustive, just useful.
Because she has a different perspective, the scenario tester will often do her own product and marketing research while she tests, on top of or independently of research done by Marketing. Here are some useful ways to guide your research. It might seem that you need to know a lot about the system to use these and, yes, the more you know, the more you can do. However, even if you’re new to the system, paying attention to a few of these as you learn the system can help you design interesting scenarios.
1. Write life histories for objects in the system.
Imagine a program that manages life insurance policies. Someone applies for a policy. Is he insurable? Is he applying for himself or a policy on his wife, child, friend, competitor? Who is he allowed to insure? Why? Suppose you issue the policy. In the future he might pay late, borrow against the policy, change the beneficiary, threaten to (but not actually) cancel it, appear to (but not) die—lots can happen. Eventually, the policy will terminate by paying out or expiring or being cancelled. You can write many stories to trace different start-to-finish histories of these policies. The system should be able to handle each story. (Thanks to Hans Schaefer for describing this approach to me.)
2. List possible users, analyze their interests and objectives.
It’s easy to say, “List all the possible users” but not so easy to list them. Don Gause and Jerry Weinberg provide a useful brainstorming list in Exploring Requirements, page 72.
Once you identify a user, try to imagine some of her interests. For example, think of a retailer’s inventory control program. Users include warehouse staff, bookkeepers, store managers, salespeople, etc. Focus on the store manager. She wants to maximize store sales, minimize writedowns (explained below), and impress visiting executives by looking organized. These are examples of her interests. She will value the system if it furthers her interests.
Focus on one interests, such as minimizing writedowns. A store takes a writedown on an item when it reduces the item’s value in its records. From there, the store might sell the item for much less, perhaps below original cost, or even give it away. If the manager’s pay depends on store profits, writedowns shrink her pay. Some inventory systems can contrast sales patterns across the company’s stores. An item that sells well in one store might sell poorly another store. Both store managers have an interest in transferring that stock from the low-sale store to the high-sale one, but if they don’t discover the trend soon enough, the sales season might be over (such as Xmas season for games) before they can make the transfer. A slow system would show them missed opportunities, frustrating them instead of facilitating profit-enhancing transfers.
In thinking about the interest (minimize writedowns), we identified an objective the manager has for the system, something it can do for her. Her objective is to quickly discover differences in sales patterns across stores. From here, you look for features that serve that objective. Build tests that set up sales patterns (over several weeks) in different items at different stores, decide how the system should respond to them and watch what it actually does. Note that under your analysis, it’s an issue if the system misses clear patterns, even if all programmed features work as specified.
3. Consider disfavored users: how do they want to abuse your system?
As Gause and Weinberg point out, some users are disfavored. For example, consider an accounting system and an embezzling employee. This user’s interest is to get more money. His objective is to use this system to steal the money. This is disfavored: the system should make this harder for the disfavored user rather than easier.
4. List “system events.” How does the system handle them?
An event is any occurrence that the system is designed to respond to. In Mastering the Requirements Process, Robertson and Robertson write about business events, events that have meaning to the business, such as placing an order for a book or applying for an insurance policy. As another example, in a real-time system, anything that generates an interrupt is an event. For any event, you’d like to understand its purpose, what the system is supposed to do with it, business rules associated with it, and so on. Robertson and Robertson make several suggestions for finding out this kind of information.
5. List “special events.” What accommodations does the system make for these?
Special events are predictable but unusual occurrences that require special handling. For example, a billing system might do special things year-end. The inventory system might treat transfers differently (record quantities but not other data) when special goods are brought in for clearance sales.
6. List benefits and create end-to-end tasks to check them.
What benefits is the system supposed to provide? If the current project is an upgrade, what benefits will the upgrade bring? Don’t rely only on an official list of benefits. Ask stakeholders what they think the benefits of the system are supposed to be. Look for misunderstandings and conflicts among the stakeholders.
7. Interview users about famous challenges and failures of the old system.
Meet with users (and other stakeholders) individually and in groups. Ask them to describe the basic transactions they’re involved with. Get them to draw diagrams and explain how things work. As they warm up, encourage them to tell you the system’s funny stories, the crazy things people tried to do with the system. If you’re building a replacement system, learn what happened with the predecessor. Along with the funny stories, collect stories of annoying failures and strange things people tried that the system couldn’t handle gracefully. Later, you can sort out how “strange” or “crazy” these attempted uses of the system were. What you’re fishing for are special cases that had memorable results but were probably not considered credible enough to mention to the requirements analyst. Hans Buwalda talks about these types of interviews (www.stickyminds.com).
8. Work alongside users to see how they work and what they do.
While designing a telephone operator’s console (a specially designed phone), I traveled around the country watching operator/receptionists use their phones. Later, leading the phone company’s test group, I visited customer sites to sit with them through training, watch them install beta versions of hardware and software, and watch ongoing use of the system. This provided invaluable data. Any time you can spend working with users, learning how they do their work, will give you ideas for scenarios.
9. Read about what systems like this are supposed to do.
So you’re about to test an inventory management program and you’ve never used one before. Where should you look? I just checked Amazon and found 33 books with titles like What To Look For In Warehouse Management System Software, and Quick Response: Managing the Supply Chain to Meet Consumer Demand. Google gave 26,100 hits for “inventory management system.” There’s a wealth of material for any type of business system, documenting user expectations, common and uncommon scenarios, competitive issues and so on.
If subject matter experts are unavailable, you can learn much on your own about the business processes, consumer products, medical diagnostic methods or whatever your software automates. You just have to spend the time.
10. Study complaints about the predecessor to this system or its competitors.
Software vendors usually create a database of customer complaints. Companies that write software for their own use often have an in-house help desk (user support) group that keeps records of user problems. Read the complaints. Take “user errors” seriously—they reflect ways that the users expected the system to work, or things they expected the system to do.
You might also find complaints about your product or similar ones online.
11. Create a mock business. Treat it as real and process its data.
Your goal in this style of testing is to simulate a real user of the product. For example, if you’re testing a word processor, write documents—real ones that you need in your work.
Try to find time to simulate a business that would use this software heavily. Make the simulation realistic. Build your database one transaction at a time. Run reports and check them against your data. Run the special events. Read the newspaper and create situations in your company’s workflow that happen to other companies of your kind. Be realistic, be demanding. Push the system as hard as you would push it if this really were your business. And complain loudly (write bug reports) if you can’t do what you believe you should be able to do.
Not everyone is suited to this approach, but I’ve seen it used with superb effect. In the hands of one skilled tester, this technique exposed database corruptors, report miscalculators, and many other compelling bugs that showed up under more complex conditions than we would have otherwise tested.
12. Try converting real-life data from a competing or predecessor application.
Running existing data (your data or data from customers) through your new system is a time-honored technique.
A benefit of this approach is that the data include special cases, allowances for exceptional events, and other oddities that develop over a few years of use and abuse of a system.
A big risk of this approach is that output can look plausible but be wrong. Unless you check the results very carefully, the test will expose bugs that you simply don’t notice. According to Glen Myers, The Art of Software Testing, 35% of the bugs that IBM found in the field had been exposed by tests but not recognized as bugs by the testers. Many of them came from this type of testing.
Risks of Scenario Testing
I’ve seen three serious problems with scenario tests:
§ Other approaches are better for testing early, unstable code. The scenario test is complex, involving many features. If the first feature is broken, the rest of the test can’t be run. Once that feature is fixed, the next broken feature blocks the test. In some companies, complex tests fail and fail all through the project, exposing one or two new bugs at a time. Discovery of some bugs has been delayed a long time until scenario-blocking bugs were cleared out of the way. Test each feature in isolation before testing scenarios, to efficiently expose problems as soon as they appear.
§ Scenario tests are not designed for coverage of the program. It takes exceptional care to cover all the features or requirements in a set of scenario tests. Covering all the program’s statements simply isn’t achieved this way.
§ Scenario tests are often heavily documented and used time and again. This seems efficient, given all the work it can take to create a good scenario. But scenario tests often expose design errors rather than coding errors. The second or third time around, you’ve learned what this test will teach you about the design. Scenarios are interesting tests for coding errors because they combine so many features and so much data. However, there are so many interesting combinations to test that I think it makes more sense to try different variations of the scenario instead of the same old test. You’re less likely to find new bugs with combinations the program has already shown it can handle. Do regression testing with single-feature tests or unit tests, not scenarios.
In Sum
Scenario testing isn’t the only type of testing. For notes on other types of tests that you might use in combination with scenario testing, see my paper, What IS a Good Test Case, at http://www.testingeducation.org/articles/what_is_a_good_test_case_star_2003_paper.pdf).
Scenario testing works best for complex transactions or events, for studying end-to-end delivery of the benefits of the program, for exploring how the program will work in the hands of an experienced user, and for developing more persuasive variations of bugs found using other approaches.

Interesting title of Web seminar, Practical Testing and Evolution: An Enterprise-wide Automation Framework

2009-11-25T20:59:00.002+05:30

not sure on how practical or objective the suggested approach will be. Have seen an earlier framework from them that was nice.

Web seminar by ThoughtWorks test automation experts Jeff Rogers and Kristan Vingrys provide guiding principles for developing long-term automation strategies including what to automate, setting reasonable automation strategies and goals, and how to evolve your test suites over time. .............sounds interesting.
Practical Testing and Evolution: An Enterprise-wide Automation Framework.....Title
Test automation efforts that stumble and die are most often the result of misconceived perceptions of the effort and resources necessary to implement a successful, long-lasting automation framework. ......what's new ?
In this event, you will also learn: ....sounds interesting

Automation strategies by product and organizational, enterprise-wide tactics to get your automation efforts to live beyond a single project
Driving automation early and having artifacts live on continuously–from genesis through development and beyond support and maintenance
Using automation to get quick feedback on the viability of the product

Comedy of errors !!

2009-11-24T00:06:00.007+05:30

Sometime back myself and Ajay had a chat ... and how can acronyms confuse one is a classy example here !! These sections are highlighted in blue.

Ajay: Hi Meeta,

me: hi

Ajay: you prefer twitter or gmail chat or nothing (considering the time)
me: btw i hv been planning to sleep since 10 pm but been consistently on

Ajay: That's the power of ET discussions I would say

me: u bet

Ajay: why do you think managers need details of a process? They are afraid that they do not know what the tester is doing?

me: nah ! they do not know what they or their team is doing. They do not have competency in most of the cases to understand what is rightly done and what is not hence the approach

Ajay: "a document which has been passed on by seniors and told that this would work in most cases" something like that?why is there a gap b/w good tester and a good manager?

me: kind of low self confidence is another reason, bad technical skills is yet another. There is never a gap between a good tester and a good manager

Ajay: is it true that testers with bad tech skills are promoted to management faster than good testers?

me: gap will be there only between a good tester and a bad manager

Ajay: If you can't be replaced, you can't be promoted stuff
me: nah !promotion in product companies is due to your skills. Mostly promotion in service industry is due to your buttering skills

Ajay: good to know why is your smiley not animated?on google talk or Gmail?

Ajay: How come iPhone testing?

me: no idea, why it does not get animated ...test it out

Ajay: so I asked: are you on Gmail or Google talk?

me: iphone- generally has been interesting me for sometime

Ajay: which browser and which version ok

me: IE7gmail

Ajay: ok let me try to simulate it

Ajay: Check from IE 6

me: cant revert using office laptop

Ajay: no no don't

me: sab band ho jaayega if i change any settings

Ajay: XP, Vista?

me: n i'll hv to spend whole of tomm with my ccd guy XP

Ajay: you have chrome installed?

me: not allowed
Ajay: could you please try once with chrome oh ok

oh ok ccd? why ccd? no office?

me: they'll immediately block my official mbox if i download n install any thing directly. ccd is our customer connection division. They take care of our hardware

Ajay: ROFL

me: whats that now ?

Ajay: Cafe Coffee Day

me: mujhe laga tha

Ajay: Rolling on Floor Laughing

me: tum yahi soch rahe hoge isiliye acronyms se door rehne ko kehte hain what is AFD btw ? Ajay: once in my Engineering interview, the external guide asked me do you know ATM- Away from Desk?I said Yes and was kind of shocked that he would give his ATM card and password and ask me to withdraw money

me: ok, gives me a new topic for blog

Ajay: and then realized that he was talking about Adobe Type Manager

New Video on BBST

2009-11-23T21:36:00.003+05:30

Found a new video on BBST by Cem posted on 7 Nov 09. I don't remember seeing it before. If you have not yet seen it, catch it on the link www.testingeducation.org/BBST/videos/CopyrightInterestAnalysis.wmv

talks about - "To know how to serve the project well, we have to understand the project, its stakeholders, and their interests."

KT Scripting our thinking caps ?

2009-11-23T21:07:00.003+05:30

Today Srini sent a tweet

------------------------------------------------

shrinik
@mheusser What is the deal about Skill Transfer (ST)? It sounds like a data transfer through an USB jump drive !!! In IT we call it as KT

-------------------------------------------------

made me think how seriously or casually we take the information gathering .......the sole reason being we do it so often ? or we are bored doing it so often ?

I liked his term "data transfer". It so aptly fits into the mechanical act of sharing information.

The whole building of the "testing castle" lies on this foundation of "KT".

"KT" not only helps us understand the objective to build into test, but also expectations for which tests have to be written.......but indirectly does it "script" our thought process ? ......are we still ready to explore and experiment more exhaustively ? ....... are we thinking more than what is feeded into us ? ......... are we asking sufficient questions beyond what is provided to us as information ? ..................??????

Worrying makes you cross the bridge before you come to it

2009-11-23T20:44:00.004+05:30

Nice Article, recently read.
Tester's read the qs inbetween carefully. Can you relate it someplace ?
......................................................................................................
Worrying makes you cross the bridge before you come to it !!
------------- By Harvey Mackay

Recently I saw a survey that says 40 percent of the things we worry about never happen, 30 percent are in the past and can't be helped, 12 percent concern the affairs of others that aren't our business, 10 percent are about sickness--either real or imagined-- and 8 percent are worth worrying about. I would submit that even the 8 percent aren't really worth the energy of worry. Did you know that the English word worry is derived from an Anglo-Saxon word that means to strangle or to choke? That's easy to believe. People do literally worry themselves to death. . . or heart disease, high blood pressure, ulcers, nervous disorders and all sorts of other nasty conditions. Is it worth it? Some folks seem to think this is a '90s phenomenon, but I've got news for you: advice about worry goes back as far as the Bible. We didn't invent it. We just need to find a way to keep it from ruling our lives. I've been spending a lot of time in bookstores lately, in the middle of a 35-city book tour. From one coast to the other, north to south, some of the most popular self-help books concern worry, stress, and simplifying your life. I have a couple of favorite books to recommend. First, an oldie. Dale Carnegie's "How To Stop Worrying and Start Living." It was first published in 1948, but the advice is just as fresh and valuable as it was then and is right-on for the new millennium. Being a chronic list maker, I found two sections that really knocked my socks off. Both were about business people trying to solve problems without the added burden of worrying. Carnegie credits Willis H. Carrier, whose name appears on most of our air conditioners, with these silver bullets: Analyze the situation honestly and figure out what is the worst possible thing that could happen. Prepare yourself mentally to accept the worst, if necessary. Then calmly try to improve upon the worst, which you have already agreed mentally to accept. Bingo! You can handle anything now. You know what you have to do; it's just a matter of doing it. Without worrying. Another approach I like is a system put into practice at a large publishing company by an executive, named Leon. He was sick and tired of boring and unproductive meetings marked by excessive hand-wringing. He enforced a rule that everyone who wished to present a problem to him first had to submit a memo answering these four questions:
What's the problem?
What's the cause of the problem?
What are all possible solutions to the problem?
Which solution do you suggest?
Leon rarely has to deal with problems anymore, and he doesn't worry about them. He's found that his associates have used the system to find workable solutions without tying up hours in useless meetings. He estimates that he has eliminated three-fourths of his meeting time and has improved his productivity, health and happiness. Is he just passing the buck? Of course not! He's paying those folks to do their jobs, and he's giving them great training at decision-making. Another little gem that's made its way to a #1 New York Times bestseller is Richard Carlson's "Don't Sweat the Small Stuff, and it's all small stuff." Of course, being an aphorism junkie and slave to short snappy chapters, I've found this book can improve perspective in 100 small doses. I love the chapter titles: "Repeat to Yourself, 'Life Isn't an Emergency,'" "Practice Ignoring Negative Thoughts," and my favorite, "Let Go of the Idea that Gentle, Relaxed People Can't Be Super achievers." The point is, you can't saw sawdust. A day of worry is more exhausting than a day of work. People get so busy worrying about yesterday or tomorrow, they forget about today. And today is what you have to work with. I remember the story of the fighter who, after taking the full count in a late round of a brawl, finally came to in the dressing room. As his head cleared and he realized what had happened, he said to his manager: "Boy, did I have him worried. He thought he killed me." Now that's putting the worry where it belongs.

Do You Spell Testing?A Mnemonic to Jump-Start Exploratory TestingBy James Bach

2009-11-22T16:24:00.004+05:30

This is a very interesting post from James Blog. Replicting here for easy read. You can check original directly at http://www.stickyminds.com/sitewide.asp?ObjectId=2510&Function=DETAILBROWSE&ObjectType=COL&sqry=*Z(SM)*J(MIXED)*R(relevance)*K(simplesite)*F(A+mnemonic+to+jump+start+testing)*&sidx=0&sopp=10&sitewide.asp?sid=1&sqry=*Z(SM)*J(MIXED)*R(relevance)*K(simplesite)*F(A+mnemonic+to+jump+start+testing)*&sidx=0&sopp=10

------------------------------------------------------------------------------------------

Do You Spell Testing?A Mnemonic to Jump-Start Exploratory TestingBy James Bach

In exploratory testing, we design and execute tests in real time. But how do we organize our minds so that we think of worthwhile tests? One way is through the use of heuristics and mnemonics. A heuristic is “a rule of thumb, simplification, or educated guess.” For example, the idea of looking under a welcome mat to find a key is a heuristic. A mnemonic, by contrast, is a “word, rhyme, or other memory aid used to associate a complex or lengthy set of information with something that is simple and easy to remember.” Heuristics and mnemonics go together very well to help us solve problems under pressure. SFDPO Spells Testing A mnemonic and heuristic I use a lot in testing is “San Francisco Depot,” or SFDPO. These letters stand for Structure, Function, Data, Platform, and Operations. Each word represents a different aspect of a software product. By thinking of the product from each of those points of view, I think of many interesting tests. So, when I’m asked to test something I haven’t seen before, I say “San Francisco Depot” to myself, recite each of the five product element categories and begin thinking of what I will test. Structure (what the product is): What files does it have? Do I know anything about how it was built? Is it one program or many? What physical material comes with it? Can I test it module by module? Function (what the product does): What are its functions? What kind of error handling does it do? What kind of user interface does it have? Does it do anything that is not visible to the user? How does it interface with the operating system? Data (what it processes): What kinds of input does it process? What does its output look like? What kinds of modes or states can it be in? Does it come packaged with preset data? Is any of its input sensitive to timing or sequencing? Platform (what it depends upon): What operating systems does it run on? Does the environment have to be configured in any special way? Does it depend on third-party components? Operations (how it will be used): Who will use it? Where and how will they use it? What will they use it for? Are there certain things that users are more likely to do? Is there user data we could get to help make the tests more realistic? Bringing Ideas to Light I can get ideas about any product more quickly by using little tricks like SFDPO. But it isn’t just speed I like, it’s reliability. Before I discovered SFDPO, I could think of a lot of ideas for tests, but I felt those ideas were random and scattered. I had no way of assessing the completeness of my analysis. Now that I have memorized these heuristics and mnemonics, I know that I still may forget to test something, but at least I have systematically visited the major aspects of the product. I now have heuristics for everything from test techniques to quality criteria. Just because you know something doesn’t mean you’ll remember it when the need arises. SFDPO is not a template or a test plan, it’s just a way to bring important ideas into your conscious mind while you’re testing. It’s part of your intellectual toolkit. The key thing if you want to become an excellent and reliable exploratory tester is to begin collecting and creating an inventory of heuristics that work for you. Meanwhile, remember that there is no wisdom in heuristics. The wisdom is in you. Heuristics wake you up to ideas, like a sort of cognitive alarm clock, but can’t tell you for sure what the right course of action is here and now. That’s where skill and experience come in. Good testing is a subtle craft. You should have good tools for the job.

Ever Scrabbled ?

2009-11-22T15:07:00.006+05:30

This has got to be one of the most innovative junk e -mails I've received in a while.
Someone out there either has too much spare time or is deadly at Scrabble. (Wait till you see the last one)!

Tester's what say ??

DILIP VENGSARKAR When you rearrange the letters: SPARKLING DRIVE
PRINCESS DIANA When you rearrange the letters: END IS A CAR SPIN
MONICA LEWINSKY When you rearrange the letters: NICE SILKY WOMAN
DORMITORY: When you rearrange the letters: DIRTY ROOM
ASTRONOMER: When you rearrange the letters: MOON STARER
DESPERATION: When you rearrange the letters: A ROPE ENDS IT
THE EYES: When you rearrange the letters: THEY SEE
A DECIMAL POINT: When you rearrange the letters: IM A DOT IN PLACE
AND FOR THE GRAND FINALE:
MOTHER-IN-LAW: When you rearrange the letters: WOMAN HITLER

Easy Tips on Art of Writing Better

2009-11-22T12:35:00.014+05:30

One of my new friends in testing space asked me to review a small piece of writing.
The gap in the work was setting the symphony between words and sentences and the sync of all the words. I was missing the harmony from the orchestra.
Thought will pen a few quick key tips for our new friends experimenting with writing that have been my learning's in this space.
Here you go ....

Chuck the thought what others will think on your writing out of window. People will think what they want to and you will come to know of it only once they read it and give their comments. Give them a chance to speak for you to improve. You need critics towards building success.

Learning - Don't Assume. Believe in what you see.

Ask a question "WHY" behind every word and sentence and see if you are able to visualize it from what you have written. You need to "script" readers thought process. "Why, What and How " are most important.

Learning- your reader does not get lost trying to assume / interpret things while reading your work.

Don't contradict yourself through the work. Its a catch.

Learning - leaves a bad impression on the reader about you

Know your vocabulary well. Do not experiment with words if you do not understand them in depth. The simpler words you choose, more audience you get.

Learning - Let the reader understand what you want to say easily.

Don't assume and build perception around things that you do not know basics and facts about. If you have an idea, bounce it as an idea. If you have a learning, bounce it as a learning. If it is a new approach you have thought of, let it go as that.

Learning- Clarity solves many a problems and misconceptions.

Do not be influenced with others to such an extent that you loose novelty in whatyou wanted to write. Easy way that I have found to handle it is, first write you ideas on a piece of paper. then start to read about other's ideas/ opinions. Document what you feel is relevant on another piece of paper. Compare both notes. Now with relevant credits document what you feel is your novel ideation.

Learning - Research well. Give due credits. Be ethical.

Remember - Think about WHY’s the person who reads it will ask after reading what u want to write.

Welcome to the world of effective articulation !!

Experience of a job seeker !!

2009-11-22T10:11:00.005+05:30

Been talking to a friend .....he quit working with a service company giant in India and started on his own recently.
While the business was slow due to recession, he thought to appear for some interviews....
He says" if business does not help, I used to go to interviews very often and tell people that I came out of "XXX" to start business I never got offers.......when I told them I got chucked out they offer me ..." :)

Irony of this job space !!

Performance measurement analyst role and responsibilities

2009-11-22T09:54:00.001+05:30

Recently read ....Performance measurement analyst role and responsibilities
By Lior Arussy, President, Strativity Group

What are the main job functions of a performance measurement analyst? How is the person in this role responsible for the customer experience?
Customer experience success is highly dependent on measuring what matters the most to customers. From establishing the right measures to linking them to real results, a performance measurement analyst needs to be fully aware of what the customer experience is about and how to measure it and make the results actionable.
The roles and responsibilities will include:
Identify key customer measurements for the whole organization
Identify customer experience measures per touch point
Determine frequency and scope of measurements
Link measurement results to actual customer spend to justify investment
Link customer measurements to operational measurements to enable change
Track changes and improvements

Gartner's top 10 strategic technologies for 2010

2009-11-22T09:45:00.003+05:30

If you have not yet read ...

Plan your test strategeis and competancy upgrades.

...........................................................................................................................................
Gartner's top 10 strategic technologies for 2010
By Anne McCrory, Editorial Director22 Oct 2009
ORLANDO, FLA. -- Gartner Inc. released its top 10 strategic technologies for 2010 this week, a list that paints a picture of an agile, mobile, secure enterprise where advanced analytics and social media identify early warning signs of failure and predict emerging business trends.
That vision was further extolled in numerous sessions at the annual Gartner Symposium/ ITxpo, where the research firm's executives described the past year as possibly the worst ever for IT. "Trust declined more dramatically in the past year than ever before," Gartner CEO Gene Hall said in his opening remarks.
Though IT budgets won't increase at many organizations, Gartner predicted a 3.3% growth rate for IT spending next year, plus a shift from capital to operating expenditures as "IT costs become scalable and elastic with the business," said Peter Sondergaard, senior vice president of research.
The top 10 strategic technologies list, proffered annually by David Cearley and Carl Claunch, wasn't the only such list offered up at the event. Sondergaard offered a list of nine focus areas based on an analysis of what people are searching for on Gartner's website. The top tier: Cost management, which will continue to be a top issue for 2010 but will encompass risk and growth as well; cloud computing, which will move from the discussion phase to small pilots; and process optimization around enterprise applications (ERP, customer relationship management, supply chain management) that will allow organizations to get more out of these investments.
His second tier included business intelligence; virtualization, as organizations create the foundation of a cloud infrastructure and move from owned to shared assets; and social media. The latter isn't just for so-called digital natives but also for "silver surfers," those over 60 who will become the most important segment in the next 10 years, he said.
The top 10 strategic technologies for 2010
Cearley and Claunch's list focuses on technologies that have the "potential for significant impact on the enterprise during the next three years." Some have fallen off the list from past years because companies should have already incorporated them into their plans (like service-oriented architecture or master data management), their adoption has slowed (unified communications) or there won't be market shifts warranting inclusion on the 2010 list (specialized systems and servers beyond blades). Others have come back in new forms: virtualization, which topped the 2009 list, is now embedded in several wider areas as well as standing on its own for a specific usage.
Here, then, is the list for 2010:
Gartner's 2009 list
The top 10 strategic technologies for 2009 were as follows:1. Virtualization2. Business intelligence3. Cloud computing4. Green IT5. Unified communications6. Social software and social networking7. Web-oriented architecture8. Enterprise mashups9. Specialized systems10. Servers -- beyond blades
1. Cloud computing. Organizations should think about how to approach the cloud in terms of using cloud services, developing cloud-based applications and implementing private cloud computing environments. "Everything will be available as a service," Cearley said. "That doesn't mean you use it all [or] move it all there."
2. Advanced analytics. Real-time data analysis will enable fraud detection on one hand and prediction and simulation on the other, as organizations use data to look ahead.
3. Client computing. Enterprises need to develop a five- to eight-year client computing roadmap before making near-term decisions such as whether or how to upgrade client hardware or move to Windows 7. The progression of desktop virtualization technology and the range of devices available make this an important analysis. "Build a strategic client computing roadmap bringing all issues and devices together, or you will be following vendor roadmaps," Cearley said.
4. IT for green. The "green" concept has moved beyond energy-efficient data centers to using IT to enable green throughout the enterprise. For example, an organization could use IT to analyze and optimize shipping of goods.
5. Reshaping the data center. A flexible "pod" model, where data center sections can be independently heated, cooled and powered, allows the organization to light up new sections only when needed.
6. Social computing. Organizations need to examine the use of social media by both internal and external constituents and figure out how to govern it. Social network analysis can be used both to detect fraud and to change business processes to boost internal efficiency.
7. Security -- activity monitoring. As targeted attacks rise and cloud computing adds complexity, organizations need to identify a longer-term plan for how all of their security technologies come together. Security incident and event management devices, for example, are one approach that is becoming mainstream.
8. Flash memory. This technology, made ubiquitous by popular USB sticks, is a faster, although more expensive, storage alternative. Price drops mean it will offer a "new layer of the storage hierarchy in servers and client computers," Gartner said.
9. Virtualization for availability. Live migration technology such as VMware Inc.'s VMotion will enable the use of virtualization for high performance, possibly displacing failover cluster software and even fault-tolerant hardware.
10. Mobile applications. Mobile is at a tipping point, given the proliferation of handheld devices and their power and storage.

Requirements and testing

2009-11-22T09:21:00.002+05:30

"Requirements and testing" .........below mentioned points are from Richard Bender's approach

Writing Testable Requirements - Deliver requirements that are concise, accurate, modular, and highly testable.
Requirements-Based Testing - Identify important ambiguities in requirements specifications before coding starts.
Mastering the Requirements Process – Learn the complete process of eliciting and writing testable requirements.
Requirements Modeling – Understand how to find and verify requirements with models.
Essential Software Requirements – Use powerful techniques for identifying, documenting, and verifying requirements, including formal Plan-Driven and Agile requirements approaches.
Extending Requirements - Extend the foundations laid in the “Mastering the Requirements Process” course by learning how to choose the best set of requirements to give you a competitive edge and still get your product to market on time.

What categories of tools we should be looking for while thinking the tester way ?

2009-11-21T11:56:00.003+05:30

What makes sense for a tester to have an extended support in terms of tools ........

Questions to ask -

do we really need them ?
will they help me perform better in this situation ?
are these tools scripting ideas & inputs ?
are they able to "think" cognitively like you and me ?
can they really unearth bugs ?
will they increase my productivity ?

Specific to Automation tools

Are they able to let me explore the inputs ?
am I experimenting while doing testing ?
can I make them work they way I'd want them to work ?
Are they actually doing what I wanted them to do while executing a script ?

Checkers .........Testers ??

2009-11-21T07:57:00.005+05:30

Think tanks .........where are you ??????
This was the question I asked, while I sat through Rapid testing class with Michael Bolton as my instructor ............on Nov 17 & 18 2009 ............
It made me realize how mundane our daily activities have become ........ what are our customers primarily focussed on .......... what are we primarily focussed on ..................?????????
Cutomers - test cases that pass or fail .......success criteria .....pass ;
We - how many pass test cases go from my desk.......
Sadly ........the focus is no where exploratory most of the times ......:(

Metrics is the BUZZ word all over......how many times are we measuring and awarding the maximum bugs identified ?
Lets make the change and do it .......... Let exploratory minds think !!

Wake up time ......... !!

Amazing Energy Group !

2009-11-21T07:56:00.003+05:30

Weekend Testers !!

Attended STC on 19 Nov 09 ........and you should have been there to hear from Ajay B on the thought wave called "Weekend Testers" ...........what a redention of thoughts !! ...........it was a housefull and had a standing ovation from many including Michael Bolton !!

Great Going Folks !!

Lets be the leaders towards making the change the world needs ........."THINKING TESTERS" !!

Learning's from Michael's Rapid Testing class

2009-11-21T07:55:00.002+05:30

...................................... yet to scribe

Thanks Parimala :)

2009-11-21T07:52:00.003+05:30

While I am at this page, how can I not thank Parimala ......... who asked me a simple question ......why have I stopped blogging ??

and will definitely like to thank her....... coz that statement made me open this page and realize how quick time passes by ........and that did not let this become my new year resolution ;)

Come back !! Wake up time !

2009-11-21T07:39:00.006+05:30

I never realized that it has been more than a year that I published something on this page :)

Attended a Rapid Testing workshop with Michael Bolton in Bangalore on 17 & 18 Nov 09.........and was I amazed at his class handling ?? .......

.......All that could be said was WOW !! ..............this is the way to engage the class ........ perfect one !!

and how can I NOT blog about this .........

Thanks Michael !!

for opportunity to learn from you .....
for teaching us the differentiator of good testors ......... "checkers and Tester" http://www.testingreflections.com/node/view/2709
for "food for thought" bouncers
and for waking me up and bringing me back to this world :)

Interesting Thoughts on Achieving More

2008-05-08T19:08:00.002+05:30

Found the below text on net ....... though many of us know these but hardly implement them 100% in our practical lives ........ these are simple and very well worded by Penelope Trunk .......a good read.
-------------------------------------------------------------------------------------
Five Steps to Being More Productive
by Penelope Trunk
Posted on Wednesday, May 9, 2007, 12:00AM
One of the best ways to distinguish yourself at work is through productivity. We're all sifting through too much email, we all have more work than we can ever get done, and we all have access to more information than we could ever consume.
The people who make the best decisions about how to process this information quickly and effectively are the people who will stand out in the workplace.
Productivity Is a Skill
It used to be that people went to work from 9 to 5, and if you were serious about your career you worked much longer hours. But few people still aspire to a 9-to-5 job, and most of us use productivity tools to manage our time in a way that facilitates a great personal life and a great work life.
Thousands of people read productivity tips on Lifehacker.com every day of the week, and dissect David Allen's bestselling book "Getting Things Done: The Art of Stress-Free Productivity" with the fervor of an English lit student explicating "Ulysses."
Productivity skills are a new measure of career potential, so you need to develop them. Here are five ways to excel at productivity:
1. Do the most important thing first.
Gina Trapani, the editor of Lifehacker.com, calls this a "morning dash." She sits down at her desk and does the No. 1 item on her to-do list so that she knows it's finished.
This requires a lot of prior planning. You need to write an accurate, prioritized list and you need to block out a portion of your morning to accomplish your No. 1 task uninterrupted.
The hardest thing about living by a to-do list is that you have to constantly ask yourself the difficult question, "What's the most important thing to me right now?"
A good to-do list includes long-term and short-term projects, and it integrates all aspects of your life. "Pick out lawn furniture" is on the same list at "go to the board meeting" because both are competing for the same, limited amount of your time.
2. Keep your inbox empty.
Your inbox is not your to-do list; your to-do list is something you compile and prioritize. If your inbox is your to-do list, then you have no control over what you're doing -- you've ceded it to whoever sends you an email next.
Productivity wizards experience less information overload because they deal with an email as soon as they've read it -- respond, file, or delete. Nothing stays in the inbox. Reading each email four or five times while it languishes in your inbox is a huge waste of time, and totally impractical given the amount of email we all receive.
3. Become a realist about time.
You can schedule and schedule and schedule, but it won't do any good unless you get more realistic about time. Develop a sense of who in your life is good at estimating time and who isn't, because you need to be able to compensate for the people who mess up your schedule with poor time estimates.
In general, though, we're all bad at estimating time. We overestimate how much time we have and cope poorly with the fact that what we do with our time changes from day to day. So the first step toward being good at estimating time is to understand your own inherent weaknesses. Then, at least, you can start compensating.
4. Focus on what you're doing so you can do it faster and better.
Most of the time, multitasking doesn't help you. It works for short, repetitive tasks that you're very familiar with. But you don't want to develop good work habits for boring work. You'd probably prefer to stretch your brain and try new things, and that kind of work requires focus.
A wide range of research has shown that even if you can talk on the phone and use email and IM at the same time, multitasking decreases your productivity. Our creative powers are compromised when we multitask.
The other common culprit to focusing is lack of sleep. Some people think they can use caffeine to dull the need for sleep, but it catches up with them. Fortunately, you only need a 10-minute nap to get your brain back on track. And when you're making up for several nights of lost sleep, you don't need to make it all up -- you just need seven hours to get back on your game.
5. Delegate.
Once you know what's most important to you in all aspects of your life, you'll know what to delegate. And the answer will be almost everything. The hardest part of productivity is admitting that you can't do everything.
In fact, it's the core of what being an adult is -- as a child, everything looks possible. Adults are hit quickly with the cold reality that they can only do what's most important. So be very clear on what that is, and delegate as much of the other stuff as you can.
At work, good delegating doesn't mean dumping your worst tasks on your co-workers. In fact, you often need to delegate your most appealing work and do some of the grunt work yourself. Because in the end, your No. 1 productivity goal is to get what's important done -- it doesn't matter who gets it done, and you're more likely to get a lot of help if you offer your fun stuff.
This holds true for your home life, too -- you can delegate a lot more at home than you think you can without losing the things you care about most.
Productive to the Core
The core of productivity is self-knowledge, which is emotional intelligence.
You have to know what you want most in order to know what to do first, and you have to know your goals before you can productively meet them.

Test as an instrument

2008-03-15T04:28:00.004+05:30

My friend Pradeep Srajan made a comment few days back "The test doesn't find the bug. A human finds the bug, and the test plays a role in helping the human find it."

A pretty thought that I agree with .........As I believe that a test only becomes an instrument in hands of a human.

Some points to ponder .......

The first set of tests are created by humans on their interpretation of the requirements
The tests generated will be towards both positive as well as negetive testing
The first set of goof ups can start from here itself .......if the tester has not understood the requirements clearly and cannot identify the positive and negetive test sets
The test set maynot always be exhaustive in nature

These are just the start points for testing.

But what is important to think is that can we accept the fact "to err is human" in the testing community ?

Crisis Management

2008-03-12T23:15:00.005+05:30

Crisis Management in projects :
Some questions ........

What is crisis ?
How does that arise ?
Why does it happen ?
How do you do crisis management ?
What are things to be careful about when you are doing project management during crisis in a project.

There can be many forms of project crisis .....

let me start with one ......."dis-satisfied customer"

The biggest point of dissatisfaction comes to a customer when he finds that his requirements / expectations have not been met.

Mitigation action to expectation is little easy to handle. Ensure that SOW (statement of work)/ TO (task order) is very clear and all the do's and dont's are mentioned there in with clear information on procedure for that additional requirement handling.

But still to keep your CSAT high, you need to always know what are the free-bee's that can be provided to the client and how to harp about them.

Problem area : missing on client requirement

Some things that can be done as a PM to ensure no client escalations arise

Ensure that the complete end to end process is in place
All checklists are created
Verify all client requirements personally
Conduct regular quality and technical audits
Keep taking a regular feedback from the customer

Problem area : Dynamic and unclear client requirement

The client is unsure of what he needs and what he can achieve in his set up. Their inexperience with the IT set ups are usually the reason for it.

If you encounter a dynamic client, try to figure out who will be the key communicators on their side and the stakeholders. It is very important that at any point of time you and the stakeholders have a good dialogue in operation with no scope left for communication gap of any kind.

It is also important to be honest to the client along with generating revenue for your own company. Try to give the best possible solution to the client that will optimize his requirements and their closures. The confidence that you enjoy as the face of your company from your clients is what will help solve many hidden and unpercieved risks of any project execution.

Influence of Bad Managers

2008-02-24T17:23:00.004+05:30

Again, coming from the latest ....... the appraisals :)

What damage can bad managers do to the company and their subordinates .........

I will prefer to open this as a debatable topic and take it to logical conclusion after we have few significant posts here :)

The industry trend

2008-02-24T17:09:00.003+05:30

Last few weeks there has been a scare that people are getting laid off and industry will hit a low again ......... out of all the companies, I read only Mohandas Pai from Infosys deny any such fact ........
and actually if you look at history of every year you will find that during this time of the year there are many layoff's every year.
Last year also all the Indian big names had a good lay off due to false certificates / bills / etc

Does this show a trend by any chance ?

Yes, the markets are definitely slowing down.
We all know that out project inflows are not steady and strong across the industry. Rupee appreciation is going up .......companies relying on US as main ROI will definitely take some impact.

but my thoughts for food .........this is also appraisal time ........generally people are not satisfied with the appraisal results.....its not the companies to blame but the managers ......I have personally seen how managers can reduce company policies to just exist on paper and take things up on personal whim and fancy .............. and how do they know to politically use it to perfection ........ :)
yes, that is an angular truth that lies here ...... hold down the attrition percentage ......
If an engineer who is thinking to quit n move on but is unsure of the industry trend, might just lie low and stay on and resultant looses one precious year of his career ......

Need some more thoughts to flow ........

starting 2008

2008-01-23T06:12:00.001+05:30

Hmmmmm.......... someone dropped a note today to ask when am I writing further ........ I never knew someone other than myself and couple of close friends read my page ....... :)

Anyways ........long due writings .......... intend to write something on 'nuances of project management' soon.

Long time .......

2007-09-01T04:13:00.000+05:30

Yes ....... I suddenly realized that it has been a long time that I scribbled something sensible here ..... and I also have a lot of past posts to which I should add addendums .......

I actually was busy with the new job and then the travel .......

the travel experience was the one that had a lot of learnings ........ most important of all ....... client/customer interaction ....... integral part of this IT service industry .......

Business Proposals -------- The chaos thereafter !!

2007-05-16T13:02:00.006+05:30

Involved in lot of business proposal off n on, seen the anarchy of dis-organization ....... the expectations are hilarious .........from client side as well as from onsite folks ......

None of them understand testing as a "tester". The perceptions are usually from "fake testers" approach.
Jist of RFP- (Most of time)

Prime requirement - metrics.
Usability of metrics - not defined, not known.
Skills seeked - certified.
Experience - not asked / not required.
Expectations - not so clear.
Requirements - I wish I knew.
Technical Expertise - I wish I had.
My system complexity - I have way too many but its simple, thats why I want you on board.

Jist of response to RFP- (Many a time)

What you need - We'll give
Proposal / Project - pls give us
How - has whole company story running in pages
Case studies - who understands
Customer will understand - not required
Work allocation - build good customer - vendor relationship

Jist of project execution - (Many a time)

Staffing - get people.
Skills - will build on job, get a few skilled ones if available.
Risks - will handle later. First project needs to start.
Change in request - do it, we'll raise a CR.
Customer angry - immediately talk, need a good CSAT.
Milestones - Meet them.
People Issues - Forget them.
Deliverable - On time.
Quality - Certify through a "metric"

Golden rules to retain staff

2007-04-15T15:48:00.000+05:30

I have recently changed jobs ....... yes, after continuing with last one for ages :)

saw the following 2 posts on the net and found them very interesting

http://www.rediff.com/money/2007/apr/11spec.htm

http://conlak.blogspot.com/2007/03/blog-post.html

Elementary ........ starter

2007-03-16T09:25:00.000+05:30

I have seen people coming back and asking what should they test ??

Yes, these are essentially people with less exposure and experience but the fact is that its them who get confused !!

An experienced tester would immediately comment .......EVERYTHING !!

So coming back to the core question what should you test ??

The BlackBox perspective .....
Any sofware would have certain madatory fields and certain non madatory fields on the user interface.

I am not taking any part of usability testing into consideration here .....

some interesting blogs

2007-03-14T19:57:00.000+05:30

Cem Kaner
James Bach
Matt Heuser
Scott Barber
Michael Bolton
Pradeep S
Jonathan Kohl
Karen Johnson
Shrini Kulkarni

Confusion ....tester = QC ? or QA ? ...something else

2007-03-10T22:10:00.000+05:30

Hmmmm.......

for some good time now, I've been seeing confusions in people regarding who is a tester ..... Some people percieve that tester is a quality control person ........some think they are quality assurance persons ........ the list is slightly more bigger, but these two are the main confusing roles ......

Why can't a tester be percieved as tester ? .....why cant he be percieved as someone who knows how to break the code ........ oh !! not another confusion ......... i am not talking about a hacker here but a tester ........

You may agree to differ in opinion but honestly that is what a tester does .......his job is to build scenarios, create plans, find testcases, generate testwares .......and test .........

White Box testing experts get in to delve into the structural aspect of the code and Black Box testing experts want to understand the acceptance levels of the software ....... with the client/ customer perspective.

Oh !! how did I forget to add ......a biggest misconception that failed developers become testers .....

Does the argument finish here ......... NO... wait to hear more on this blog !!

Scenarios in Product and service industry

2007-03-10T07:48:00.000+05:30

In a service company scenario you do not own the source code under any circumstances nor the test (plans/scenarios/cases ) etc. You do it for a client who has outsourced these jobs to you. The ownership for all this eventually lies with the client and you have to share it back with him. This will be dependent on the statement of work agreement with the client.

In a product company scenario, source code along with all test related documentation is owned by the company itself. They may or may not share it with the customer of the product. Sharing will be highly dependent on the business need.

Test coverage

2007-02-23T06:15:00.000+05:30

My perception:
Test coverage is the quality metric suggesting the quality of test cases and hence of test adequacy criteria.

In short .... we are trying to quantify test adequacy.

A test case/suite is meant to cover or execute test objects like statements, conditions, paths etc as per its test adequacy criterion. The test adequacy criteria might at times be part of agreement between the client / customer and the service provider.

The more number of test objects the test adequacy criteria covers, more will be its coverage. And the more test coverage given by a test case/suite, better will be its quality.

General definition says ...
Test coverage = (no. of test objects covered or executed at least once) / (total number of test objects)

The concept can be illustrated as follows:
Suppose one test case/test suite covers 80 stmts out of 100, 8 branches out of 10, and 20 paths out of 25 then it is giving 80% stmts coverage, 80% branch coverage and 80% path coverage. And it will be a better test case/suite than that which provides lesser coverage than 80%.As an ideal case test cases/test suite should give 100% test coverage. But in practice it does not happen.

Actually test coverage analysis is a type of the code coverage analysis. The academic world more often uses the term "test coverage" while practitioners more often use "code coverage". Test coverage provides a quantifiable measure of how well the test suite actually tests the product. The most basic form of test coverage is to measure what procedures were and were not executed during the test suite.

There are many other test coverage measures.
1.Statement Coverage
2.Decision Coverage
3.Condition Coverage
4.Multiple Condition Coverage
5.Condition/Decision Coverage
6.Path Coverage
7.Function Coverage
8.Call Coverage
9.Data Flow Coverage
10.Object Code Branch Coverage
11.Loop Coverage
12.Relational Operator Coverage and many more.

Test coverage specifies the extend to which test suite ( at times test criteria) fulfils its defined objectives in the system from its inception to retirement like analysis,design,...... for practitioners (BRD, FDD, TDD, ......)
In each phase of SDLC, nature of test coverage varies but purpose remains same.

Test suites which encompasses test cases and results of each one of them, provides big time support during implementation.
In my opinion, test coverage techniques need to mature a little more so that there are no consequences where one phase (or may be more but rarely all) has higher test coverage but others strive to obtain average.

Hence result of that either others are not performed well or suppose to be eliminated.

Interesting Debate

2007-02-15T00:40:00.000+05:30

Me and Cem have been having a very interesting debate over complete testing.

According to Cem the correct answer to the question should be choice ‘b’
Qs ) Which is the best definition of complete testing:
Choose one answer.
a. You have completed every test in the test plan.
b. You have discovered every bug in the program.
c. You have reached the scheduled ship date.
d. You have tested every statement, branch and combination of branches in the program.

And I say answer should be choice ‘d’. Cem reasons, How can testing be complete if there might still be bugs remaining?

And I go back and say that I feel ‘b’ and ‘d’ complement each other.
‘d’ is probably one way to achieve ‘b’.

I reason that all the business units across the world ( I am leaving the small software’s out of scope here, as they can be tested completely most of the times) plan their product releases. Before a release, it is certified that the testing has been complete. The products are released, but still we find 'n' number of customer bugs reported and which directly or indirectly lead to more regressions introduced in the software. These regressions are sometimes identified by the QA teams and sometimes are reported back as new bugs by the customers.
I have till date not seen any white paper from any of the big business houses where they have not had a single bug reported ( either internal or external) against a release.
Now, coming back to my interpretation….. What do you actually try to do in complete testing scenario ?? you try and have such test cases that will check all possible statements, branches and combination of branches in the program. Basically, I try and ensure that all my complexity node points are well covered during testing.

Yes, when I say ‘complete testing’, my idea is that ideally what ever I can think of as a test engineer ( with all my white box and black box test cases) I have covered all the possible scenarios I can think of. But factually, there is always a chance that there are few uncovered, un-trodden pathways lurking around the numerous code lines. More the components, more the dependencies, more the chances of failures. This is the simple testing ‘mantra’ that fits into my thoughts……..

It will be nice if we can have your views on my thoughts ……..

Before I end ….Can anyone recall embarrassment of Bill Gates as he stood to release Windows ’98 and then publicly had to call off the release coz of a failure at the time of release and all this was going on live ……….broadcasting all over the world ……

and last but not the least ....... I am not debating against the definition, but the thought that goes behind the definition ......

what is happenning

2007-02-12T20:12:00.000+05:30

Lots of things .......

BBST-IC .......its becoming interesting day by day.............. learning other aspects of things that I had probably not laid much importance to while conducting classes .........

Moving towards Dreams

2007-02-09T06:04:00.000+05:30

I always revered people like Cem Kaner, James Bach, Michael Bolton and the likes ....... My interest in the field of testing started because of them ........ there was a time I'd spend unlimited hours in the library and in my lab at the department reading their papers in various journals and magazines ....... My topic for PhD thesis and work was also formalized around software testing .............. all this started way back in 1997 when I was doing my MTech ........... it was a dream that someday I could meet and talk to these icons .........and here in 2007, last week of Jan the dream came true .......

Today, I have joined a course that is being taught by all my icons and I feel so happy and proud to be their student .......I still have a long way to go ........ this is just a start of another dream come true......... but at least I have touched the tip of the iceberg......... hoping that I can measure the whole length, breadth and depth of it in near future ........

I also take the opportunity to thank God for all that he's given me or rather should say, blessed me with !!

Testing - Context Driven

2007-02-06T23:40:00.000+05:30

I very strongly believe in the context-driven school of testing.
Learn more at: http://www.context-driven-testing.com/

I always reason.......how can testing happen without a context ?
When ever you start testing, you already have a goal in mind. The goal can be the expected output of the program. It can be expectations from you as a tester, in sync with the Requirement document, Business requirement document, test design document or functional design document and so on ........ (I plan to keep adding to the list :) )

The crux ....... there will always be a start point and an end point to anything under test in this practical world ...... and as soon as you define these ........everything with this population has to be contextual !!

So whatever you subject to testing will be related to some or the other context.

Why 'Testing' is more important than 'Automation' as a career

2007-02-06T23:12:00.000+05:30

Today I wrote to David Gilbert asking him why he is wanting to move away from automation and his reply was worth every cents ............ He wrote ........

Meeta -- it is not that I want to get away from automation, but that I want to shift the focus of my career.
I enjoy doing automation work, I find it mentally challenging and rewarding, in the right environments. Unfortunately, it is often done badly, and then I just find it frustrating to be a test code monkey doing things that I believe will not add value long term.
But the larger point is, as a technical automation implementation expert, I am very limited as to where my career can go. Tool jockies are a dime a dozen, and no one really cares about their opinion. If I want to continue to grow my career, influence, and recognition in the industry...if I want to try to be influential and do more than just make a living...then I have to break out of the mold of just being another tool jockey. I have to become a methodologist, and a teacher and promoter of ideas. It is fortunate that this also provides an outlet for my more creative and inquisitive nature, and that it allows a venue for my opinions about what good testing is and is not.
David

The Start

2007-02-06T16:58:00.001+05:30

Well ......here I go ....... not an expert at blogging, but had been contemplating for some time ..... Cannot give any big excuse, but probably was just procrastinating the idea to leave a lot of personal info online for people to see .........

Then last month Cem Kaner asked me if I have a blog that I maintain ...... and then I decided that I just need to kick start somewhere .......sometime .......... and here I am ......... this is the first post ....... nothing technical to write in, but yes, since the new year resolution (not planned) has started, be sure to check in to some stuff !!