Public speaking continued............

This post is continued from my previous post. I dislike calling this part II and previous one as part I because every time I do that, I fail to write part II. Writing jinx.

In the book Linchpin, Seth Godin says the following :

It turns out that the three biological factors that drive job performance and innovation are social intelligence, fear response, and perception.  Public speaking brings all three together. Speaking to a group requires social intelligence. We need to be able to make an emotional connection with people, talk about what they are interested in, and persuade them. That's difficult, and we're not wired for this as well as we are wired to, say, eat fried foods.

Public speaking also triggers huge fear responses. We're surrounded by strangers or people of power, all of whom might harm us. Attention is focused on us, and attention (according to our biology) equals danger.

Last, and more subtly, speaking involves perception. It exposes how we see things, both the thing we are talking about and the response of the people in the room. Exposing that perception is frightening.

The above paragraph speaks for itself. I hope I don't have to elaborate. Seth Godin's simplicity in writing amazes me.

Content
With the advent of internet, there is no dearth of content if one intends to speak. However, speaking of one's own experiences has more human touch to it than copying something point by point and puking it in front of the audience. Learning in depth is not enough, one has to experience it before speaking highly of it. To paraphrase Rahul Verma, "Don't follow your guru's ideas blindly. Make them your own or discard them as need be. Experience ideas before professing to others"

Speaking style
Everyone's speaking style differs. I speak very fast. I speak very loudly. I don't smile enough as I talk about stuff that I am damn serious about. Some people are slow. Few others maintain a balance between the good and bad aspects of their speaking skills. One can change the style by practice. Rehearsing talks, talking amidst friends or colleagues who provide feedback are some small steps that could .3help.

Thought process
We would have prepared with a certain thought process in mind. We would have a list of topics we want to deliver. One single question can doom this whole process. Your thoughts are no longer yours. Someone hijacks it and before you realize, your talk will be over. My friend Netra suggests I try meditation. I annoyed her by saying, "I'm too restless to meditate". Slowing down while talking helps. Being conscious of where we left the topic as we answer a question helps. Off late, I have seen this work for me as I deliver lectures.

Evoking
Evoking serious thoughts through humor or satire helps convey serious messages in a funny way. I have a few speakers do this exceptionally well. This is where listening to more and more good speakers helps. One may start with imitating their favorite speakers, but eventually develop their own style.

Your style a.k.a Originality
If we have known the speaker closely, we can tell if he is original or not. By original, I mean being one's own true self. Seasoned speakers might appear to have their own style that works. However, they must have started from somewhere. By listening to some of the better speakers around and by working on their own style. It's hard to be original and still be a good speaker, I guess. Still thinking on these lines........

These are just a few highlights of what I think goes into good public speaking. It's a post written consciously to tell myself that I need to focus on these as I pursue serious speaking opportunities. If this helps any upcoming speakers, that will make me happy too.

Regards,
Parimala Shankaraiah

Foray into Public Speaking

Talk about Speaking
Here's one of those impending posts that's close to my heart.

One of the major goals for 2010 was to speak at conferences. Somehow, it got too hard. I probably didn't push enough.

Talking to a virtual audience
In October 2010, I got an opportunity to present a talk to college students across India thanks to Pradeep, Rahul Verma and the team at Edista who organized the talk. This talk was a live broadcast from M S Ramaiah Medical College to about 24 engineering colleges across India. 24 Colleges, say about 100 students in each college, which meant 2400 students from different parts of India. Numbers are amazing ego boosters. I had about a day to prepare. I was asked to talk about 'Testing as an interesting career option'. By the time I got a final confirmation for the talk, I had about 6 hrs left. I made some quick notes and it was already time to leave for the venue. I was busy rehearsing in the cab, memorizing the order in which I wanted to mention a few points, blah blah blah. Actually, my talk pretty much was blah blah blah.

Firstly, this talk was a live telecast and hence I had to be in a Recording Studio which appeared like a Bhooth Bangla (haunted place) from outside the college campus. Secondly, I had to keep staring at a defined area on the monitor to appear as if I am talking to the virtual audience. Thirdly, If someone posted questions to me on the chat window, I had to turn 45 degrees towards my left side to read those questions, again on the screen. The recording personnel was co-operative and promised to remind me where to look and when. It was a little weird to me, but I was looking forward to the talk as it was my first talk.

