Social Engineering Attacks

Social Engineering Attack
The art of tricking vulnerable and unsuspecting people into revealing confidential information like passwords, credit card numbers, social security numbers, login credentials to payroll systems, customer databases etc with little or no contact with computers.

Social Engineers
-- Sweet talkers with oozing confidence
-- Specialized in dealing with people, not necessarily computers
-- Great actors who can change their communication style and expressions at the drop of a hat
-- Already have access to few confidential details about the victim like Full name, Post code, Gender and others

Social Engineering Attacks
Impersonation
Suppose, I pose as a representative from a bank where you hold your salary account and call you at your office desk. I inform that current netbanking software faced a network outage and finance teams won't be able to credit your salary without your login credentials to the netbanking system. You are worried your salary will arrive late and share your credentials. I now have your bank account details. Whoopsie!

What you could have done?
1. Ask me to identify myself and verify my credentials.
[How do you know I work for the bank?1 It's hard on phone or email ;-). That's why social engineers use these channels more often]
2. Ask me why I called you on your office desk number though I had your mobile number.
[The attacker randomly picked a phone number based on the phone number listed on the company website where you work and modifed the last 3-5 digits to hit your number. Even worse, she asked the receptionist to connect to your extension.]
3. Was the netbanking site really down?
[If netbanking website was down, the bank should have informed you of any planned outages in advance. Even if it was down due to a sudden system failure, the website would have displayed a suitable message indicating the reason and what time the system will be up and running]

Intimidation
I pose as a direct reportee of your boss who works out of the US office. You work out of a tiny office in a small town from southern hemisphere. And of course, you are very fearful that you'll lose your job if you angered your boss. If I call you and say, "Hey Raaamalingaam, Jude asked you to share customer database server credentials with me", wouldn't you give it right away? And you'd expect a good hike in March after this great feat!

What you could have done?
1. Did Jude ever mention about this particular reportee ever?
2. Was there any kind of conversation with Jude prompting to share credentials with the attacker?
3. Customer database server has tons of customer contact details. How could you carelessly share these information with an absolute stranger?

Trespassing
I enter into your corporate campus as a plumber to fix the lavatory near the corporate virus lab. I somehow catch hold of you who swiped the access card to get into the lab and didn't notice me getting in. I get in, load some virus files into the server and get out. Meanwhile, I might have copied tons of data from your server just before I infected your server. Bingo!

What you could have done?
1. Restrict people from tailgating into restricted areas of the campus
2. Take note of suspicious people and report to Information Security team

Fake Prompts
I know of a few websites that you visit regularly first thing in the morning. If you are a teenager, you may first login to facebook or gmail. If you are a middle aged person, you may be interested in www.sharekhan.com. You happen to visit any of these sites and fail to notice the credentials prompt that threw up two consecutive times. One of the times, I stole your login credentials.Wow!  If you noticed, this was a computer assisted social engineering attack.

What you could have done?
1. You could have noticed why the credentials page prompted twice
2. You could have looked at the URL if it took you to another suspicious website or page

Shoulder Surfing
I sit very close to your work area and peeped in as you typed your password to login to your system. I even know the password for your gmail account. I'll send you an email from your email account to you if that helps.

What you could have done?

1. You could have observed if people around are looking for you

Sweet Talking (my own term)
As a friend, I ask you what your pet's name is. You say your pet's name. I type that as your secret answer for your email account and get your password. Now, your account is mine.

Here's a second level of sweetness. I ask you if your password contains 123 in it. You say 'Yes' with glee. I ask if its at the end. You say yes. I use dictionary attack, combine it with your liking for your favourite God and woohoo, I am inside your account. If your email account doesn't have account lockout policy in place, its a festival indeed.

What you could have done?
1. You shouldn't have trusted me
2. You should not have confirmed if specific data is present in your password

Countermeasures
Personal Security
-- Never reveal confidential information to suspicious people whose identity is unknown
-- Avoid revealing information out of trust or fear instilled by few people like your managers, directors, friends, family members etc
-- When someones asks for confidential information, ask them to identify themselves. Verify if the identification is correct or not

