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
Monday, December 24, 2007
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.
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
Monday, October 15, 2007
Is "Creative pause" a possible solution to minimize "Inattentional blindness" ?
Imagine a tester is working to test a last minute hot-fix of a product (which was found just before it was going to be released to a millions of consumers). He goes through the steps required to "test" that hot-fix and declares it to be fixed. A different group of testers working in a different location (and in the same project) tests the hot-fix on the same build and they found that though the bug was fixed but it resulted in some different behavior that is potentially critical from end-user's perspective.
Though there can be many reasons why the first tester missed the bug but one of the most likely reasons can be "Inattentional Blindness" (Referred to as "IB" in remainder for this post)
I was going through Black box testing presentations and videos by Cem Kaner and James Bach can came across this behavior which can have a tremendous impact on tester's effectiveness. The above situation that i have cited is not an hypothetical one but something that i have seen happening in my experience very often. And such a situation, when it occurs during the highly-critical release phase, often brings out the inadequacies of testing and there-by giving the chance for management to question the credibility of Testing group. In my experience, in the crunch situations (like the one mentioned above) where the focus is only on a certain aspect of product (hot fix in above case) and for a very limited duration- is when a tester is most likely to fall in the trap of IB. Ironically, these are the situations when usually there is a lot at stake and mistakes are the last things anyone would expect.
As an example that I can cite- I was involved in managing a team testing one such hot fix. People involved in testing demonstrated a great deal of commitment and ownership to test and release the hot-fix successfully by testing overnight and on weekends. Later on it occurred that-though the hot-fix resolved the intended issue but the testers missed to pay attention to cosmetic (but important) issue and released the fix with one of the buttons reading- "Clock here" instead of "Click here". Needless to say, such defects make the product (how-so-ever feature-rich, bug-free it may be) look unprofessional and root cause in this case was IB (probably one reason can be because the testers were involved in testing tirelessly without much of breaks in between).
All this leads to a question-
- Is there a solution to avoid "Inattentional Blindness" in Software testing ?
IB appears to be a phenomenon that is quite prevalent/common in human beings. Probably, that’s the reason for many common mistakes that a human does. Philosophically speaking, Going by the precept- "To err is human", i don't think it is entirely possible to get away from IB (i just wish i had enough data points to prove this- it’s something that i intend to explore), though we can try to form the ways to minimize the same.
The foremost way to minimize the occurrence of IB is to create awareness in the testing group about IB and its extreme effects. It is important for the testers to know about the reasons why bugs get missed in the testing cycles (IB being one of the potential reasons of the missed bugs). Being aware and conscious about the fact can help testers be more alert.
In one of my previous post i talked about the concept of Creative Pause. This is something that i feel can go a long way to help testers minimize the occurrence. Indulging in Creative Pauses are more like refreshers to testing activity. It helps recharge the cluttered minds and can help a long way in holding the attention spans of the testers, thereby making them less prone to traps of IB.
From my experience, practicing Creative Pauses requires a lot of discipline but if done in a right way can improve effectiveness (and Creativity) many fold.
Any more ideas...
Keep testing creatively!
Though there can be many reasons why the first tester missed the bug but one of the most likely reasons can be "Inattentional Blindness" (Referred to as "IB" in remainder for this post)
I was going through Black box testing presentations and videos by Cem Kaner and James Bach can came across this behavior which can have a tremendous impact on tester's effectiveness. The above situation that i have cited is not an hypothetical one but something that i have seen happening in my experience very often. And such a situation, when it occurs during the highly-critical release phase, often brings out the inadequacies of testing and there-by giving the chance for management to question the credibility of Testing group. In my experience, in the crunch situations (like the one mentioned above) where the focus is only on a certain aspect of product (hot fix in above case) and for a very limited duration- is when a tester is most likely to fall in the trap of IB. Ironically, these are the situations when usually there is a lot at stake and mistakes are the last things anyone would expect.
As an example that I can cite- I was involved in managing a team testing one such hot fix. People involved in testing demonstrated a great deal of commitment and ownership to test and release the hot-fix successfully by testing overnight and on weekends. Later on it occurred that-though the hot-fix resolved the intended issue but the testers missed to pay attention to cosmetic (but important) issue and released the fix with one of the buttons reading- "Clock here" instead of "Click here". Needless to say, such defects make the product (how-so-ever feature-rich, bug-free it may be) look unprofessional and root cause in this case was IB (probably one reason can be because the testers were involved in testing tirelessly without much of breaks in between).
All this leads to a question-
- Is there a solution to avoid "Inattentional Blindness" in Software testing ?
IB appears to be a phenomenon that is quite prevalent/common in human beings. Probably, that’s the reason for many common mistakes that a human does. Philosophically speaking, Going by the precept- "To err is human", i don't think it is entirely possible to get away from IB (i just wish i had enough data points to prove this- it’s something that i intend to explore), though we can try to form the ways to minimize the same.
The foremost way to minimize the occurrence of IB is to create awareness in the testing group about IB and its extreme effects. It is important for the testers to know about the reasons why bugs get missed in the testing cycles (IB being one of the potential reasons of the missed bugs). Being aware and conscious about the fact can help testers be more alert.
In one of my previous post i talked about the concept of Creative Pause. This is something that i feel can go a long way to help testers minimize the occurrence. Indulging in Creative Pauses are more like refreshers to testing activity. It helps recharge the cluttered minds and can help a long way in holding the attention spans of the testers, thereby making them less prone to traps of IB.
From my experience, practicing Creative Pauses requires a lot of discipline but if done in a right way can improve effectiveness (and Creativity) many fold.
Any more ideas...
Keep testing creatively!
Blog Action Day
Note:
THIS POST IS NOT ABOUT SOFTWARE TESTING....Still Interested...Read on!
Today(15th-Oct-2007) is a Blog Action day . Blogging has become quite an revoultion all around the world and over a period of time it has become one of the most powerful communication medium. The purpose of Blog Action day is to bond all the blog users (owners and readers) towards a common cause. This time, the cause is "Environment".
Through this channel i would also like to bring about the awareness of one of the Environmental issues- the usage of paper.
I would like to cite some facts- (courtesy- http://www.lisashea.com/lisabase/aboutme/paperusage.html)
* It takes 17 pulpwood market-sized trees to make a ton of paper, or one tree makes about 11,500 pages of 8.5 x 11 20-pound paper.
* Each one million pages of paper not printed saves 85 pulp trees.
* That ton of paper, when disposed of, takes up nearly 8 cubic feet of public landfill space.
* To produce one trillion pages of paper takes 8.5 million acres of trees, representing an area larger than the country of Belgium or the state of Maryland.
* It takes 390 gallons of oil to produce a ton of paper.
* In prehistoric times, 60% of the earth's surface was covered by forests - today that amount has been reduced by 30% and is still shrinking.
* That public landfill is approximately 36% waste paper products.
* Each person in an office on average uses 2.5 pounds of paper each week.
* The average office worker generates between 120 - 150 pounds of recoverable white office paper a year.
Aren’t these figures Startling ?
Aren’t we responsible for reduction of natural resources ?
Aren’t we responsible for turning green cities to concrete jungles ?
Doesn’t this act as a wake-up call for us to do something about it ?
Even though most of us always have an excuse that- "We don’t have time and we are too busy", I feel there is a lot that we can do even not being directly involved. Consider this-
1. If your office uses Paper cups for Water/Coffee etc. Refrain from using the same. Have your Coffee mug instead. How long does it take to follow this practice ? Probably, only the time/money involved i purchasing a Coffee mug.
2. If you still want to use Paper cups- Do not only use them but consider re-using them (atleast for Water- not coffee).
3. Do not print unnecessary papers. One of the best email signature quotes that i have seen is-
Please don't print this e-mail unless you really need to.
Think GREEN !!
4. Even if you have to print, try going for double-sided printing or multiple pages in a single sheet (provided you can read, of course).
5. Consider using personal cloth napkins rather Paper towel and tissues.
These are only a very small way to contribute but of done on a consistent basis by everyone, it will sure make a enormous difference.
Lets start a revolution...Together!
“ Every person is the right person to act.
Every moment is the right moment to begin.”
Jonathan Schell, author, Fate of the Earth
THIS POST IS NOT ABOUT SOFTWARE TESTING....Still Interested...Read on!
Today(15th-Oct-2007) is a Blog Action day . Blogging has become quite an revoultion all around the world and over a period of time it has become one of the most powerful communication medium. The purpose of Blog Action day is to bond all the blog users (owners and readers) towards a common cause. This time, the cause is "Environment".
Through this channel i would also like to bring about the awareness of one of the Environmental issues- the usage of paper.
I would like to cite some facts- (courtesy- http://www.lisashea.com/lisabase/aboutme/paperusage.html)
* It takes 17 pulpwood market-sized trees to make a ton of paper, or one tree makes about 11,500 pages of 8.5 x 11 20-pound paper.
* Each one million pages of paper not printed saves 85 pulp trees.
* That ton of paper, when disposed of, takes up nearly 8 cubic feet of public landfill space.
* To produce one trillion pages of paper takes 8.5 million acres of trees, representing an area larger than the country of Belgium or the state of Maryland.
* It takes 390 gallons of oil to produce a ton of paper.
* In prehistoric times, 60% of the earth's surface was covered by forests - today that amount has been reduced by 30% and is still shrinking.
* That public landfill is approximately 36% waste paper products.
* Each person in an office on average uses 2.5 pounds of paper each week.
* The average office worker generates between 120 - 150 pounds of recoverable white office paper a year.
Aren’t these figures Startling ?
Aren’t we responsible for reduction of natural resources ?
Aren’t we responsible for turning green cities to concrete jungles ?
Doesn’t this act as a wake-up call for us to do something about it ?
Even though most of us always have an excuse that- "We don’t have time and we are too busy", I feel there is a lot that we can do even not being directly involved. Consider this-
1. If your office uses Paper cups for Water/Coffee etc. Refrain from using the same. Have your Coffee mug instead. How long does it take to follow this practice ? Probably, only the time/money involved i purchasing a Coffee mug.
2. If you still want to use Paper cups- Do not only use them but consider re-using them (atleast for Water- not coffee).
3. Do not print unnecessary papers. One of the best email signature quotes that i have seen is-
Please don't print this e-mail unless you really need to.
Think GREEN !!
4. Even if you have to print, try going for double-sided printing or multiple pages in a single sheet (provided you can read, of course).
5. Consider using personal cloth napkins rather Paper towel and tissues.
These are only a very small way to contribute but of done on a consistent basis by everyone, it will sure make a enormous difference.
Lets start a revolution...Together!
“ Every person is the right person to act.
Every moment is the right moment to begin.”
Jonathan Schell, author, Fate of the Earth
Friday, October 12, 2007
Soft Skills that Make a Tester- Redefined
In the Year 2003, I had written an article on the topic- "Soft Skills that Make a Tester" (http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=6752) as a part of Original section on Stickyminds website. In this article, I had attempted to list down the Soft skills of the testers that differentiate and helps the testers be successful in their jobs (in addition to Technical skills, of course!). Considering India Software testing scenario, I feel that early part of this decade was the time when there was a lot of emphasis on Technical skills and every other tester wanted to learn Automation and about how to do testing, test designing etc.(Its prevalent even now to some extent). In my experience, I came across quite a few people who left their organizations just because they didn’t get opportunity to work on Automation! Such was the extreme focus on Technical skills that Testers used to believe that "If you are not involved in programming, then you are not being productive".
Contrary to this belief, I think Soft skills are extremely important for the people in Software testing and this is something that is often found to be neglected by the upcoming testers. In order to become an all-round tester with great skills, Soft skills have to be given their due importance. There are many situations that we come across on the day-to-day work life as a testers in which one person perform better than the others just on the basis of Soft skills- be it winning an argument with developer on the basis of his/her communication or finding handling multiple tasks effectively because if superior organizational abilities etc.
In the mentioned article, I had tried to put focus of some of the important soft skills namely-
- Discipline and Perseverance
- Reading Skills
- Negative Thinking
- Communication and Interpersonal Skills
- Time Management and Effort Prioritization
- Attitude
Most of the testing practitioners will argue that this list of Soft skills isn’t complete. Even I agree with this and have to admit that I had to leave out some of the important skills in order to meet the word-limit requirement of the article.
I believe there is a lot of change that has happened in the way Software testing is conducted in many organizations since last 4-5 years or so. The terms like Security Testing, Stress Testing, to an extent Performance testing, White box testing, Code inspections by testing groups etc. which used to be in testing theory earlier, has gradually become a part of testing schedule and plans. I have seen this change in many organizations- i.e. the drift in focus from Only Functional Testing, Automation to different streams of testing as described earlier. There were multiple factors governing this change mainly- Expectations of customers, Post production bugs (and the noise generated by these!) and motivation to deliver ”complete" software to the market. This change has been a good one for the Software Testing fraternity and has opened up a myriad of growth paths- both horizontal and vertical, both Technical and Management paths for the testers. This has created the jobs for new Technical skills in the market and has enhanced the role of Software Testing in overall scheme of things.
This changed focus has also brought about the changes in the way Soft skills are perceived. Earlier, in my article I had classified Soft skills generically for Software testing profession. Now, with the shift happening in Software testing profession- every unique kind of testing requires certain specific Soft skills.
For example Security Testing requires a lot different mindset as compared to Functional Testing. A Security tester will need to have an attacker's mindset, always thinking of finding the ways to expose Security holes in Software. Also, the bug find rate for the Security tester may not be as high as that of a functional tester, so a Security Tester will have to show more perseverance and patience in dealing with testing. On the contrary, a Functional tester also needs to do negative testing but it is generally not as extreme as is required of a Security Tester.
The case of White box tester is even more unique. The tester in this case has to strike an effective balance between being a developer and a tester and he/she is often required to switch the roles with ease.
If you are new to any type of testing or any new work for that matter, it always makes the job easier (and thereby, increasing the chances of success) if one tries to approach the job by learning about the associated soft skills first. In my experience, I have found it easier to get into new role and learning new skills by first working to master the soft skills required and learning the technical skills along-side.
Watch out this blog space for more on the variety of skills sometime soon!
Keep testing passionately!
Contrary to this belief, I think Soft skills are extremely important for the people in Software testing and this is something that is often found to be neglected by the upcoming testers. In order to become an all-round tester with great skills, Soft skills have to be given their due importance. There are many situations that we come across on the day-to-day work life as a testers in which one person perform better than the others just on the basis of Soft skills- be it winning an argument with developer on the basis of his/her communication or finding handling multiple tasks effectively because if superior organizational abilities etc.
In the mentioned article, I had tried to put focus of some of the important soft skills namely-
- Discipline and Perseverance
- Reading Skills
- Negative Thinking
- Communication and Interpersonal Skills
- Time Management and Effort Prioritization
- Attitude
Most of the testing practitioners will argue that this list of Soft skills isn’t complete. Even I agree with this and have to admit that I had to leave out some of the important skills in order to meet the word-limit requirement of the article.
I believe there is a lot of change that has happened in the way Software testing is conducted in many organizations since last 4-5 years or so. The terms like Security Testing, Stress Testing, to an extent Performance testing, White box testing, Code inspections by testing groups etc. which used to be in testing theory earlier, has gradually become a part of testing schedule and plans. I have seen this change in many organizations- i.e. the drift in focus from Only Functional Testing, Automation to different streams of testing as described earlier. There were multiple factors governing this change mainly- Expectations of customers, Post production bugs (and the noise generated by these!) and motivation to deliver ”complete" software to the market. This change has been a good one for the Software Testing fraternity and has opened up a myriad of growth paths- both horizontal and vertical, both Technical and Management paths for the testers. This has created the jobs for new Technical skills in the market and has enhanced the role of Software Testing in overall scheme of things.
This changed focus has also brought about the changes in the way Soft skills are perceived. Earlier, in my article I had classified Soft skills generically for Software testing profession. Now, with the shift happening in Software testing profession- every unique kind of testing requires certain specific Soft skills.
For example Security Testing requires a lot different mindset as compared to Functional Testing. A Security tester will need to have an attacker's mindset, always thinking of finding the ways to expose Security holes in Software. Also, the bug find rate for the Security tester may not be as high as that of a functional tester, so a Security Tester will have to show more perseverance and patience in dealing with testing. On the contrary, a Functional tester also needs to do negative testing but it is generally not as extreme as is required of a Security Tester.
The case of White box tester is even more unique. The tester in this case has to strike an effective balance between being a developer and a tester and he/she is often required to switch the roles with ease.
If you are new to any type of testing or any new work for that matter, it always makes the job easier (and thereby, increasing the chances of success) if one tries to approach the job by learning about the associated soft skills first. In my experience, I have found it easier to get into new role and learning new skills by first working to master the soft skills required and learning the technical skills along-side.
Watch out this blog space for more on the variety of skills sometime soon!
Keep testing passionately!
Tuesday, October 9, 2007
Software Testing "paused" Creatively
"Being creative may just be a matter of setting aside the time needed to take a step back and allow yourself to ask yourself if there is a better way of doing something. Edward de Bono calls this a 'Creative Pause'. He suggests that this should be a short break of maybe only 30 seconds, but that this should be a habitual part of thinking. This needs self-discipline, as it is easy to forget."
Source: http://www.mindtools.com
Edward de bono has brought out an amazing concept in the above lines. The concept of "Creative Pause". In my experience in working in the field of Software testing, i have found "Creativity" and "Innovation" as something everyone feels as necessary to grow but at the same time have found people to be clueless as to how to be Creative and Innovative. May be in a feedback session- If tester is indicated to be creative and Innovative in carrying out day-to-day tasks , he/she is often seen wondering-
"What do you want me to do ?"
"What is it that i am not doing right now that you want me to do ?"
"Am i not performing to the Manager's expectations ?"
I was reading one of the books by Edward de bono's (For those who don’t know, Edward de bono is widely known as "Father of Creativity") and he so rightly mentions that- "Creative thinking is skill. Its not a matter of individual talent.
Being a skill, Creative thinking is something that can be developed and acquired by practicing the right things, the right way of thinking.
In one of the my previous posts , i have mentioned that- "Creativity is an essence of Software Testing." Probably, a trait that this profession can gain the most from.
The concept of "Creative Pause" is something that can be applied in a variety of situations in Software Testing. This concept gives an indication to a tester on how he/she can go about on the path of creativity.
Considering the situations-
- A tester performing Exploratory testing for a few hours often gets into a situations when all the ideas and enthusiasm starts drying up. It is at this stage, a brief Creative Pause can do wonders. The Creative Pause can open up some of the ideas that a tester never thought about before and he/she ends up with an unimaginable high value bug.
- A tester in a situation when he/she is struck with so-called monotonous chores, a creative pause can give an immense value to find better ways of doing things that are considered to be bane for Software testing profession.
- I have found Creative Pause mostly working in a situations when one is attempting any problem solving be it solving test coverage related issues, test execution issues, people/management related issues etc., taking a Creative pause and assessing the situation gives immense value and proactively gives chance to rectify any errors.
The intent of this post is to introduce this amazing concept to software testing. Keep watching this blog-post on more of "Creative Pause" Experiences.
Always remember, as Edward mentions- "There is no point being different for the sake of being different. Creative idea must have a value.
Keep testing creatively!
Source: http://www.mindtools.com
Edward de bono has brought out an amazing concept in the above lines. The concept of "Creative Pause". In my experience in working in the field of Software testing, i have found "Creativity" and "Innovation" as something everyone feels as necessary to grow but at the same time have found people to be clueless as to how to be Creative and Innovative. May be in a feedback session- If tester is indicated to be creative and Innovative in carrying out day-to-day tasks , he/she is often seen wondering-
"What do you want me to do ?"
"What is it that i am not doing right now that you want me to do ?"
"Am i not performing to the Manager's expectations ?"
I was reading one of the books by Edward de bono's (For those who don’t know, Edward de bono is widely known as "Father of Creativity") and he so rightly mentions that- "Creative thinking is skill. Its not a matter of individual talent.
Being a skill, Creative thinking is something that can be developed and acquired by practicing the right things, the right way of thinking.
In one of the my previous posts , i have mentioned that- "Creativity is an essence of Software Testing." Probably, a trait that this profession can gain the most from.
The concept of "Creative Pause" is something that can be applied in a variety of situations in Software Testing. This concept gives an indication to a tester on how he/she can go about on the path of creativity.
Considering the situations-
- A tester performing Exploratory testing for a few hours often gets into a situations when all the ideas and enthusiasm starts drying up. It is at this stage, a brief Creative Pause can do wonders. The Creative Pause can open up some of the ideas that a tester never thought about before and he/she ends up with an unimaginable high value bug.
- A tester in a situation when he/she is struck with so-called monotonous chores, a creative pause can give an immense value to find better ways of doing things that are considered to be bane for Software testing profession.
- I have found Creative Pause mostly working in a situations when one is attempting any problem solving be it solving test coverage related issues, test execution issues, people/management related issues etc., taking a Creative pause and assessing the situation gives immense value and proactively gives chance to rectify any errors.
The intent of this post is to introduce this amazing concept to software testing. Keep watching this blog-post on more of "Creative Pause" Experiences.
Always remember, as Edward mentions- "There is no point being different for the sake of being different. Creative idea must have a value.
Keep testing creatively!
Friday, October 5, 2007
Globalization testing- The High business impact testing
Wikipedia defines Globalization as follows-
Globalization (or Globalisation) refers to increasing global connectivity, integration and interdependence in the economic, social, technological, cultural, political, and ecological spheres.
With most businesses across the world following Globalization trend, the world has rapidly become a well-connected place (thanks to the advent of Internet and other communication technologies). Any news that happens in any extreme corner of the world gets known to everyone in seconds. This is very different from how world used to operate in may be 10-15 years earlier.
The business model for almost all the successful Software products and services have had its basis in Globalization i.e. the products are developed and delivered for International markets. One of the huge advantages in case of Software business is its mode of distribution through Internet. This makes the products accessibility in the different countries far superior as compared to physical products. With more and more Software products going global, the Globalization testing has assumed a mammoth importance. It has been in the Project Life cycle of all the top notch product organizations.
Consider this- Windows XP is available for 90 plus locales all across the globe. This proves the kind of geographies, market , millions of customers and the immense business impact that is dealt with when Globalization testing is done.
Keep watching this blog space for more on Globalization testing experiences…
Globalization (or Globalisation) refers to increasing global connectivity, integration and interdependence in the economic, social, technological, cultural, political, and ecological spheres.
With most businesses across the world following Globalization trend, the world has rapidly become a well-connected place (thanks to the advent of Internet and other communication technologies). Any news that happens in any extreme corner of the world gets known to everyone in seconds. This is very different from how world used to operate in may be 10-15 years earlier.
The business model for almost all the successful Software products and services have had its basis in Globalization i.e. the products are developed and delivered for International markets. One of the huge advantages in case of Software business is its mode of distribution through Internet. This makes the products accessibility in the different countries far superior as compared to physical products. With more and more Software products going global, the Globalization testing has assumed a mammoth importance. It has been in the Project Life cycle of all the top notch product organizations.
Consider this- Windows XP is available for 90 plus locales all across the globe. This proves the kind of geographies, market , millions of customers and the immense business impact that is dealt with when Globalization testing is done.
Keep watching this blog space for more on Globalization testing experiences…
Thursday, October 4, 2007
Do you love Software Testing ?
If you want happiness for an hour...take a nap
If you want happiness for an day...Go for a picnic
If you want happiness for an week...Go on vacation
If you want happiness for a month...Get married :-)
If you want happiness for a year...Inherit wealth
If you want happiness for a lifetime...LEARN TO LOVE WHAT YOU DO.
(Quotes referred from the book- "Management Thoughts for the Family" by Pramod Batra and Vijay Batra)
The above excerpt talks so rightly about true happiness/success lesson out of life. This is something thats applicable for any kind of work that exists in this world. Software testing is no different. Consider the situations-
- A tester is struck with a bug that is not reproducible at all the instances. In order to reproduce the bug he goes through the whole series of steps again and again. A passionate tester in this situation will persevere to find a better alternative and a non-passionate tester is most likely to crib his job.
- As part of a daily routine, a tester has been asked to collect data about test cases executed, bugs logged, etc. A passionate tester will consider this as an integral part of his job and will strive to understand the context and provide as much information as possible to assist with decision making. A non-passionate tester will barely provide the asked information and as usual blame the world for making him do a silly job.
- After discovering a defect, a tester is supposed to write steps to recreate the defect. A Passionate tester will write the steps in such a way to sell his defect and strive to be perfect at Bug advocacy. A non-passionate tester will take this as just another routine job and is most likely to make more mistakes in reporting the defects. (i don’t mean to say that Passionate testers don’t do any mistakes)
- A tester is asked to take handle multiple things. Mostly in the projects when different phases of project life cycle overlaps (e.g. Test case creation overlaps with actual testing of the project), a tester is required to do multiple things at once i.e. test case creation, testing the software, documenting results etc. all at the same time. Passionate testers see this as an opportunity to excel and demonstrate desire for responsibility by effectively managing time and efforts.
- Tester A comes into work and constantly gives suggestions to improve the status quo. Tester B comes into work and just do what he/she is asked to do. No prizes for guessing which tester loves his/her work more than the other.
- A tester gets promoted to a Test leader. Considering that he/she would have ideally tested for past 5-6 or more or less years,he/she starts showing no inclination towards hands-on considering hands-on testing is supposed to be done by Engineers and not leads! Such a situation is very much prevalent in Software testing fraternity. A passionate tester would never lay his hands off testing. He/She will be always on the look out of extra-ordinary, unknown bugs no matter what designation he/she holds.
Such situations and many many other situations clearly demarcate a passionate tester with a non-passionate one i.e. the one who loves his/her job vs. the one who doesn’t.
Passionate testers always have something unique to offer and that may be in terms of their thought process, the way they carry the day-to-day work, their outputs, efficiency, the way they give suggestions and improve things around them tirelessly. Passionate testers are never satisfied with what they achieve and always strive to find unimaginable bugs of high value and priority.
There is only one way out- Love your job or find something that you love doing and happiness/success will be all yours.
Keep testing passionately!
If you want happiness for an day...Go for a picnic
If you want happiness for an week...Go on vacation
If you want happiness for a month...Get married :-)
If you want happiness for a year...Inherit wealth
If you want happiness for a lifetime...LEARN TO LOVE WHAT YOU DO.
(Quotes referred from the book- "Management Thoughts for the Family" by Pramod Batra and Vijay Batra)
The above excerpt talks so rightly about true happiness/success lesson out of life. This is something thats applicable for any kind of work that exists in this world. Software testing is no different. Consider the situations-
- A tester is struck with a bug that is not reproducible at all the instances. In order to reproduce the bug he goes through the whole series of steps again and again. A passionate tester in this situation will persevere to find a better alternative and a non-passionate tester is most likely to crib his job.
- As part of a daily routine, a tester has been asked to collect data about test cases executed, bugs logged, etc. A passionate tester will consider this as an integral part of his job and will strive to understand the context and provide as much information as possible to assist with decision making. A non-passionate tester will barely provide the asked information and as usual blame the world for making him do a silly job.
- After discovering a defect, a tester is supposed to write steps to recreate the defect. A Passionate tester will write the steps in such a way to sell his defect and strive to be perfect at Bug advocacy. A non-passionate tester will take this as just another routine job and is most likely to make more mistakes in reporting the defects. (i don’t mean to say that Passionate testers don’t do any mistakes)
- A tester is asked to take handle multiple things. Mostly in the projects when different phases of project life cycle overlaps (e.g. Test case creation overlaps with actual testing of the project), a tester is required to do multiple things at once i.e. test case creation, testing the software, documenting results etc. all at the same time. Passionate testers see this as an opportunity to excel and demonstrate desire for responsibility by effectively managing time and efforts.
- Tester A comes into work and constantly gives suggestions to improve the status quo. Tester B comes into work and just do what he/she is asked to do. No prizes for guessing which tester loves his/her work more than the other.
- A tester gets promoted to a Test leader. Considering that he/she would have ideally tested for past 5-6 or more or less years,he/she starts showing no inclination towards hands-on considering hands-on testing is supposed to be done by Engineers and not leads! Such a situation is very much prevalent in Software testing fraternity. A passionate tester would never lay his hands off testing. He/She will be always on the look out of extra-ordinary, unknown bugs no matter what designation he/she holds.
Such situations and many many other situations clearly demarcate a passionate tester with a non-passionate one i.e. the one who loves his/her job vs. the one who doesn’t.
Passionate testers always have something unique to offer and that may be in terms of their thought process, the way they carry the day-to-day work, their outputs, efficiency, the way they give suggestions and improve things around them tirelessly. Passionate testers are never satisfied with what they achieve and always strive to find unimaginable bugs of high value and priority.
There is only one way out- Love your job or find something that you love doing and happiness/success will be all yours.
Keep testing passionately!
Friday, September 28, 2007
Being creative...
Oxford dictionary defines "Creative" as "bring into existence".One of the quotes that has bowled me over completely goes as follows-
"Life is beautiful because you can always do something you have never done before".
This quote brings a unique kind of freshness and hope. Doesnt that make us ponder that- Creativity is indeed an essence of life. From ancient times till now the tremendous progress made by mankind can be attributed to this one trait- "Creativity".
Software testing is a fairly new profession. Is this profession at par with innovations that are happening in other engineering fields ? Consider this-
Why arent we not consistent in finding all the bugs in earlier stages of life cycle ?
Why do we still miss bugs during the testing phase ?
Why do customers still find major bugs even though the product is tested ?
Why arent we consistently able to gain considerable ROI from automation tools ?
Why does testing take a long time ?
Why arent we consistently able to deliver on time ?
These are some of the questions that i have found tough to answer based on experiences that i have gone through. Though these may seem too big a problems with any project but i feel that the solution to these (and may more problems like these) lies in finding imaginative and creative ways and not in trying the age old ways and getting the same results all the time. Being creative helps...and thats the essence of Software testing too.
Keep testing creatively!
"Life is beautiful because you can always do something you have never done before".
This quote brings a unique kind of freshness and hope. Doesnt that make us ponder that- Creativity is indeed an essence of life. From ancient times till now the tremendous progress made by mankind can be attributed to this one trait- "Creativity".
Software testing is a fairly new profession. Is this profession at par with innovations that are happening in other engineering fields ? Consider this-
Why arent we not consistent in finding all the bugs in earlier stages of life cycle ?
Why do we still miss bugs during the testing phase ?
Why do customers still find major bugs even though the product is tested ?
Why arent we consistently able to gain considerable ROI from automation tools ?
Why does testing take a long time ?
Why arent we consistently able to deliver on time ?
These are some of the questions that i have found tough to answer based on experiences that i have gone through. Though these may seem too big a problems with any project but i feel that the solution to these (and may more problems like these) lies in finding imaginative and creative ways and not in trying the age old ways and getting the same results all the time. Being creative helps...and thats the essence of Software testing too.
Keep testing creatively!
Thursday, September 27, 2007
My first post
I have been a Software testing professional for quite some time now (do not really want to quantify time in years or hours :-)). All the while i spent in this profession, i have always beleived in sharing knowledge as a means to grow as a professional and participating in this wonderful profession. Earlier in my career and even now, i have been involved in sharing knowledge by writing articles or presenting in various conferences. Somehow, i never really got into blogging. Of late, i have been following some great blogspots by James Bach, Google testing blog, Shrini Kulkarni, Debasis Pradhan and many many more. All these blogs are extremely useful sources of valuable professional information and one striking point is that each of these has a unique value to offer based on tester's experience. This is something fantastic and here i am writing my first blog with only intention to sharing my experience in this field and do my little to enhance this profession.
Thought its appropriate to start my first blog with the looks for first computer bug. have a look-
http://en.wikipedia.org/wiki/Image:H96566k.jpg
Wanna find more like these...Keep testing passionately!
Thought its appropriate to start my first blog with the looks for first computer bug. have a look-
http://en.wikipedia.org/wiki/Image:H96566k.jpg
Wanna find more like these...Keep testing passionately!
Subscribe to:
Posts (Atom)