Even before I started the talk, I had gulped about 250 ml of water from a giant 2 litre bottle. I started with usual introduction and set the agenda. I spoke about why testing is considered a "not so sexy" career option, how this perception is changing, what's wrong with college graduates thinking testing doesn't pay as well as programming and a few other things. Most of what I spoke that day escapes my memory. Blame it on my pregnancy at the time :)

As I spoke, I could see students in conference halls of respective colleges looking at the large screens in their hallway, a few of them coming forward to type in questions and a major chunk of those walking out of the hall because the talk was on "testing". Nothing unusual. College graduates don't even want to listen what testing is all about. I was happy that at least a few students stayed back to listen to what I had to say. I very well knew I was not presenting well. I also knew that the content I had was good (which was actually not enough for a good talk anyway). I pretty much ended the presentation with my email and blog details for any impending queries. Students left and I left too. Out of curiosity, I asked the recording guy how many would have attended my talk approximately (fancy numbers again). He answered it would be around 50-100 people overall as that day fell into one of those long weekend holidays in India. I wondered, "Even if one person found my talk useful, I would be happy". I also hoped that, that one person would contact me in some way and tell me how useful it was. It did happen. That talk did help one person to be exact. It was Me.

I knew that with the time I had for preparation, that is the best I could have done. After that, I got busy with personal things, but somehow wasn't happy about the progress I made in public speaking.

Talking to a live audience 
Bangalore Testers Monthly Meets came in handy. I strongly felt I should start presenting regularly at these meetups. The day finally came. I presented on "Testimation" at Blrtmm#3. I make it a point to attend all meets and mini-conferences in and around bangalore for most part. One glaring thing about many of these is the fact that the audience is very keen on learning new tools or scripting languages. Not a single person would possibly think of skills development, optimal test documentation, how to work on new test ideas etc. I am biased towards these topics as I believe that these are perceived as major pain points in many organizations today. We need education in these areas more than ever.  Since, I had struggled with test estimation myself for a while, I thought of presenting my challenges. Luckily, most of the audience related to it. It was a good start for me as a speaker with this topic.

The feedback I received was awesome. Not that my talk was awesome. It's just that it was decent for a start. One of the common feedback I got was, "To smile more often while presenting". Second feedback was to get a strong hold on the topic that I present. There were many more like this.

These two talks will be very special to me as they helped me realise I'm not all that bad. Yeah, I crack really poor jokes.  I should probably take up some classes in Standup Comedy.

I admire Vipul Kocher and Rahul Verma when it comes to public speaking. They capture audience's attention within fraction of seconds. I don't really know how they manage. Michael Bolton cracks up the audience so often in a span of minutes. And Malcolm Gladwell! Oh! Malcolm does it so well..........apparently, he said in one of his Ted speeches that he memorizes all his speeches in advance line by line. I won't buy that argument anyway. Hopefully, I'll learn from many of these good speakers out there.

So this was a sneak preview into my speaking journey. I didn't have time to update about my talk at Blrtmm#3 to the blogging world as I was in a transition phase with my previous company and hardly had free time. Will keep you posted on new happenings as they occur.

Thank You,
Parimala

I am Moolya family

Life's been super hectic! Tons of interesting things happening and too little time! In the midst of all this comes a mega annoucement that some of you have guessed at some point or the other in the past.

I am officially part of Moolya family as on 4th July 2011

I came into contact with Pradeep Soundararajan in December 2008 through his blog. A little later, he joined an organization which was at a stone's throw away from my house. Every day, as I walked back home in front of his office, I desperately wanted to meet him. I just wanted to say 'Hi', shake hands with him and run away as fast as I could - before he could realize what had happened. That's how much I respect his work in testing!

That's also how embarassed I was to face him with the skillset I had at that time. Slowly, I started helping myself. Most of my growth is visible on this blog thanks to my enthusiasm to write about everything that I stumble upon. And I can guarantee there's lot more to come. I am thankful to Pradeep Soundararajan for his belief towards my contribution to Moolya in times to come.

