Lessons I learnt about being a good exhibitor

Exhibition time 

Your stall is set up, you have got your exhibitor badges, the laptops are connected to the external monitors and the brochures are arranged in the brochure stands. Your colleagues are on the stall, fresh and shining like a new penny.
Then the exhibition opens and the visitors swarm in.
Get set...All your exhibition preparations are soon going to get tested.

Typical 'Demo-er' life-cycle in an exhibition

On the first day, mostly you can see visitors stroll through your booth - with few moments of pause in front of your booth, with intriguing glances at the booth backdrop and then pick up a brochure, have a cursory glance at it and then leave in a hurry. Typically this group first wants to get a feel of the exhibition landscape and about who is located at which location. Later they analyse which of the exhibitors deserve a visit in their second lap.

Then there is one set of visitors who are more proactive and come have a chat with you. Ask about what the product / service offers - but do not seem to be heeding great attention to the answer that you give. At the end of your well crafted technical explanation, they state their company profile, exchange business cards and ask you to contact them directly by mail after the exhibition is over.

As the day progresses, you come across some valued visitors who are genuinely interested in knowing about your solution. They introduce themselves, state their company profile, clearly putting forth what they are looking for in our solutions and are eager to have a live demo of our product. During the demo, they are very engaging and receptive. They are proactive in getting their concepts reaffirmed and doubts cleared. Finally also state what they like about the product and / or what they feel is missing in our product. They also would be interested in knowing what can be expected in the future versions. Finally, they leave after having inquired about the price and exchanging the business cards. Overall a real good - 'value demo'.
But here's a catch associated - every value demo takes up good portion of the 'demoers' energy.

Over the next few days, you also get tired and even a little bored of going through the same script again and again. The enthusiasm you had while giving a first value demo wanes and slowly you start going through motions. As the show goes on, you spend more time sitting in the demo chairs, checking mails and doing your personal business. You also start engaging your co-exhibitors with the tittle-tattles. You settle for the fact that if some one 'really' wants the demo - they would approach you and wake you up from the slumber and engage you. Other customers - they may not be worth it. Subsequently, you begin to anticipate about the end of the day / show and dread about how wonderful and comforting the office environment was.

My story and my lessons:

All through my 6 year-old professional career, as an exhibitor I have participated in 6 international exhibitions (in Germany, England and USA). This has been my early story of exhibition experience until I decided to give it a thought about how to become a good exhibitor.
I am going to state below, few lessons that I learnt through my journey - which later I crafted and implemented to good effect.
And I can assure you, putting these into action will make you a very effective exhibitor.
These points are more directed towards exhibiting a  software product in an exhibition, but nevertheless- the gist of these points are relevant for all exhibitions. GO ahead and have a read!

Set your goal

First up, you need to ask yourself the question - Why am I attending this exhibition?
Though the straightforward answer is to sell the product - try to think in a holistic perspective. Or rephrase the question as 'Apart from selling the product what can I get out of this event?'
Being a technical person, my goal was to interact with the exhibitors, understand their workflow environment, evaluate their needs and helping them with a solution. I sought to understand and genuinely care for the visitor and build a rapport with them rather than merely sell the product.

Attitude

A good exhibitor will possess the attitude of a good host - warm, welcoming and pleasant.
Practice the following to exhibit these attitudes:

• Smile often.
• Be graceful.
• Be organized and ready.
• When somebody stops and looks at the stall - walk up to them (slowly) and inquire politely if you may help them.
• When the visitor talks about himself / his company / his background - do not interrupt. Acknowledge and whenever possible compliment as much as you can.

Set the tone for interaction

Invariably the first question faced by an exhibitor would be 'What do you guys do?' Have a catchy 15 - second answer for this. This generally sets the tone for further interaction.
So rather than being stereotypical - technically correct answer, you might try answering with a little more creativity, punch and positivism. As the old folks say - 'the first impression is the best impression.'

Demo iteration

While giving a demo - we need to know two things about the person to whom the demo is given:

• What is his competence level in the area?
• How much time he is willing to spend?

Sometimes, we can directly ask the person whether they need an in-depth demo coverage or just the outline. If you do not feel comfortable asking the above question, have 3 levels of demo. After each level based on his receptivity and his attention decide whether to proceed to next level.

• In the first level - show the most automated / sophisticated procedure which involves least clicks and hence we convey the idea that the software saves lot of effort and time. 
• In the second level - show the other semi - automated workflows. This conveys the idea that the software design is also flexible and can adjust and adapt to existing manual workflow.
• In the third level - show the database arrangement and about other configuration / settings involved. This level is mostly reserved for a technical / hands-on designer operator to show the depth.

Having a fixed demo script helps you find your feet initially (maybe during the start every day), but there is also a strong chance that you might get saturated / bored with the demos as you proceed. So as you gain your confidence in demos - play, have fun, personalize, improvise and innovate. Can you give the audience something refreshing at the same time relate to them on a more personal basis in a shorter time - that's the high point.

Interaction during demo

Presentation should be loud, slow and clear - Why?
Loud (Loud enough) - Somewhere people relate it to the confidence of the person in the product that he sells. It gives them a reassurance that the solution is right for them.
Slow and Clear - The person who is looking at your software is looking at it for the first time. His jargon might be different. So, the only way he can understand this is:
If he sees what's going on screen
Relates it with what you are saying and
Correlates (digests) with what's happening in his workplace.
As you see, this is an analytical process - not merely an 'Audio-Visual' process.
So give time.

Ask more questions - This helps in two ways.

1. It straightaway brings emotional involvement from the person and makes the environment more receptive. 
2. You can re-route your demo based on the feedback and become more relevant.

Listen, acknowledge and compliment - Do not interrupt when the other person talks. This way, you would learn more about the working culture and environment (including jargons) and thereby talk 'his language'.  

Mind your Body Language

Maintain a positive, energetic body language throughout. Your body language will reinstate to the customer that this is a comfort-zone environment. Use your arms and shoulders to explain, communicate. Laugh aloud when you hear a humorous remark from your visitor.
Subtle 'Mirroring' is a tried and tested way that makes the visitor feel more relaxed and encourages them to open up. It is the behavior in which one person copies another person usually while in social interaction with them. It may include miming gestures, movements, body language, muscle tensions, expressions, tones, eye movements, breathing, tempo, accent, attitude, choice of words or metaphors, and other aspects of communication.

Finish it off well

• Round off the demo by summarizing how your product would fit into his existing workflow and what benefits it can offer. 
• Agree on the action steps - the next interaction, the date and the medium. 
• Acknowledge the visitor feedback, thank him for his valued time and wish him well.  

Be grateful

Exhibitions offer you a wonderful platform to interact with the industry, peers and competitors. Be grateful for the medium and enjoy the presence and the people around.  

Every good demo given will make you more confident and enhances your CCQ (customer connectivity quotient). Every bad demo is a lesson - you are only getting better, enriched by it - if you are able to analyze and acknowledge.
The key is to be conscious and keep trying.








            

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....