Corporate Security
-- Have a secure corporate security policy in place
-- Contact details of employees including email address, mailing addresses, personal phone numbers, official phone numbers and other details should be concealed from external world as much as possible
-- Desk phone numbers should be shielded from external world
-- Employ dummy social engineering attacks by internal security engineers as a periodic check

Here's a simple rule to handle social engineering:

When it comes to security, trust no one!

Regards,
Pari

Addendum on 17th Dec 2011: 
Added Shoulder Surfing and Sweet Talking attacks.

Claims Testing (Mindmap)

Claims Testing

P.S : This is in continuation with an old blog post on Claims Testing.

Regards,
Parimala Shankaraiah

Ramblings on Math and Testing

I was teaching math to one of my cousins who's about to get certified as a 10th grade pass out. I now figure pass out rhymes with drop out :-).

Math is an interesting subject. You have hundreds of theorems and corollaries, millions of formulae and lots of problems that appear like "Life and Death" problems to some of us at. I was looking into arithmetic progression in particular. There have been many theories based on which there is a formula that looks something like this :

Tn = a +(n-1)*d

In straight forward problems, students are asked to find one of the above parameters while giving away the rest. For e.g. Find Tn given a and d. What some students don't realize is that n is present in Tn itself. They go looking for n, get lost and leave the problem unsolved.

I was trying to simplify this for my cousin. First, I made her write down all given parameters, followed by some parameters known to her. I asked her to list out what her end goal (Tn) is. I asked her what more she needed to calculate Tn. And she did.

Trap Gods must be happy
Trap Gods are happy whether they trap you or lead you towards traps. One striking thing about my cousin was this. The moment I dictated one problem, she pounced upon the problem like a tigress on its prey. That is how some of us feel when we are working on math problems ;-). She didn't notice what's in the question, what is she supposed to find and how to proceed. All she did was to listen to one key term (Tn, in this case) and go looking for it. In short, she heard what she wanted to hear. Rest escaped into wilderness.

Why math class on a testing blog?
As I was helping her with her problems on problems , I figured how similar it is to testing.

• We are given some problem to test(product).
• We may know a few things about the product.
• We may not know many things about the product.
• Based on what we know, we go scouting for new things.
• If we don't know anything about the product, we still need to figure out how to know (learn) the product.
• Once we think we know at least a decent part of the product, we go figure new stuff again and again and again.
• Every observation made, every direction taken leads to different paths which become solutions.
• There is no one right answer, there could be a second right answer and even more.
• There is no one time permanent solution unlike in math.
• Every time, there is a new solution, there is a new breakthrough.

Heraclitus, a Greek philosopher once said, "Expect the unexpected or you won't find it". Unless we look for the unexpected, we won't find it. If we do, we may not recognize it. It's good to calm down, relax and look for the unexpected. Often, we lose out on sometimes obvious things either because we are looking for something else or we don't recognize what we see.

 [ PS : I have been struggling to write this post. I wanted to write this because I am thrilled for some weird reason. At the same time, I am not too thrilled with the way I am struggling to think and write. Need to be writing more often. Until then, have a good time reading this post. Who knows, a few years down the lane, I may look at this post and proudly say, "Oh! My writing used to be so damn bad :D" ]

Update: My friend Dhanasekar asks, "Expect the Unexpected, how is this possible? You are expecting so it can no more be called unexpected". Me : Go read some of Heraclitus's writings.
Expect the Unexpected,
Regards,
Parimala

Experience Report : BWST 3

 Bangalore Workshop on Software Testing – 3

Theme : Personal Excellence and Skill Development

6th August, 2011 @ S hotel, Bangalore

T-shirt Sponsor: Moolya

Photo courtesy : Santhosh Tuppad

Ever since BWST 3 announcement was put up on Pradeep's blog, we got many registration emails and calls. The slots got filled really fast. When some of them got to know that, they started sending emails asking "What can we do to get a slot in BWST3". We are Anna. We don't accept bribes :-)

