Retrospection is important

Failure is a 50% probability for every new experiment. That does not stop us from experimenting, which is an important and positive attribute of humans. But there is another side of experiment, which is the lesson learned. Whether an experiment succeeds or fails, it is critical for the experimenter to retrospect. Indeed the entire task will be dear to the experimenter but the emotions should not bias the retrospect. If it is difficult to let go of the emotional attachment then it is best to employ the services of a neutral party for the retrospection.

The outcome of this task holds great future benefits. It tells us
- what we did rightly
- what we did not do rightly
- are the rights more than the wrongs, or vice-versa
- do we require to do the same experiment all over again
- should this experiment be aborted or continued with enhancement
- if the objective was met and to what extent
- what is the feedback of the stakeholders, satisfied or dissatisfied

To put the above theory into real-life scenario, lets take the most common experiment that occurs in the tester's work-life; "the automation experiment".
There is a lot of rich and useful information written on the subject of automation by almost all thought-leaders of testing such as Cem Kaner, James Bach, Michael Bolton, Jonathan Kohl, Scott Barber and others. But somehow the people who take decisions seem to be unaware of this information. I can safely vouch that in this case, ignorance is not bliss. Periodically, I have been subject to the experiment of automation by enthusiastic, starry eyed seniors who assume that automation is THE only and best alternative to manual testing. In order to sell the idea of automation they draw up graphs and charts that show the huge savings in terms of time and effort if the entire regression suite is automated. Statements such as 'it will take 3 hours to run the entire automated test suite as opposed to 3 weeks of manually testing it by a 5 member team' is a strong seller indeed. Its not surprising then that the management is willing to give a green signal to this experiment.

What stumps me though is that after investing a good chunk of the year in this experiment and having seen it fail, the very same initiators want to automate another product with a new tool. No retrospection, no lesson learned. Will a new tool magically wipe out the mistakes that can be repeated? Or will the new product bend itself to accommodate the new tool? Or will the testers, who (in most cases) do not know the basics of programming, begin to write sensible robust test scripts?

Automation is not magic. An automation tool is not a magic wand. The user of the tool has to be trained to use the tool effectively first. The automation tester should be a good manual tester first. Secondly, she should also know the basics of programming, know flow-charting and algorithms or at least to write pseudo-code of the flow of sequences.
Its important to automate but its even more important to form an effective automation team. But its most important to retrospect after each experiment, to avoid wasting precious time, money, effort and importantly to maintain the sanity of testers!

Getting over inertia

I was very excited to join a self-learning group for Ruby and Selenium last month. In the first week, I did my share of self-study and attempted the assignments with fair amount of sincerity and enthusiasm. Week 1 was a success. Second week too I did fairly well in terms of commitment and learning. But in week 3 I had a break in routine due to travel and this put a wedge in my self-learning cycle. Even after returning to normalcy, I couldn’t find the motivation to get me started once again, this confused me. The worry that I would fall behind the group and will have to cover a lot of ground in a short term added to my cup of worries. But instead of taking action I kept worrying!

Tip1: Don’t let the work pile expand beyond your capacity to tackle it in the given amount of time. Sometimes you have to postpone tasks but its better to use the mantra ‘I’ve started so I’ll finish’ ¹

Finally, I set myself a deadline and decided to dedicate X hours for the study. I settled down in front of the laptop with a hot cup of coffee and sufficient enthusiasm to kick start the ‘event’.

Tip 2: It is important to mentally prepare yourself first before taking action.

I started by reading the group emails, they were one too many, each stating the progress made accompanied by technical discussions. The discussions seemed alien to me and the group progress made my enthusiasm fade. I took a deep breath and started from the start. Patiently, I read through each of the mails, clicked every link in them. Opened every attachment and followed every instruction in them. This was to get me familiarised with what was going on.

Tip 3: Overload of information cause a heavy head. Don’t try to understand all the information the first time, instead simply keep reading. Your brain is smart so while you are reading, it will sort, organize and queue the data.

To say that I was confused is an understatement. I hit roadblocks while following the instructions, my heavy head prevented me from ‘searching’ for solutions, and I figured that I needed hand-holding. Thankfully help was just a chat message away as my group friends were online.

