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 ?
Friday, April 1, 2011
Tuesday, March 29, 2011
How well do your team members know each other ?
Sometime back i wrote on the topic- How well do you know your team..." which had a prime focus on team work and why knowing the team is a prime tasks for any leader. In today's world, no matter how virtual we may become in conducting our work , the team bonding remains one of the foremost task for a leader. It’s not only important for a leader to know his or her team but it is also of great significance for the team members to know each other. This is especially true of a team in which people have been working together for a while, may be 2-3 years and beyond.
One can always argue that more the team members work with each other-the more time they spend together, the more they "know" each other. While this may be true to an extent, it is equally true that more time people spend working with each other, the more they start taking each other's strengths for granted. And they start considering their egos bigger than relationship and think more of shortcomings rather than positives. I don’t write this to say that this is necessarily right or wrong but this aspect is very human for sure.
It does become challenging to appreciate each other's strengths after a while so there is a constant need to remind each other of the value that each one brings in to the organization and to the team. How can one remind other team member of their Strengths ? He or She can openly appreciate the other person but in true sense this may sound as more artificial than anything else. There can be many ways to address this but i have found one exercise when done with the team quite useful to address this aspect.
Here are the details-
Required:
• blank sheets of paper (same as no. of team members)
• pens (same as no. of teamm members)
• Around 20-30 min in a team meeting
• Paricipants with Open unbiased mind
Procedure:
1. Participants sitting in a sort of round table setting.
2. Each participant gets one piece of paper and write their name on it.
3. As a next step, each participant passes on the paper (with their name) to the person sitting on right of him/her.
4. Each person now has a paper with someone else’s name on it.
5. As a next step, Each participant thinks for a while (1 minute or less) and writes something positive about the person who name appears on the sheet. The participant need not write his/her name with the comment. “Something positive” can be even some good instance, good experience that he/she would have shared with that person, or some personality trait he/she likes about him/her or even some professional achievement, skill about that person. Preferably write it in sentence form rather than a single word. The bottom line is that it should be something positive. If you need more to write, take it but try and be as honest as possible in the praise.
6. After the participant has completed writing, go to Step# 3 till 5 repeatedly till you get the paper with your name back.
7. After you receive the sheet with your name, each person tells any one interesting Positive thing someone has written about him/her.
Benefits:
• Helps people thinking something positive (beyond their egos) about the team members and reinforcing that belief.
• Help people reinforce the fact that irrespective of the personality differences, there is something positive to cherish about.
• The final sheet is something people can keep with them and refer to it anytime later. This can be referred especially when chips are down and looking at the positives helps one regain the confidence.
• Share some light moments within the team especially when everyone is communicating the Interesting Positive fact in a team setting.
Do you know of any other interesting ways ?
One can always argue that more the team members work with each other-the more time they spend together, the more they "know" each other. While this may be true to an extent, it is equally true that more time people spend working with each other, the more they start taking each other's strengths for granted. And they start considering their egos bigger than relationship and think more of shortcomings rather than positives. I don’t write this to say that this is necessarily right or wrong but this aspect is very human for sure.
It does become challenging to appreciate each other's strengths after a while so there is a constant need to remind each other of the value that each one brings in to the organization and to the team. How can one remind other team member of their Strengths ? He or She can openly appreciate the other person but in true sense this may sound as more artificial than anything else. There can be many ways to address this but i have found one exercise when done with the team quite useful to address this aspect.
Here are the details-
Required:
• blank sheets of paper (same as no. of team members)
• pens (same as no. of teamm members)
• Around 20-30 min in a team meeting
• Paricipants with Open unbiased mind
Procedure:
1. Participants sitting in a sort of round table setting.
2. Each participant gets one piece of paper and write their name on it.
3. As a next step, each participant passes on the paper (with their name) to the person sitting on right of him/her.
4. Each person now has a paper with someone else’s name on it.
5. As a next step, Each participant thinks for a while (1 minute or less) and writes something positive about the person who name appears on the sheet. The participant need not write his/her name with the comment. “Something positive” can be even some good instance, good experience that he/she would have shared with that person, or some personality trait he/she likes about him/her or even some professional achievement, skill about that person. Preferably write it in sentence form rather than a single word. The bottom line is that it should be something positive. If you need more to write, take it but try and be as honest as possible in the praise.
6. After the participant has completed writing, go to Step# 3 till 5 repeatedly till you get the paper with your name back.
7. After you receive the sheet with your name, each person tells any one interesting Positive thing someone has written about him/her.
Benefits:
• Helps people thinking something positive (beyond their egos) about the team members and reinforcing that belief.
• Help people reinforce the fact that irrespective of the personality differences, there is something positive to cherish about.
• The final sheet is something people can keep with them and refer to it anytime later. This can be referred especially when chips are down and looking at the positives helps one regain the confidence.
• Share some light moments within the team especially when everyone is communicating the Interesting Positive fact in a team setting.
Do you know of any other interesting ways ?
Wednesday, March 16, 2011
Myths about Globalization Testing
I think i havent contributed to the Myths about Globalization Testing Series in a while. I do intend to write more about this and soon. In the meantime, i thought to just go back in time a little and list all myths that i have worked to uncover in the previous blogs. Here's the list-
Uncovering Myths about Globalization testing -1
Myth 1: G11n testing is not technical enough
Myth 2: G11n testing is majorly about testing the UI
Myth 3: G11n Testing can start only after the base product is translated
Uncovering Myths about Globalization testing -2
Myth 4: A person who doesn't know French cannot test the French version of the Software
Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
Myth 6: There is no scope of exploratory testing while testing internationalized applications
Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.
Uncovering Myths about Globalization testing -3
Myth 8: If a test case works fine in French language, it will work fine in German language as well
Myth 9: If the Foreign text input in application text fields work fine by using the Soft keys, then it means the data input through respective Foreign language key board would also work fine.
Myth 10: Globalization testing doesn't require the same test setup as is required to do the Base language testing. Globalization testing can be done with a minimum test setup.
Uncovering Myths about Globalization testing -4
Myth 11: Localization - means Localized product on a localized Operating System, Internationalization- means Localized product on English Operating System
Uncovering Myths about Globalization testing- Demystifying MUI Packs
Myth 12: Testing International applications using "Microsoft's MUI Pack" or "Localized OS installation" means one and the same thing
Uncovering Myths about Globalization testing- Input validation testing 2
Myth 13- A tester can perform tests specific to text inputs for Localized applications using the similar approaches as the English language testing
Uncovering Myths...."Security Testing is from Mars and Globalization Testing is from Venus"
Myth 14- Security Testing is from Mars and Globalization testing is from Venus
Uncovering Myths about Globalization testing- English version on Localized setup
Myth 15: There is no use testing the English version of a product on Localized Operating systems
Uncovering Myths about Globalization testing- MUI Packs in Win XP and Win Vista
Myth 16: There is no difference between MUI technology being used in Win XP and Win Vista
Uncovering myths about Globalization Testing- Reusing Test Automation
Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing
Uncovering myths about Globalization testing- Context driven planning
Myth 18: There is one standard way of Test Planning the Globalization testing, which is applicable to all the contexts.
Uncovering Myths about Globalization Testing- Websites with localized addresses
Myth 19: There is no need to include localized web addresses as a part of your test data as Web addresses are always in English
Uncovering Myths about Globalization Testing- Knowledge of Native Language
Myth 20: If i dont know German at all, i can still effectively test a German application
Uncovering myths about Globalization Testing- Finding Localization bugs before actual translation takes place
Myth 21: It is not possible to find the Localization bugs before actual translation takes place
Uncovering myths about Globalization Testing- Testing MUI feature
Myth 22 : A tester testing Globalization features need not pay any special attention towards testing MUI feature.
Uncovering myths about Globalization testing- Approach to generate Localized test data
Myth 23: It is possibly the right strategy to randomly pick the test data specific to the localized language you are testing
Hope you enjoyed going over these again. Would appreciate your comments, suggestions!
Uncovering Myths about Globalization testing -1
Myth 1: G11n testing is not technical enough
Myth 2: G11n testing is majorly about testing the UI
Myth 3: G11n Testing can start only after the base product is translated
Uncovering Myths about Globalization testing -2
Myth 4: A person who doesn't know French cannot test the French version of the Software
Myth 5: A tester only needs to follow the test cases executed for Base language in order to thoroughly test the internationalized applications
Myth 6: There is no scope of exploratory testing while testing internationalized applications
Myth 7: The language verification of User Interface can be done by comparing the text on screen with translation outputs of any freely available Online translator.
Uncovering Myths about Globalization testing -3
Myth 8: If a test case works fine in French language, it will work fine in German language as well
Myth 9: If the Foreign text input in application text fields work fine by using the Soft keys, then it means the data input through respective Foreign language key board would also work fine.
Myth 10: Globalization testing doesn't require the same test setup as is required to do the Base language testing. Globalization testing can be done with a minimum test setup.
Uncovering Myths about Globalization testing -4
Myth 11: Localization - means Localized product on a localized Operating System, Internationalization- means Localized product on English Operating System
Uncovering Myths about Globalization testing- Demystifying MUI Packs
Myth 12: Testing International applications using "Microsoft's MUI Pack" or "Localized OS installation" means one and the same thing
Uncovering Myths about Globalization testing- Input validation testing 2
Myth 13- A tester can perform tests specific to text inputs for Localized applications using the similar approaches as the English language testing
Uncovering Myths...."Security Testing is from Mars and Globalization Testing is from Venus"
Myth 14- Security Testing is from Mars and Globalization testing is from Venus
Uncovering Myths about Globalization testing- English version on Localized setup
Myth 15: There is no use testing the English version of a product on Localized Operating systems
Uncovering Myths about Globalization testing- MUI Packs in Win XP and Win Vista
Myth 16: There is no difference between MUI technology being used in Win XP and Win Vista
Uncovering myths about Globalization Testing- Reusing Test Automation
Myth 17: The test scripts meant for English language automated tests cannot be reused for Internationalization testing
Uncovering myths about Globalization testing- Context driven planning
Myth 18: There is one standard way of Test Planning the Globalization testing, which is applicable to all the contexts.
Uncovering Myths about Globalization Testing- Websites with localized addresses
Myth 19: There is no need to include localized web addresses as a part of your test data as Web addresses are always in English
Uncovering Myths about Globalization Testing- Knowledge of Native Language
Myth 20: If i dont know German at all, i can still effectively test a German application
Uncovering myths about Globalization Testing- Finding Localization bugs before actual translation takes place
Myth 21: It is not possible to find the Localization bugs before actual translation takes place
Uncovering myths about Globalization Testing- Testing MUI feature
Myth 22 : A tester testing Globalization features need not pay any special attention towards testing MUI feature.
Uncovering myths about Globalization testing- Approach to generate Localized test data
Myth 23: It is possibly the right strategy to randomly pick the test data specific to the localized language you are testing
Hope you enjoyed going over these again. Would appreciate your comments, suggestions!
Saturday, February 19, 2011
Have you defined your Body of Work ?
I tried searching for Software Testing Records, could not find anything. Why dont Software Testers have any records ?
This was one of the questions raised by one of the participant in an Open session of recently concluded Bug-De-Bug conference . Honestly, a part of me thought of dismissing it as one of those naive questions usually asked in the public forums/conferences. Luckily, another (and better) part persisted in giving this question a more thought in-depth.
During my early days in the profession, i often used to wonder- Why cannot Software Testing be as glamorous a profession as Cinema or Politics or may be like Soccer or Cricket ? What aren't Software Testers as popular and as famous as people involved in these fields ? As the time has passed and if i look back to find the answers to these questions, i see it in different ways listed below-
- Everything that is Glamorous and popular isn’t necessarily always great. We have had several example of High profile Politicians, Actors and even Sports personalities who are involved in larger than life scams thereby signifying a sort of ethical deficit. All that Glitters is certainly not Gold!
- With time and energy of people, Software Testing profession has evolved into a larger ecosystem, which is large enough to have its own Celebrities. It was not very long ago that Jerry Weinberg got chosen as a Testing Luminary by a democratic voting process. Is Jerry any short of a Testing Celebrity ? There are a lot of media coverage associated with Software Testing and its practitioners. And all this attention is well-deserved for a profession that is expected to have a market of $56 Billion by 2013. Yes, you heard that number right, its $ 56 Billion. The future of testing is going to see a lot of new Celebrities evolve and who knows it may become a sort of Glamorous profession (in literal sense) when someone comes up with a concept of Reality Show on Software Testing possibly having real time testers working in time-bound interval to test a challenging Software. Wow, the future looks exciting!
Thinking over both these questions again- there may be many reasons why dont we have records for Software Testing like there is no historian taking care of maintaining the record (like we have in various Sports, Politics), Nobody has attempted to apply in Guinness Book of World records or may be testers are not really fascinated by records or by being Glamorous and like to silently add value to the product.
Now, that raises a very Interesting question- What are Software Testers really fascinated by ? What defines the body of work for a Software Tester ? One of the Art blogs defined Body of Work as something that is comprised of multiple pieces that are cohesive in nature.
Robin Sharma in one of his books mentions this anecdote about the Body of Work-
Art Buchwald, the writer, who was around 80 and battling Kidney failure was once asked, "What is your idea of perfect happiness ?" "Being Healthy" was his reply. He was asked, "Which talent would you most like to have ?" "Living" was his reply. Then he was asked, "What is your most treasured possession ?" "All of my writing- my 32 books and all of my columns".
The point of wisdom that you and I can take away ? Greatness comes when you create something with your life that is not only bigger that you but outlasts you. Legitimacy and recognition and prestige and material things are all fine and are very human pursuits. But there is something far more important: Legacy. Making a difference. Having an impact. Creating something special. And meaningful.
What Body of Work will you create over your life so that the generations who follow will know that you've been here ? What will your "most treasured possession" look like ?
If you as a Software Tester are at the fag end of your career, what kind of things do you want to look back with pride ?
If you were to do a paragraph about your accomplishments in Software Testing, how would it look ?
Have you defined your Body of Work ?
This was one of the questions raised by one of the participant in an Open session of recently concluded Bug-De-Bug conference . Honestly, a part of me thought of dismissing it as one of those naive questions usually asked in the public forums/conferences. Luckily, another (and better) part persisted in giving this question a more thought in-depth.
During my early days in the profession, i often used to wonder- Why cannot Software Testing be as glamorous a profession as Cinema or Politics or may be like Soccer or Cricket ? What aren't Software Testers as popular and as famous as people involved in these fields ? As the time has passed and if i look back to find the answers to these questions, i see it in different ways listed below-
- Everything that is Glamorous and popular isn’t necessarily always great. We have had several example of High profile Politicians, Actors and even Sports personalities who are involved in larger than life scams thereby signifying a sort of ethical deficit. All that Glitters is certainly not Gold!
- With time and energy of people, Software Testing profession has evolved into a larger ecosystem, which is large enough to have its own Celebrities. It was not very long ago that Jerry Weinberg got chosen as a Testing Luminary by a democratic voting process. Is Jerry any short of a Testing Celebrity ? There are a lot of media coverage associated with Software Testing and its practitioners. And all this attention is well-deserved for a profession that is expected to have a market of $56 Billion by 2013. Yes, you heard that number right, its $ 56 Billion. The future of testing is going to see a lot of new Celebrities evolve and who knows it may become a sort of Glamorous profession (in literal sense) when someone comes up with a concept of Reality Show on Software Testing possibly having real time testers working in time-bound interval to test a challenging Software. Wow, the future looks exciting!
Thinking over both these questions again- there may be many reasons why dont we have records for Software Testing like there is no historian taking care of maintaining the record (like we have in various Sports, Politics), Nobody has attempted to apply in Guinness Book of World records or may be testers are not really fascinated by records or by being Glamorous and like to silently add value to the product.
Now, that raises a very Interesting question- What are Software Testers really fascinated by ? What defines the body of work for a Software Tester ? One of the Art blogs defined Body of Work as something that is comprised of multiple pieces that are cohesive in nature.
Robin Sharma in one of his books mentions this anecdote about the Body of Work-
Art Buchwald, the writer, who was around 80 and battling Kidney failure was once asked, "What is your idea of perfect happiness ?" "Being Healthy" was his reply. He was asked, "Which talent would you most like to have ?" "Living" was his reply. Then he was asked, "What is your most treasured possession ?" "All of my writing- my 32 books and all of my columns".
The point of wisdom that you and I can take away ? Greatness comes when you create something with your life that is not only bigger that you but outlasts you. Legitimacy and recognition and prestige and material things are all fine and are very human pursuits. But there is something far more important: Legacy. Making a difference. Having an impact. Creating something special. And meaningful.
What Body of Work will you create over your life so that the generations who follow will know that you've been here ? What will your "most treasured possession" look like ?
If you as a Software Tester are at the fag end of your career, what kind of things do you want to look back with pride ?
If you were to do a paragraph about your accomplishments in Software Testing, how would it look ?
Have you defined your Body of Work ?
Sunday, February 13, 2011
Key Career Planning Lessons from Nokia's Slide
One of the most talked about Tech News in past week or so has been Nokia CEO Stephen Elop's letter to the employees making people aware of current state of the Organization.
I am not sure how this letter got public but reading through this had me split into varying thoughts. One of the thought, i was feeling sympathy for the Nokia employees who received this. It must have been Earth shattering for a lot of them, after all who would feel comfortable in the organization when the CEO itself is describing the business to be a "burning platform". But at the same time, Other thought line is about the Learnings one can extract from the situation Nokia is in currently.
One of the aspects about Elop's email that catches immediate attention is his use of a burning platform metaphor to make people understand the extent of downfall of Company's business.
There is a pertinent story about a man who was working on an oil platform in the North Sea. He woke up one night from a loud explosion, which suddenly set his entire oil platform on fire. In mere moments, he was surrounded by flames. Through the smoke and heat, he barely made his way out of the chaos to the platform's edge. When he looked down over the edge, all he could see were the dark, cold, foreboding Atlantic waters.
As the fire approached him, the man had mere seconds to react. He could stand on the platform, and inevitably be consumed by the burning flames. Or, he could plunge 30 meters in to the freezing waters. The man was standing upon a "burning platform," and he needed to make a choice.
He decided to jump. It was unexpected. In ordinary circumstances, the man would never consider plunging into icy waters. But these were not ordinary times - his platform was on fire. The man survived the fall and the waters. After he was rescued, he noted that a "burning platform" caused a radical change in his behavior.
This immediately reminded me of Vineet Nayar's HCL transformation story in his book Employees First Customers Second . Vineet says One of the first Ingredient in making people onboard for any change initiative is by making them show the reality as is. People, quite naturally, have the habit to rest on Organization's past laurels and most often do not see the need to change. Mirror Mirror exercise is nothing but a metaphor to make sure that people view the reality as it exists as against seeing the reality in the rear view mirror (where they can see only positive results and laurels).
It is quite evident that getting large employee population aware of the need of change and getting them out of their comfort zones cannot be done in any soft manner. It requires a Strong communication by all possible means. That is where Elop's metaphor about burning platform helps him take charge of situation and people understand the heat of the situation.
Are there any learnings we can take from this saga in the way we plan our careers ? Some that came across my mind-
Do we often play the Mirror-Mirror exercise during our careers ?
i.e. Do we tend to get complacent (often without our own knowledge) and tend to rest on our past professional laurels ? Do we really take a real hard look at the way our careers are going and prepare ourselves for the Action how-so-ever risky (but with immense value potential) it may be.
Do we always wait for the platform to really burn before we accept that a change is needed in our careers ?
Here Change does not necessarily mean Changing the Jobs, most of the people in the IT industry (atleast in India, i know) are really good at that. The Change here mean Change in the way we perceive work, Change in the way we do the work, Change in the direction we wish to take our skill levels to. Are you really expert at initiating such change ? We often aim for expertise in our Subject area not in skills around Change Management and other Soft skills.
Are we really aware of how the ecosystem is taking shape around us ?
If you read Elop's email full length, you will realize how Nokia actually misread the way Mobile phones ecosystem was shaping up around. The massive popularity of Apple's design + Low cost manufacturers like Macromax, Karbon + growing dominance of Android platform almost consumed Nokia's business. And all this happened in no less than 2 years. The World Leader and a household name like Nokia came down almost tumbling within as less as 2 years. Astonishing!
The understanding of the way the industry is growing is not only important but also essential while planning for careers in today's time. Gone are the days when just knowing and mastering what you are supposed to do in your jobs was enough. Its isn’t clearly just enough. No doubt that one need to become expert at the very thing that defines our job but don’t just limit or narrow your thinking around that. Have a broad view of the job, the view that gives you a broad sense of way ecosystem is shaping up in the career of your choice.
Recession is a Reality. Do we make a mistake of blindfolding to the possibility of a Recession while planning for Career ?
Coming to my first point in this write-up when i mentioned that this email from Elop would have caught many employees by surprise. Why would such a situation be a surprise for employees ? Recession and Slow growth is a reality of today's times. I think the world will rarely see Hundred years old organizations anymore considering the rapidity of the change around us. Companies will come and go and Economies will go up and down following more or less irregular patterns. Do plan for 4-5 recessions in a career spanning 30-35 years. It is no rocket science but requires a bit of foresight and willingness to go beyond the comfort zones
Do not Quit when the chips are down.
Great careers are made when one learns how to deal with the crisis. There will many who would be planning for career shift from Nokia after reading Elop’s email. Most of those who choose the career move when they see crisis around are often looking for that elusive comfort shield . No doubt everyone has some personal/financial commitments w.r.t. the jobs they are in and in some cases Career move in crisis when chips are really down may be a good Option. But not always! Staying on and persisting often opens up the treasure of learning that one will never get in more relaxed, complacent Work environment.
Is your career on a burning platform ? Are you game for that elusive leap into unknown or stay on the platform that’s burning ?
Change Mindset,Not Jobs!
Please share your thoughts!
I am not sure how this letter got public but reading through this had me split into varying thoughts. One of the thought, i was feeling sympathy for the Nokia employees who received this. It must have been Earth shattering for a lot of them, after all who would feel comfortable in the organization when the CEO itself is describing the business to be a "burning platform". But at the same time, Other thought line is about the Learnings one can extract from the situation Nokia is in currently.
One of the aspects about Elop's email that catches immediate attention is his use of a burning platform metaphor to make people understand the extent of downfall of Company's business.
There is a pertinent story about a man who was working on an oil platform in the North Sea. He woke up one night from a loud explosion, which suddenly set his entire oil platform on fire. In mere moments, he was surrounded by flames. Through the smoke and heat, he barely made his way out of the chaos to the platform's edge. When he looked down over the edge, all he could see were the dark, cold, foreboding Atlantic waters.
As the fire approached him, the man had mere seconds to react. He could stand on the platform, and inevitably be consumed by the burning flames. Or, he could plunge 30 meters in to the freezing waters. The man was standing upon a "burning platform," and he needed to make a choice.
He decided to jump. It was unexpected. In ordinary circumstances, the man would never consider plunging into icy waters. But these were not ordinary times - his platform was on fire. The man survived the fall and the waters. After he was rescued, he noted that a "burning platform" caused a radical change in his behavior.
This immediately reminded me of Vineet Nayar's HCL transformation story in his book Employees First Customers Second . Vineet says One of the first Ingredient in making people onboard for any change initiative is by making them show the reality as is. People, quite naturally, have the habit to rest on Organization's past laurels and most often do not see the need to change. Mirror Mirror exercise is nothing but a metaphor to make sure that people view the reality as it exists as against seeing the reality in the rear view mirror (where they can see only positive results and laurels).
It is quite evident that getting large employee population aware of the need of change and getting them out of their comfort zones cannot be done in any soft manner. It requires a Strong communication by all possible means. That is where Elop's metaphor about burning platform helps him take charge of situation and people understand the heat of the situation.
Are there any learnings we can take from this saga in the way we plan our careers ? Some that came across my mind-
Do we often play the Mirror-Mirror exercise during our careers ?
i.e. Do we tend to get complacent (often without our own knowledge) and tend to rest on our past professional laurels ? Do we really take a real hard look at the way our careers are going and prepare ourselves for the Action how-so-ever risky (but with immense value potential) it may be.
Do we always wait for the platform to really burn before we accept that a change is needed in our careers ?
Here Change does not necessarily mean Changing the Jobs, most of the people in the IT industry (atleast in India, i know) are really good at that. The Change here mean Change in the way we perceive work, Change in the way we do the work, Change in the direction we wish to take our skill levels to. Are you really expert at initiating such change ? We often aim for expertise in our Subject area not in skills around Change Management and other Soft skills.
Are we really aware of how the ecosystem is taking shape around us ?
If you read Elop's email full length, you will realize how Nokia actually misread the way Mobile phones ecosystem was shaping up around. The massive popularity of Apple's design + Low cost manufacturers like Macromax, Karbon + growing dominance of Android platform almost consumed Nokia's business. And all this happened in no less than 2 years. The World Leader and a household name like Nokia came down almost tumbling within as less as 2 years. Astonishing!
The understanding of the way the industry is growing is not only important but also essential while planning for careers in today's time. Gone are the days when just knowing and mastering what you are supposed to do in your jobs was enough. Its isn’t clearly just enough. No doubt that one need to become expert at the very thing that defines our job but don’t just limit or narrow your thinking around that. Have a broad view of the job, the view that gives you a broad sense of way ecosystem is shaping up in the career of your choice.
Recession is a Reality. Do we make a mistake of blindfolding to the possibility of a Recession while planning for Career ?
Coming to my first point in this write-up when i mentioned that this email from Elop would have caught many employees by surprise. Why would such a situation be a surprise for employees ? Recession and Slow growth is a reality of today's times. I think the world will rarely see Hundred years old organizations anymore considering the rapidity of the change around us. Companies will come and go and Economies will go up and down following more or less irregular patterns. Do plan for 4-5 recessions in a career spanning 30-35 years. It is no rocket science but requires a bit of foresight and willingness to go beyond the comfort zones
Do not Quit when the chips are down.
Great careers are made when one learns how to deal with the crisis. There will many who would be planning for career shift from Nokia after reading Elop’s email. Most of those who choose the career move when they see crisis around are often looking for that elusive comfort shield . No doubt everyone has some personal/financial commitments w.r.t. the jobs they are in and in some cases Career move in crisis when chips are really down may be a good Option. But not always! Staying on and persisting often opens up the treasure of learning that one will never get in more relaxed, complacent Work environment.
Is your career on a burning platform ? Are you game for that elusive leap into unknown or stay on the platform that’s burning ?
Change Mindset,Not Jobs!
Please share your thoughts!
Friday, February 4, 2011
Google-Microsoft Saga: When Testers become Detectives ?
2011 has certainly started with a bang (or a Bing!) Of the most talked about topic on the web in the recent history is Google accusing Microsoft of Copying its Search results. Refer this Google post for more details.
To give a brief background of this, am quoting the above blog-
It all started with tarsorrhaphy. Really. As it happens, tarsorrhaphy is a rare surgical procedure on eyelids. And in the summer of 2010, we were looking at the search results for an unusual misspelled query [torsorophy]. Google returned the correct spelling—tarsorrhaphy—along with results for the corrected query. At that time, Bing had no results for the misspelling. Later in the summer, Bing started returning our first result to their users without offering the spell correction (see screenshots below).
Once Google got a Sniff (Suspicion) of this, they started detailed investigation into this and even inserted some sort of Pseudo-results while Searching using some unusual parameters and to their surprise they found Bing results to be exactly the same. Now, that’s something! There are several thoughts and terms that comes to mind when talking about Investigation of this magnitude and its relation with Software Testing.
Is it similar to Competitor Analysis ?
In a typical Software Product Testing setup, when one organization is competing with other- Testing serves many additional purposes and one of which is Competitor Analysis. In this Analysis, a tester tests the product vis-à-vis the features in the Competitor’s products with a primary intent to figure out what we lack and what we are good at. For example- Comparing the how long it takes to access and use a certain feature (Performance Test) with Competitor product is a common practice. The data that we get after such analysis is very useful for the Product Management and even the Sales teams to help prove a point to the Customers.
Is it similar to Patent Infringement Test ?
Its well-known that Organizations reaps great rewards on the Employees who help Organization develop a Technology or an Innovation that could be Patented. One of the lesser known facts is that the same Organizations reaps even greater rewards if their Employees can help and find that their Patents or Patented Technology is being used by a Competitor. This is something that can help Organizations prove Patent Infringements, which not only gets hefty sums in winning Lawsuits but also help to pull down a reputation of customers. The Tests done to prove Patent Infringements require In-depth skills and Technical Orientation and it is usual that these are found accidently than in an Structured manner.
Is it similar to Hacking ?
Hacking may be an extreme term to describe Google-Microsoft Saga but the underlying principles of hacking remains the same i.e. You start Investigating with an Intention to prove something- it may be your Technical prowess, gain competitive advantage, damage reputation etc.
Whatever it may be, under each of these similarities and even more like these- there is one common theme- Investigation or in other words Detective Testing . Have you ever seen a Detective TV serial or a movie ? The way Detective goes about doing his or her job is by gathering the facts, gaining access to the Clues, finding the ways to establish the complex correlation between different events, form some hit and trial stories to solve the mystery and finally nailing the culprit.
The nature of testing that Google exhibited is nothing less than Detective Testing. Once they had a sniff of something fishy in Bing (Gaining access to the Clues), They formed a team of Detectives (20 Testers), Gave them laptop with IE8 installed with Bing toolbar, Created dummy test data, checked the results in the Bing (finding the ways to establish the complex correlation between different events), Tried more data (form some hit and trial stories) and then finally arrived at a conclusion.
This is an interesting correlation. Probably is true for situations when we test fully aware of what the end result we want to achieve. Suspicion may be thought of as a negative emotion in many a situations but when it comes to Testing such situations, it may prove to be a boon.
What’s your take on Testing based on Suspicion?
To give a brief background of this, am quoting the above blog-
It all started with tarsorrhaphy. Really. As it happens, tarsorrhaphy is a rare surgical procedure on eyelids. And in the summer of 2010, we were looking at the search results for an unusual misspelled query [torsorophy]. Google returned the correct spelling—tarsorrhaphy—along with results for the corrected query. At that time, Bing had no results for the misspelling. Later in the summer, Bing started returning our first result to their users without offering the spell correction (see screenshots below).
Once Google got a Sniff (Suspicion) of this, they started detailed investigation into this and even inserted some sort of Pseudo-results while Searching using some unusual parameters and to their surprise they found Bing results to be exactly the same. Now, that’s something! There are several thoughts and terms that comes to mind when talking about Investigation of this magnitude and its relation with Software Testing.
Is it similar to Competitor Analysis ?
In a typical Software Product Testing setup, when one organization is competing with other- Testing serves many additional purposes and one of which is Competitor Analysis. In this Analysis, a tester tests the product vis-à-vis the features in the Competitor’s products with a primary intent to figure out what we lack and what we are good at. For example- Comparing the how long it takes to access and use a certain feature (Performance Test) with Competitor product is a common practice. The data that we get after such analysis is very useful for the Product Management and even the Sales teams to help prove a point to the Customers.
Is it similar to Patent Infringement Test ?
Its well-known that Organizations reaps great rewards on the Employees who help Organization develop a Technology or an Innovation that could be Patented. One of the lesser known facts is that the same Organizations reaps even greater rewards if their Employees can help and find that their Patents or Patented Technology is being used by a Competitor. This is something that can help Organizations prove Patent Infringements, which not only gets hefty sums in winning Lawsuits but also help to pull down a reputation of customers. The Tests done to prove Patent Infringements require In-depth skills and Technical Orientation and it is usual that these are found accidently than in an Structured manner.
Is it similar to Hacking ?
Hacking may be an extreme term to describe Google-Microsoft Saga but the underlying principles of hacking remains the same i.e. You start Investigating with an Intention to prove something- it may be your Technical prowess, gain competitive advantage, damage reputation etc.
Whatever it may be, under each of these similarities and even more like these- there is one common theme- Investigation or in other words Detective Testing . Have you ever seen a Detective TV serial or a movie ? The way Detective goes about doing his or her job is by gathering the facts, gaining access to the Clues, finding the ways to establish the complex correlation between different events, form some hit and trial stories to solve the mystery and finally nailing the culprit.
The nature of testing that Google exhibited is nothing less than Detective Testing. Once they had a sniff of something fishy in Bing (Gaining access to the Clues), They formed a team of Detectives (20 Testers), Gave them laptop with IE8 installed with Bing toolbar, Created dummy test data, checked the results in the Bing (finding the ways to establish the complex correlation between different events), Tried more data (form some hit and trial stories) and then finally arrived at a conclusion.
This is an interesting correlation. Probably is true for situations when we test fully aware of what the end result we want to achieve. Suspicion may be thought of as a negative emotion in many a situations but when it comes to Testing such situations, it may prove to be a boon.
What’s your take on Testing based on Suspicion?
Tuesday, February 1, 2011
Bug debug- A Conference with a difference!
I haven’t blogged in a while and there were quite a few topics doing rounds in my mind. During this creative tussle, I got to attend a conference in Chennai. The conference was Bug-De-Bug , certainly a catchy name. I got to talk on the topic- Emergence of Cloud Computing and Software Testing- A Perspective . I liked quite a few things about this conference-
- This was the first time the organizers the RIA-RUI Society and Chennai Software Testing Group organized a Conference of this magnitude. But what was most impressive was great exhibition of Organization skills by the team. The team work was pretty evident and everything just happened dot on time.
- I think Audience was participative and it was good initiative by the Organizers to reach out to the College Students. As a general trend that i have seen, the Conferences usually have only Industry representation. Having Students from the colleges attend is a good practice that can help to eventually bridge the Practical Education gap that we see when people fresh from college join the organizations. Another good aspect was the students stepping out of their comfort zones and asking questions. Certainly the way forward.
- Conference with a Cause. The Help Chandru campaign gained momentum. Was great to see it being a part of this conference. Wishing Chandru a speedy recovery.
- The topics chosen were relevant and each presented with unique style.
- It was good to see Software Testing Entrepreneurs on the same stage. Vipul Kocher (President, Indian Testing Board), Narayan Raman (CEO, Tyto Software), Praveen Singh (Founder, 99tests), Pradeep Soundararajan (Director, Moolya Testing). I have a feeling that this group is going to grow in positive direction in the time to come and it is a great news for Software Testing profession. We need Risk Takers.
Looking forward to more such conferences!
More on Bug-deBug conference in the BlogoSphere-
http://testingideas.wordpress.com/2011/02/02/bug-debug/
http://passionatetester.wordpress.com/2011/02/01/bug-debug-an-unforgettable-learning-journey/
http://shivakumar-mathivanan.blogspot.com/2011/01/why-testers-should-attend-software.html
http://balajiponnada.wordpress.com/2011/01/31/bug-debug-conference-chennai/
http://ticketnumber.wordpress.com/2011/02/03/bug-de-bug-the-testing-conference/
- This was the first time the organizers the RIA-RUI Society and Chennai Software Testing Group organized a Conference of this magnitude. But what was most impressive was great exhibition of Organization skills by the team. The team work was pretty evident and everything just happened dot on time.
- I think Audience was participative and it was good initiative by the Organizers to reach out to the College Students. As a general trend that i have seen, the Conferences usually have only Industry representation. Having Students from the colleges attend is a good practice that can help to eventually bridge the Practical Education gap that we see when people fresh from college join the organizations. Another good aspect was the students stepping out of their comfort zones and asking questions. Certainly the way forward.
- Conference with a Cause. The Help Chandru campaign gained momentum. Was great to see it being a part of this conference. Wishing Chandru a speedy recovery.
- The topics chosen were relevant and each presented with unique style.
- It was good to see Software Testing Entrepreneurs on the same stage. Vipul Kocher (President, Indian Testing Board), Narayan Raman (CEO, Tyto Software), Praveen Singh (Founder, 99tests), Pradeep Soundararajan (Director, Moolya Testing). I have a feeling that this group is going to grow in positive direction in the time to come and it is a great news for Software Testing profession. We need Risk Takers.
Looking forward to more such conferences!
More on Bug-deBug conference in the BlogoSphere-
http://testingideas.wordpress.com/2011/02/02/bug-debug/
http://passionatetester.wordpress.com/2011/02/01/bug-debug-an-unforgettable-learning-journey/
http://shivakumar-mathivanan.blogspot.com/2011/01/why-testers-should-attend-software.html
http://balajiponnada.wordpress.com/2011/01/31/bug-debug-conference-chennai/
http://ticketnumber.wordpress.com/2011/02/03/bug-de-bug-the-testing-conference/
Subscribe to:
Posts (Atom)