As you notice, this experience report comes very late. Some of you must know that Moolyavans have been very busy with many exciting things at Moolya. By the way, we must confess we are loving every single moment of being busy. Pradeep kept delaying posting it despite repeated reminders from Santhosh Tuppad and Me. I just broke the tradition and decided to post the experience report on my blog. Feels very good, you know why :-).

The D-day finally arrived. It started with participants coming in, registering and receiving Moolya T-shirts. Common friends started chatting up, first time participants started making new friends.

Rahul Verma was the facilitator. We were glad  Rahul accepted to facilitate as we have seen him facilitate many discussions – formal and informal on several occasions. He started the day with a Welcome note, briefed the audience about K-cards and rules for using them.

Theme : Personal Excellence and Skill Development

Anuj Magazine was the first presenter. He started with a sponge ball trick. He popped a sponge ball in one hand and tossed it around. As it changed hands, the sponge ball multiplied into two. The audience slided into a tizzy. He started speaking about his foremost influence towards personal excellence and skill development..........and that was reading.  He went on to say, "Just reading is powerless. One needs to absorb what's in there and act on it". He quoted from many books which influenced him early on in life.

Anuj highlighted how we could manage disappointments in life using a  24-hour rule – cry, crib and feel sad, but move on after 24 hrs. One another thing he mentioned about is to identify the difference between commitment and interest. Are you committed or plain interested?, he asked as he shook the audience a bit. He also emphasized on how self discipline and prioritization helps achieve personal excellence.

Throughout the session Anuj spoke about his journey towards personal excellence. It appeared as though everyone could kick-start a journey with what they have at the moment, which is true by the way. Towards the end, he appeared to ask, “Do you have it in you to get started, to initiate, to ask for a slap in the face?”. He concluded the session by saying,

The idea of Personal excellence goes beyond self

We had about 45 minutes for Q & A. There were many questions floating around on how one can read more books, what are the challenges in asking a slap in the face and many more. Many veterans in the room shared their experience with regard to personal excellence and skill development. An engaging session indeed.

Tea Break.

Next in presenter's line was Sudip Naha, Program Director – Testing at Mindtree. His presentation was titled “My problems, someone else's solutions”. Sounded interesting. He started with the Theory of contradiction, “When you want to punish, appreciate it. It could change the way things are done”.

'Tritz' principals remained the highlight of his presentation. This is a model borrowed from the manufacturing industry containing a matrix of problems and solutions. If a particular problem exists, there is already someone somewhere who has faced and solved a similar problem. Tritz suggests to check if an already existing solution can solve current problem on hand. It's about using existing solutions to solve problems instead of re-inventing the wheel by looking for new solutions.  Many in the audience disagreed that this must have worked for the manufacturing domain, but fails in IT. He quoted examples from his own team where it worked wonders on multiple projects.

As expected, there was a flurry of activity in the hall after Sudip's session. Many concerns were raised regarding adopting Tritz to software industry. Meeta Prakash politely disagreed with Sudip on how these will de-motivate testers further. For this, Sudip mentioned that these are just ideas that have worked for his team and a few others in his organization. He also emphasized that there could be teams where it may work exceptionally well and where it might not work at all. It all depends on how people in the team perceive and implement it. On a side note, Sudip's session reminded us of the book “Are your lights on?” by Gerald M. Weinberg. The session drilled down to one thing:

My solution may not be the best solution to your problem.

Lunch time.

Post lunch, Deepak from chennai presented on “Testing Seed”. This session was about how Deepak and his friend Santhosh figured different challenges in testing early on in their careers and how they overcame those challenges.

Deepak highlighted the importance of conscious learning. As he and Santhosh faced resistance to the improvement suggestions they had to test in their day job,  it became clear that they had to learn about a lot of other things that tick and provide complete information especially to the senior management. This helped them come up with the idea of live demonstrations where they actually demonstrated to the teams about their exploration from time to time. This instilled confidence in the senior management that things can be done differently and for the better.

Often in life, each of us are encountered with challenges that we don't know how to face and overcome. Only the tough get going under such circumstances. I was amazed by sheer hard work and enthusiasm that Deepak and Santhosh had put in to fight many hurdles in their team. Kudos to both of them.

