Of being a Self starter, Receiving Feedback, Mentorship and Michelangelo

I was recently reading thbe book- The Habit of Winning by Prakash Iyer and came across this story

The great painter and sculptor Michelangelo has several masterpieces to his credit. Perhaps at the top of that list is "David", his eighteen-foot-tall statue sculpted in marble in Florence, Italy. Now over 500 years old, this icon of Renaissance sculpture continues to attract- and fascinate- millions of visitors every year, from all over the world. Everyone who sees it goes back impressed by the genius of Michelangelo. But I am not sure if they all also take back the story behind the sculpting of this masterpiece.
The story goes that this mammoth eighteen-foot block of marble had been lying around for several years. In fact, it had been around long before Michelangelo was even born. Some great artists, including Leonardo da Vinci, were invited to create something from the slab of marble. They all looked at it and dismissed it as flawed and worthless. Nothing could come of it, they felt. Several years later, Michelangelo got to work on that 'flawed and worthless' piece of marble, and went on to create a magnificent work of art. Apparently, while he was working on David, a little boy went up to Michelangelo and asked him why he was banging away at the rock of marble, and hitting it so hard. 'Young man,' said Michelangelo. "There's an angel inside that rock. I am just setting him free.".

I did quite relate to this story as this tale is full of powerful lessons that we could apply in our Professional and Personal lives. Some of them below-

Power of Getting Started:
Before Michelangelo many renowned artists were called upon to give shape and life to this rough slab of marble but most of them dismissed the same as worthless even without thinking to try. Beyond all the artistic talent that Michelangelo had, he had a special quality i.e. the Power to initiate, that innate desire to start something.
In our work places, how many ideas (initiated by others or self) do we reject everyday either by saying or within our minds thinking they are worthless? How many times we get scared to ask a question in a large gathering thinking that people will ridicule even a single slip of tongue? How many times our own self stops us from trying something new just because that very something new will break the routine way of doing things ? I salute you if you answer "None" to any or all of these questions. But the fact of matter is that in most of the situations, without realizing, we fail to initiate. Many ideas die a silent death just because they are not allowed to come out, Just because we don’t get started.

I was reading this interesting article on How to measure Initiative ? . Found some great wisdom against which one can measure self on Initiative scale. It talks of following Stages-
1. Wait- People don’t initiate anything from self but keep waiting for Instructions.
2. Ask- Instead of Indefinitely waiting, you Ask your superior to involve you in something of meaning to you.
3. Recommend- This stage is more of not only "just" asking but also Recommending what interests you and the direction in which you would like to proceed.
4. Act Independently but Report Immediately- Think of an Action, Get convinced that it is right for business and take it immediately and report it back to Superior. This is mostly for areas you are delving into for the first time and building trust with your superior.
5. Act Independently and Report routinely- This is a stage when you are completely Independent and has been initiating lot of stuff from your side.
The story doesn’t tell whether Michelangelo had any boss but we certainly do have one. That’s why the above framework helps you know where you stand on an Initiative scale.

As Seth Godin says in his book Poke the Box , The challenge, it turns out, isn’t in perfecting your ability to know when to start and when to stand by. The challenge is getting into the habit of starting.
Start early, Start without someone prompting you- And become Michelangelo of your craft!

Mentorship:
When Michelangelo says those magical words- "There's an angel inside that rock ? I am just setting him free.", what is he actually doing to that rock. In some sense, he is acting as a Mentor to that Rock, chiselling it, correcting it and giving it a World class shape. Without googling for it, if i have to define a Mentor, he or she is someone who shapes your mind towards success in any undertaking. Mentor helps correct your flaws not even when going is rough but even stands to influence you even during normal conversations.
I always feel having a good mentor more important than being in the Influence of good books. It only helps to open up and look for mentor and create a stage for yourself to be a mentor to someone.

Receiving Feedback:
Another learning i gather from this story is that if the Rock was rigid, it would never have transformed into David. Likewise, if we as humans are rigid in receiving feedback, we would turn into a Rock that could never be moulded. Receiving feedback is as much as a skill as is relaying feedback. Hearing a negative feedback about self is sometimes as painful as Rock (if it was living) that Michelangelo chiselled. The ones who absorb this pain becomes better and eventually World class.

Do you have any more learnings from this Story ?

What does Twitter bios say about Software Testers ?