Tip 4: Sometimes, when you are badly stuck, u need a hand to pull you out. It’s OK to ask for help.

I was now on Level 2. The task on hand was known. I made a rough estimate for the task completion. Things were looking fine until a new wave of confusion swept through. Questions started popping in my head as I followed the instructions mechanically. I wanted to know the theory behind the practical.

Tip 5: Questions are good. Do not ignore or silence the inquisitive mind. Note down your questions however basic they seem. They may just open up a new door of information.

So, I broke off from the terminal window and opened the documentation site. I love user guides. I feel protected in their presence. They show you the way when you are lost. This is exactly how I felt when I saw the contents of the user guide site, http://seleniumhq.org/docs/index.html. I have now decided to read the guide first and then do the exercises. I like to know how deep the water is before jumping in. Reading the user guide will help me gauge the depth and breadth of the task.

Tip 6: Each individual has a unique style of study. Some like to skim through the chapter while others may start highlighting the main points in the first read. Identify your style and study accordingly.

After numerous breaks and couple of hours, I think I have just about ‘warmed-up’ for the main study. Technically, my progress today has been negligible, but this dedicated effort was required to align the mind with the task. I intend to keep posting about this interesting journey as I believe that most of struggle to keep commitments and to concentrate. This simply leads to feeling of guilt and displeasure which is detrimental in the long run.

Tip 7: Success is not always about the marks you score or the money you earn. Getting back on track is also success. Measure your success/progress in quantity and quality, both.

Reference/Acknowledgement:

[1] Magnus Magnusson, the former presenter of BBC TV's Mastermind, was known for his catchphrase "I've started so I'll finish" on the long-running quiz show.; http://news.bbc.co.uk/2/hi/6239745.stm

Testers != Programmers?

Im trying to figure out the mindset of a subset of the class of 'programmer turned manager' who deny testers their rightful equal status alongside programmers.

Testers are still treated as second-class citizens. They get lesser pay, lesser time for their tasks, lesser resources, lesser appreciation, lesser recognition than their programmer colleagues.

Do they think that:

• testing is an easy job
• anyone can do testing
• testing is not technical
• no special skills are required for testing

Is this thinking a result of:

• ignorance
• insecurity
• lack of continuous learning and improvement
• lack of leadership skills

Its been a long time now since the testing industry has achieved a unique identity, a decade since the Agile Manifesto was published, yet people choose to live in the dark ages.

In most workplaces, team parties and dinners are a common feature. It is treated as a team-building activity and rightly so. Informal settings usually relax people, make them lose inhibitions thus forging closer bonds.

But what if such events are used to divide the team rather than unite them? Is that possible? Ofcourse it is.

*Organize a picnic and send the mail to the programmers of the team.

The testers will come to know about it anyways. They will feel left-out and 'not part of the gang'.

*Or on the eve of a release, when the entire team has slugged it out, take the programmers out for dinner, to appreciate their hard work!

Can you imagine how the tester feels then? Demoralized, unwanted.

Wondering if this behavior is intentional or is the manager just following the footsteps of his predecessors?

It wont be surprising if the programmers of such a team, treat testers in a similar manner when they become managers. Because this is the training that they have received and they are not interested in questioning it either.

Is there something that we, the testers can do about it? For one, we could atleast start voicing about this to the concerned people, in this case, the manager. That is what I shall do too!

Its just a job.......

Do you ever get to hear "Hey, its just a job, so chill!", when you offload your office troubles to friends/family?

Its just a job....... or is it?
Let us see.
Most of our waking hours are spent in office, physically or virtually.
Work is the axis around which our life spins.
We plan, schedule and re-schedule events according to our work; marriage, vacations, reunions to name a few. Thankfully we have not yet begun re-scheduling our birthday parties .... or have we?

During our working life, work becomes the number one priority; family, friends and we ourselves become secondary in importance and attention.
Work sure is important, very important, I agree but look at the paradox that our behaviour has created.
When we are studying, our life did not just revolve around studies. Extra-curricular activities were encouraged and valued.
'All-round development' was the key. We did not ignore friends or hobbies. We cared for our happiness and even rebelled at times to achieve it.