My interactions didn't end just with Pradeep. I was part of an awesome "outside the office" team of Santhosh Tuppad (my little bro!), Sharath Byregowda, Manoj Nair, Dhanasekar and many others. We used to hang out, meet regularly, discuss how we could do things differently in testing and crack jokes about funny processes and practices in organizations. All in smoking zones or pubs or bars which I hated to the core. All for the passion of testing, you know. This was a time when I was slowly getting out of the 'Cribbing Employee' mentality and hitting upon 'Let me do something instead of blaming and complaining' mentality. That was when this group was most helpful and supportive of my work. I am indebted to each one of them for lifetime. In all probability, these people don't know that they had an influence on me. Thanks guys!

There was this sub-consious voice within me that kept telling 'You can do something better' for over 4 years now. Do What? was the question. All I knew was this, "When a person really desires something, all the universe conspires to help that person to realize his dream ~ from the book The Alchemist". The moment I got a feeler that I'll join Moolya, I felt, 'This is it'.

OK. Here I am at Moolya. One of the coolest things at Moolya is this - We have an awesome team of testers. So what? Most organizations have teams of testers. But, WE have an awesome team of passionate testers! Wanna challenge that?

If you want to get your products tested well enough, reach out to Moolya. If you are looking to work with our awesome team, rush to Moolya hiring page.

Btw, our annual peer workshop, Bangalore Workshop on Software Testing 3 is coming soon. Check out!

Wish me luck,
Thanks for your time,
Parimala Shankaraiah

Interview with Curious Tester

My interview is published in Testing Circus magazine, May 2011 Issue. You could read it HERE. Let me know what you think.

Testing Circus is a free monthly magazine read by testers across the world. Testers worldwide contribute content to this magazine which is free of cost at this point in time. You can also read previous issues on the websites by downloading or reading the pdf online. Recommended for Testers and the rest alike - It's one of the best testing magazines for coffee time reading. Did I tell you they accept articles from "not so expert people" like us too. This could be your first shot at public writing about testing.

We're all busy people. It's with great difficulty that we find time to read blogs, like you're reading mine. Where is the time to read magazines?

How about carrying it to the toilet? How about glancing it while you walk in your balcony (avoid high rise buildings please!)? How about reading as you travel, unless you are driving? How about reading it as you wait for mustard seeds to splutter as you cook? How about spending a few minutes just before you hit the bed? How about letting your 6 yr old to read it for you as you get household chores done? How about trying at least one of the above? Now.

There is no dearth of time Friends; Einstein had the same number of hours in a day that we do.
'Come on Pari, everyone can't be like Einstein'. You can't. But, You can be YOURSELF!

Happy Reading,

Regards,
Parimala Shankaraiah

Co-operative Unit

Rapid Fire Question - What comes to your mind when I say “Co-operative unit”? I was curious to know what people would come up with and tweeted this question. Below are the only 3 responses I got:

1. A team located in the same premises, cooperative bank, a team cooperative with each other (vipsgupta)
2. Football (lnsimha)
3. Amul (sdhanasekar)

I was expecting “Team” as an answer.

Over the years, I watched many teams perform. Some excelled, some merely existed while the rest fell asleep. What is a Great Team made up of? Unity? Collaboration? Strict Manager? A Great Team is made up of Great Individuals who believe in Team Work.

Couple of months ago, I was chatting with a friend who said something like this: “I want to hire a great team” My response was: “You can’t hire a great team, but you can build one”. Building teams is serious business today. We may solve millions of business problems, but if you leave one people problem unsolved, that is good enough to bring down entire business. Here’s a sneak preview into few good/bad/ugly teams.

Real life example: “Solo Ownership”
Solo Ownership team consisted of team members with sole ownership for anything and everything

Key features of the test team
a. Each tester owned a module based on his experience and knowledge of products
b. Not a single tester looked into someone else’s module [even if his module was tightly integrated with some other module ]
c. If a tester found a bug in a module other than his own, he would not report it. He would not even mention it to the original owner [The attitude was “it’s not my problem”]
d. If a reasonably responsible tester found a bug in a module other than his own and reported it, he would be reprimanded. His reporting manager would ask, “Why are you spending time on someone else’s module?” The other module’s manager would ask, “Why are you testing our module. We have our own test team to do that”.
e. Testing happened in isolation most of the time
f. Integration/System testing happened at the end of the cycle during which severity 1 bugs poured left, right and centre.

