Wishing all of you a rather delayed Happy New Year! After being offline from my blog for quite some time, here I am- Refreshed and Recharged.
I would like to begin the New Year with a post on a subject that is quite close to my heart. I have been passionate about the science of Graphology (Handwriting Analysis) and hold a professional qualification in the same. Over a period of last few years, I have found out an interesting co-relation or rather a very powerful way in which the science of Graphology helps in the day-to-day life as a Software tester, lead and a manager. I am hereby posting an un-edited version of my article that recently got published in the print and the web version of “TheSmartTechie” magazine in the month of Feb 2008.
Introduction:
“Factual Approach to decision making”- This principle is an integral part of Quality Management System offered by ISO 9001: 2000, any TQM recognition award such as Malcom Baldrige National Quality Award or a Quality initiative like Six Sigma.
It can be concluded from the above principle that effective organizations involve decision making based on analysis of data and information. In above context, the “Factual approach to decision making” principle mostly deals with decisions about products, processes, sales, profits etc. as there are proven statistical techniques that aid decision making in these areas.
An area that is often neglected while considering data driven decision making is the one involving human related decisions.
Every Leader, Manager or Supervisor in Software arena has a responsibility of human resources in addition to the successful launch of product and processes. Further, in Software field, every leadership, Managerial position requires an individual to possess certain capabilities of a Human Resource Manager because people in these positions are involved in important human related decisions such as Selection of right candidate for the job, Ideal team formation, Ideal resource and work Allocation etc. It is often noticed that such decisions are made out of gut feel and intuition without effectively considering the personality traits an individual possesses. This can lead to wrong human related decisions being taken and that eventually affects goals of team, productivity, Return of Investment from a particular team. Thus, there’s always a need of more realistic approach to decision making in human related areas.
Graphology is one such tool that accurately reveals one’s personality traits. Graphology is a scientific method of identifying, evaluating, and understanding a person's personality via the strokes and patterns revealed by a person’s handwriting. Handwriting is a visual representation of one’s thought process. Consider the following situations-
Case study 1- Hiring the right candidate:
As a Manager of the Software group, you intend to hire Engineers with diverse Technical skill sets. As a general Interview process that is followed in most of the organizations, the Technical skills gets evaluated by series of Interviews by experts and practical tests would give fairly accurate insights into candidate’s technical competencies. Every job requires an applicant to posses certain soft skills that ultimately plays an important part in success or failure of an individual in the profession. E.g. a Software Developer, in addition to strong technical skills, would require soft skills such as Analytical, problem solving skills, creative in approach etc. On the other hand, a Software tester might require skills such as Good attention to details, persistence, Organizational ability etc. Importantly for the organization hiring an individual, adequate time should be spent evaluating these skills in the candidate along with the technical skills. The usual way this is done in most of the organization is at the tail-end of the Interview process when an experienced manager or an HR manager asks the questions. The whole method of evaluating the soft skills of an individual sometimes turns out to be more a subjective exercise. How can Graphology help here? With the help of Graphology, one can get to know a lot of personality traits about an individual even without meeting him/her once just by having a look at the handwriting. It would definitely be unfair here to make hiring decisions simply on the basis of candidate’s handwriting but this powerful medium can be used to ask right questions to candidate in the Interview thereby helping to bring out the necessary personality information and making more informed decisions E.g. by means of handwriting one can easily know about the Thinking Patterns of a person. A Software Developer may require Comprehensive Thinking ability for most part of his job whereas a Software Tester involved in manual testing would do well with Cumulative thinking ability. Having this knowledge before-hand, the Interviewer can ask right questions to judge the Thinking patterns in an individual.
Case study 2- Relaying the right feedback:
Feedback sessions or a One-on-One meeting between Employee and Manager is one of the most important conversations that eventually defines the success or failure of Employee-Manager relationship. Of the many traits that Graphology helps one know is an individual’s Sensitiveness to Criticism. The people who are sensitive to criticism do not always take feedback in right way as they become quite defensive during such sessions. Knowing this information in advance through Graphology can help a Manager handle feedback sessions more effectively.
Conveying an employee what he needs to improve upon should obviously be based on the facts but the role of Manager does not end there. It is equally important for the Manager to help the employee improve upon a certain aspect under discussion. Having accurate understanding of employee’s personality traits helps the Manager drive the necessary improvements in an objective and effective manner. This is where Graphology can be of immense help.
Likewise there are innumerable number of situations where knowing the personality traits of a person accurately before-hand can add enormous value. Graphology is indeed a useful tool that helps achieve exactly the same. I am sure by this time you might already have a lot of questions about credibility and working of the science of Graphology. Let me try to address some of these-
How does Graphology work?
Handwriting is instantaneous photograph of your mind. Your nervous system acts as a wire from brain to hand. Your muscles are coordinated in a more or less writing movement. It begins with a thought in your brain, which is transmitted to central nervous system and then to your hand and fingers, the latter of which are only the vehicles that put in writing.
Handwriting is driven by brain and since hands are the natural vehicles to write something, it is called as “Handwriting”.
Does Graphology accurately reveal one’s personality characteristics?
Graphology does not work on intuition or guess work- it is a science. The accuracy of this science in revealing the personality traits depends upon the skill of the practitioner. In my experience, I have found this to be as accurate as 95%. It’s not my claim but the admittance of the people whose handwriting got analyzed.
What kinds of personality traits can be revealed using Graphology?
In general more than hundred individual personality traits can be revealed accurately using Graphology. It becomes much more when one considers precisely the impact one trait has on others.
Handwriting Analysis provides glimpses into subconscious mind, emotional responsiveness, intellect, energy, and traits such as Thinking patterns, Self esteem, ambitions, concentration, attention to details, Ego strength, Diplomacy, Enthusiasm, Fear of success, Fear of failure, Self consciousness and many more.
Is there anything one cannot tell using Handwriting?
Handwriting cannot reveal one age, gender, nationality, religion, whether writer is left-handed or right-handed and Future of an individual.
Graphology has a great potential to become a powerful tool in Managers’ toolbox. It definitely helps in better understanding of people and minimizes, to a large extent, the intuitive approach in dealing with human resources. It’s not something that is too difficult to learn as more than anything else it involves desire, passion and interest.
Welcome to the wonderful world of Graphology!
Disclaimer:
The views in this article are my personal thoughts on the subject and it does not depict these being a practice in my current or previous organization.
Friday, February 15, 2008
Monday, December 24, 2007
Software Testing Certifications- Does the Industry need them?
I have been one of the testers who had got caught up with the Software Certifications trend early in my career and have also managed to "Pass" a few of them. As a general format, these certifications (provided by many private vendors) has its own Body of Knowledge for Software Testing and follow a certain format for evaluating candidates. Some of these certifications have been really popular among the testers as well as some of the big organizations. Some organizations even have these certifications as a part of their "must-have" or "good to have" skills for particular Software Testing jobs. I have even come to know of a few organizations in which one of the criteria for promoting the people to a new role is to successfully pass one or few of these certifications. All these signify the lack of standardization of education on Software testing. With no available benchmark to appropriately judge testers, the authorities providing these certifications have turned this situation to a successful business idea. These certification cost the applicants a few hundred dollars or thousands of Rupees and have thus turned out to be huge money spinners needed to sustain the profits of these organizations. Moreover, all these certifications comes with a certain Expiry date after which the candidate is required to "renew" the same (meaning spend more Dollars).If the applicant wants the additional study guide which incidentally is required to pass the certification exam, then one is required to shell hundreds of dollars again. Shelling money for a cause that helps you gain knowledge is good but over the years what I have found is that the whole process of gaining the Certification is no good than learning the skills required to pass the examination. There is a little one really gains about Software Testing in the whole process. I believe that all the people who have reached a stage in their lives to called as "Software Testing Engineer" would have already "passed" many examinations in the journey of being called the same and are smart enough to understand what is the difference between passing the exam and gaining the knowledge on the subject. In the current context, these are two different things. Being certified doesn’t not mean that one is an expert in the field. Being certified simply means that one has met all the defined criteria set by the Certification authority which incidentally is only passing the exam in most of the cases. The fact -of-the-matter is that there are many people who would struggle to define "Software Testing" or even present their perspective of Software testing even after being Certified. As the one who has worked at the ground level, there are few reasons that I could think of on why there is a mad rush among the people to be certified-
1. People perceive "being Certified" by a certain body as a means of being recognized in the profession.
2. The role models/Seniors in their respective organizations have got certain certifications, so people would want to emulate the role model.
3. Certifications are often seen as the Status Symbols. Some use it as a means to make their Signature more impressive.
4. Most organizations promote these certifications as a part of Continuous education of employees.
5. Managers put it as one of the goals for their subordinates to complete a certain certification in a review year.
6. Some junior testers would want to do the certifications to "improve" their job prospects.
7. Since most of the published jobs in the market today have a mention of some certifications as a required or desired skills, people opt for these.
8. People interested in going out of the country for the job perceive these certifications as important to have.
9. People want to learn something new, something meaningful that they can apply in their jobs.
10. Want to become experts in Software Testing.
These reasons are not cooked by me but are as result of opinion I have formed upon meeting the different people. The percentage of entire population that I have come across who wants to go for certification for the last reason (point#9, 10) is quite less.
Having being Certified myself, I can tell that personally I do have gained some good things from these certifications. Apart from knowledge, the concept of re-certification has helped me plan my career in some ways. Instead of going for exams for recertification I chose to collect the Credit points (honestly!) in different suggested areas. It really helped to broaden my horizons and helped me to take the road less travelled. But of course, one doesn't need to be certified to do such things; it can be a part of one's career planning only.
Further views on Software Testing certifications at- here
1. People perceive "being Certified" by a certain body as a means of being recognized in the profession.
2. The role models/Seniors in their respective organizations have got certain certifications, so people would want to emulate the role model.
3. Certifications are often seen as the Status Symbols. Some use it as a means to make their Signature more impressive.
4. Most organizations promote these certifications as a part of Continuous education of employees.
5. Managers put it as one of the goals for their subordinates to complete a certain certification in a review year.
6. Some junior testers would want to do the certifications to "improve" their job prospects.
7. Since most of the published jobs in the market today have a mention of some certifications as a required or desired skills, people opt for these.
8. People interested in going out of the country for the job perceive these certifications as important to have.
9. People want to learn something new, something meaningful that they can apply in their jobs.
10. Want to become experts in Software Testing.
These reasons are not cooked by me but are as result of opinion I have formed upon meeting the different people. The percentage of entire population that I have come across who wants to go for certification for the last reason (point#9, 10) is quite less.
Having being Certified myself, I can tell that personally I do have gained some good things from these certifications. Apart from knowledge, the concept of re-certification has helped me plan my career in some ways. Instead of going for exams for recertification I chose to collect the Credit points (honestly!) in different suggested areas. It really helped to broaden my horizons and helped me to take the road less travelled. But of course, one doesn't need to be certified to do such things; it can be a part of one's career planning only.
Further views on Software Testing certifications at- here
Saturday, December 1, 2007
A perspective on Lesson# 67 and 75- Bug Advocacy
Yes, I am talking here about the book that must be on every Tester's desk for myriad of reasons. It's "Lessons learnt in Software Testing" by Cem Kaner, James Bach and Bret Pettichord. I have been following this book for a while now and have experienced that this book not only provides valuable Testing lessons by super experienced trio of authors but quite a few lessons in effective book writing.
This book is all about Context driven testing approach and summarizes valuable lessons in different areas. The best way that i have found to enhance learning from this book is to read a particular lesson and then close the book and co-relate the learnt lesson to your experience or context. Here's some of my comments (based on context of my experience)-
Lesson# 67: Report Defects Promptly
Lesson# 75: Do follow-up testing on seemingly minor coding errors
Both these lessons are self-explanatory as the title suggests but a particular thing that i wanted to highlight here is that in some of the situations that i have been-it is typically challenging to get both these lessons going together in a context. Take a look at following experience snippets-
1. In the past, i have been involved in testing a networking product that had a huge dependency on setup and at the same the product had a very short release cycles. In such a product, the testing involved used to be quite setup intensive and understandably it was very time consuming. Every bug found would involve a lot of investigation which would typically take a lot of time (running into hours and sometime a whole day). And since the release cycles were short, everyone expected test team to report bugs as early as possible to give development team ample time to fix it. And to further add to this situation, the development and test teams were located in separate location geographically (separated by almost 12 hours time zone wise).In this situation, following the above lessons(#67 and #75) used to be quite challenging. Some of the challenges include-
a. If a tester is new (i.e. hasn’t yet established a reputation with the developer), then it was imperative for him/her to write complete bug report with all the investigation. If he/she fails to do so, it would result in damaging the equation with developer who sits remotely. This is a typical issue with a "faceless culture" i.e. the organization culture in which you need to team up with people who you haven’t met or seen. In such a culture, a tester would be judged solely on the basis of his work products i.e. Defect report. So a new tester would typically need more time thereby, delaying the defect logging time.
b. Even for an experienced tester in such a situation, it would take more time if he/she comes across a non reproducible kind of a bug which would take a lot more Investigation.
In such situations, we found it to be typically wise to contact developer with all the details. This has a people management challenge as It definitely means the tester work late hours to contact with offshore development team and have a talk and get into agreement to report a bug with available information and continue with further Investigation the next day.
If the development team and testing team work in the same time zone, it becomes easier to collaborate in these situations.
2. There is one more situation in which i have found the follow-up testing to be typically time consuming. This situation occurred during the Internationalization testing of a Client/Server product in 5 languages. As a part of bug information, sometimes the developers would expect the testing team to report results of the bug in all the 5 languages. What this would mean for testing team is to prepare a setup in all the languages under test and reproduce the defect 5 times and report in the bug. Being a client/server product would make preparing such a setup even more time consuming, thereby increasing the bug
logging time. It is always good in these situations (typically Internationalization testing) to get in the agreement with developer during the planning phase to understand the expectations because such a testing is indeed time consuming and would have impact on test schedule.
This book is all about Context driven testing approach and summarizes valuable lessons in different areas. The best way that i have found to enhance learning from this book is to read a particular lesson and then close the book and co-relate the learnt lesson to your experience or context. Here's some of my comments (based on context of my experience)-
Lesson# 67: Report Defects Promptly
Lesson# 75: Do follow-up testing on seemingly minor coding errors
Both these lessons are self-explanatory as the title suggests but a particular thing that i wanted to highlight here is that in some of the situations that i have been-it is typically challenging to get both these lessons going together in a context. Take a look at following experience snippets-
1. In the past, i have been involved in testing a networking product that had a huge dependency on setup and at the same the product had a very short release cycles. In such a product, the testing involved used to be quite setup intensive and understandably it was very time consuming. Every bug found would involve a lot of investigation which would typically take a lot of time (running into hours and sometime a whole day). And since the release cycles were short, everyone expected test team to report bugs as early as possible to give development team ample time to fix it. And to further add to this situation, the development and test teams were located in separate location geographically (separated by almost 12 hours time zone wise).In this situation, following the above lessons(#67 and #75) used to be quite challenging. Some of the challenges include-
a. If a tester is new (i.e. hasn’t yet established a reputation with the developer), then it was imperative for him/her to write complete bug report with all the investigation. If he/she fails to do so, it would result in damaging the equation with developer who sits remotely. This is a typical issue with a "faceless culture" i.e. the organization culture in which you need to team up with people who you haven’t met or seen. In such a culture, a tester would be judged solely on the basis of his work products i.e. Defect report. So a new tester would typically need more time thereby, delaying the defect logging time.
b. Even for an experienced tester in such a situation, it would take more time if he/she comes across a non reproducible kind of a bug which would take a lot more Investigation.
In such situations, we found it to be typically wise to contact developer with all the details. This has a people management challenge as It definitely means the tester work late hours to contact with offshore development team and have a talk and get into agreement to report a bug with available information and continue with further Investigation the next day.
If the development team and testing team work in the same time zone, it becomes easier to collaborate in these situations.
2. There is one more situation in which i have found the follow-up testing to be typically time consuming. This situation occurred during the Internationalization testing of a Client/Server product in 5 languages. As a part of bug information, sometimes the developers would expect the testing team to report results of the bug in all the 5 languages. What this would mean for testing team is to prepare a setup in all the languages under test and reproduce the defect 5 times and report in the bug. Being a client/server product would make preparing such a setup even more time consuming, thereby increasing the bug
logging time. It is always good in these situations (typically Internationalization testing) to get in the agreement with developer during the planning phase to understand the expectations because such a testing is indeed time consuming and would have impact on test schedule.
Friday, November 30, 2007
Using Time boxes to boost testing efforts
Wikipedia defines "Time Box" as following-
a timebox is a period of time in which to accomplish some task. The end date is set in stone and may not be changed. If the team exceeds the date, the work is considered a failure and is cancelled or rescheduled.
Using Time box is not a tough proposition. It is an easy to understand technique and its implementation is not tough either but it definitely involves Self discipline and commitment.
The concept of Time box can be described as follows-
Considering the general approach of accomplishing tasks, we take something to accomplish and put all our energies to complete the task.
With time box approach, with little thinking- the whole task is divided into manageable parts and some time is devoted to accomplish each part. So at a given time, we are focusing only on a smaller part and hence it helps to accomplish the same with more efficiency. This technique helps us track the progress and is an able tool to accomplish things. This technique can be used effectively in smaller tasks as well. As a rule, the Focus has to be maintained on the task at hand without worrying about what task was done before the current time box and what task has to be done after the current time box. In reality, the
thinking is "boxed" with the task at hand. This Technique has a striking similarity to Dale Carnegie's concept of "Living in Day Tight Compartments" theory for eliminating worry in our lives.
Almost all of us have to deal with the tasks that we don't really like to do but we have to do it because of our commitments. Such tasks can be termed as "Unpleasant tasks". All of us invariably spend some time during the day to accomplish Unpleasant tasks and people generally tend to delay unpleasant tasks or do it with a degraded efficiency. The concept of Time box can help master the unpleasant tasks by assigning them an appropriate Time box. Such tasks can have smaller time frame than usual time boxes to achieve more effectiveness.
J.D. Meier defines simple steps to gain maximum out of Time boxing technique here-
http://blogs.msdn.com/jmeier/archive/2007/10/21/how-to-use-time-boxing-for-getting-results.aspx
Summary of prescribed steps-
Step 1. Identify candidate areas for time boxing.
Step 2. Identify your objectives.
Step 3. Identify the appropriate time box.
Step 4. Execute results within your time box.
Step 5. Evaluate and adapt.
Regarding Step 4, it is always advisable to stick to the assigned Time box at all costs. In the beginning, it might look like a difficult thing to achieve but over a period of time you will get a fair idea. That is where Step 5 becomes important (where you do the evaluation)
Time boxes' application in Software Testing:
1. One of the true applications of Time Box technique has been explored by Jonathan Bach as mentioned in the article- Session-Based Test Management where the methodology is to perform Exploratory testing in time-bound, goal oriented sessions. Read the document to gain knowledge on how the Test based sessions work.
I have myself applied this concept ("session" or "Time boxes") and it proved to be quite an effective way to do a focused testing. If done without planned time bounds, the Exploratory testing does tend to get unfocussed and very ineffective as well. Personally, it helped me ensure that Testing efforts remain focuses, provide the means to measure the effort spent and in understanding what was tested and what was left.
2. There are times in professional lives when we get assigned with the tasks without stipulated timelines to complete the same. I have found in my experience that usually these are the tasks which one tends to get complacent with and get indulged in tendency to delay. Some examples of such tasks that come to my mind are- The tasks related to not-so-urgent process improvement such as defining better Test case creation methodology, preparing Training presentation for new testers joining 2 months later etc. Applying Time boxes in this situation can help to do these tasks in a better way without an unreasonable delay.
3. During a typical day, a tester is involved in numerous activities. Consider a typical Test case execution phase, a tester might be involved in editing the test case, executing the test cases, Investigating the issues, logging issues in Bug tracking system, clarifying issues with Development team, Read emails, write emails, responding to queries asked by Manager, doing other organizational paper work etc. As it can be seen there is a lot of activities that a tester is involved in which could distract him/her from the primary job at a given time. The application of Time boxes in this scenario will help ensure that a tester is focusing the energies completely on testing at a given time and not on other activities given that it is a Test Execution phase. In this case, it is advisable for the tester to plan and divide his entire day into different time boxes and stick to the assigned time.
4. A Tester can use this technique even when doing the testing using test cases. It is easier for a experienced tester to define the accurate time boxes as he/she would usually know the time. Tester can divide the whole day in time boxes for Test case execution. This would help a tester produce results with good efficiency.
Keep testing effectively with Time boxes!
Further reading:
http://www.davecheong.com/2006/07/26/time-boxing-is-an-effective-getting-things-done-strategy/
a timebox is a period of time in which to accomplish some task. The end date is set in stone and may not be changed. If the team exceeds the date, the work is considered a failure and is cancelled or rescheduled.
Using Time box is not a tough proposition. It is an easy to understand technique and its implementation is not tough either but it definitely involves Self discipline and commitment.
The concept of Time box can be described as follows-
Considering the general approach of accomplishing tasks, we take something to accomplish and put all our energies to complete the task.
With time box approach, with little thinking- the whole task is divided into manageable parts and some time is devoted to accomplish each part. So at a given time, we are focusing only on a smaller part and hence it helps to accomplish the same with more efficiency. This technique helps us track the progress and is an able tool to accomplish things. This technique can be used effectively in smaller tasks as well. As a rule, the Focus has to be maintained on the task at hand without worrying about what task was done before the current time box and what task has to be done after the current time box. In reality, the
thinking is "boxed" with the task at hand. This Technique has a striking similarity to Dale Carnegie's concept of "Living in Day Tight Compartments" theory for eliminating worry in our lives.
Almost all of us have to deal with the tasks that we don't really like to do but we have to do it because of our commitments. Such tasks can be termed as "Unpleasant tasks". All of us invariably spend some time during the day to accomplish Unpleasant tasks and people generally tend to delay unpleasant tasks or do it with a degraded efficiency. The concept of Time box can help master the unpleasant tasks by assigning them an appropriate Time box. Such tasks can have smaller time frame than usual time boxes to achieve more effectiveness.
J.D. Meier defines simple steps to gain maximum out of Time boxing technique here-
http://blogs.msdn.com/jmeier/archive/2007/10/21/how-to-use-time-boxing-for-getting-results.aspx
Summary of prescribed steps-
Step 1. Identify candidate areas for time boxing.
Step 2. Identify your objectives.
Step 3. Identify the appropriate time box.
Step 4. Execute results within your time box.
Step 5. Evaluate and adapt.
Regarding Step 4, it is always advisable to stick to the assigned Time box at all costs. In the beginning, it might look like a difficult thing to achieve but over a period of time you will get a fair idea. That is where Step 5 becomes important (where you do the evaluation)
Time boxes' application in Software Testing:
1. One of the true applications of Time Box technique has been explored by Jonathan Bach as mentioned in the article- Session-Based Test Management where the methodology is to perform Exploratory testing in time-bound, goal oriented sessions. Read the document to gain knowledge on how the Test based sessions work.
I have myself applied this concept ("session" or "Time boxes") and it proved to be quite an effective way to do a focused testing. If done without planned time bounds, the Exploratory testing does tend to get unfocussed and very ineffective as well. Personally, it helped me ensure that Testing efforts remain focuses, provide the means to measure the effort spent and in understanding what was tested and what was left.
2. There are times in professional lives when we get assigned with the tasks without stipulated timelines to complete the same. I have found in my experience that usually these are the tasks which one tends to get complacent with and get indulged in tendency to delay. Some examples of such tasks that come to my mind are- The tasks related to not-so-urgent process improvement such as defining better Test case creation methodology, preparing Training presentation for new testers joining 2 months later etc. Applying Time boxes in this situation can help to do these tasks in a better way without an unreasonable delay.
3. During a typical day, a tester is involved in numerous activities. Consider a typical Test case execution phase, a tester might be involved in editing the test case, executing the test cases, Investigating the issues, logging issues in Bug tracking system, clarifying issues with Development team, Read emails, write emails, responding to queries asked by Manager, doing other organizational paper work etc. As it can be seen there is a lot of activities that a tester is involved in which could distract him/her from the primary job at a given time. The application of Time boxes in this scenario will help ensure that a tester is focusing the energies completely on testing at a given time and not on other activities given that it is a Test Execution phase. In this case, it is advisable for the tester to plan and divide his entire day into different time boxes and stick to the assigned time.
4. A Tester can use this technique even when doing the testing using test cases. It is easier for a experienced tester to define the accurate time boxes as he/she would usually know the time. Tester can divide the whole day in time boxes for Test case execution. This would help a tester produce results with good efficiency.
Keep testing effectively with Time boxes!
Further reading:
http://www.davecheong.com/2006/07/26/time-boxing-is-an-effective-getting-things-done-strategy/
Wednesday, November 28, 2007
Ensuring Up-to-date Device Drivers for your Test Environment
One of the key requirements in most of the Software Testing endeavors is to ensure that the Test Environment is up-to-date. The term- "Test Environment" can include- Application servers, Web servers, databases, client machines etc. It is always a challenge for the Testing team to keep the environment up-to-date considering there are a lot of external dependencies that a Test environment has such as Operating System service packs, Operating System patches, Application service packs, Latest device drivers etc.
I recently came across a website which i found to be useful in ensuring that a part of Test environment is up-to-date. The website URL is-
http://driveragent.com/
This website has a free scan facility which helps to judge whether the various device drivers are up-to-date on the test machine.
It enables to check the device drivers for Hardware such as-
Audio, Chipset, Joysticks, Network, Scanners, Cameras, Drives, Modems, Bluetooth, USB, CD-ROM, DVD, Mouse, Printers, Video and checks for many popular vendors.
At a given time the application under test may be interacting with any of these hardware. Unless you are doing a specific testing, most often the requirement will be to ensure that the devices installed on the machine has the latest drivers.
This is what the Free scan facility in this website helps you achieve.
It will tell you neatly which of the device drivers are up-to-date and which ones have the latest updates available and provides the ready link to download the same.
Quite an useful utility for ensuring up-to-date Test environment.
I recently came across a website which i found to be useful in ensuring that a part of Test environment is up-to-date. The website URL is-
http://driveragent.com/
This website has a free scan facility which helps to judge whether the various device drivers are up-to-date on the test machine.
It enables to check the device drivers for Hardware such as-
Audio, Chipset, Joysticks, Network, Scanners, Cameras, Drives, Modems, Bluetooth, USB, CD-ROM, DVD, Mouse, Printers, Video and checks for many popular vendors.
At a given time the application under test may be interacting with any of these hardware. Unless you are doing a specific testing, most often the requirement will be to ensure that the devices installed on the machine has the latest drivers.
This is what the Free scan facility in this website helps you achieve.
It will tell you neatly which of the device drivers are up-to-date and which ones have the latest updates available and provides the ready link to download the same.
Quite an useful utility for ensuring up-to-date Test environment.
Thursday, November 15, 2007
Conveying the "bad" news...
This came up from an interesting discussion I was having with the colleague of mine. The situation is something like this- A Software Testing team is working in a high pressure release of a product in which a lot is at stake, so much so that most of organization's revenue depends upon its successful launch. In obvious terms, this is a very high visibility release in which all the stake holders are keeping an eye on daily progress. From testing perspective, everything seems to be going on track i.e. Test coverage is growing steadily, bugs reported are being logged timey with precise information, Bugs are being
fixed and regressed on time, the defect trends are under control and all this is giving huge confidence to the project stakeholders. The project reaches Release candidate phase riding on this confidence. The release is just a few days later and when all is looking so well and on the doorsteps of an immensely successful release with accolades awaiting everyone in the project.....BANG, BANG, BANG!!! Testing group comes across two new bugs and initial (rather tensed!) analysis by testing team reveals that these bugs "looks" to be showstoppers. Such situations are a common place in most of the projects. And these kind of situations are generally very stressful and a thought on "How to convey the bad news" often crosses a tester's mind. It turns out often that who/how to bell the cat.
Conveying the right information/status about the project to its stakeholders is one of the primary tasks of the testing group. So, every now and then, the tester would be in a situation where he/she would need to convey so considered "bad" news about the happenings in the project. Now, the question in mind is- how to deal with such situation? I have a few thoughts around this based on what I have observed in my experience-
1. Don't Panic...
The first reaction to such a reaction is usually that of Panic. But being in panic won’t get you anywhere and can worsen the situation. So, Don't Panic.
2. Don't blame yourself...
Another thing that might not help you think clearly in this situation is the feeling of guilt. Basically the feeling which says- I am the owner of testing the module under question and it was supposed to be perfect and bug free. Well, displaying ownership towards the task at hand is definitely one of striking qualities of a tester but it doesn’t mean that one ends up taking all the blame on self if something goes wrong (even without analyzing the situation). So, don’t blame yourself and understand that "any" tester can be in a situation that you are in. If at all it turns out to be your fault later, learn from it and emerge as a better tester.
3. Don't be defensive...
Other situation can be when the tester chooses to report the issue to his/her superior and immediately becomes defensive and starts putting in points in favor of his/her's argument even without being asked. The phrases like- "You know we never had specifications", "I don’t think it was even considered by a person who wrote the test cases", "I think i tested this in the last build and it worked, Must be that developers have made some late change" etc. take prominence. Being defensive means that a tester is trying to just save him/her and is not even thinking about the project. This is a situation which tells a great deal about the ownership potential of a tester. By getting into a defensive argument he/she is just trying to get away with the situation leaving an impression of immaturity.
4. Be ethical...
Conveying the bad news about the project status definitely needs a lot of courage. Those who are less courageous may even be tempted to cover the situation and do not even report the failure. Such an action is self-destructive and against the professional ethics. A tester is not doing his/her job if he/she is not choosing to report the issue. Do not fall into this trap, it may cause you to feel guiltier when the issue is reported by the customer.
5. Anticipate and Analyze...
Thinking with a clear mind, the next step is to anticipate what questions the project stakeholders might be asking you once they hear about the newly found issues. Usually, you might be asked the questions such as-
- Is this an failure that is reproducible all the times?
- Are the steps followed constitute the basic use case that a customer would be following?
- Is the Software failure severe that you user is not able to access other features?
- Was the failure prevalent in the previous builds that we tested? If yes, since when?
- Is the failure because of a recent code change?
- Is the failure dependent on a specific OS and the environment?
- Does the failure exist on all the supported languages?
Etc.
The key is to think about all the possible questions. You will notice that in most of the cases, the questions asked in this situation would aim at finding the impact the failure has on the release and not necessarily at finding the scapegoat. But it helps a lot to be prepared with answers to the questions such as-
- Why didn’t testing group find the issue earlier?
- Are there any flaws in testing process?
- Is this a human error by the tester?
Etc.
Once you have anticipated all the questions, the next step is to analyze the situation and dig into details to find more information about each question taking into consideration the bug under question. The Analysis should not be biased anytime thinking that testing group is not at fault. Remember, the primary goal of this exercise to provide project stakeholders with all the relevant facts.
6. Report the facts
Once the thorough analysis is done, the next step is to report the findings. A good report is the one that answers all the queries the recipient might have and at the same time the presented information is not too detailed that it takes a long time for a person to comprehend. One of the suggestions of the report format could be in a question-answer format in which answers to all the anticipated questions are presented either in an email or in a meeting/call with the stake holders.
7. Answering the questions not anticipated earlier
A good sense of anticipation comes from experience. It might as well be the case that there are some questions that were not anticipated earlier and these might take you by surprise. This situation can be very tricky to handle as these questions might get asked in a meeting constituting of various Senior Management personnel and other key stake holders. Some of these questions would be aimed at gaining more information about the failure and some "hard to answer" might question your ability.
The key is to be honest, have the facts in place and answer with tact. This is where Effective communication skills play a key role. There will be situations where it would be most apt to agree that it was the mistake by test team and make sure to follow-up with plans to avoid such instances in future depending upon the tone of the meeting.
8. Post meeting thoughts
Most of the times, everyone's priority is to get rid of this situation and make the release happen on time. If such is the case, then ensure to take the valuable learning post meeting and start thinking about how best to not be in such situations in future.
Sometimes, there can be the case that some of the stakeholders lose patience and give you a tough talk (read- shout at you). Well, if you are convinced that it’s an issue at your end, then it makes sense to accept the mistake and assure the stakeholder of the necessary steps that would be taken to improve the process. And if it’s not your fault, then presenting the facts and your conclusion politely often helps. It gets even trickier if you are on a telephonic call with a superior whom you haven’t seen or met in person. Maintaining calm and presenting facts in a right way helps you through successfully in such a situation.
Please share if you have been in such a situation and how you handled the same.
fixed and regressed on time, the defect trends are under control and all this is giving huge confidence to the project stakeholders. The project reaches Release candidate phase riding on this confidence. The release is just a few days later and when all is looking so well and on the doorsteps of an immensely successful release with accolades awaiting everyone in the project.....BANG, BANG, BANG!!! Testing group comes across two new bugs and initial (rather tensed!) analysis by testing team reveals that these bugs "looks" to be showstoppers. Such situations are a common place in most of the projects. And these kind of situations are generally very stressful and a thought on "How to convey the bad news" often crosses a tester's mind. It turns out often that who/how to bell the cat.
Conveying the right information/status about the project to its stakeholders is one of the primary tasks of the testing group. So, every now and then, the tester would be in a situation where he/she would need to convey so considered "bad" news about the happenings in the project. Now, the question in mind is- how to deal with such situation? I have a few thoughts around this based on what I have observed in my experience-
1. Don't Panic...
The first reaction to such a reaction is usually that of Panic. But being in panic won’t get you anywhere and can worsen the situation. So, Don't Panic.
2. Don't blame yourself...
Another thing that might not help you think clearly in this situation is the feeling of guilt. Basically the feeling which says- I am the owner of testing the module under question and it was supposed to be perfect and bug free. Well, displaying ownership towards the task at hand is definitely one of striking qualities of a tester but it doesn’t mean that one ends up taking all the blame on self if something goes wrong (even without analyzing the situation). So, don’t blame yourself and understand that "any" tester can be in a situation that you are in. If at all it turns out to be your fault later, learn from it and emerge as a better tester.
3. Don't be defensive...
Other situation can be when the tester chooses to report the issue to his/her superior and immediately becomes defensive and starts putting in points in favor of his/her's argument even without being asked. The phrases like- "You know we never had specifications", "I don’t think it was even considered by a person who wrote the test cases", "I think i tested this in the last build and it worked, Must be that developers have made some late change" etc. take prominence. Being defensive means that a tester is trying to just save him/her and is not even thinking about the project. This is a situation which tells a great deal about the ownership potential of a tester. By getting into a defensive argument he/she is just trying to get away with the situation leaving an impression of immaturity.
4. Be ethical...
Conveying the bad news about the project status definitely needs a lot of courage. Those who are less courageous may even be tempted to cover the situation and do not even report the failure. Such an action is self-destructive and against the professional ethics. A tester is not doing his/her job if he/she is not choosing to report the issue. Do not fall into this trap, it may cause you to feel guiltier when the issue is reported by the customer.
5. Anticipate and Analyze...
Thinking with a clear mind, the next step is to anticipate what questions the project stakeholders might be asking you once they hear about the newly found issues. Usually, you might be asked the questions such as-
- Is this an failure that is reproducible all the times?
- Are the steps followed constitute the basic use case that a customer would be following?
- Is the Software failure severe that you user is not able to access other features?
- Was the failure prevalent in the previous builds that we tested? If yes, since when?
- Is the failure because of a recent code change?
- Is the failure dependent on a specific OS and the environment?
- Does the failure exist on all the supported languages?
Etc.
The key is to think about all the possible questions. You will notice that in most of the cases, the questions asked in this situation would aim at finding the impact the failure has on the release and not necessarily at finding the scapegoat. But it helps a lot to be prepared with answers to the questions such as-
- Why didn’t testing group find the issue earlier?
- Are there any flaws in testing process?
- Is this a human error by the tester?
Etc.
Once you have anticipated all the questions, the next step is to analyze the situation and dig into details to find more information about each question taking into consideration the bug under question. The Analysis should not be biased anytime thinking that testing group is not at fault. Remember, the primary goal of this exercise to provide project stakeholders with all the relevant facts.
6. Report the facts
Once the thorough analysis is done, the next step is to report the findings. A good report is the one that answers all the queries the recipient might have and at the same time the presented information is not too detailed that it takes a long time for a person to comprehend. One of the suggestions of the report format could be in a question-answer format in which answers to all the anticipated questions are presented either in an email or in a meeting/call with the stake holders.
7. Answering the questions not anticipated earlier
A good sense of anticipation comes from experience. It might as well be the case that there are some questions that were not anticipated earlier and these might take you by surprise. This situation can be very tricky to handle as these questions might get asked in a meeting constituting of various Senior Management personnel and other key stake holders. Some of these questions would be aimed at gaining more information about the failure and some "hard to answer" might question your ability.
The key is to be honest, have the facts in place and answer with tact. This is where Effective communication skills play a key role. There will be situations where it would be most apt to agree that it was the mistake by test team and make sure to follow-up with plans to avoid such instances in future depending upon the tone of the meeting.
8. Post meeting thoughts
Most of the times, everyone's priority is to get rid of this situation and make the release happen on time. If such is the case, then ensure to take the valuable learning post meeting and start thinking about how best to not be in such situations in future.
Sometimes, there can be the case that some of the stakeholders lose patience and give you a tough talk (read- shout at you). Well, if you are convinced that it’s an issue at your end, then it makes sense to accept the mistake and assure the stakeholder of the necessary steps that would be taken to improve the process. And if it’s not your fault, then presenting the facts and your conclusion politely often helps. It gets even trickier if you are on a telephonic call with a superior whom you haven’t seen or met in person. Maintaining calm and presenting facts in a right way helps you through successfully in such a situation.
Please share if you have been in such a situation and how you handled the same.
Wednesday, November 7, 2007
High self esteem- An essential skill for a valuable tester
In one of my Previous posts , I talked about the Soft skills and their impact on Software testing in the current context. In this post I would like to further touch upon a specific soft skill that’s at the heart of all other soft skills. It’s the tester’s Self Esteem.
What is self-esteem?
Self-esteem is the total value one gives to self. The National Association for Self-Esteem defines self-esteem as "The experience of being capable of meeting life's challenges and being worthy of happiness." Self esteem is an experience. It is a particular way of experiencing the self. It is one of the most important ingredients’ of success in one’s professional and personal lives. Self-esteem is a soft skill that has a maximum bearing on other Soft skills a person possesses. High self-esteem is the most desirable personality trait an individual can have. When a person feels good about self, he feels that anything is possible and goals can be achieved. Having such confidence is first step towards achieving anything substantial.
Self-esteem and Software Testers- A correlation
A Person’s self-esteem has an influence in each and every aspect of person’s life including professional and personal lives. Software testing profession is no different in this regard. There is an enormous correlation between Self-esteem and Software testing and this can be well understood if we consider various characteristics of people with low self-esteem and high self-esteem.
Testers with low self esteem….
People with low self-esteem have a fear of failure. They do fear failure and the changes that failure could bring. Such people imagine failure. This situation is not desirable for Software testers. Imagine a Software tester showing hesitation to take up new project or a kind of technology he/she is not too sure about because he/she is not sure whether taking up something new would be a success. Learning capabilities of a tester comes into picture only if he/she has a desire to indulge into something new. In my observation, such behavior is quite common among testers when they fail to recognize the opportunity to work on the right project just because they feel they might fail in their attempt or even if they do take up the project, they take it half-heartedly. They just let the opportunities go anticipating the failures.
People with low self-esteem tend not to take many risks. They do possess rather passive approach towards life. Like every other profession, person’s successes in Software Testing field too depend upon the risk taking abilities to a certain extent. Software testers’ grow in their professions when in addition to doing their current role to perfection, they initiate to think beyond their currently assigned roles and execute the additional responsibilities. Successful testers would always tend to take the path which is less traveled and do all that’s needed to be a success. Such kind of thinking itself involves courage to take risks. A tester with low self-esteem lacks such courage.
Having a goalless life or no high goals in life is one of the typical characteristic of people with low self-esteem. Such people have short-sightedness as far as their goals are concerned. Software testers are also highly effective in their careers and for their organizations if they have well-defined goals for themselves and for their profession. Having high goals in right direction definitely leads to innovativeness which is the need-of-the-hour for the Software testing profession and gives tester a necessary sense of direction.
Whenever a person with low self-esteem thinks of self, he tends to think about imperfections. As a result, these people tend to blame others for not achieving something. Things such as- “I am not able to find more bugs because Development team is not writing documentation” or “My boss prefers the fellow tester more, why should I push myself so hard ?” etc. This kind of attitude is definitely not positive and such attitude stops self-development. Most often, Software testing is a team activity. Having people blame each other for small things definitely does not lead to a desirable team environment and can affect the overall results. Such people have a hard time getting to terms with the fact that their colleague can be better than them. Definitely this is not an attitude that promotes team work.
People with low self-esteem constantly doubt their capabilities. As a result, they tend not to take initiatives even when they could easily have. Such people are hugely dependent on other’s approval. They exhibit low self confidence and resist change. Such a situation is counter-productive from the point of view of Software testing profession as tester has to deal with lot of changes e.g. Changes in requirements, projects, role etc. Such people have tendency to criticize every change because a change gets them out of their so called- “comfort zone”. Lack of confidence can have huge impact on tester’s credentials as the testers have to exhibit certain confidence to test the software to report the status effectively and to maintain the rapport with development team.
Testers with high self esteem….
On the other hand, the testers with high self-esteem-
- Have more faith in their abilities. This helps tester take more initiatives because such people are not dependent on other’s approval to try something new and worthwhile.
- Are more confident and such confidence shows up while testing, communicating and certainly the other aspects of the work.
- Have high goals and have tremendous clarity of goals. Also have a great ability to take risks to achieve their high well-planned goals towards self-development and advancement of Software testing profession.
- Have good self image leading to high personal expectations and have lesser self-doubt. Such people have a greater sense of purpose.
It is evident that testers with high self-esteem are definitely assets to Software testing profession. Low self esteem is often the root cause of other unpleasant and undesirable personality traits the tester may possess. Testers should take all the efforts to build high self-esteem and also work towards maintaining it for a life time.
Means to enhance self esteem among testers-
A tester owns a complete responsibility of the state of his/her self-esteem. He/She should take adequate measures to enhance the self-esteem at all times. Having said this, the leadership/Management also has an important role to play in this regard. Lets consider the some ways to enhance the self-esteem-
Knowledge enhancement
Software testing is a knowledge based industry. Often, knowledge on a certain aspect is a distinguishing factor between testers. A tester should not only always look to enhance knowledge by all means possible but also ensure the application of knowledge at the work-place. Successful implementation of such initiatives surely enhances self-esteem.
Encouragement for having higher goals
A Tester should always work to seek clarity of goals and should aim from something significant. Having clarity of goals reduces the distractions and prepares tester to achieve something significant for self and for the profession. The process of achieving such goals itself enhances self-esteem. Spending whole days without a set direction and meaningful goals often makes you feel bad about self at the end of the day.
Timely Appreciation
Having a proper recognition system in place for testers help enhance the self-esteem. There are various ways tester’s efforts can be recognized such as recognizing the efforts in various aspects of work such test case creation, testing, finding bugs etc. People in the leadership positions have important roles to play to make such programs successful and to ensure the testers are genuinely and timely appreciated for their efforts.
Think beyond current roles
Testers should always be encouraged not to fall in the rut of daily routine and think beyond their currently assigned roles. Of-course, this can be done effectively only when the testers are able to do their current roles to perfection. Thinking out-of-box and achieving noteworthy improvements to current way of doing things certainly enhances self-image.
Conquer fears
Having knowledge of self limitations and working towards getting rid of those limitations is a primary step towards self-development. Testers should always work to know their fears and then work towards eliminating them e.g. a tester may have fear to deliver a presentation to the group, or fear of change etc. Conquering fears by adopting step-by-step approach helps one feel good about self.
There can be many such ways to enhance self-esteem which a tester can think and implement. Getting rid of the traces of low self-esteem in your personality takes you closer to achieving success. Having awareness of your self-esteem and then subsequently working to enhance the same is first step towards achieving greater things for the profession.
What is self-esteem?
Self-esteem is the total value one gives to self. The National Association for Self-Esteem defines self-esteem as "The experience of being capable of meeting life's challenges and being worthy of happiness." Self esteem is an experience. It is a particular way of experiencing the self. It is one of the most important ingredients’ of success in one’s professional and personal lives. Self-esteem is a soft skill that has a maximum bearing on other Soft skills a person possesses. High self-esteem is the most desirable personality trait an individual can have. When a person feels good about self, he feels that anything is possible and goals can be achieved. Having such confidence is first step towards achieving anything substantial.
Self-esteem and Software Testers- A correlation
A Person’s self-esteem has an influence in each and every aspect of person’s life including professional and personal lives. Software testing profession is no different in this regard. There is an enormous correlation between Self-esteem and Software testing and this can be well understood if we consider various characteristics of people with low self-esteem and high self-esteem.
Testers with low self esteem….
People with low self-esteem have a fear of failure. They do fear failure and the changes that failure could bring. Such people imagine failure. This situation is not desirable for Software testers. Imagine a Software tester showing hesitation to take up new project or a kind of technology he/she is not too sure about because he/she is not sure whether taking up something new would be a success. Learning capabilities of a tester comes into picture only if he/she has a desire to indulge into something new. In my observation, such behavior is quite common among testers when they fail to recognize the opportunity to work on the right project just because they feel they might fail in their attempt or even if they do take up the project, they take it half-heartedly. They just let the opportunities go anticipating the failures.
People with low self-esteem tend not to take many risks. They do possess rather passive approach towards life. Like every other profession, person’s successes in Software Testing field too depend upon the risk taking abilities to a certain extent. Software testers’ grow in their professions when in addition to doing their current role to perfection, they initiate to think beyond their currently assigned roles and execute the additional responsibilities. Successful testers would always tend to take the path which is less traveled and do all that’s needed to be a success. Such kind of thinking itself involves courage to take risks. A tester with low self-esteem lacks such courage.
Having a goalless life or no high goals in life is one of the typical characteristic of people with low self-esteem. Such people have short-sightedness as far as their goals are concerned. Software testers are also highly effective in their careers and for their organizations if they have well-defined goals for themselves and for their profession. Having high goals in right direction definitely leads to innovativeness which is the need-of-the-hour for the Software testing profession and gives tester a necessary sense of direction.
Whenever a person with low self-esteem thinks of self, he tends to think about imperfections. As a result, these people tend to blame others for not achieving something. Things such as- “I am not able to find more bugs because Development team is not writing documentation” or “My boss prefers the fellow tester more, why should I push myself so hard ?” etc. This kind of attitude is definitely not positive and such attitude stops self-development. Most often, Software testing is a team activity. Having people blame each other for small things definitely does not lead to a desirable team environment and can affect the overall results. Such people have a hard time getting to terms with the fact that their colleague can be better than them. Definitely this is not an attitude that promotes team work.
People with low self-esteem constantly doubt their capabilities. As a result, they tend not to take initiatives even when they could easily have. Such people are hugely dependent on other’s approval. They exhibit low self confidence and resist change. Such a situation is counter-productive from the point of view of Software testing profession as tester has to deal with lot of changes e.g. Changes in requirements, projects, role etc. Such people have tendency to criticize every change because a change gets them out of their so called- “comfort zone”. Lack of confidence can have huge impact on tester’s credentials as the testers have to exhibit certain confidence to test the software to report the status effectively and to maintain the rapport with development team.
Testers with high self esteem….
On the other hand, the testers with high self-esteem-
- Have more faith in their abilities. This helps tester take more initiatives because such people are not dependent on other’s approval to try something new and worthwhile.
- Are more confident and such confidence shows up while testing, communicating and certainly the other aspects of the work.
- Have high goals and have tremendous clarity of goals. Also have a great ability to take risks to achieve their high well-planned goals towards self-development and advancement of Software testing profession.
- Have good self image leading to high personal expectations and have lesser self-doubt. Such people have a greater sense of purpose.
It is evident that testers with high self-esteem are definitely assets to Software testing profession. Low self esteem is often the root cause of other unpleasant and undesirable personality traits the tester may possess. Testers should take all the efforts to build high self-esteem and also work towards maintaining it for a life time.
Means to enhance self esteem among testers-
A tester owns a complete responsibility of the state of his/her self-esteem. He/She should take adequate measures to enhance the self-esteem at all times. Having said this, the leadership/Management also has an important role to play in this regard. Lets consider the some ways to enhance the self-esteem-
Knowledge enhancement
Software testing is a knowledge based industry. Often, knowledge on a certain aspect is a distinguishing factor between testers. A tester should not only always look to enhance knowledge by all means possible but also ensure the application of knowledge at the work-place. Successful implementation of such initiatives surely enhances self-esteem.
Encouragement for having higher goals
A Tester should always work to seek clarity of goals and should aim from something significant. Having clarity of goals reduces the distractions and prepares tester to achieve something significant for self and for the profession. The process of achieving such goals itself enhances self-esteem. Spending whole days without a set direction and meaningful goals often makes you feel bad about self at the end of the day.
Timely Appreciation
Having a proper recognition system in place for testers help enhance the self-esteem. There are various ways tester’s efforts can be recognized such as recognizing the efforts in various aspects of work such test case creation, testing, finding bugs etc. People in the leadership positions have important roles to play to make such programs successful and to ensure the testers are genuinely and timely appreciated for their efforts.
Think beyond current roles
Testers should always be encouraged not to fall in the rut of daily routine and think beyond their currently assigned roles. Of-course, this can be done effectively only when the testers are able to do their current roles to perfection. Thinking out-of-box and achieving noteworthy improvements to current way of doing things certainly enhances self-image.
Conquer fears
Having knowledge of self limitations and working towards getting rid of those limitations is a primary step towards self-development. Testers should always work to know their fears and then work towards eliminating them e.g. a tester may have fear to deliver a presentation to the group, or fear of change etc. Conquering fears by adopting step-by-step approach helps one feel good about self.
There can be many such ways to enhance self-esteem which a tester can think and implement. Getting rid of the traces of low self-esteem in your personality takes you closer to achieving success. Having awareness of your self-esteem and then subsequently working to enhance the same is first step towards achieving greater things for the profession.
Subscribe to:
Posts (Atom)