But as soon as we get a job, we dedicate, or rather surrender ourselves to our job. Do we ever question ourselves, why we do so?
One of the reasons why we work is for money. Money is a necessity. Sure, but enslaving oneself in the pursuit of money is questionable.
There are people who find pleasure in this kind of enslavement as their only goal is earning money. But on the other hand there are people who work for intellectual stimulation or for an identity or to feel important or simply to keep busy. Whatever the reason for work, one should always review his situation often to identify gaps between his goals and his reality.

Its always faster and easier to cure in the early stages, it is said. This holds true for every situation.
Symptoms of discomfort are very useful in identifying the gaps. The symptoms could be on a physical level such as weight gain or loss, headaches, digestive problems, colds and coughs, sleeplessness, high or low blood pressure, high cholesterol levels, aches and pains, etc.
The symptoms could also manifest on the psychological level such as irritability, lethargy, sadness, mood swings, anger, etc.
Usually, we go to a doctor to treat physical conditions but tend to ignore the psychological conditions until they affect us physically. For example, we ignore the feeling of lethargy until we gain 10 pounds and then join a gym!

A lot has been written about 'work-life balance' and various kinds of management such as stress, time, money etc. But do we really use those principles? When faced with a deadline don't you still shut out the world and work till the job gets done? Such times occur in everyone's lives, but if they start occurring too often then its time to sit up and take action against it. Scientific studies suggest that stress is good in moderation. Its the same as the universal principle of 'anything in moderation is good'.

My friend Ajay came up with a phrase, "If you want to know the fruit, know its root.". So we've seen the symptoms, now lets look at the causes.
If you see your office in your dreams then its time you spent some amount of your waking time in identifying and resolving work issues, for a good night's sleep!

The causes could be numerous. A few that I can think of are, lack of recognition, lack of responsibility, lack of trust, below par monetary compensation, below par position/title/role, work overload, lack of support, etc.

Now what can the possible cure be? This is a much debated and discussed issue. Theoretically the cures could be asking for what you want, if you get it - good, if you dont get it then you have two options, either accept and continue as is or move on.

Its not easy to move on, it takes immense self-confidence and courage to stand on your own.
Its much more easier to withdraw into a shell and be a silent sufferer.
Either ways, the choice is yours.
The external environment plays a very big role in your decision.
But finally, it is you who has to take the risk and own the responsibility of your decision. Being patient, grounded and optimistic at such times is helpful.

There will be people who will say, "Hey, its just a job!". But you know better. :-)

The power of peer workshops!

Recently I was privileged to attend a peer workshop, BWST-2. This was my first and I was very excited about it. But I decided to go with a clean slate so that my assumptions and expectations do not overshadow the actual.

The Theme

The theme of this peer workshop was Bold and Beautiful, it read "Cutting the (c)trap and getting good things done".
Wow!! I thought. I was already impressed by the good intent of the organizers and knew that this would be one memorable event!
According to me it takes ample measures of courage and self-confidence to make a stand against what one considers wrong. To bring that forth in front of your peers is even more commendable because there is high possibility that your views may be completely dismissed or questioned or challenged or jeered upon. You have to be a brave-heart to face this.
That is one aspect I was looking forward to. What would the speakers talk about and what would the discussions be?

The concept of the workshop

In preparation for attending the workshop I read the report on the previous year's BWST-1 and also LAWST.
The concept of a peer workshop is very empowering.
Quoting from James Bach's blogpost, "A peer conference is a get together among practitioners of a particular discipline for the purpose of learning to practice better." and "At a peer conference, everyone is a speaker, and it is expected that we will criticize each others’ ideas. We’re after deep learning, and it’s hard to get that without getting behind the Powerpoint glitz."

The participants

Another highlight of such an event is that the participants are pre-selected by the organizer. The great advantage of this aspect is that a unique blend of participants can be achieved as they are hand-picked by the organizer who keeps the theme as the basis for selection. The speakers are selected because they have had the experience of cutting the traps and implementing good things. Whereas, the other participants are selected such that they may learn and implement from the experiences of the speakers.