This is meant to be just a fun post. If you are able to figure out any inferences (good or bad), i leave that entirely upto your own Interpretation.
I have included the Twitter bios of some of the people who are making some meaningful contributions to Software testing (except may be the last one in this list :-)). I am no authority to come up with the list of accomplished Software testers, so if you are reading and your name does not appear in the below list, Please feel free to think that i am at fault here.

Here we go, some Twitter Bios:

James Bach: @jamesmarcusbach
Author of Secrets of a Buccaneer-Scholar, high school dropout, unschooling parent, philosopher, neo-pyrrhonian skeptic, software tester

Arunkumar Khannur: @arun_khannur
Arunkumar Khannur, with 23+ years of IT career, is a Leading Advisor, Author, Speaker and Senior Faculty on Software Testing.

Praveen Singh: @vpsingh
Author'Real Startups' http://amzn.to/gqlImq Entrepreneur, Web Enthusiast, Blogger. Founder/CEO of 99tests.com

Michael Bolton: @michaelbolton
I solve testing problems that other people can't solve, and I teach people how they can do it too.

Ajay Balamurugadas: @ajay184f
Software tester passionate to learn to test any software

Jerry Weinberg: @JerryWeinberg
Author of more than 60 books, fiction & non-fiction, Consultant, Teacher

Shrini Kulkarni: @ShriniK
Software Testing Generalist, Systems thinker, Skeptic

Rahul Verma: @rahul_verma
Software Tester, Blogger, Python Enthusiast with special interest in performance testing, security testing and design of test automation frameworks

Vipul Kocher: @vipulkocher
Bhartiya, entrepreneur, Software Tester. Books, History, Movie, Food, ~Lover - TOO MANY INTERESTS, TOO FEW SKILLS