Tea Break.

Lightning Talks
Over the years, we have noticed that many folks who have attended BWST have been working wonderfully well on their skill sets and putting their organizations ahead of themselves by delivering better than what is expected of them. This is of utmost pride for us and something that brings utmost satisfaction. After all, peer workshops are meant for just that – Empowering People.

How did BWST 3 go this time?
This time around, we wanted to provide more time for discussions after each presentation. This worked really well. Many people were happy with the time allocated for questions. There was enough time not just for questions, but also for getting inputs/suggestions from experienced testers and managers who threw light upon different aspects of personal excellence and skill development.

We intentionally provided lengthy tea breaks so the participants from different organizations could chat up with others, discuss testing and challenges they face in day to day life.

We had a good mix of fresh grads turned testers, experienced testers and managers in BWST3. This resulted in different perspectives on many topics discussed during the day. There are many times in life when we feel victimized. Having a few folks who can empathise with us and set a direction will always help. This is where Meeta Prakash, Rahul Verma, Rahul Mirakhur, Natarajan, Sudip, Anuj Magazine and many others' presence helped.

Rahul Mirakhur was very happy with how BWST3 was organized and arrangements were made this time around. Now, that's a huge compliment. From our side, we had a gala time setting up the whole event and we were happy that every participant went back home satisfied for a day truly well spent!

Party time!
We got clicked. One of the hotel staff was kind enough to take a group picture. Many kept saying, "click a few more" to ensure they looked their unusual best :-)

What's a workshop without beer and snacks, huh? :-). We checked out of the hotel at 5.30 pm and went to a nearby pub to hang out for some more time. We spoke, ate, drank testing until we got tired and got back home safe.

Vote of Thanks
Special thanks to Rahul Verma for facilitation and to every participant at BWST3 who made this  event successful. And if you wanna know who cut through this years' tough competition to be at BWST 3, here's the list :

Rahul Verma, Rahul Mirakhur, Meeta Prakash, Anuj Magazine, Smitha Maraliga, Natarajan Alagappan, Mohit Verma, Yeshwantrao (Madurai), Pawan Kumar, Manjunatha C, Ravisuriya, Nagaraj Adarsha, Sudip Naha, Santhosh (Chennai), Deepak (Chennai), Vithya J, Korauhanba Singh, Pradeep Soundararajan, Parimala Shankaraiah, Santhosh Tuppad, Sunil Kumar, Dhanasekar S, Sreenuraj Varma.

What's next?
Get ready for next years' BWST :)

Regards,
Parimala
(On behalf of BWST team)

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

Where’s Curious Tester been?

Ever since I started blogging, I kept bragging how Curious Tester was my second child and how much I enjoyed spending most of my online time here. When my second child arrived in REAL 3 months ago, I realized how this blog became a step child almost instantly. It hurt because for two years, I nurtured it as if it was a baby and all of a sudden I had orphaned it. As the proverb goes “No pain, no gain”. I had to prioritize and my little one won over unanimously. As she grappled with the outside world, I grappled with my learnings, shortcomings and also came up with some cool stuff.

So what did I do all this while? Thanks to many of those wonderful sleepless nights, I was still on twitter and my RSS feeds entertained me while I was awake at odd hours. I read several books spanning testing, technology, parenting, relationships, motivation and many more. Now, don’t ask me for the list of books, I seriously don’t remember and I am too lazy to look up the bookshelf to recreate the list here J. I also happened to test many websites and applications on my Nokia E63 cell phone which was a great boon this time around. My reactions varied from ‘Oh, this site is so lousy on the phone’ to ‘What more can be done?’ to 'What value does testing bring in here' to many many more. There were many interesting observations which I wouldn't have found out if I had to test on a computer. Again, don’t ask me for those experience reports J

For a while, I often wondered if my readers would ever miss my writings ( this little human thing in me!). Thankfully, many did and I am grateful to all of them who messaged to find out if all was well with me. And yes, I am back! Watch this space!

New Beginnings!

Regards,

Parimala Shankaraiah