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/
Friday, November 30, 2007
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.
Friday, November 2, 2007
Thinking hats that make Software testing effective
One of my articles got published in the recent issues of TheSmartTechie Magazine- http://www.thesmarttechie.com.
This article talks about the application of Six thinking hats technique (by Edward de Bono) in Software Testing. This is my curret area of interest. Read on some Excerpt of this article-
"ABB: Reduced multinational project meetings from 30 days to 2 days."
"MobiFon-Connex: Average speed to answer a customer phone call went down from 225 seconds to 40 seconds."
These are results that are nothing short of a miracle. These are the numbers which are indeed an epitome of improvement by all standards.
This immediately brings a question to our minds, "How is this possible?" How much resources these organizations would have put in to get there?
The answer to this lies in Edward de Bono's brainchild on thinking performance, "Six Thinking Hats". Yes, these results are a testimonial on the extent of success that can be achieved by "just" optimizing one's thinking. Aren't the results astonishing?
Six Thinking Hats - an introduction
Six Thinking Hats, as Edward de Bono puts it, is a simple and effective parallel thinking process. This concept advocates the use of parallel thinking over the traditionally used critical, argumentative thinking. The conventional argumentative thinking is aimed most of the times at killing ideas and creativity and it lacks the constructive energy. Parallel thinking, on the other hand, is a kind of thinking in which each thinker keeps his thought parallel to those of other thinkers and at no instance attacks others’ ideas and thoughts.
Hoes does it work?
Six Thinking Hats concept aims at minimizing the confusion in thinking that arises mainly because of the way human brain usually thinks, taking into consideration emotions, facts, creativity, hope, and logic all at once. This concept helps a thinker take up these elements of thinking one at a time, thereby simplifying thoughts and making solutions more approachable. The term "Hat" is used primarily to benefit from already existing association of many cultures to the phrase "Thinking Hat" i.e., a certain kind of thinking that can be put on or off.
What are the different hats and what do they signify?
Edward de Bono defines six different types of hat, each signifying a different way of looking at thinking.
Click the image to see the enlarged view and read the text
Software testing and thinking skills
Over the past decade or so, software testing has evolved a lot. There was a time when software testing was perceived to be something to be done at the tail-end of Software Development Life Cycle (SDLC), something for which no expertise was needed, something "anyone" could do without any training.
All this has changed over a period of time and software testing has emerged as an integral part of SDLC and this profession has witnessed many innovations. The emergence of Six Thinking Hats is one such innovation and software testing is bound to reap rich benefits from this concept for the primary reason that it optimizes a key resource required for Testing - "Thinking".
Effective Thinking skills indeed form the basis of Effective Testing and this is evident from some of the important activities in software testing - Test Planning, Test design, and Test Execution.
Test planning
Test Planning forms one of the key phases in Testing Life cycle. A Test plan usually is the beginning of involvement of testing group in the overall scheme of things.
Test Planning is a complex activity, and to get the best results Collaborative Test Planning is a viable option in many cases. Collaborative Test Planning is the one in which the key members of stakeholder testing group meet and discuss the key planning items and draw up the plan together. This is where Six Thinking Hats method can be most effective. Here is an excerpt of how it can be done -
Test plan owner (usually a Test Lead or Manager) wears a Blue hat and thereby owns the thinking process, defines the problem statement, manages the thinking process during the meeting, and owns the outcome of the meeting.
The way the meeting can be conducted depends primarily on the context. Here's one such way - Each section of the test plan is picked up and the participants are asked to wear each hat one by one to explore each section in its entirety. Consider that Test Plan section is Software Risk issues and contingency planning. It is most practical to start the discussion on Software risks with everyone wearing a Black hat. Each member in the group thinks in the same direction (i.e., about difficulties, risks, etc.) and gives his inputs. Once all the points under Black Hat are covered, the team moves on to the other relevant thinking hat.
While exploring the Software risks, it is important to ask for people's feelings and emotional views of the topic. This generally brings out some usually not thought about risks. So, the Blue hat owner instructs the team to switch to Red hat. And then everyone in the group gives relevant Red hat outputs.
A person wearing blue hat ensures that the members do not deviate from their assigned roles according to the hats and directs the members in case it is found otherwise. This way the section under consideration gets covered completely.
Software risk contingency planning usually deals with positive assessment of the problem at hand and thus, it is appropriate for everyone to switch to Yellow hat. Yellow hat thinking helps in exploring constructive proposals and suggestions to the given problems. Another aspect that helps in contingency planning is the search for alternatives i.e., finding creative solution to complex problems. Once the team is exhausted with providing Yellow hat outputs, the team switches to Green hat to explore more alternatives to ensure robust planning.
The key here is that the whole group is focused on only one type of thinking at any given time, thereby eliminating the wastage of time and the distraction due to difference of opinions and arguments. This example gives an insight into how each section of the Test Plan can be covered comprehensively by thinking in all directions. This method eliminates complexity in thinking by simplifying the thinking process and if executed in a right way, it helps eliminate ego-tussle (which is sometimes prevalent among individuals in a meeting) by making everyone think in the same direction, thereby eliminating unproductive confrontations.
Test design and execution
Six Thinking Hats method can be used effectively in group thinking as well as in Individual thinking. The use in individual thinking requires a lot of discipline and practice. Consider a tester involved in exploratory testing. While testing a feature, a tester can split available time into different time-boxes and assign each time-box to a particular hat, thereby ensuring that the software gets tested in consideration of each thinking perspective that a customer can have while using the software. While most of the time testers are concerned with "Customer's Requirements coverage", this approach will help them achieve "Customer's Thinking coverage" as well. Thus, Six Thinking Hats method can be a powerful tool to ensure flawless planning, gain greater test coverage, timely detection of bugs, and enhancing the overall effectiveness of testing just by optimizing one's thinking and virtually without any additional cost.
"Software testing efficiency increases by 100% by super effective planning."
"Bugs found in early phases of testing increase by 50% due to effective test design and execution."
Fancy these results for your testing organization! It’s time Software Testing benefited from this amazing concept of Six Thinking Hats.
Inspiration: Six Thinking Hats by Edward de Bono.
Courtesy: The SmartTechie Magazine www.thesmarttechie.com
This article talks about the application of Six thinking hats technique (by Edward de Bono) in Software Testing. This is my curret area of interest. Read on some Excerpt of this article-
"ABB: Reduced multinational project meetings from 30 days to 2 days."
"MobiFon-Connex: Average speed to answer a customer phone call went down from 225 seconds to 40 seconds."
These are results that are nothing short of a miracle. These are the numbers which are indeed an epitome of improvement by all standards.
This immediately brings a question to our minds, "How is this possible?" How much resources these organizations would have put in to get there?
The answer to this lies in Edward de Bono's brainchild on thinking performance, "Six Thinking Hats". Yes, these results are a testimonial on the extent of success that can be achieved by "just" optimizing one's thinking. Aren't the results astonishing?
Six Thinking Hats - an introduction
Six Thinking Hats, as Edward de Bono puts it, is a simple and effective parallel thinking process. This concept advocates the use of parallel thinking over the traditionally used critical, argumentative thinking. The conventional argumentative thinking is aimed most of the times at killing ideas and creativity and it lacks the constructive energy. Parallel thinking, on the other hand, is a kind of thinking in which each thinker keeps his thought parallel to those of other thinkers and at no instance attacks others’ ideas and thoughts.
Hoes does it work?
Six Thinking Hats concept aims at minimizing the confusion in thinking that arises mainly because of the way human brain usually thinks, taking into consideration emotions, facts, creativity, hope, and logic all at once. This concept helps a thinker take up these elements of thinking one at a time, thereby simplifying thoughts and making solutions more approachable. The term "Hat" is used primarily to benefit from already existing association of many cultures to the phrase "Thinking Hat" i.e., a certain kind of thinking that can be put on or off.
What are the different hats and what do they signify?
Edward de Bono defines six different types of hat, each signifying a different way of looking at thinking.
Click the image to see the enlarged view and read the text
Software testing and thinking skills
Over the past decade or so, software testing has evolved a lot. There was a time when software testing was perceived to be something to be done at the tail-end of Software Development Life Cycle (SDLC), something for which no expertise was needed, something "anyone" could do without any training.
All this has changed over a period of time and software testing has emerged as an integral part of SDLC and this profession has witnessed many innovations. The emergence of Six Thinking Hats is one such innovation and software testing is bound to reap rich benefits from this concept for the primary reason that it optimizes a key resource required for Testing - "Thinking".
Effective Thinking skills indeed form the basis of Effective Testing and this is evident from some of the important activities in software testing - Test Planning, Test design, and Test Execution.
Test planning
Test Planning forms one of the key phases in Testing Life cycle. A Test plan usually is the beginning of involvement of testing group in the overall scheme of things.
Test Planning is a complex activity, and to get the best results Collaborative Test Planning is a viable option in many cases. Collaborative Test Planning is the one in which the key members of stakeholder testing group meet and discuss the key planning items and draw up the plan together. This is where Six Thinking Hats method can be most effective. Here is an excerpt of how it can be done -
Test plan owner (usually a Test Lead or Manager) wears a Blue hat and thereby owns the thinking process, defines the problem statement, manages the thinking process during the meeting, and owns the outcome of the meeting.
The way the meeting can be conducted depends primarily on the context. Here's one such way - Each section of the test plan is picked up and the participants are asked to wear each hat one by one to explore each section in its entirety. Consider that Test Plan section is Software Risk issues and contingency planning. It is most practical to start the discussion on Software risks with everyone wearing a Black hat. Each member in the group thinks in the same direction (i.e., about difficulties, risks, etc.) and gives his inputs. Once all the points under Black Hat are covered, the team moves on to the other relevant thinking hat.
While exploring the Software risks, it is important to ask for people's feelings and emotional views of the topic. This generally brings out some usually not thought about risks. So, the Blue hat owner instructs the team to switch to Red hat. And then everyone in the group gives relevant Red hat outputs.
A person wearing blue hat ensures that the members do not deviate from their assigned roles according to the hats and directs the members in case it is found otherwise. This way the section under consideration gets covered completely.
Software risk contingency planning usually deals with positive assessment of the problem at hand and thus, it is appropriate for everyone to switch to Yellow hat. Yellow hat thinking helps in exploring constructive proposals and suggestions to the given problems. Another aspect that helps in contingency planning is the search for alternatives i.e., finding creative solution to complex problems. Once the team is exhausted with providing Yellow hat outputs, the team switches to Green hat to explore more alternatives to ensure robust planning.
The key here is that the whole group is focused on only one type of thinking at any given time, thereby eliminating the wastage of time and the distraction due to difference of opinions and arguments. This example gives an insight into how each section of the Test Plan can be covered comprehensively by thinking in all directions. This method eliminates complexity in thinking by simplifying the thinking process and if executed in a right way, it helps eliminate ego-tussle (which is sometimes prevalent among individuals in a meeting) by making everyone think in the same direction, thereby eliminating unproductive confrontations.
Test design and execution
Six Thinking Hats method can be used effectively in group thinking as well as in Individual thinking. The use in individual thinking requires a lot of discipline and practice. Consider a tester involved in exploratory testing. While testing a feature, a tester can split available time into different time-boxes and assign each time-box to a particular hat, thereby ensuring that the software gets tested in consideration of each thinking perspective that a customer can have while using the software. While most of the time testers are concerned with "Customer's Requirements coverage", this approach will help them achieve "Customer's Thinking coverage" as well. Thus, Six Thinking Hats method can be a powerful tool to ensure flawless planning, gain greater test coverage, timely detection of bugs, and enhancing the overall effectiveness of testing just by optimizing one's thinking and virtually without any additional cost.
"Software testing efficiency increases by 100% by super effective planning."
"Bugs found in early phases of testing increase by 50% due to effective test design and execution."
Fancy these results for your testing organization! It’s time Software Testing benefited from this amazing concept of Six Thinking Hats.
Inspiration: Six Thinking Hats by Edward de Bono.
Courtesy: The SmartTechie Magazine www.thesmarttechie.com
Subscribe to:
Posts (Atom)