Real life example: “Young Entrepreneurs”
Each one in this team felt young and believed in entrepreneurial thinking. It comprised a mature set of individuals who thought not just about getting their work done, but helping others to get their work done too.

Key features of the test team
a. Every tester was a primary owner for one module and secondary owner for another module.
b. Every tester reported bugs in any module of his choice as long as he completed testing his module within stipulated time.
c. Testing happened over the shelf – people walked to almost anyone in the team or outside the team if they had questions or concerns
d. Integration/System testing started pretty early in the testing cycle.
e. Job oriented trainings - mostly conducted by members internal to the team to facilitate quick learning curve for new hires in the team.

Real life example: “Mind your own Business”
This team comprised mostly of senior testers with several years of testing experience in their kitty, yet behaved like a bunch of egoistic people. There were a few good people, but tried hard to appear bad because good deeds weren't respected. In fact, good people would often be taken for a ride.

Key features of test team
a. Each tester would do what he liked – mostly after threatening his reporting manager to quit if things don’t improve [by the way, this happened just before the end of each quarter during which bonus numbers would be decided].
b. If critical bugs were found early in the test cycle by a colleague, some team members would say “Dude! It’s no big deal. You are doing your job. After all, that is why you were hired”
c. If a cosmetic bug was missed and customer reported it, team members crucified the corresponding tester and ask, “Were you sleeping? How did you miss such a simple bug? You should get your eyes checked” in a mocking tone.
d. Any delay in dropping builds to testers was OK, but deadline was NOT negotiable.
e. It was mandatory to work extra hours every day. Anyone who consistently spent more than 14 hrs a day in office was a rock star tester and a dedicated team member [Notice the word “spent”]
f. Every problem reported by the customer in any tester’s module meant his bonus would be reduced by 20%. Five such problems and zero bonus. Simple Math.
g. Testers attend trainings so they can sleep for a while and occasionally shout from the top of their voices to show off that they are more intelligent than the rest.
h. And there is no end to this story. It goes on and on …..

Real life example: “We are Family”
Truly a family. There is no distinction between programmers, testers, managers, technical writers and other immediate stakeholders within the organization. Everyone was important and was encouraged to make some unique contribution. Each team member worked closely with rest of the team to meet commonly set objectives. These objectives were directly aligned with organizational objectives.

Key features of the team
a. There was no single rock star team member. All were star performers and pushed each other to excel and perform better.
b. Every complex activity happened in pairs or in groups – which encouraged group learning and on the job training.
c. Team members met at regular intervals to discuss the state of the project they were working on to ensure everyone is on the same page.
d. Programmers highlighted risks pretty early in the life cycle and testers would test early builds to provide immediate information to them.
e. Product owners wrote/re-wrote/reviewed requirements in detail at the beginning of any project and reviewed/modified them periodically with customers and engineering teams.
f. Customers were given monthly demos of working features to solicit early feedback.

Closing comments
While writing this blog post, I wrote a little section called Outcome for each team and how those teams excelled or disintegrated. During review, I realized everyone who hears about these teams knows the outcome. Why bother calling names? Let's bother about building teams. Eh?

My ex-manager Dipankar Roy had tremendous influence on me with regard to team work. His belief in team work helped him build not just extraordinary teams, but amazing professionals as well. He once said “Any team is only as strong as its weakest link”. It doesn’t matter how many are star performers, how many won quarterly awards or how many excelled. Even if one team member is slow or not on par with rest of their crew, the entire team slows down and heads downhill. The key to any strong team is to empower ‘weaklings’ to become star performers. Remember, these so called ‘weaklings’ are not on par with the rest simply because they don’t know that they don’t know. You read it right. They don’t know that they don’t know (MOSTLY). The moment, they are nurtured and valued, they’ll outgrow the best of star performers. Empower people to transform as stars. Whether they shine or become dust is their choice.

Regards,
Parimala Shankaraiah