Narayan Raman: @narayanraman
Programmer, Wildlifer, Entrepreneur, CEO - Tyto Software, Author of Sahi (http://sahi.co.in)

Parimala Shankaraiah: @curioustester
Testing Junkie, Wife of a 30 yo kid, Mother of 3 yo kid, loves to read, enjoys long walks, foodie and a horrible cook!

Santosh Tuppad: @santhoshst
Passionate tester, blogger, testing enthusiast, friendly & fun loving. Director at Moolya Software Testing Private Limited.

Pradeep Soundararajan: @testertested
Known for creativity & moving software testing forward in India. Author Speaker Coach Consultant Director @ Moolya Software Testing Pvt Ltd http://moolya.com

Anuj Magazine: @anujmagazine
Passionate about Software Testing,ReadnWrite,Graphology,Running….Lives by- Life is beautiful because you can always do something that you have never done before

Some Inferences:
To me Twitter bio or any other bio for that matter is the manner in which the people want the public to view them. Sometimes, there is an intersection between how you view yourselves as against how you want the world to view you but such an intersection is rare. There is always some good deal of difference between the way the world views you as against who you really are. But lets forget this for sometime and go on and read the inferences i draw from all the above bios.

- For most of these people, they take pride in associating themselves to testing.
- Not for all though, the Testing is not the central theme of their bio as the word "Testing" does not appear in everyone's bio.
- For only a handful, the Years of experience in their respective field is important enough to deserve a mention in the bio.
- Most of these folks have multiple interests i.e. some prominent interests beyond Software Testing.
- For some, they associate themselves with an important event in their lives.
- Very few of these bios make a mention of their personal life in the bio. Most are inclined towards their professional achievements.
- Most of people like to highlight atleast one Achievement that differentiates them or makes them unique.
- Only a very few bios have some sort of numbers in their Bio. precisely, Years of experience, No. of books published and Age.
- While most indicated that they Love testing, very few were clear in their Bio on what type of testing they are keen on.

If you can think of any more inferences from these bios, Please add it to comments. Would love to hear your views.

Should the testers be responsible for pinponting the cause of Defects ?

A tester works fabulously to find an important bug in an application and raises a bug report with lot of excitement and possibly all the details that he could include. The bug is 100% reproducible. After some days, the bug report gets assigned back to him stating that the Developer needs more information. Upon further analysis of the request, the tester figures out that Developer is actually requesting for assistance to help him "pinpoint" the problem in the code. Of course, the Developer is not asking the tester to go through the code but asking more intricate details that are beyond the scope of a bug report (as the bug is 100% reproducible). The tester is in confused state! He thinks that he provided all the information that was there to be provided and the bug is 100% reproducible, then why on earth would a developer need more Information. Let’s look at a perspective about this problem-

Is pinpointing problem a part of test group's job?
In my view, in an ideal world, in couple of words- It should be. Let me explain my perspective here.
Project teams develop Software to serve the customers. The test teams primarily exist to provide Specialized Services to the overall projects. The extent of Service include “what” and “how” of it and primarily depend upon the overall Testing mission we choose. Generally, one of the common views is to consider testing only as “Detection” and “Reporting” of issues. That certainly leaves out pinpointing activity. To simply put, pinpointing a problem is a activity that helps a developer figure out the buggy part of code.
It’s no wrong in treating testing more alongside the “Detection” and “Reporting” areas but when we talk about the notion of Service, one of the things that get associated with it is Value generation. In my view- In any Service related profession, more than anything else, the overall Value should always be upwardly mobile. Value from the testing group as such is perceived differently by different people who we work with and provide our Services.
Testing all that’s possible, Providing an Accurate flawless defect report, Providing accurate bug related information (metrics) that can help Management make crucial product decision, Helping support team giving crucial information on a customer problem etc. are some Value generating activities that goes beyond the idea of Detecting and Reporting. Of course, Pinpointing problems is another activity that helps add Value as a developer perceives it from the Test group. I know in some cases test teams even helped in fixing the bugs, so essentially it boils down to what “mission” do we commit to.
As Gerald Weinberg also states in his book Perfect Software: And Other Illusions about Testing
Testing (can be) for Discovery, pinpointing, Locating, determining significance, repairing, troubleshooting and testing to learn.

As I mentioned in the beginning, the above description represents and close to Ideal world situation.

Is it really possible to have the clear distinction between pinpointing and testing?
I think No, its not possible to create that distinction especially when we consider the product from a black-box perspective. If we do White-box testing, it is possible to have some sort of clear distinction. I think more or less every good bug report has some level of Troubleshooting done. But “some level of troubleshooting” is often not as accurate as “pinpointing”. Pinpointing just helps the developer to reach the faulty lines of code, identify the problem and fix it. Apparently, in a product with millions of lines of code reaching that faulty line of code is a very tedious job (sometimes a mystery!). If a tester helps a developer do that, then we have a delighted customer (i.e. if at all we treat him/her as a customer. In normal circumstances, we should). From test perspective, it is again the amount of cost we are willing to spend to reach this level of delight. Again, it leads to the eternal question- “what is our mission”.
In short, it is not possible to have that clear distinction between pinpointing and testing in our kind of test setup.

Does the time-limit heuristic usually work always ?
Gerald Weinberg also talks about Time-limit heuristic.
A heuristic that helps untangle who does what for how long states the concept simply:
Nobody on a project should carelessly waste the time of anyone on the project

According to this, the test team member sets a time limit and communicate to the Development team on how much time can they spend on the Development specific investigation. Beyond this time, the onus is on the Development team to figure out.
Since this is a heuristic and not a rule, its quite hard to define the time-limit. Only way it can work is if we make it as a rule i.e. Test team would not spend more than 1 man-day or whatever is the limit and track it accordingly. Doing so (without prior agreement) , will cause some grim repercussions including the relations with Development team.
Having said this, testers don’t have endless time at their disposal. So, till the time there are a formal guidelines around this, it's good to make the Development team (requesting the pinpointing Service) aware of the extent we can help without causing the Testing schedule in Jeopardy.

If the bug is reproducible, to what extent should the test team help the dev pinpoint the bug?
The greater degree of conflict (regarding pinpointing) between Dev and Test arises when the bug is reproducible 100% of time. Ideally, the Dev should Investigate, debug and figure out where the bug is in the code with some help from Test team.
If the bug is non-reproducible then there is even finer distinction between Bug detecting and bug pinpointing. I think Test team should lead the Investigation here whereas for Reproducible bugs the Dev team should lead the investigation.

Closing thoughts:
Considering the above points, I can think of the following points-
• Get in agreement with the Dev team on what level of pinpointing can the test team help with. It should be made clear at the start of project involvement.
• Have a Clear distinction on what Activities include Detection, Troubleshooting and Pinpointing. Possibly, include the same in the Test plan.
• Include Pinpointing activities as a part of Standard Test estimations. It won’t be too high a cost considering the entire span of release but it is worthwhile to consider it as a separate line-item.
• Be aware of impacts of frequent Task-switching for testers (which usually happens when testers switches to Bug investigation away from testing work). Not everyone can do it with an ease. This can be one area specific training can be designed/conducted for testers if there is a need.

Any thoughts ?