The Facilitation

Each presentation is a high value entity. Unlike presentations at other events which are termed as ‘exhibition conferences’ by James Bach, peer conferences give an opportunity to all participants to actively participate in the topic being presented. This is invaluable.

K-cards were used to maintain discipline and smooth flow of each presentation. There were 3 cards, green, blue and red in color that each participant could raise during a presentation. A green K-card indicated that the participant wanted to ‘add his thoughts to the topic being presented’. A blue K-card indicated ‘adding a thought about another topic which could or could not be related to current topic’. A red K-card when flashed indicated that the participant wanted to ‘say something right then’. It could either mean adding to the point or debating it or challenging it.

The Bonds

How many times do you get a chance to share the lunch table with a CEO or have coffee with a math wizard heading the testing of health care products? Can you imagine the wealth of information you can get in those 10 minutes? Can you also imagine the lessons you learn about greatness, humbleness and being a giver?

Social animals that we are, we love being part of a community. Being part of workshops/seminars expands your network and makes you part of the community that matters most in your working life; the professional community!

We work in organizations with huge workforce but our daily work routine does not permit us to create bonds outside of our team or project. Hence, meeting your peers outside of office is very essential.

The take-away

To each his own, so goes a saying, the take-away from peer exchanges can be different for different people. To some it may create new ideas and learning, to some it could be introspection while for others it may be a fertile ground for creating professional relations.

What you and I could do

Of course its not feasible to organize or attend such large scale workshops very often. But exchange of knowledge cannot be a quarterly event.

So what we can do is organize informal meetings where people spare a few hours and assemble for a face-to-face discussion. If time is limited then only one topic can be discussed.

Such events can motivate us to hold extended workshops. At least we can get the ball rolling!

Are we writing a wholesome test case?

What is a wholesome test case anyway?
There are many definitions and articles about a test cases available in books and sites.
But when it comes down to actually using a test case written by someone else, the wholesomeness of a test case really matters .

Can we certify a test case as complete, if, without any external guidance, the user is able to execute each step with a correct understanding of the purpose of the test?

We usually encounter some challenging test steps such as:
'Enter valid information in the required fields.'

• What is valid information after all? .. Do I, the user, have to assume/search for or randomly play with data in order to hit upon the valid information?
• What are the required fields? .... I know you are thinking, hey this is easy, the required fields will have a red asterisk besides them ..... well, not always, as I have now come to know!

'Verify that following information is fetched from XYZ and few of them displayed on screen'

• What is 'XYZ'? ... XYZ is the name of the host and it was assumed by the author that it would be a known thing.
• What is 'few information'? ...... all fields of the screen are listed, how is the tester to guess which information should be displayed after all?

Why do we write such steps?
Is it because we:

• have weak writing skills ?
• are crunched for time?
• think it unnecessary to write so much information in each test case?
• forget that the test case will be used by many others besides us, especially when we aren't associated with the project?
• are plain lazy?

Is it justified to put a newcomer through the trouble of interpreting the test cases for each new project that she works on? Isn't it a waste of productive time for her as well as the old hand who will have to guide her?

So is there a solution for this problem?

Of course there is, only if we are ready to accept the problem and are willing to invest in taking corrective and preventive measures.

A few points to keep in mind while writing the steps could be:

• use plain and simple language
• write the test for a newcomer, not for yourself
• be a liberal information provider

• mention the possible test data in the test itself

  provide links to more information such as requirements
  documents

  attach informative documents to the test suite

• ensure smooth flow of logic between steps
• word the expected behaviour in a precise manner
• get a non-team member to execute the test on the application,

be a mute observer

take notes

is she taking too long to comprehend the step

is she struggling to find the objects in the application

she cant proceed without asking questions to you

• if she isn't frowning by the end of the exercise then you can smile, else
  you know what to do :)

While writing this blog, many cases have been kept out deliberately, such as, writing tests for complex scenarios that span multiple screens or a test with more than 15 steps, etc. Such cases require some more intense introspection and we shall deal with them later.

Till then, lets be more careful and caring ........ at work!