P.S.
Weakling is an offensive word. The reason I used it here is to emphasize how people who are slow/passive in the team are considered almost worthless by their immediate leads/managers. These very same weaklings can deliver beautifully if mentored by true leaders who believe in people power. Some leaders create magic with people. They value each person’s interests, ambitions, goals and help align team goals such that every team member feels respected and contributes to the team. Only true leaders can do that.

Belling the Cat - Learnings from Testing Contests

There is a huge rise in testing contests in some parts of the world. Many testing conferences today facilitate testing contests, quiz competitions, puzzles solving sessions and many more to draw people’s attention at conferences. Several crowdsourcing companies today offer short term testing projects as contests and award testers appropriately for reported bugs. If you are a tester, you love what you do and you have disposable time with you and willing to make some quick bucks, why not participate?

I have participated in many testing contests in the last one year. It’s been quite an experience. I would like to share my learnings here as it might help some of you who follow suit.

What do testing contests offer?
Quick Learning
Learning a product quickly and reporting problems within stipulated time is a challenge. Testing contests offer such an environment. You are expected to learn as much as possible and test the product. Zero Documentation available. Some of us feel miserable. Zero Documentation? It’s impossible to test. If you are working for a large organization, you must be familiar with Feasibility analysis, requirements specification, functional specification, technical specification, test design specification and technical documentation. If you are working for a tiny startup, all you would have is a bundle of code which looks like a 2 month old foetus; If you are a little fortunate, you might be blessed with a developer whom you can talk to; if you are a little more fortunate, you may have that guy next to your cubicle. Your luck factor ends right there. What if you neither have documents nor people to tell about the product. Self Learning. This is one of the most wonderful ways of learning till date. Self Learning nurtures creativity, exploration, investigation and critical thinking. Testing contests encourage self learning to a good extent.

Time Pressure
There’s not a single tester who wouldn’t crib about lack of enough time to test [except testers who have learned the art of coverage and risk mitigation]. Testing contests offer this pressure too. BUT, participants hardly take pressure. Its just a game for them. They neither have fear of missing a bug nor do they worry about getting laid off for lousy work. At the most, they won’t win the contest. Outcome: Calm and Relaxed Mind. This helps them think critically about how to test the product. Contests offer a lot of time for testers to think without worrying about time. Weekend Testing participants can tell you better how enjoyable testing experience is when testers test without anyone sitting on their heads for status or numbers.

Fault-Safe Environment
Contests offer a fault-safe setup where one can exercise individual skills without rebuke. Success in contests is not about winning alone, but the journey one goes through to reach the destination. Testers should cash in on their knowledge and enhance their skills on such platforms. One of my ex-ceo Josh Pickus often said, “Never be afraid to fail. Whenever you fail, don’t fail to learn from your mistakes”.

Exposure to variety of products
Where can you get exposure to different products at your fingertips? Softwares used in medical devices, online library management, applications on mobile devices, banking - anything that you would not have tested before. At workplace, many testers end up testing same product for 1-3 years, sometimes maintaining them for many more years. There’s nothing wrong with that, but learning about products addressing different customer needs is interesting and fun. When such an opportunity strikes, one should not let go of it.

Collaboration with other testers
Some products in some contests require collaboration from multiple users. For e.g. if there is a chat feature, unless the same user is logged in on multiple browsers/machines, it may not be possible to have real time chat sessions. Such scenarios facilitate collaboration with other testers who not just help themselves, but help others too. I collaborated with Bharath in one such competition and tested some shared features together. This virtual pair testing took us through a journey of loopholes in the product. We found many interesting bugs and each one different at my end and at his end. Both were happy not just because we found more information about the product,but because we unearthed them in such a short time as we worked closely with each other. That was a great lesson on collaboration.

Credibility
Win or lose - Testers build credibility as they take part in more contests. Such credibility gives them not just more practice, but more and more contests go their way. If that works out, they might even end up getting some free lance projects to test - in their spare time. What more do you want? Wake up folks.
Contests are open for everyone alike. This throws you open into a group of diverse people whose brains are wired differently. This facilitates a one of the kind experience by allowing many less experienced testers or students to take guidance from experienced testers. This also provides a great opportunity to mentor other testers who need help.

