Research is Life

Currently, I am heading the research in a packaging application, where I am expected to provide the functional requirements of the software and validate them with the industry for the appropriateness and automation. I am also associated with another Graphic Arts product for planning and imposition, where I collaborate and sometimes (by virtue of being 'the oldie') mentor the development along with a very young and enthusiastic team of 2 members. Our domain team is a small one, but one that is very highly motivated. The motto being to reach out to the needs of our product users, addressing their needs effectively.

Research - a story of Transcendence:

  by  steeleman204 

Over the years that I have been associated with this activity 'RESEARCH', I started developing a consummate love for it. Now it has become my way of life. My identification, character and my personality. This love story is a story of transcendence. 

Shifting from Production environment to Research environment:

I came into this R & D field from a production environment. To give a glimpse of my previous birth (yeah it seems a birth ago now - though it's been 5 years now),Productivity was the essence of a production environment. Time was the most sacred resource involved. Blasphemy is not to have achieved the daily numbers target. Quality was always the 'next' big thing. 'BOSS' was your yardstick. Your performance was measured solely in the 'opinion' of your yardstick. Regardless to say, your moods and satisfaction reflected your yardstick's. My pascal meter was touching an all-time high. Then the lid was taken off. A call from Chennai - seemed more like a life belt. 

I joined this company India Metamation. Everything seemed to be surreal. Nice-straight talking-honest people around with a transparent, employee friendly environment. All of this came under a tag - 'R&D'. Little did I know then, it would become my avatar. 

Research - as an activity:

The 'R' in this 'R & D', started off with being an activity - a task in my To-do list that was very specific to the issue I had to research on. More specifically, since my work deals with software development - a research was confined to a feature needed in the application. Putting it in a cruder fashion, research was about a button in the user interface - where to have it, what should it do - Period. 

Commonly this activity was carried out with the help of a call and a peep. A phone call to the operator asking where he wants this and what all he wants to do with it. A peep into the competitors manual for improvising. 

This was followed by a cute little research document. One describing the research - containing the conversation of the call and the screen shots of the competing product: 'fidelity' being the stand out attribute of the document. Care was taken not to give my personal opinion or judgment within this. It was truly an open document. The reader - the developer could build up on this further and interpret this the way he wanted to. But the research was done. My production mentality prevailed: a research done, a document submitted, a number shown.

The beginning of life: 'Am I missing something?'

Then the results of these - made me think about what was missing. The product was merely what was enough - what the customer expected. It matched the competing product. There was never any exclamation or a eye brow rise from anyone seeing the product. At this same time, I was also looking at some of the software products in other domains. Google was one of those that I watched closely - because it was one that I was using most. Every time, I saw a new release or a product update from them - I was astonished. Why? Because every time I got the new feature and used them, I felt like 'how could I live without this feature from now on'. They had sensed my mind - they had not asked what I had wanted, but they sensed it. This thought made me take up my research a level further. 

Research - as a duty:

My next level was looking at Research as a duty. It was my official duty to think about what the user wants. My research began not by calling him or by peeping into a competitor's user manual - but by becoming a user, thinking how he thinks and seeing what he sees and finally sense what he wants. I still call up him and look at some competitor manuals - but that's certainly not the starting point but an additional rounding off activity to improvise.

I could see a marked change into my documents from then on. Even if I was not able to complete my research in a specific time, I was convinced to think that this research would yield a feature that is going to make life of a user easier and better. The features that resulted out of these research documents - truly reached out to the users. For a start - they acknowledged these. It was a lesson learnt. Also the time spent on this seemed worth every second of it, so my production mentality melted away.

Twist of life: Non-research tasks becoming mundane and a burden:

Amidst all of these, I was also doing other domain related activities such as testing, documentation and customer support. Because I had associated an intent in my research activities - that of sensing a need - it was a task that I began longing for. If there was a research topic in my daily kitty - it made up my day. The flip side to it was these other tasks started appearing mundane and looking unglamorous. They lacked the appeal and the high that a research task gave. As a result, the quality of my work in these areas waned. I was found lacking in these areas. Again this made me think. One day the realization struck - There was a research involved in these tasks as well. 

Research - as a way of life:

I began to understand that any process, had methods and tools involved. That these methods and tools - when sensed, researched and refined - yielded maximum mileage. 

For example this is what happened earlier when I wrote the user documents. I was merely worried with conveying the knowledge about the software to the user. I was constantly sweating over the usage of voices here. However later a minor change in perspective made me at ease with the documentation: Instead of communicating 'What I know about the software?' I had to communicate 'What does the user want to know about the software?'. I started seeing this document creation from the eyes of a new user. I started using tools available such as Google Docs for collaborative working - that made the approval process simpler. I started documenting FAQ's about screenshot capturing and voices in a commonly available location so that people could review and voice their opinions on it. This became a guideline knowledge source for the future. I was at peace with this method from that moment on.

There was a similar thing with testing. With testing I started creating testing procedures and also started classifying the categories of testing - that way I could quickly go through these and perform an effective testing. I also learnt that the key to testing is preparation, imagination and persevering execution. 

To round it off, looking at each activity involved as research stems from a need of systematic analytical approach to an issue. The moment we decide to tag each activity as a Research activity - we start thinking about the methods and tools that can be used for & subsequently how we can improvise these methods and tools for better efficiency of the process. Also as a side effect, it made the process more enjoyable and lucrative. 

And I was able to extend this realization to the other spheres of my life - personal included. That is any process or activity in life - has in it a potential research. It is up to one to sense this, address this and refine this - making the activity, one to look forward to and enjoy. 

This has been my philosophy - research is life.

________________________________________________________________________

ALL THAT I LEARNT ABOUT RESEARCH

• Research Activity - Systematic Investigation with an open mind to generate new ideas or ways of doing things.
  • Major steps involved:
    • Identification of a research issue
    • Literature review
    • Specifying the purpose of research
    • Data Collection
    • Analyzing and interpreting the data
    • Reporting and evaluating research
• Researcher - A scientist who devotes himself to doing research
  • Traits of a researcher:
    • Patient
    • Honest
    • Curious
    • Observant
    • Organized
    • Perseverant
    • Enthusiastic
  • You are good researcher:
    • If you have a desire to contribute something original to the world
    • If you are never satisfied by one or two sources & dig a little deeper to find the answers
    • If you are able to extract relevant information from large amounts of information
    • If you take in the (inevitable) rejection or disappointment {in terms of having your research data accepted and acknowledged} as fuel to make your research more complete
  • Skills to develop:
    • Analytical skills: Ability to apply logical thinking to gathering and analyzing information, designing and testing solutions to problems, and formulating plans.
    • Communication skills: Asking pointed, well directed questions
    • Documentation skills: Documenting clearly with known, doubtful and unknown areas
    • Presentation skills: Presenting an unambiguous, clear picture of the research

Inside the mind of a tester and how to don the role better

Software Quality Assurance a.k.a. Bug Spotting

  by  FastJack 

This is often a hat that has to be worn by me, mostly after periods of activity slumber. In the midst of an interesting research about the future development of the projects or at the helm of one of those tech fruitions - 'TA DA!!!' - a mail from my partner arrives. 

"New version, here's a list of what it covers and what it does not do! Test!". Like a child being called back home by its mother in the evening, to do the never-ending homework - I start trudging, pushing myself to this world. 

The world of software testing

Software testing is the process of testing the correctness of executable code which does operation on data. Tester will provide various data to the executable code to see if it works as expected or if that handles all possible errors on various environments. 

OK OK - That's about being a good boy - and being politically correct as to what software testing is. But here's what I personally think about software testing: 

Any code is guilty, until proven innocent. I don the role of a paranoid - always suspicious, uncompromising and cunning, trying to frame the developer. 

A PARANOID

  by  Little Miss no Name 

The only difference here is, it is a case of constructive paranoia. What makes it super special is my developer (well, most of the times) loves me for this. 

Deep-in I realize, that validation and then subsequently testing is the second most important activity involved in a project after the conceptualization. However there is always a melancholy associated at the beginning. I began to ponder over the reasons.

Why testing is the least glamorous actress around?

• NO RECOGNITION: Foremost, there might not be any rewards from the end user in terms of approval or recognition for our testing. Give your customer a totally bug-free product. Prod him and state him the amazing fact that it does not have any bugs. Invariably his reaction to this would be: "Whats so great about this? Aren't these software applications supposed to be bug-free?". Bug-free attribute will never become a selling point for the application. And here's another killer - 'Bug-free'ness can never be demoed.
• RESPONSIBLE FOR EVERY FAULT: Tester is responsible for every fault of the software. There is so much at stake, if I miss anything but at the same time very little that I get if I find one.
• ANY MORTAL CAN DO TESTING: It is also a common perception that there is lesser skill levels associated with testing. To put it in other words, we think that testing can be done by any mortals. There is no proficiency that can be showcased to the world by doing a fine act of testing.
• NO CLEAR END: A testing act at the outset, has no clear 'THE END' stage. We have grown up with the idea in mind that any software will have bugs. This vox populi retards the motivation of performing a perfect job. 
• CUMBERSOME: Testing is also an umbrella act - there are many testing categories involved in an act of testing. To identify which are the relevant test categories that a given version needs to be put to and to stack up the relevant resources involved - this is a cumbersome task in itself.
• VICIOUS CYCLE OF BUG FINDING - FIXING - REGRESSIVE BUG TESTING - REPORTING: Rigorous bug testing will be inhibited by the following cycle. Any version given initially for testing - will contain a bug. Fixing this bug will throw other bugs. Also other bugs might regress after the fix. So why do a rigorous test, when you have to go through the same vicious cycle after a fix is going to come? So a typical attitude will be: 'At the sight of any bug - abandon further testing. Let's rigorous test this when the fix for this comes.' 
• BORING: There is some repetitiveness associated which might make it boring.
• STATUS: Management doesn't consider testers equally with developers.

Why all the wooing then?

I was able to feel all the above points in my heart. But the issue was: If all this were there, why do our directors (a.k.a coders / product developers) keep spurring on the testers. They spend a good portion of their energies, motivating these guys. They seem to be pinning a lot of hopes on an act the result of which will not make the product sell more.After significant pondering over this, the parallelism dawned upon me:

'Testing is not a heroine - she is a character artist'. A character artist may not be able to attract people to come and watch the movie, but if there is no character artist and the associated scenes of emotion, the film will crash at the box office. That is what testing is : Its the character of a software. No matter how good the looks of a software may be (features), it will not be liked by people if it lacks character (being bug-free).

Reliability - A testers brainchild

The principal objective of software testing is to give confidence in the software. A customer can wait more for a new build or product release, but they don't like to work with defected software. Reliability is a hugely understated but yet powerful attribute to an application. Reliability can be defined as the probability of a computer program performing its intended functions, without any failure for a specified time under a specified environment. It is solely a testers brainchild.

"Reliability - Directly proportional to - Customer Satisfaction"

Reliability enhances (or diminishes) a product and in-turn a company's reputation.

Testers provide an environment of positive reinforcements to developers

For programmers, getting better at what they do requires quick feedback - positive and negative - on what they have done. The faster they they get the feedback, the faster they will learn. A great tester is such a precious asset to a developer. There is no better way to improve a programmer's morale, happiness and subjective sense of well-being than to have dedicated testers, who get frequent releases from developers, try them out and give negative and positive feedback. 

Even developers spend large chunk of their time testing too!

Microsoft chairman Bill Gates quotes the following about testing:

"Microsoft in terms of this quality stuff–we have as many testers as we have developers. And testers spend all their time testing, and developers spend half their time testing. We’re more of a testing, a quality software organization than we’re software organizations ."

Testing is an act of a discovery

Discovering the unexpected is as important and in some cases more important than conforming the known. While doing testing initial rounds of testing, wear the second hat first and the first hat from there on. As to the attitude of a discoverer, Isaac Asimov quotes: 

"The most exciting phrase to hear in Science, the one that heralds discoveries, is not 'Eureka!' but 'Now that's funny..."

Every bug missed is a learning activity

Don't worry too much about a bug (may be a big one) that slipped through. Identify it, acknowledge it and learn from it. Every bug missed and acknowledged later - is a learning activity. The right spirit would be: 'This particular bug path will be considered every single time from now on and shall never be missed in my future tests.'

Testing activity as a team

It can also be an environment of fun and challenge, if testing can be done as a group activity. This provides ample scope for learning more about the software as well as the testing procedures.  

Graduate from testers to test designers

More than the act of testing, the act of designing tests in one of the best bug preventers known. Use all of your analytical and cognizant abilities, to design a testing procedure. 

Before any of the testing sessions, prepare:

1. Testing documents - stating:
   1. features covered in the version
   2. features not addressed
   3. any other special environmental and process exceptions specified by the developer
   4. suitable knowledge base materials
   5. smoke areas for bugs
   6. testing categories that this version can be subjected to
2. Resources for testing

 To conclude software testers do not make software; they make them better.

In God we trust, the rest we test....

Don't google... yet...

  by  Aray Chen 

Google is a very good tool and is a necessity in this fast growing internet age. But it cannot serve as an answer to anything.

COMMUNICATE WITHIN FIRST:

In fact for some of the most important things, the answers lie within. Not every problem that we face have a direct answer to them. A lot of them may be subjective and open to one's own imagination. It is after constant and continual reflections within that we can find the answers to some of these things. We need to urge ourselves to communicate to the voice deep within. Resist your urge to google your question immediately and quickly look at what like-minded people have arrived at. In my opinion, googling must be the last resort that should follow after 'talking-hearing-within' and appropriately documenting your thought process. 

INTERNAL CHEMISTRY:

Googling habit or tech-gadget reliance immediately at the surfacing of a question retards the chemistry that one enjoys with his inner self. Progressively one starts believing that he does not have the capability to provide a solution. One becomes a cattle member following the crowd. Believing that a 'ready-made' answer - that will perfectly solve your problem - lurks somewhere in the internet, diminishes the 'YOU' individuality. It makes you one among the common stereotypes.

HOW TO USE GOOGLE:

• DOCUMENT WHAT YOU ARE LOOKING FOR AND WHY: When you reach a block, for which you have to find an answer - first document in your own words what are you looking to achieve / solve and why. This will help you set the context clearly not allowing you to distract. Use this to frame your search query astutely.
• PRESENT THE BIGGER PICTURE: This might follow immediately after documenting the issue or after gathering the first set of search results. How does the answer shapes the further proceeding of the project. This helps in looking 'beyond'. By this you don't limit your search to 1 answer - which is good in a lot of cases.
• ASK YOURSELF IF YOUR UNDERSTANDING THIRST IS QUENCHED: Ask yourself whether the answer that you have arrived is completely satisfying your understanding. If there are areas of uncertainties, document them and either research more or proceed further based on your judgement of the magnitude of the uncertain areas.

WHEN TO USE GOOGLE:

• Validation of properly established opinions and calculated assumptions
• Events, locations and people searching
• Direct answer questions such as math related issues
• Documentation templates

Finally remember to constantly revisit / evolve what you are looking for.

Traits of the "rainmakers" and how to become one

"The Rainmaker Professional", Photo Credits: amrufm via Flickr 

The Rainmaker:

Each day of our lives, we get to meet a lot of people doing their work. These people may be selling their product / service to us or they may be our clients or they may be our colleagues. Once awhile during such interludes, some one amongst this crowd may throw up himself / herself as a 'rainmaker'. The coining of the word 'rainmaker' might be more biased on the economical scale and personalized to an institution - but the intent that it is being used here in this post is simple. 

'Rainmaker' is the person whom we want to be associated with. With whom we yearn to enter into a business. Whom you would love to have on your team list. When it is said that these rainmakers throw themselves up amongst a crowd - it barely is by verbal acclamation, but they stand out by their approach towards the work. What is subtle is that the other people in the crowd, although have an envious attitude towards these people, eventually gravitate towards their work.

In this post,we are going to discuss about the approach of our rainmakers towards work. Some people seem to be naturally blessed with these traits while some go through a lot of experiences to imbibe these traits. But here's the good news: the first step towards becoming a rainmaker is being conscious of these traits. After realizing it has to be put into action and then eventually by practicing it again and again, it has to become a characteristic. 

Acquiring these traits present a huge challenge that involves addressing the minute little things in the path but the rewards are very high. You will build up a huge self respect and also be respected by others in your working circles. In the long term, you will be viewed as a 'Go-getter' and become a very influential person in other's life. Ultimately you will start attracting positiveness in all the spheres of your life.

Anatomy of a rainmaker:

Now lets do the mental anatomy of our rainmaker. Here is the list of traits of the 'I-like-to-work-with' individuals that we come across:

Enthusiasm

Enthusiasm encourages a person to stay open to tasks and face their underlying challenges rather than focusing merely the outcomes. Don't get me wrong - Results do matter. But keeping a constant focus on the results alone is akin to eating merely for having one's stomach full. You have got to enjoy the taste of the food. Rainmakers are process gourmets and this paves way for acquiring a cognitive mindset.

 
Devotion

Devotion to one's job is placing the work ahead of one's personal interests, egos, likes & dislikes. In Hindu principals - it is the highest virtue to be possessed by an individual and is treated as a means for attaining spiritual salvation - 'Karma Yoga'. One can often watch rainmakers would just stretch a little bit more to get the work done even when conditions are unfavorable or when people are satisfied.   

Passion

Passion arises when the work done makes one feel good about oneself. In other words, it is ignited when the core value of an individual is addressed. Rainmakers associate and bind their core values strongly to the work they do. And passion can make any task that looks tiresome to others, a satisfying pleasure trip for one. 

Focus

Focus is born when an assignment poses itself as a challenge. The quest of mastery of work - makes any task a challenge, notwithstanding the magnitude of the task. One would get to observe the rainmakers get 'into the zone' when they encounter challenges. In those Zen moments, one can feel the peak of concentration.

Resourceful

In order to be resourceful, one should venture into unknown territories. Here the focus is on lateral (horizontal) growth and not merely longitudinal (vertical). No doubt rain makers are proficient at what they do, but they also chip-in with significant contributions that could take the pressure of a working partner. Being resourceful also demands that you have a helping nature and a willingness to play the team game.

Troubleshooters

Experience results when one has the courage to time & again put oneself in a vulnerable, difficult position. And as one gains experience - one also gets composed, balanced and peaceful. All of these resulting from the 'been-there-seen-it-all' attitude complemented by a 'constant-improvement' attitude. Rainmakers  would not be deterred by anything and by virtue of which they have people wanting to come to them for refuge.

Composed

Being composed helps you put things in proper perspective. One's judgment and cognitive quotient shoots up when things are approached with a calmness. Rainmakers are real shock-absorbers for the rest of the team. Contributions from a composed person who has clarity of thoughts are always valuable. 

Patiently curious

Curiosity reflects a constant desire to expand oneself in his/her field. However curiosity with desperation works often in a negative way. Curiosity when constant and aided by patience and action results in a positive working mode. Rainmakers are naturally curious - but their patience often results in practical work-around when they do not have a clear answer. This makes them very effective. 

Forward looking

Planning / plotting before acting arises out of a person's tendency to avoid harm or difficulty. But this forethought fuels the evolution of an amateur into a professional. Rainmakers make sure all the bases are covered and often have an alternative plan up their sleeve just in case something fails.

Deliver more

Last but one of the most business relevant trait is add more value than what is expected. How good it is when someone gifts a fountain pen with ink filled in it. That is the art of delivering more. This comes from putting oneself in the shoes of the user and think what adds more value to the transaction. When rainmakers are approached with a service, one can be rest assured that they think more than what is requested and then offer greater value.

RECAP:

At the end of reading this exhaustive list, one might feel overwhelmed by the number of traits listed here. But these traits will throw up as choices or decisions one can take sides in real life circumstances. Identifying and choosing to take these positive decisions will slowly build you up into a rainmaker.

 

The first time I came across this term in a popular John Grisham novel - initially it represented a street smart person. But as I began encountering my work heroes in real time - it felt very relevant to tag them as my world's rainmakers. Today, I would like to challenge you - to be conscious of these traits and try to imbibe them, put them into action at your work and become rainmakers.