Consistency in quality of bugs
Contests don’t accept your bugs as they are. Each bug is validated, prioritized and weighed against the criticality of fixing it. That brings us to valid and invalid bugs. Its hurtful when bugs get rejected. However, each rejected bug teaches a lesson, not of ridicule, but of realization. Taking part in contests can help you by allowing you to think about the validity of each bug before reporting it. This way, testers can learn to weed out invalid bugs from their queue. This helps get rid of ‘report anything and everything different as a bug’ thinking.

Varied Test Combinations
Unless you have worked on One Man Army projects where you are the only tester, you wouldn’t know that testing under different configurations (operating systems, browsers etc) can reveal amazing things about these products. Contests usually offer a choice to choose from different test configurations where you can learn and experiment based on your skillset/expertise. You can also choose to test using a completely new approach and get bowled by your performance.

Test ideas and bug ideas exhaustion
I happened to take part in a few contests where scores of bugs were already reported. My first thought was, “Oh! Most of the bugs are fished out already. I don’t think I am needed here”. I took these opportunities as challenges and said to myself, “Let’s see if I can find anything new here”. I was surprised by the variety of choices I had to test. Sometimes, I chose different test techniques. Other times, I tested on different operating systems and browsers. In some cases, I tested for different language support options, search engine optimization support, looking for broken links etc. At the end of this exercise, I was happy as I found many problems in the product which I would not find if I was one of the earliest testers on the contest. Filing straight forward bugs is a cakewalk. Filing hard to notice bugs is a uphill task.

And don't forget the test ideas you might get for future tests when you read through existing bug reports of other testers. That is a gold mine of knowledge as well. Are you game for it?

Challenges in a testing contest
Filing bugs - left, right and center
Contest instructs your brain more often to Win. To win, you can do anything. If you can win more by cheating instead of playing fair, why not do that. Many testers get lost in suchemotions and report anything that they think is a deviation from the product. This trend makes programmers life difficult which many testers fail to understand or in simple terms ignore. Another common problem is poor bug reporting skills. Some testers produce lousy test reports in a hurry to find more bugs. Sure. find more bugs and report more. But work on your writing skills. Don't degrade them further. Let me tell you, bug reporting is an art in itself.

Severity vs. Priority
This is another common problem where testers report low severity bugs as higher ones. In cases, where testers are not aware of whether a particular type of bug is severe or not, assigning a severity based on their experience and belief is fine. In situations where testers are instructed to find only certain types of bugs, if other types of defects are reported and at high severity, it would annoy the product management team for sure.

Not sticking to the mission
When there is a mission set for any contest, testers should stick to their mission. They shouldn’t deviate from the mission. Though deviations are unavoidable, sticking to the mission and executing tests within the mission gives more focus to that contest can be more productive. Testers often miss out on these things. In most cases, they tend to ignore which is not a good approach to contests.

Winning streak
Increasing bug count for winning the contest than providing quality information about product is a wrong doing. Though testers can win many contests this way, not reporting quality bugs can eat into our own credibility. Again, reporting symptoms as bug clusters may hamper credibility. Success is not just about winning, so its high time testers take contests in the right competitive spirit and put up a fair fight with the rest of the crew.

Duplicates
Testers file duplicates without looking into similar bugs reported already. How much time does it take to quickly look at defects before reporting one especially in a crowdsourcing environment. Many testers say that they get bored to browse through already reported bugs. Imagine the plight of programmers who have to go through every bug 2-3 times assuming at least 3 testers are testing one product and most of the bugs are duplicates.

Stake holders late entry
Bringing in stake holders very late into the project who then instruct testers to shift focus to other testing approaches or test techniques do more harm to the contest especially if there was no mission set at the begginning. It is a good idea to throw open stake holders and testers into an open room where they discuss the requirements, expectations and risks involved in the products. This will bring more success to the contests in long run.

Testing Contests I know of
If you have come this far, you must be wondering where you can find paid/unpaid testing contests to nurture your testing soul and also make some extra money. Some of these include 99Tests, uTest Bug Battles and Software Testing Club (Flash Mob Testing). These days, many testers on twitter offer free testing challenges as well.

Next time, you come across a contest, please give it a try. If you have already participated in some of these, I would love to hear about your experiences. Let's talk.

Regards,
Parimala Shankaraiah