I took part in James Bach's Testing Challenge at Weekend Testing recently. Pradeep Soundararajan reviewed my report and spoke about the gaps in my testing effort as well as the report. As always, I revisited my report to figure out areas that need improvement(read dismal performance report). One of the key problems with my report was that - I did not question the mission that was given to me. I did skype James before the testing session with a few questions that were either too broad or too open ended. James did help me by rephrasing a few questions. However, I did not use this opportunity to its fullest potential.
A little while later, Jonathan Bach & James Bach tweeted on Traps in testing
JBTestPilot: The #1 trap that testers fall into when I ask them to test something: They start testing'.
CuriousTester: I am trapped! din't see testing without questioning as a trap! Traps work that way. This is more often than I would wish to get trapped!
JBTestPilot: No worries... there are many ways out of traps. The trick is, knowing you're IN one.
JamesMarcusBach: Good testing is a questioning process. All tests are questions. But some things are better asked of humans.
Here I am inflicted with lack of good questioning skills. I did not worry much about it until it started affecting my ability to test better. Now you ask ‘Do you mean you never questioned till date?’. Of course, I did. They did not seem to add value to what I already do. They did not appear to bring in new ideas. In short, I am not skilled at questioning yet.
[ Tester ] - [ Questioning Skills ] = [ Unskilled Testing ]
I am wondering why questioning is not in my DNA. Is it really in my DNA and I am unaware? I grew up as an obedient child. I don’t remember saying ‘No’ to my parents, no matter what I was told to do - a very big claim indeed (grins). When I say as a child, I mean the period from which I remember the events of my life to a considerable extent. Being obedient, not breaking the rules, not being demanding and many more blocked my ability to question since childhood.
In general, questions are not encouraged in India (I think so). They are seen as a symbol of revolt. Questions from elders are reprimanded and questions from children are snubbed. Children are taught to be obedient without questioning. If they break the rules, they will be punished. Yes, child beating is quite normal and not violent. Actually, its not even violent as it sounds to you as you read this. A 911 type helpline may flop here. Growing amidst a culture where questioning is a taboo could be one reason why I am not good at it.
Every question adds a new dimension to better understanding through answers. Yet, we don’t question. The sad part is most of us don’t question because we don’t know that we can question. We have the liberty to question, but we don’t.
Question what? Question your product, question your testing mission, question your test strategies question your deliverables. Question anything that you think will make a difference to what you do. Some people are good at questioning and a few others are not so good. The good news is that this skill can be inculcated with constant practice by one and all. It can be honed over a period of time.
Practice questioning skills with your programmers/team members. Play games that help improve your questioning skills. Play Twenty questions game. Playing Dumb Charades might be of great help too. Ask the right questions. To ask the right questions, you will need to ask many wrong questions and learn from them. Open ended questions may be too broad. Close ended questions may be too vague. Probing questions focus on specific areas (can be open or close ended) and are very useful. A good mix of above three types of questions will improve questioning skills. Note taking if coupled with Questioning is a powerful tool for testing.
Wishing You a Prosperous & Happy New Year 2010!
Addendum on 30th April 2010
One way to practice questioning skills is using Q-Patterns by Vipul Kocher.
P.S: The title of this post is inspired by Rahul Mirakhur who made a mention of 'Questioning in your DNA' during one of our informal talks.
Happy Questioning,
Parimala Shankaraiah
30 December, 2009
19 December, 2009
Easter Eggs in Software
Easter eggs are specially decorated eggs given to celebrate the Easter holiday. These eggs are often hidden, allegedly by the Easter Bunny, for children to find on Easter morning as per Wikipedia.
Easter Eggs in software refer to hidden features in the program that are intentionally injected into the product by the programmer. These may include hidden commands, animations, funny jokes, games, credits for programmers who built the product etc. The programmers of easter eggs do it for their own personal reasons or for entertainment and are not meant to be harmful. If the programmer intentionally added malicious code to behave as a virus/spam/trojan, it may not be an easter egg. However, if the programmer added some code to behave as an easter egg that accidentally turned out to be harmful, it is still an easter egg.
How to unearth easter eggs?
Programmers Names
Search for the names of programmers who built the product. These are a very common form of easter eggs. These references mean that a few programmers wanted to take credit for the work done by them and inserted their names into the code without the knowledge of the management. More often, programmers resort to this method due to lack of appreciation for their work by the management.
Guidewords
Looking for swear words or expletives helps discover easter eggs. Dissatisfied/disgruntled/quitting employees may add these words in the code to take revenge on people they disliked or hated. I once saw a line reading ‘Thomas is a fool’ as part of a code snippet in one of the products that I tested a few years ago (No offense to Thomas here!).
Personalized images/animations
A few programmers embed their favorite images or animation in the code as they find themselves emotionally bound to the images/animations as much as the code that was written. For eg, a programmer might include icon images to include one of his favorite picture or a scenery.
Magical Keystrokes
A few easter eggs can be found by pressing a magical key combination/shortcut keys on the keyboard. These may be discovered accidentally or based on the knowledge of similar easter eggs in previous versions of the product.
Clusters of Easter Eggs
If an easter egg of any one type as described above was found, there is a high possibility of many more being found in close proximity to the already found egg. Pattern matching with previously found easter eggs helps find a few more surrounding them.
Read the code
Reading the code completely is one of the ways of looking for any unusual code that does not fall in line with the actual code in the product. Any code that is not in sync with the rest of the code may be easter eggs.
Ask the programmers
One of the fastest ways of finding most easter eggs is to ask the programmers themselves about what kind of easter eggs have been injected into the code. Not all programmers would reveal about all the easter eggs. A few of them might reveal theirs, but may not know about other programmers easter eggs. Some of them might be tightlipped to talk about easter eggs for fear of being fired or disciplined by the management.
Easter eggs by definition cause no harm by hiding inside the product. However, If the customers find easter eggs in the production environment, it could raise doubts about the kind of testing done on the product by the testers. The companies become liable for any offensive or illegal content that is shipped in the product and may face legal consequences. It is therefore very important to test for easter eggs as part of the normal testing process to avoid embarrassing situations after the product is shipped to the customer.
Start looking for Easter Eggs – in your software,
Happy Testing,
Parimala Shankaraiah
Easter Eggs in software refer to hidden features in the program that are intentionally injected into the product by the programmer. These may include hidden commands, animations, funny jokes, games, credits for programmers who built the product etc. The programmers of easter eggs do it for their own personal reasons or for entertainment and are not meant to be harmful. If the programmer intentionally added malicious code to behave as a virus/spam/trojan, it may not be an easter egg. However, if the programmer added some code to behave as an easter egg that accidentally turned out to be harmful, it is still an easter egg.
How to unearth easter eggs?
Programmers Names
Search for the names of programmers who built the product. These are a very common form of easter eggs. These references mean that a few programmers wanted to take credit for the work done by them and inserted their names into the code without the knowledge of the management. More often, programmers resort to this method due to lack of appreciation for their work by the management.
Guidewords
Looking for swear words or expletives helps discover easter eggs. Dissatisfied/disgruntled/quitting employees may add these words in the code to take revenge on people they disliked or hated. I once saw a line reading ‘Thomas is a fool’ as part of a code snippet in one of the products that I tested a few years ago (No offense to Thomas here!).
Personalized images/animations
A few programmers embed their favorite images or animation in the code as they find themselves emotionally bound to the images/animations as much as the code that was written. For eg, a programmer might include icon images to include one of his favorite picture or a scenery.
Magical Keystrokes
A few easter eggs can be found by pressing a magical key combination/shortcut keys on the keyboard. These may be discovered accidentally or based on the knowledge of similar easter eggs in previous versions of the product.
Clusters of Easter Eggs
If an easter egg of any one type as described above was found, there is a high possibility of many more being found in close proximity to the already found egg. Pattern matching with previously found easter eggs helps find a few more surrounding them.
Read the code
Reading the code completely is one of the ways of looking for any unusual code that does not fall in line with the actual code in the product. Any code that is not in sync with the rest of the code may be easter eggs.
Ask the programmers
One of the fastest ways of finding most easter eggs is to ask the programmers themselves about what kind of easter eggs have been injected into the code. Not all programmers would reveal about all the easter eggs. A few of them might reveal theirs, but may not know about other programmers easter eggs. Some of them might be tightlipped to talk about easter eggs for fear of being fired or disciplined by the management.
Easter eggs by definition cause no harm by hiding inside the product. However, If the customers find easter eggs in the production environment, it could raise doubts about the kind of testing done on the product by the testers. The companies become liable for any offensive or illegal content that is shipped in the product and may face legal consequences. It is therefore very important to test for easter eggs as part of the normal testing process to avoid embarrassing situations after the product is shipped to the customer.
Start looking for Easter Eggs – in your software,
Happy Testing,
Parimala Shankaraiah
07 December, 2009
Book Review: I am a Bug
I am a Bug is a book written by Robert Sabourin. This is a short book illustrated by his daughter Catherine which explains the software development process using cartoons and live examples from real time projects.
Little Nuggets from the book
1. When a bug is found, we do not ask if the bug is good or bad. We decide if it is important. We guess how much damage it could cause.
2. When we rush too much making new software, our offices and programs can get pretty messed up. We know there will be a lot of bugs!
3. Some bugs have many brothers and sisters (Bug clusters).
4. Bugs much worse than buffer overflows would just walk right by! (Inattentinal Blindness).
5. Some bugs are good friends! (Deferred bugs). A friendly bug is a bug that does not stop users from enjoying and benefiting from the software.
6. If we use the program in a different way, we will avoid some bugs completely (Change in perception).
7. Bugs can be fixed, avoided, or ignored. If a bug won't be fixed, users can be encouraged to use the software in a way that avoids the bug (Workarounds).
8. Sometimes we find bugs a long time after people start to use the program (Sleeping bugs).
9. Salespeople from tool vendors sometimes misrepresent the costs and benefits of tools and their ease of use. For example, they may claim that a test automation tool that can capture actions and play them back will "solve all your problems". They'll say, "Take this tool, and you can write a program that will find all your bugs."
Testers vs. Frogs
1. Frogs like bugs! People, at work, think positively about bugs. We like to find bugs!
2. Frogs eat bugs!
a. When we find bugs we really, really, really like to fix them!!
b. Whether or not a given bug should be fixed depends upon the business context.
c. Just as the frog's stomach can only contain a finite amount of bugs, a development team doesn't usually have the time, effort, and money to fix all of the bugs found in a program.
d. Bug priority and severity need to be established based on a cost/benefit analysis to figure out which bugs are worth fixing. The costs of not fixing a bug can be the damage to a user's computer, the number of support calls generated by a bug, damage to a company's reputation, and so on.
e. Just a few of the potential drawbacks of fixing a bug are the danger of injecting or uncovering more bugs, the developer time and effort spent, and the chance of decreasing adherence to quality goals for availability, performance, etc.
3. Bugs try to avoid frogs - Naturally, when we try to fix a bug, it tries to avoid us!
4. Getting lots of frogs (Crowdsourcing) can help get rid of lots of bugs. Once we decided to get lots of people to help us find and correct all the bugs. but too many frogs in the same place are a big problem too!!! But that didn't help because we got mixed up and confused.
5. How did we catch it? Is it important? Can it hurt us?
6. Quick patches don't solve problems. Fix it right the first time!
7. Think about how the program will be used. The exact same program can be used by many different people in many different ways, and a bug that is a dealbreaker for one user community may be inconsequential to another.
a. This is why I want everyone on a project or specific task within a project to have a common notion about what the answer to the fundamental question is. This way everyone knows what her role in the completion of the task is.
As testers, we are emotionally bound to every single bug that we report to the development. We expect that every bug be fixed in the immediate next build. In reality, it is very hard to fix all the bugs. Any business context demands that a product be released in the quickest time possible, within budget and on schedule. As a result, it is important to realize which bug is important and which is not. Testers are not decision makers, they are information providers. Let the decision makers decide which bug to fix. This book highlights the importance of bugs and the prioritization of fixes for the important bugs. I have documented important points from the book in the ‘Pearls of Wisdom’ section. Do take a look if that helps. Rob Sabourin has been generous to provide a FREE online version of this book on his website Amibug.com.
Happy Reading,
Parimala Shankaraiah
Little Nuggets from the book
1. When a bug is found, we do not ask if the bug is good or bad. We decide if it is important. We guess how much damage it could cause.
2. When we rush too much making new software, our offices and programs can get pretty messed up. We know there will be a lot of bugs!
3. Some bugs have many brothers and sisters (Bug clusters).
4. Bugs much worse than buffer overflows would just walk right by! (Inattentinal Blindness).
5. Some bugs are good friends! (Deferred bugs). A friendly bug is a bug that does not stop users from enjoying and benefiting from the software.
6. If we use the program in a different way, we will avoid some bugs completely (Change in perception).
7. Bugs can be fixed, avoided, or ignored. If a bug won't be fixed, users can be encouraged to use the software in a way that avoids the bug (Workarounds).
8. Sometimes we find bugs a long time after people start to use the program (Sleeping bugs).
9. Salespeople from tool vendors sometimes misrepresent the costs and benefits of tools and their ease of use. For example, they may claim that a test automation tool that can capture actions and play them back will "solve all your problems". They'll say, "Take this tool, and you can write a program that will find all your bugs."
Testers vs. Frogs
1. Frogs like bugs! People, at work, think positively about bugs. We like to find bugs!
2. Frogs eat bugs!
a. When we find bugs we really, really, really like to fix them!!
b. Whether or not a given bug should be fixed depends upon the business context.
c. Just as the frog's stomach can only contain a finite amount of bugs, a development team doesn't usually have the time, effort, and money to fix all of the bugs found in a program.
d. Bug priority and severity need to be established based on a cost/benefit analysis to figure out which bugs are worth fixing. The costs of not fixing a bug can be the damage to a user's computer, the number of support calls generated by a bug, damage to a company's reputation, and so on.
e. Just a few of the potential drawbacks of fixing a bug are the danger of injecting or uncovering more bugs, the developer time and effort spent, and the chance of decreasing adherence to quality goals for availability, performance, etc.
3. Bugs try to avoid frogs - Naturally, when we try to fix a bug, it tries to avoid us!
4. Getting lots of frogs (Crowdsourcing) can help get rid of lots of bugs. Once we decided to get lots of people to help us find and correct all the bugs. but too many frogs in the same place are a big problem too!!! But that didn't help because we got mixed up and confused.
5. How did we catch it? Is it important? Can it hurt us?
6. Quick patches don't solve problems. Fix it right the first time!
7. Think about how the program will be used. The exact same program can be used by many different people in many different ways, and a bug that is a dealbreaker for one user community may be inconsequential to another.
a. This is why I want everyone on a project or specific task within a project to have a common notion about what the answer to the fundamental question is. This way everyone knows what her role in the completion of the task is.
As testers, we are emotionally bound to every single bug that we report to the development. We expect that every bug be fixed in the immediate next build. In reality, it is very hard to fix all the bugs. Any business context demands that a product be released in the quickest time possible, within budget and on schedule. As a result, it is important to realize which bug is important and which is not. Testers are not decision makers, they are information providers. Let the decision makers decide which bug to fix. This book highlights the importance of bugs and the prioritization of fixes for the important bugs. I have documented important points from the book in the ‘Pearls of Wisdom’ section. Do take a look if that helps. Rob Sabourin has been generous to provide a FREE online version of this book on his website Amibug.com.
Happy Reading,
Parimala Shankaraiah
03 December, 2009
Claims Testing
What is a Claim?
A claim can be anything that someone in the company says about the product. It could be requirements, online help, sales/marketing material, Advertisements on different media or even word of mouth blabbering along the hallway by a project manager to the stakeholder.
Claims can be classified into two categories. ‘Explicit’ claims are the claims that are explicitly stated. ‘Implicit’ claims are not stated explicitly, but imply something. It is important to analyze all the individual claims and clarify vague claims. Every claim about the product needs to be verified. In reality, most of the time goes in testing the product that there is hardly any time left to test the claims. I am forced to think that most projects do not see the light of the day when it comes to claims testing, usability testing and performance testing. If the context does not demand these, so be it. Is the customer Ok with this is the question?
Application to Test
Tux Paint is a free, award-winning drawing program for children ages 3 to 12 (for example, preschool and K-6). It combines an easy-to-use interface, fun sound effects, and an encouraging cartoon mascot who guides children as they use the program. Kids are presented with a blank canvas and a variety of drawing tools to help them be creative.
Mission
Test the claims made in Tux Paint application
Sue-ability
In my experience so far, the Sales/Marketing professionals handling product demos make a few fake promises to the customers about some features and then rush back to the engineering team to create that feature from scratch. So these folks claimed that the feature that the customer is interested in is indeed present in the product while it is not! Wow. What a Claim! I have seen this happen in a few projects where the sales guys come running to the Product Management team t(y)elling ‘I have told the customer that this is supported. You develop it now’ kind of a statement. What if the customer sues the organization on this basis?
There are hardly any projects where claims made by the product/people are tested. Moreover, it is hard to track what each and every person in the project is claiming about the product. Hence, there is a strong need to educate the entire project team to the pitfalls of false claims within and outside the organization. If the organization does not educate you, you educate yourself! Claim the Truth.
Click HERE for the SBMT Report on Tux Paint.
Happy Claiming,
Parimala Shankaraiah
Addendum on 18th November 2011
Mindmap for Claims Testing is found HERE
A claim can be anything that someone in the company says about the product. It could be requirements, online help, sales/marketing material, Advertisements on different media or even word of mouth blabbering along the hallway by a project manager to the stakeholder.
Claims can be classified into two categories. ‘Explicit’ claims are the claims that are explicitly stated. ‘Implicit’ claims are not stated explicitly, but imply something. It is important to analyze all the individual claims and clarify vague claims. Every claim about the product needs to be verified. In reality, most of the time goes in testing the product that there is hardly any time left to test the claims. I am forced to think that most projects do not see the light of the day when it comes to claims testing, usability testing and performance testing. If the context does not demand these, so be it. Is the customer Ok with this is the question?
Application to Test
Tux Paint is a free, award-winning drawing program for children ages 3 to 12 (for example, preschool and K-6). It combines an easy-to-use interface, fun sound effects, and an encouraging cartoon mascot who guides children as they use the program. Kids are presented with a blank canvas and a variety of drawing tools to help them be creative.
Mission
Test the claims made in Tux Paint application
Sue-ability
In my experience so far, the Sales/Marketing professionals handling product demos make a few fake promises to the customers about some features and then rush back to the engineering team to create that feature from scratch. So these folks claimed that the feature that the customer is interested in is indeed present in the product while it is not! Wow. What a Claim! I have seen this happen in a few projects where the sales guys come running to the Product Management team t(y)elling ‘I have told the customer that this is supported. You develop it now’ kind of a statement. What if the customer sues the organization on this basis?
There are hardly any projects where claims made by the product/people are tested. Moreover, it is hard to track what each and every person in the project is claiming about the product. Hence, there is a strong need to educate the entire project team to the pitfalls of false claims within and outside the organization. If the organization does not educate you, you educate yourself! Claim the Truth.
Click HERE for the SBMT Report on Tux Paint.
Happy Claiming,
Parimala Shankaraiah
Addendum on 18th November 2011
Mindmap for Claims Testing is found HERE
22 November, 2009
Software Testing Conference 2009
The 9th Annual International Software Testing Conference 2009 in India was held at Hotel Le Meridian, Bangalore on 19th and 20th November 2009. This was my first time at a software testing conference. Naturally, I was thrilled.
Conference Highlights
Exploring Testing Leadership
The Conference kick started with Michael Bolton. Michael spoke about ‘Exploring Testing Leadership’ which is the need of the hour in India. Testing provides quality related information to make informed decisions. It is the leadership who assures quality. Michael focused on how the leadership needs to change its mindset towards exploratory testing and its benefits. As always, Michael left the audience spell bound. Great start to a great conference.
Weekend Testers – Test, Learn and Contribute
Weekend Testers is a peer testing group that started on 1st August 2009 in Bangalore. This group is a common practice ground for freshers and junior testers now. Till Date, the group has successfully run 15 weekend testing sessions for the benefit of the testing community. Ajay Balamurugadas, one of the key initiators of Weekend Testers group delivered an electrifying speech on how this group was formed, how many open source products have been tested so far and the future roadmap. This presentation received a standing ovation from Michael Bolton, Pradeep Soundararajan, Shrini Kulkarni, Dr. Meeta Prakash, Rahul Mirakhur, myself and many others seated in the hall. During later part of the day, Michael was kind enough to mention that Weekend Testers was one of his best presentations in any testing conference ever. Pradeep Soundararajan has been quietly mentoring Weekend Testers from the time of its inception. This success is owed to him and to all the participants of Weekend Testers who have made it a grand success.
Exploratory Testing – The Steroid of Testing
Shaham Yusuf from Deloitte Consulting presented Exploratory Testing – The Steroid of Testing. Shaham went on to show how he made the shift from scripted approach to exploratory approach to provide quality information about the product to the management. He also mentioned about the support he received from the management. How lucky? Or should I say that is lot of hard work. Shaham’s experience report received rebuke from a few scripted testers who asked a lot of questions which Shaham answered very elegantly.
Meetup with Testers
I was thrilled to meet Shrini Kulkarni after the keynote sessions. His energy and willingness to talk was amusing. We discussed a bit about exploratory testing and how scripted testers see ET more as a threat and less as a complimentary approach. He also asked me about my writing challenges. I was glad to know that he reads my blog because he spoke quite a lot about my post on writing.
Pradeep Soundararajan was there wherever there was a false claim related to testing. He was in his usual best to question and it was fun to watch him. Pradeep’s joy knew no bounds when he witnessed the response to Weekend Testers presentation. He also introduced me to a few testers like Tarik Sheth and Shaham Yusuf in later part of the day. It was fun discussing about the topics in the conference. It was also fun to see his bag carry a paper badge saying 'I don't support Certifications'.
Rahul Mirakhur is a geeky tester specialized in Apple Macintosh. I have known him from my previous company, but he got to know me at the RST workshop the previous day. Though Rahul is the Director of QA in the company he works for, he still tests the products like any other tester. I had very good discussions with him spanning Team egos, Software Testing, Audio books, BBST and weekend testing sessions. He is a very good listener and a good mentor. I want to meet more and more testers in India who choose testing over managerial roles. It is so sad to see that most testers here are merely interested in designations and managerial roles than actual testing. That way, Rahul is very encouraging.
Dr. Meeta Prakash is the first woman tester in India with a PhD in Software Testability. She is also one of the first woman bloggers in India. As a woman myself, I look for the firsts’ in Indian woman because it very hard for a lot of woman to come out of the social dogma and make a mark in their professional lives. It’s good that times are changing for the good. I met Dr. Meeta at the RST workshop. We met again at the conference where we spoke about testing, blogging, discussed about certifications. When I asked her about certifications, she said that she did not have any and did not believe in them. To her surprise, there was an annoucement that she had to distribute prizes to the toppers in CSTE in 2009! Rahul and I had a good laugh while she was annoyed. Dr. Meeta helped Weekend Testers by suggesting a lot of improvements in the regional qualifying rounds and fine tuning the presentation for the conference. I am bowled over by her humble nature and willingness to help upcoming testers.
I also met Allmas Mullah, Govindaraja Gupta, Sathya Thambuswamy, Satabdi Roy, Sheeba Elizabeth Ninan, Subramanya Gupta Boda and many others at the conference. Like I mentioned earlier, the participants at the workshop and the conference represented organizations, backgrounds, cultures that were unique in their own sense. It was superb to learn about testing in such a diversified setting.
What I disliked about the conference?
The first day went awry with Bangalore traffic playing a demon to the conference attendees. Couple keynote speakers got delayed and a few sessions were shuffled. This directly had an impact on the Q & A session after every presentation. A lot of good questions got missed because the organizers shooed away most of the questions.
Most fruitful discussions happened outside the sessions with testers and managers from different organizations. This also meant skipping the presentations in the conference. Maybe, this is the way it works in most conferences. This tells me I need to attend more conferences in and outside India. I need to work on being a presenter than an attendee.
A few presentations were so boring that it just went over my head. I also thought that many people like you and I could present better than some of these presenters. When I told this to Pradeep, he said 'There will be more people who feel the same when you are presenting right up there'. It’s human, Isn't it?
Time for Reflection
I was left with mixed feelings about the conference. On one side, there were many presentations that were designed around buzzwords like Agile development, Cloud Computing and tons of automation tools. On the other side, there were people who talked about predictability models which help in predicting the number of test cases and the number of defects in the software. I was shocked by this particular presentation where the speaker went on to say that the defects and test cases could be predicted and the testers would achieve these targets. What crap!
Overall, given that Indian testing industry is tightly focused on scripted approaches to testing and 100% automation dreams, it was no surprise that the conference focused more and more about these and less about exploratory testing. Nevertheless, it was a good learning experience for me.
October 2009 and November 2009 have been the most hectic times in my life. These are also times where I have learned a lot of different things. BBST, RST, STC 2009 – great experiences. It’s time to put my learning’s to use. It’s time to test better than ever.
Happy Testing,
Parimala Shankaraiah
Conference Highlights
Exploring Testing Leadership
The Conference kick started with Michael Bolton. Michael spoke about ‘Exploring Testing Leadership’ which is the need of the hour in India. Testing provides quality related information to make informed decisions. It is the leadership who assures quality. Michael focused on how the leadership needs to change its mindset towards exploratory testing and its benefits. As always, Michael left the audience spell bound. Great start to a great conference.
Weekend Testers – Test, Learn and Contribute
Weekend Testers is a peer testing group that started on 1st August 2009 in Bangalore. This group is a common practice ground for freshers and junior testers now. Till Date, the group has successfully run 15 weekend testing sessions for the benefit of the testing community. Ajay Balamurugadas, one of the key initiators of Weekend Testers group delivered an electrifying speech on how this group was formed, how many open source products have been tested so far and the future roadmap. This presentation received a standing ovation from Michael Bolton, Pradeep Soundararajan, Shrini Kulkarni, Dr. Meeta Prakash, Rahul Mirakhur, myself and many others seated in the hall. During later part of the day, Michael was kind enough to mention that Weekend Testers was one of his best presentations in any testing conference ever. Pradeep Soundararajan has been quietly mentoring Weekend Testers from the time of its inception. This success is owed to him and to all the participants of Weekend Testers who have made it a grand success.
Exploratory Testing – The Steroid of Testing
Shaham Yusuf from Deloitte Consulting presented Exploratory Testing – The Steroid of Testing. Shaham went on to show how he made the shift from scripted approach to exploratory approach to provide quality information about the product to the management. He also mentioned about the support he received from the management. How lucky? Or should I say that is lot of hard work. Shaham’s experience report received rebuke from a few scripted testers who asked a lot of questions which Shaham answered very elegantly.
Meetup with Testers
I was thrilled to meet Shrini Kulkarni after the keynote sessions. His energy and willingness to talk was amusing. We discussed a bit about exploratory testing and how scripted testers see ET more as a threat and less as a complimentary approach. He also asked me about my writing challenges. I was glad to know that he reads my blog because he spoke quite a lot about my post on writing.
Pradeep Soundararajan was there wherever there was a false claim related to testing. He was in his usual best to question and it was fun to watch him. Pradeep’s joy knew no bounds when he witnessed the response to Weekend Testers presentation. He also introduced me to a few testers like Tarik Sheth and Shaham Yusuf in later part of the day. It was fun discussing about the topics in the conference. It was also fun to see his bag carry a paper badge saying 'I don't support Certifications'.
Rahul Mirakhur is a geeky tester specialized in Apple Macintosh. I have known him from my previous company, but he got to know me at the RST workshop the previous day. Though Rahul is the Director of QA in the company he works for, he still tests the products like any other tester. I had very good discussions with him spanning Team egos, Software Testing, Audio books, BBST and weekend testing sessions. He is a very good listener and a good mentor. I want to meet more and more testers in India who choose testing over managerial roles. It is so sad to see that most testers here are merely interested in designations and managerial roles than actual testing. That way, Rahul is very encouraging.
Dr. Meeta Prakash is the first woman tester in India with a PhD in Software Testability. She is also one of the first woman bloggers in India. As a woman myself, I look for the firsts’ in Indian woman because it very hard for a lot of woman to come out of the social dogma and make a mark in their professional lives. It’s good that times are changing for the good. I met Dr. Meeta at the RST workshop. We met again at the conference where we spoke about testing, blogging, discussed about certifications. When I asked her about certifications, she said that she did not have any and did not believe in them. To her surprise, there was an annoucement that she had to distribute prizes to the toppers in CSTE in 2009! Rahul and I had a good laugh while she was annoyed. Dr. Meeta helped Weekend Testers by suggesting a lot of improvements in the regional qualifying rounds and fine tuning the presentation for the conference. I am bowled over by her humble nature and willingness to help upcoming testers.
I also met Allmas Mullah, Govindaraja Gupta, Sathya Thambuswamy, Satabdi Roy, Sheeba Elizabeth Ninan, Subramanya Gupta Boda and many others at the conference. Like I mentioned earlier, the participants at the workshop and the conference represented organizations, backgrounds, cultures that were unique in their own sense. It was superb to learn about testing in such a diversified setting.
What I disliked about the conference?
The first day went awry with Bangalore traffic playing a demon to the conference attendees. Couple keynote speakers got delayed and a few sessions were shuffled. This directly had an impact on the Q & A session after every presentation. A lot of good questions got missed because the organizers shooed away most of the questions.
Most fruitful discussions happened outside the sessions with testers and managers from different organizations. This also meant skipping the presentations in the conference. Maybe, this is the way it works in most conferences. This tells me I need to attend more conferences in and outside India. I need to work on being a presenter than an attendee.
A few presentations were so boring that it just went over my head. I also thought that many people like you and I could present better than some of these presenters. When I told this to Pradeep, he said 'There will be more people who feel the same when you are presenting right up there'. It’s human, Isn't it?
Time for Reflection
I was left with mixed feelings about the conference. On one side, there were many presentations that were designed around buzzwords like Agile development, Cloud Computing and tons of automation tools. On the other side, there were people who talked about predictability models which help in predicting the number of test cases and the number of defects in the software. I was shocked by this particular presentation where the speaker went on to say that the defects and test cases could be predicted and the testers would achieve these targets. What crap!
Overall, given that Indian testing industry is tightly focused on scripted approaches to testing and 100% automation dreams, it was no surprise that the conference focused more and more about these and less about exploratory testing. Nevertheless, it was a good learning experience for me.
October 2009 and November 2009 have been the most hectic times in my life. These are also times where I have learned a lot of different things. BBST, RST, STC 2009 – great experiences. It’s time to put my learning’s to use. It’s time to test better than ever.
Happy Testing,
Parimala Shankaraiah
20 November, 2009
Michael Bolton – The Magician Tester – Rapid Software Testing Workshop
A couple of months ago, I was keeping my fingers crossed that Michael Bolton should make it to the STC 2009 Conference in Bangalore which also meant there were chances of his workshop in Bangalore. This is the first time I attended Michael Bolton’s Rapid Software Testing (RST) workshop at Bangalore on 17th and 18th Nov 2009.
I hated magic until I attended RST workshop. Michael stated ‘Magic fools people, so do bugs’. How about learning the tricks of magic (bugs) and stop getting fooled?
Debunking Magic Tricks from RST Workshop
1. Focus on the states of the product under test
2. Watch out for the change in states
3. Look for distractions while the changes happen
4. Observe the sequences
5. Believe that magic (bug) does not exist
6. Search for backdoor entry (Sneak in)
7. Turn on the lights
8. Record and watch in slow motion
9. Distract the magician (programmer)
10. Inject yourself into the process
11. Ask the magician (programmer)
12. Read a book
13. Search on the internet
14. Share the problem
15. Use visual, auditory and tactile skills
16. Take notes – Whoever takes notes controls history (Don’t know whose quote this is)
17. Ask questions
18. You may be right about bugs. But, let the product owner decide
19. Get around the constraints while testing
20. Critical Thinking (huh?, Really?, So? by James Bach)
21. Learn to make snap judgments
22. A visible bug is just the tip of an iceberg. Don’t rest until you find the iceberg
23. Don’t mind a bug if you know that it is not the tip of the iceberg
24. When you don’t know about something, you feel the pain. Get over the pain and learn about it.
25. Break the rules
Rapid Software Testing Workshop
Rapid Software Testing (RST) workshop is very experiential in nature with a good mix of testing exercises, puzzles, magic tricks and games. The workshop consisted of testers, leads, managers, senior managers, directors, development managers and independent consultants. It was a good mix of people from different domains which provided a great platform for discussion about different challenges faced in testing. RST is a once in a lifetime experience. If you have missed it this time, don't let it happen again. Wait for Michael to come back again.
Michael Bolton
Meeting Michael Bolton is one of the most special moments in my life. I have been following his teachings and writings for almost a year now. Talking to Michael in person was mind boggling. It was very startling to see an expert tester like him being so down to earth and open to listening and learning about new ideas. Michael was also very interested in interacting with testers after the workshop and spent time discussing about testing. He also posed for a lot of photographs with tons of energy and excitement.
Guru Devo Maheshwara
I always wanted to meet Cem Kaner, Michael Bolton, James Bach, Pradeep Soundararajan and Shrini Kulkarni in person even if it was just saying ‘Hi’. I met Pradeep on 15th June 2009 - a superb moment. I met Michael at the RST Workshop on 17th November 2009 – a dream come true. I met Shrini at the STC 2009 Conference on 19th November 2009 – a big surprise. I never thought that meeting 3 of my Testing Gurus would happen so early in my life. What startles me about each of them is their humble nature and broad minded attitude to interact with, encourage and motivate thousands of testers like me. I am still waiting to meet Cem and James.
Great Learning, Great Moments!
Parimala Shankaraiah
I hated magic until I attended RST workshop. Michael stated ‘Magic fools people, so do bugs’. How about learning the tricks of magic (bugs) and stop getting fooled?
Debunking Magic Tricks from RST Workshop
1. Focus on the states of the product under test
2. Watch out for the change in states
3. Look for distractions while the changes happen
4. Observe the sequences
5. Believe that magic (bug) does not exist
6. Search for backdoor entry (Sneak in)
7. Turn on the lights
8. Record and watch in slow motion
9. Distract the magician (programmer)
10. Inject yourself into the process
11. Ask the magician (programmer)
12. Read a book
13. Search on the internet
14. Share the problem
15. Use visual, auditory and tactile skills
16. Take notes – Whoever takes notes controls history (Don’t know whose quote this is)
17. Ask questions
18. You may be right about bugs. But, let the product owner decide
19. Get around the constraints while testing
20. Critical Thinking (huh?, Really?, So? by James Bach)
21. Learn to make snap judgments
22. A visible bug is just the tip of an iceberg. Don’t rest until you find the iceberg
23. Don’t mind a bug if you know that it is not the tip of the iceberg
24. When you don’t know about something, you feel the pain. Get over the pain and learn about it.
25. Break the rules
Rapid Software Testing Workshop
Rapid Software Testing (RST) workshop is very experiential in nature with a good mix of testing exercises, puzzles, magic tricks and games. The workshop consisted of testers, leads, managers, senior managers, directors, development managers and independent consultants. It was a good mix of people from different domains which provided a great platform for discussion about different challenges faced in testing. RST is a once in a lifetime experience. If you have missed it this time, don't let it happen again. Wait for Michael to come back again.
Michael Bolton
Meeting Michael Bolton is one of the most special moments in my life. I have been following his teachings and writings for almost a year now. Talking to Michael in person was mind boggling. It was very startling to see an expert tester like him being so down to earth and open to listening and learning about new ideas. Michael was also very interested in interacting with testers after the workshop and spent time discussing about testing. He also posed for a lot of photographs with tons of energy and excitement.
Guru Devo Maheshwara
I always wanted to meet Cem Kaner, Michael Bolton, James Bach, Pradeep Soundararajan and Shrini Kulkarni in person even if it was just saying ‘Hi’. I met Pradeep on 15th June 2009 - a superb moment. I met Michael at the RST Workshop on 17th November 2009 – a dream come true. I met Shrini at the STC 2009 Conference on 19th November 2009 – a big surprise. I never thought that meeting 3 of my Testing Gurus would happen so early in my life. What startles me about each of them is their humble nature and broad minded attitude to interact with, encourage and motivate thousands of testers like me. I am still waiting to meet Cem and James.
Great Learning, Great Moments!
Parimala Shankaraiah
16 November, 2009
Black Box Software Testing Foundations Course
I just completed my BBST Foundations course. BBST Foundations course is an online course which includes a basic introduction to black box testing. Ah! An online course, 1 month duration, black box testing. Yeah, Yeah, You have heard a lot about universities offering online/distance learning courses to working professionals who are desperate for university stamped paper certificates. I just figured out this is NOT such a course.
What I learned in BBST foundations course?
Basic knowledge of Computers
Before you think that I am challenging your ego, just answer this question ‘Do you know how memory storage works in computers?’ Compare your answer with actual facts of memory storage. Do they match? Basic knowledge of memory storage in computers is essential to being a good tester. This adds to the skill set of the black box tester. BBST showed me how miserable my knowledge of the basic computers is.
Basic knowledge of Arithmetic
While working on Matt’s Testing Challenge, I was surprised to see how the number of potential test cases was arrived at. At that time, I just wondered about that magic number. I did not realize that it was simple arithmetic computation. Knowledge of basic arithmetic computations is important to find the populace of tests that need to be executed.
Self-Inflicted Captivity
In India, test cases and scenarios are written by the leads and passed on to the sub-ordinates to test without questioning (in most organizations). In simple words, the trainees, junior/senior testers would not have scripted test cases or designed test strategies until they become leads themselves. The problem with these people is that they never stepped out of this captivity like me. Now I know why I failed in Matt’s Challenge. I am not concerned about winning or failing a challenge. I am concerned about not learning from these challenges. My ex-CEO Josh Pickus once said ‘Don’t be afraid to fail. Fail. But don’t fail to learn from your failure’.
Automated Testing
I worked very little on automated testing in my first job. Later on, I learned Perl which I never used. In my current job, I hardly find enough time for manual testing; forget about automated testing. Solid excuses. The truth is I have not made a determined effort to learn and practice automated testing. I realized this gap while I was studying BBST course. There were a couple of questions that focused on test automation and I was pathetic to say the least. Testers need to have a hang of automated testing. Like Elizabeth Hendrickson tweeted recently ‘I advocate 100% of *regression* tests being automated. But no, I don't know anyone who thinks 100% of all *testing* can be auto’.
Solving Practical Problems and Investigation
A tester needs to think beyond the testing job to be a good tester. Just testing may not make anyone a good tester. Being able to learn and solve different types of problems helps think differently. Identifying and solving real time problems as simple as ‘Door Lock not working’ or ‘Your car making strange noise while driving’ gives good experience in investigation skills. Investigate Now!
Careful vs. Sloppy Reading
All of us read blogs/articles/magazines/books on the internet. How much of it we really absorb and apply to our context matters over how many of these we read. Most of us fail to see the significance of careful reading. You never know when an idea strikes while you are reading. Read carefully. Sloppy reading hardly fetches anything.
Written Communication
Some of us fail to write as well as others who are good at it. Some of us write better in native languages and get intimidated to write in English for fear of losing the right ideas during translation. What if you are expected to work in a global setup where you need to interact with testers from different parts of the world? You need to interact in English and put across your thoughts precisely. You may be saying the right thing, but you may not be clear enough in your writing. This challenge was significantly seen in the foundations course where a few of us were unable to articulate our thoughts clearly resulting in more and more clarifications during group discussions. Written communication is a key skill for a tester. Start writing your experiences. Blogging is a great way to learn about writing. Start your own blog and practice writing.
Reading about diverse topics
Being a science graduate, I found psychology books fascinating. I would read psychology text books for hours on Saturdays in my college library. This helped me be a good counselor among my friends to help with their problems (silly teen problems!). Back then, I felt very proud of this trait and I read more just for fun. Today, as a tester, I find that knowledge helping me understand the emotions of the humans much better while using the software. Read anything and everything that fascinates you. Don’t get bogged down by the fact that you can’t put what you read to immediate use. Knowledge is power. Get that power.
What I learned in BBST Foundations course does not make me a good tester overnight or over a period of few months or years. It makes me a good tester if I have assimilated what made sense to me and my context and put it to practice in my daily working life. This course clearly highlighted my strenghts and weaknesses. I need to enhance my strenghts and work on my weak areas to be a better tester.
BBST Foundations course is a MUST for all people who test and who manage people who test. It was a course of reflection for me and I am glad I took this course so early in my career. I now know where I was heading all this while and I also know where I want to be heading going forward.
BBST Foundations course emphasizes on learning through practice and experience instead of memorizing answers to objective questions like the ISTQB/CSTE/CSQA and other crappy certifications (I call them crappy because the value add after getting certified is so little). Being an online course, this is no easy one to get through. It is a well thought out and practically designed course with years of hard work, revisions and modifications. BBST does not certify that you are a good tester, it will show you different paths to be a good tester. You need to figure out which path to choose and how to make it work for your context. This course has taken me a little closer to James Bach's Personal Vision of Testing Expertise 'I can test anything under any conditions in any time frame relative to my standing in the local community, how hard I try and my technical insight'.
This course is by far one of the best learning experiences in my entire life. I am looking forward to the Bug Advocacy course already! Go Experience BBST!
Thank You BBST for the lovely learning experience,
Addendum on 1st Dec 2009:
I passed the BBST exam. Pari Pass Ho Gayi!
Happy Learning,
Parimala Shankaraiah
What I learned in BBST foundations course?
Basic knowledge of Computers
Before you think that I am challenging your ego, just answer this question ‘Do you know how memory storage works in computers?’ Compare your answer with actual facts of memory storage. Do they match? Basic knowledge of memory storage in computers is essential to being a good tester. This adds to the skill set of the black box tester. BBST showed me how miserable my knowledge of the basic computers is.
Basic knowledge of Arithmetic
While working on Matt’s Testing Challenge, I was surprised to see how the number of potential test cases was arrived at. At that time, I just wondered about that magic number. I did not realize that it was simple arithmetic computation. Knowledge of basic arithmetic computations is important to find the populace of tests that need to be executed.
Self-Inflicted Captivity
In India, test cases and scenarios are written by the leads and passed on to the sub-ordinates to test without questioning (in most organizations). In simple words, the trainees, junior/senior testers would not have scripted test cases or designed test strategies until they become leads themselves. The problem with these people is that they never stepped out of this captivity like me. Now I know why I failed in Matt’s Challenge. I am not concerned about winning or failing a challenge. I am concerned about not learning from these challenges. My ex-CEO Josh Pickus once said ‘Don’t be afraid to fail. Fail. But don’t fail to learn from your failure’.
Automated Testing
I worked very little on automated testing in my first job. Later on, I learned Perl which I never used. In my current job, I hardly find enough time for manual testing; forget about automated testing. Solid excuses. The truth is I have not made a determined effort to learn and practice automated testing. I realized this gap while I was studying BBST course. There were a couple of questions that focused on test automation and I was pathetic to say the least. Testers need to have a hang of automated testing. Like Elizabeth Hendrickson tweeted recently ‘I advocate 100% of *regression* tests being automated. But no, I don't know anyone who thinks 100% of all *testing* can be auto’.
Solving Practical Problems and Investigation
A tester needs to think beyond the testing job to be a good tester. Just testing may not make anyone a good tester. Being able to learn and solve different types of problems helps think differently. Identifying and solving real time problems as simple as ‘Door Lock not working’ or ‘Your car making strange noise while driving’ gives good experience in investigation skills. Investigate Now!
Careful vs. Sloppy Reading
All of us read blogs/articles/magazines/books on the internet. How much of it we really absorb and apply to our context matters over how many of these we read. Most of us fail to see the significance of careful reading. You never know when an idea strikes while you are reading. Read carefully. Sloppy reading hardly fetches anything.
Written Communication
Some of us fail to write as well as others who are good at it. Some of us write better in native languages and get intimidated to write in English for fear of losing the right ideas during translation. What if you are expected to work in a global setup where you need to interact with testers from different parts of the world? You need to interact in English and put across your thoughts precisely. You may be saying the right thing, but you may not be clear enough in your writing. This challenge was significantly seen in the foundations course where a few of us were unable to articulate our thoughts clearly resulting in more and more clarifications during group discussions. Written communication is a key skill for a tester. Start writing your experiences. Blogging is a great way to learn about writing. Start your own blog and practice writing.
Reading about diverse topics
Being a science graduate, I found psychology books fascinating. I would read psychology text books for hours on Saturdays in my college library. This helped me be a good counselor among my friends to help with their problems (silly teen problems!). Back then, I felt very proud of this trait and I read more just for fun. Today, as a tester, I find that knowledge helping me understand the emotions of the humans much better while using the software. Read anything and everything that fascinates you. Don’t get bogged down by the fact that you can’t put what you read to immediate use. Knowledge is power. Get that power.
What I learned in BBST Foundations course does not make me a good tester overnight or over a period of few months or years. It makes me a good tester if I have assimilated what made sense to me and my context and put it to practice in my daily working life. This course clearly highlighted my strenghts and weaknesses. I need to enhance my strenghts and work on my weak areas to be a better tester.
BBST Foundations course is a MUST for all people who test and who manage people who test. It was a course of reflection for me and I am glad I took this course so early in my career. I now know where I was heading all this while and I also know where I want to be heading going forward.
BBST Foundations course emphasizes on learning through practice and experience instead of memorizing answers to objective questions like the ISTQB/CSTE/CSQA and other crappy certifications (I call them crappy because the value add after getting certified is so little). Being an online course, this is no easy one to get through. It is a well thought out and practically designed course with years of hard work, revisions and modifications. BBST does not certify that you are a good tester, it will show you different paths to be a good tester. You need to figure out which path to choose and how to make it work for your context. This course has taken me a little closer to James Bach's Personal Vision of Testing Expertise 'I can test anything under any conditions in any time frame relative to my standing in the local community, how hard I try and my technical insight'.
This course is by far one of the best learning experiences in my entire life. I am looking forward to the Bug Advocacy course already! Go Experience BBST!
Thank You BBST for the lovely learning experience,
Addendum on 1st Dec 2009:
I passed the BBST exam. Pari Pass Ho Gayi!
Happy Learning,
Parimala Shankaraiah
07 November, 2009
The Writer’s Block
Recently, I got a chance to write about testing. A couple of testing magazines called for testing articles for their upcoming publications. I thought I should try. I have never written a formal article before. By formal, I mean writing about testing for testing magazines. I did think a couple of times to write for stickyminds before I started this blog, but then it never materialized. I wasn’t probably passionate enough to write at that time.
I thought of a topic and wrote an article with a friend of mine because we thought that both of us could clear the writing hurdles easier and faster than if each of us wrote articles on our own. We wrote it, got it reviewed by a few generous friends. One of them termed the article ‘Dangerous’ – yet was kind enough to review it. We emailed the article to the concerned person. We did not receive an acknowledgment email. I and my friend knew that it was a good first attempt, but maybe not good enough even to be acknowledged. I was left depressed, but thought that I should not give up.
I got lucky second time when I got an email from a very great tester asking me if I could write an article. I was excited. I chose a topic, brainstormed a bit, gathered a lot of information by speaking to my friends about the topic and reading up a little on a few related areas. I wrote the article the second time not to mention I wrote it all by myself. The same set of generous friends reviewed it and provided feedback. One of them thought that my article sounded like an ‘Attack’ to the intended audience. This time around I was deeply hurt. For a moment, I thought I was useless. I am still struggling with this article while I write this blog post.
In the last few years, I have not found anything as hard as writing about testing. This has been the most challenging task for me in a long time now. What is stopping me from writing about what I know about testing? Why is it that I am unable to write better though I have good written communication skills? At least my blog posts aren't that bad in terms of writing (I think so). At this point of time, I am thinking that the reason for my failure in writing about testing has got to do with the following:
1. Insufficient knowledge about the chosen topic
2. Inability to brainstorm in the right direction
3. Lack of widened knowledge (there is a need to know a lot more beyond testing in order to write better about testing)
4. Lack of experience (more the experience, wider the perspective)
5. Not reading enough testing books, articles, blogs etc
I have been watching a few testers who can just write about anything related to testing based on a few catchwords (theme) given to them. That can’t be magic for sure though I know it involves a lot of hard work to get to that stage. I am not worried about failing. I would be worried for sure if I did not learn from my failure. I have not given up yet. I think of chasing every little task that challenges me. I am going to give it my best shot yet again. I am hoping I will get better each time I fail.
It is important to start practicing writing. If you cannot write well and express your thoughts about testing, how will you succeed in convincing your developer to fix a bug by writing a not-so-good bug report. Start writing and get better at it. This is a very important skill in our day-to-day job as testers.
Happy Writing,
Parimala Shankaraiah
http://curioustester.blogspot.com
I thought of a topic and wrote an article with a friend of mine because we thought that both of us could clear the writing hurdles easier and faster than if each of us wrote articles on our own. We wrote it, got it reviewed by a few generous friends. One of them termed the article ‘Dangerous’ – yet was kind enough to review it. We emailed the article to the concerned person. We did not receive an acknowledgment email. I and my friend knew that it was a good first attempt, but maybe not good enough even to be acknowledged. I was left depressed, but thought that I should not give up.
I got lucky second time when I got an email from a very great tester asking me if I could write an article. I was excited. I chose a topic, brainstormed a bit, gathered a lot of information by speaking to my friends about the topic and reading up a little on a few related areas. I wrote the article the second time not to mention I wrote it all by myself. The same set of generous friends reviewed it and provided feedback. One of them thought that my article sounded like an ‘Attack’ to the intended audience. This time around I was deeply hurt. For a moment, I thought I was useless. I am still struggling with this article while I write this blog post.
In the last few years, I have not found anything as hard as writing about testing. This has been the most challenging task for me in a long time now. What is stopping me from writing about what I know about testing? Why is it that I am unable to write better though I have good written communication skills? At least my blog posts aren't that bad in terms of writing (I think so). At this point of time, I am thinking that the reason for my failure in writing about testing has got to do with the following:
1. Insufficient knowledge about the chosen topic
2. Inability to brainstorm in the right direction
3. Lack of widened knowledge (there is a need to know a lot more beyond testing in order to write better about testing)
4. Lack of experience (more the experience, wider the perspective)
5. Not reading enough testing books, articles, blogs etc
I have been watching a few testers who can just write about anything related to testing based on a few catchwords (theme) given to them. That can’t be magic for sure though I know it involves a lot of hard work to get to that stage. I am not worried about failing. I would be worried for sure if I did not learn from my failure. I have not given up yet. I think of chasing every little task that challenges me. I am going to give it my best shot yet again. I am hoping I will get better each time I fail.
It is important to start practicing writing. If you cannot write well and express your thoughts about testing, how will you succeed in convincing your developer to fix a bug by writing a not-so-good bug report. Start writing and get better at it. This is a very important skill in our day-to-day job as testers.
Happy Writing,
Parimala Shankaraiah
http://curioustester.blogspot.com
23 October, 2009
Best Practices and Fairness Cream adverts
Project A followed practice ’P’ and faired quite well, Project B followed and faired better, Project C followed ‘P’ and it was one of the best releases ever. Now practice ‘P’ becomes a benchmark for all the projects in the organization and is crowned the 'Best Practice'.
A Best Practice is defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people as per wikipedia.
Repeatable procedures – If a series of tasks(independent/dependent) are accomplished using trial and error, improvised over time and made to succeed either by tweaking or brute force, does this become a best practice?
Proven over time – If a certain practice has been followed for a long period of time without questioning it irrespective of its advantages or disadvantages, does this become a best practice?
Large numbers of people – If most of the organizations are following a certain practice, does this become a best practice?
Have you seen Fairness Cream adverts? Pick up the most fairish model around. Put up some color to make her look wheatish in complexion and make up a lot of acne. Then start applying some colors to make her fairer each day . It could be a 7 day miracle, 14 day miracle, 1 months or 6 weeks. Anything more than this could be termed as an ineffective fairness cream(that is how the marketing works). At the end of the promised timeline, the model becomes fairer and all the acne just vanish. What an ideal world? We admire these adverts, don’t we? Well, we admire the models more than the adverts and end up buying the creams because we liked the models in the adverts. Same with best practices. More than the practice itself, we tend to think that it has worked for so many organizations/projects/teams. Why would it not work for us? Isn’t this wastefulness?
There is no harm in learning about a new practice, getting gung ho about it and hoping to learn, follow and benefit from it. What is harmful is to tweak the quality of work to fit into the guidelines of the best practices. What is even more harmful is to follow this to impress your higher ups and not because you believe in the value that it brings.
I once worked for a company wherein every time we released a patch to the customer, we had to fill in a 20 page excel worksheet. The only ones that mattered were not more than 3 to 4 worksheets. But every tester had to fill all 20 pages for every patch! When I questioned this, I was told that this was designed as part of one of the Senior Manager’s MBO goals and he needed to ensure that everyone follows it by hook or crook. Best Practices are born exactly like this. If you come across a best practice, do not escape from it. At the same time, do not accept it right away. Analyse what suits best for your project. Defy the best practices!
Happy Defying,
Parimala Shankaraiah
http://curioustester.blogspot.com
PS: I have no offense to fairness cream ads or the models in them. By the way, I have been using a fairness cream for about 10 years now. I am born wheatish and was told that I would become fair. I have not. I tried to stop using it. My skin was so used to it that I got a lot of acne and had to continue using it. Once you get into them, its hard to get out without getting hurt.
Addendum on 19th Dec 2009:
James has written a superb blog post about Best Practices HERE.
A Best Practice is defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people as per wikipedia.
Repeatable procedures – If a series of tasks(independent/dependent) are accomplished using trial and error, improvised over time and made to succeed either by tweaking or brute force, does this become a best practice?
Proven over time – If a certain practice has been followed for a long period of time without questioning it irrespective of its advantages or disadvantages, does this become a best practice?
Large numbers of people – If most of the organizations are following a certain practice, does this become a best practice?
Have you seen Fairness Cream adverts? Pick up the most fairish model around. Put up some color to make her look wheatish in complexion and make up a lot of acne. Then start applying some colors to make her fairer each day . It could be a 7 day miracle, 14 day miracle, 1 months or 6 weeks. Anything more than this could be termed as an ineffective fairness cream(that is how the marketing works). At the end of the promised timeline, the model becomes fairer and all the acne just vanish. What an ideal world? We admire these adverts, don’t we? Well, we admire the models more than the adverts and end up buying the creams because we liked the models in the adverts. Same with best practices. More than the practice itself, we tend to think that it has worked for so many organizations/projects/teams. Why would it not work for us? Isn’t this wastefulness?
There is no harm in learning about a new practice, getting gung ho about it and hoping to learn, follow and benefit from it. What is harmful is to tweak the quality of work to fit into the guidelines of the best practices. What is even more harmful is to follow this to impress your higher ups and not because you believe in the value that it brings.
I once worked for a company wherein every time we released a patch to the customer, we had to fill in a 20 page excel worksheet. The only ones that mattered were not more than 3 to 4 worksheets. But every tester had to fill all 20 pages for every patch! When I questioned this, I was told that this was designed as part of one of the Senior Manager’s MBO goals and he needed to ensure that everyone follows it by hook or crook. Best Practices are born exactly like this. If you come across a best practice, do not escape from it. At the same time, do not accept it right away. Analyse what suits best for your project. Defy the best practices!
Happy Defying,
Parimala Shankaraiah
http://curioustester.blogspot.com
PS: I have no offense to fairness cream ads or the models in them. By the way, I have been using a fairness cream for about 10 years now. I am born wheatish and was told that I would become fair. I have not. I tried to stop using it. My skin was so used to it that I got a lot of acne and had to continue using it. Once you get into them, its hard to get out without getting hurt.
Addendum on 19th Dec 2009:
James has written a superb blog post about Best Practices HERE.
14 October, 2009
Painting the Right Picture
I read an article about New York city police officers attending a training on The Art of Perception. I have been very bad in understanding and interpreting works of art. I prefer to sit up and listen to a story instead. Being a science student, reading psychology books during my college days has helped me a great deal to understand the emotions of people, products, interactions, arguments, debates and many more. This experience also encouraged me to read diverse stuff, not just on testing. The above article forced me to think if I was sidelining a few attributes that would benefit the tester in me by not studying art.It was high time for me to re-think about my attitude on works of art.
While I was thinking about this whole thing, Marlena Compton posed a challenge on her recent blog post titled Visionary Testing – When Blogs Collide. I wished to take it up and try it out for myself. I have admired Raja Ravi Varma’s artwork all along my childhood. I chose the Lady with Lamp for my study.
My mind drew blank at the first glimpse of the portrait. I could not think anything about the portrait except that the lady in the portrait was yelling at me ‘Don’t you see what I am doing?, you nut!’. I took a couple more minutes to observe some attributes of the portrait. I have written my observations in two parts below: What I saw in the portrait and What I inferred from it.
What I saw?
The lady gives a strange yet polite stare while holding the lamp.
What I inferred?
There is a very high level of clarity and loads of confidence brimming in her eyes while she holds the lamp. She seems to know what she is doing, Why she is doing and How she is doing.
What I saw?
She is holding the stem of the lamp with her left hand as if with clinched fist.
What I inferred?
The way in which she is holding the stem of the lamp displays her determination to hold the lamp upright to avoid spilling the oil in the lamp. This also conveys that this lamp is made up of a copper/brass/iron or any other metal which is not only hard to hold, but also very heavy. Hence she has held it tight so it does not slip out of her hand.
What I saw?
She has held her right hand close to the flame.
What I inferred?
She does not want the flame to get blown away. Hence she is covering her right hand to avoid the wind/breeze from blowing the flame off. I also infer that there is a window/a door or a few windows/doors which are opened at this point in the room where she is standing right now. There is lot of wind/breeze flowing into the room that can put off the flame.
What I saw?
The lamp and the flame appear very close to her body.
What I inferred?
It appears like she has held the lamp very close to her body which in turn means that the flame can possibly burn her saree. However, there is a certain distance between the flame and her body which is concealed in the picture.
What I saw?
There is a large shadow behind her.
What I inferred?
This means that she is in a relatively dark room. This also means that the room is lit up from the light that is coming from the lamp and no other source of light. This has resulted in a large shadow behind her while she holds the lamp.
What I saw?
The veil on her head is partially covering her head.
What I inferred?
The veil on her head to me means that she belongs to a slightly conservative family where woman are expected to cover their faces with veil (which is typically one loose end of the saree) in front of other men and elderly people in the family. The partially covered veil means that she is alone in this room at this point.
What I saw?
The loose end of the saree on her left side appears wavy.
What I inferred?
There is a lot of breeze flowing into the room making the saree appear wavy.
Now what’s this got to do with the tester in me?
1. The Big Picture heuristic – Big picture looks too scary. Break it into smaller chunks. You will be able to see smaller parts of the big picture which makes the big picture clearer.
2. Observation – Having an eye for detail is a great attribute for a tester. If I do not observe the intricate details, I cannot figure out smaller attributes in the portrait! Good observation skills help identify the nitty gritties and boosts our imagination of the context of the portrait.
3. Perception – Perception is becoming aware of something via the senses. My perception of the portrait may be similar or drastically different from yours . This could be because we are different people having different perspectives and coming from different cultural backgrounds. To perceive what is exactly in the portrait is a challenge and that comes with studying more portraits.
4. Interpretation – Interpretation is a mental representation of something. Interpretation needs a deeper knowledge of the portrait and the context in which it was designed.
5. Investigation – What is the background into the portrait? Why is the portrait painted in a certain way? Why is the lady staring and not smiling? Investigate when all is well and investigate even when all is not well. Do you smell something fishy? Wow. you are on track!
Products are just like paintings. Unclear(Why is the product built this way?), Little or no background (Lack of Requirements), Difficult to Understand (What does it do, Why does it do and How does it do?), Difficult to convince people to buy (customizing the product to suit the needs of the customer). Well the customer asked for a soap and we jazz up a match box like a soap box. And the customer asks 'Nice box, but where is the soap?' .
At the end of this exercise, I felt amazing. Wow. I can study a portrait too. Atleast my first attempt looked decent enough. I am so glad I pushed myself to study a work of art and analyse it. I am sure to be respecting artists and works of art a lot more now.
Can you paint the right picture of the product in your mind?
Happy Painting,
Parimala Shankaraiah
http://curioustester.blogspot.com
While I was thinking about this whole thing, Marlena Compton posed a challenge on her recent blog post titled Visionary Testing – When Blogs Collide. I wished to take it up and try it out for myself. I have admired Raja Ravi Varma’s artwork all along my childhood. I chose the Lady with Lamp for my study.
My mind drew blank at the first glimpse of the portrait. I could not think anything about the portrait except that the lady in the portrait was yelling at me ‘Don’t you see what I am doing?, you nut!’. I took a couple more minutes to observe some attributes of the portrait. I have written my observations in two parts below: What I saw in the portrait and What I inferred from it.
What I saw?
The lady gives a strange yet polite stare while holding the lamp.
What I inferred?
There is a very high level of clarity and loads of confidence brimming in her eyes while she holds the lamp. She seems to know what she is doing, Why she is doing and How she is doing.
What I saw?
She is holding the stem of the lamp with her left hand as if with clinched fist.
What I inferred?
The way in which she is holding the stem of the lamp displays her determination to hold the lamp upright to avoid spilling the oil in the lamp. This also conveys that this lamp is made up of a copper/brass/iron or any other metal which is not only hard to hold, but also very heavy. Hence she has held it tight so it does not slip out of her hand.
What I saw?
She has held her right hand close to the flame.
What I inferred?
She does not want the flame to get blown away. Hence she is covering her right hand to avoid the wind/breeze from blowing the flame off. I also infer that there is a window/a door or a few windows/doors which are opened at this point in the room where she is standing right now. There is lot of wind/breeze flowing into the room that can put off the flame.
What I saw?
The lamp and the flame appear very close to her body.
What I inferred?
It appears like she has held the lamp very close to her body which in turn means that the flame can possibly burn her saree. However, there is a certain distance between the flame and her body which is concealed in the picture.
What I saw?
There is a large shadow behind her.
What I inferred?
This means that she is in a relatively dark room. This also means that the room is lit up from the light that is coming from the lamp and no other source of light. This has resulted in a large shadow behind her while she holds the lamp.
What I saw?
The veil on her head is partially covering her head.
What I inferred?
The veil on her head to me means that she belongs to a slightly conservative family where woman are expected to cover their faces with veil (which is typically one loose end of the saree) in front of other men and elderly people in the family. The partially covered veil means that she is alone in this room at this point.
What I saw?
The loose end of the saree on her left side appears wavy.
What I inferred?
There is a lot of breeze flowing into the room making the saree appear wavy.
Now what’s this got to do with the tester in me?
1. The Big Picture heuristic – Big picture looks too scary. Break it into smaller chunks. You will be able to see smaller parts of the big picture which makes the big picture clearer.
2. Observation – Having an eye for detail is a great attribute for a tester. If I do not observe the intricate details, I cannot figure out smaller attributes in the portrait! Good observation skills help identify the nitty gritties and boosts our imagination of the context of the portrait.
3. Perception – Perception is becoming aware of something via the senses. My perception of the portrait may be similar or drastically different from yours . This could be because we are different people having different perspectives and coming from different cultural backgrounds. To perceive what is exactly in the portrait is a challenge and that comes with studying more portraits.
4. Interpretation – Interpretation is a mental representation of something. Interpretation needs a deeper knowledge of the portrait and the context in which it was designed.
5. Investigation – What is the background into the portrait? Why is the portrait painted in a certain way? Why is the lady staring and not smiling? Investigate when all is well and investigate even when all is not well. Do you smell something fishy? Wow. you are on track!
Products are just like paintings. Unclear(Why is the product built this way?), Little or no background (Lack of Requirements), Difficult to Understand (What does it do, Why does it do and How does it do?), Difficult to convince people to buy (customizing the product to suit the needs of the customer). Well the customer asked for a soap and we jazz up a match box like a soap box. And the customer asks 'Nice box, but where is the soap?' .
At the end of this exercise, I felt amazing. Wow. I can study a portrait too. Atleast my first attempt looked decent enough. I am so glad I pushed myself to study a work of art and analyse it. I am sure to be respecting artists and works of art a lot more now.
Can you paint the right picture of the product in your mind?
Happy Painting,
Parimala Shankaraiah
http://curioustester.blogspot.com
08 October, 2009
Get your Context Right
Once upon a time, there lived a beautiful Princess. The Supreme Commander of the kingdom lusted on the Princess, while she fell in love with one of the greatest warriors of her kingdom who trained soldiers for war. She admired him for his bravery and courage. This resulted in a battle between the commander and the warrior on a tall mountain which is 10 times bigger than Mount Everest. After a futile attempt to kill the warrior, the commander took revenge by piercing a dagger in the Princess’s heart. She lay motionless at the edge of that mountain while the warrior killed the commander. The warrior runs towards the Princess to say that he loves her…. something that he never confessed to her until that time though he loved her. And the Princess dies and slips from the edge of the mountain. The warrior sees the Princess falling down, runs back a few steps and jumps from the mountain hoping to reach out to her. He somehow manages to go close to the falling Princess, but not close enough to catch hold of her.
I was fully involved watching this scene in a multiplex theatre when my niece shook me up with a question. ‘Did you know that the warrior can never reach out to the Princess if he jumps with an initial velocity 0?' I was like 'What? Why do you think so?' She said ‘The dead Princess slipped off with an initial velocity 0 (inertia of rest). However, the warrior went running and jumped off the mountain with a certain velocity say ‘X’ (inertia of motion)'.
She continued ‘If the warrior jumped with initial velocity 0, then the distance between him and the dead Princess would be same until the Princess reaches the ground. If the warrior jumped with an initial velocity ‘X’, then the distance changes and he will be able to get closer and even reach the Princess’. It was a truly ‘WOW’ moment. I am pretty bad at physics thanks to my teachers who only forced and tortured me and my class mates to learn formulae by rote and vomit it in exams. It is also my mistake that I never questioned what I was taught (shame on me!).
Imagination, Analogy, Practical thinking is infinite. This experience left me thinking for quite some time. As a tester, I set a mission for myself to ‘Test whether the warrior catches hold of the Princess’s hand and report my observations’. Just like any movie buff, I got busy watching the warrior reach out to the Princess. What if I did not know anything about initial velocity? What if I did not know under what circumstances the Princess fell off the mountain? What if the Princess jumped at her own will? What if the warrior suffered a shock, died and then slipped off the mountain. I would end up watching them falling until they reach the ground without focusing on my mission.
It is important to understand the context be it testing or problem solving or even a crime scene investigation.
1. What problem is the application intended to solve?
2. How will the application be used in a real world?
3. Who is the target audience for this application?
4. What is the environment/platform in which the application will be used?
5. Where does the application stand with regard to competitor products catering to a similar target audience?
6. What is the expected scalability for the application in the near future?
7. What kind of performance is expected of the application?
Without knowing answers to many more questions like these, testers can only do superficial testing leaving out critical defects in the application intact. Imagine the plight of the customer who buys this application?
We talk about getting laid off in our organizations. We do not talk about why the organization laid off or even shut down the entire office. We ask about why the organization did not retain people with the profits it made the last to last before year(correct me if this phrase is wrong). We do not ask why the customers did not buy the application. We need to provide the application the way the customer wants it, not the way we want it to be. If we do provide the way we want it to be, it will be with us. It will never go to the customer and by god's grace(sales/marketing) even if it does, it will come back to us. Do we want the application to come back or the appreciation?
Get your Context Right,
Parimala Shankaraiah
http://curioustester.blogspot.com
I was fully involved watching this scene in a multiplex theatre when my niece shook me up with a question. ‘Did you know that the warrior can never reach out to the Princess if he jumps with an initial velocity 0?' I was like 'What? Why do you think so?' She said ‘The dead Princess slipped off with an initial velocity 0 (inertia of rest). However, the warrior went running and jumped off the mountain with a certain velocity say ‘X’ (inertia of motion)'.
She continued ‘If the warrior jumped with initial velocity 0, then the distance between him and the dead Princess would be same until the Princess reaches the ground. If the warrior jumped with an initial velocity ‘X’, then the distance changes and he will be able to get closer and even reach the Princess’. It was a truly ‘WOW’ moment. I am pretty bad at physics thanks to my teachers who only forced and tortured me and my class mates to learn formulae by rote and vomit it in exams. It is also my mistake that I never questioned what I was taught (shame on me!).
Imagination, Analogy, Practical thinking is infinite. This experience left me thinking for quite some time. As a tester, I set a mission for myself to ‘Test whether the warrior catches hold of the Princess’s hand and report my observations’. Just like any movie buff, I got busy watching the warrior reach out to the Princess. What if I did not know anything about initial velocity? What if I did not know under what circumstances the Princess fell off the mountain? What if the Princess jumped at her own will? What if the warrior suffered a shock, died and then slipped off the mountain. I would end up watching them falling until they reach the ground without focusing on my mission.
It is important to understand the context be it testing or problem solving or even a crime scene investigation.
1. What problem is the application intended to solve?
2. How will the application be used in a real world?
3. Who is the target audience for this application?
4. What is the environment/platform in which the application will be used?
5. Where does the application stand with regard to competitor products catering to a similar target audience?
6. What is the expected scalability for the application in the near future?
7. What kind of performance is expected of the application?
Without knowing answers to many more questions like these, testers can only do superficial testing leaving out critical defects in the application intact. Imagine the plight of the customer who buys this application?
We talk about getting laid off in our organizations. We do not talk about why the organization laid off or even shut down the entire office. We ask about why the organization did not retain people with the profits it made the last to last before year(correct me if this phrase is wrong). We do not ask why the customers did not buy the application. We need to provide the application the way the customer wants it, not the way we want it to be. If we do provide the way we want it to be, it will be with us. It will never go to the customer and by god's grace(sales/marketing) even if it does, it will come back to us. Do we want the application to come back or the appreciation?
Get your Context Right,
Parimala Shankaraiah
http://curioustester.blogspot.com
06 October, 2009
The Power of Mnemonics
I always wondered how a few testers catch killer bugs so quickly. How is their intuition so sharp compared to others? Practice? In addition to practice, these testers find easy ways to remember important stuff that matters to them in different contexts. Mnemonics can be very useful to remember heuristics and oracles. I compiled the below list for me and you to learn and practice. Of course, with due credit to the creators of these heuristics and oracles.
Michael D Kelly’s Touring Heuristics – FCC CUTS VIDS
Feature tour, Complexity tour, Claims tour, Configuration tour, User tour, Testability tour, Scenario tour, Variability tour, Interoperability tour, Data tour, Structure tour
Michael D Kelly’s Test Reporting Heuristics – MCOASTER
Mission, Coverage, Obstacles, Audience, Status, Techniques, Environment, Risk
Ben Simo’s Error handling Heuristics – FAILURE
Functional, Appropriate, Impact, Log, UI, Recovery, Emotions
Adam Goucher’s ordering of Testing Tasks heuristics – SLIME
Security, Languages, requIrements, Measurement, Existing
Scott Barber’s Performance Testing heuristics – FIBLOTS
Frequent, Intensive, Business Critical, Legal, Obvious, Technically risky, Stakeholder Mandated
James Bach’s Test Strategy Heuristics – SFDPOT (San Francisco Depot)
Structure, Function, Data, Platform, Operations, Time
James Bach’s Project Environment Heuristics – CIDTESTD (Kid Tested)
Customers, Information, Developer relations, Team, Equipment & tools, Schedule, Test Items, Deliverables
James Bach’s Quality Criteria heuristics – CRUSSPIC STMPL
A. Operational Criteria - CRUSSPIC
Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility
B. Development Criteria - STMPL
Supportability, Testability, Maintainability, Portability, Localizability
James Bach’s Test Techniques Heuristics – DUFFSSCRA(FDSFSCURA)
Domain, User, Function, Flow, Stress, Scenario, Claims, Risk, Automatic
James Bach’s Test Oracles – HICCUPPSF
History, Image, Comparable product, Claims, User Expectation, Product, Purpose, Standards and Statutes, Familiar Problems
James Bach’s Learning Heuristics – SACKED SCOWS
Scouting Obsessively, Authentic Problems, Cognitive Savvy, Knowledge attracts Knowledge, Experimentation, Disposable Time, Stories(Contrasting Ideas, Skepticism, Critical thinking, Lateral thinking), Other Minds, Words and Pictures, Systems Thinking
Most of us probably read and learn about a lot about heuristics and oracles. While we continue to use them, we blindly stick to them forever without discovering our own heuristics or oracles that work best for us. Please note I have a lot of respect for the existing heuristics and oracles and the people who came up with them. All I want to convey here is for us to think and experiment more to see if we can come up with our own heuristics and oracles which makes better sense to the testing that we do.
Points to Note
1. I have intentionally not detailed the above heuristics because I want you to go read those wonderful articles/blog posts where these heuristics are as is (if you are not already familiar). Summon google for help.
2. James Bach's book 'The Secrets of a Buccaneer Scholar' has a lot more learning heuristics - Will update this list once I buy the book and read it a second time.
3. If you know of any heuristics/oracles or you have come up with on your own, please do let me know.
4. There is a bug in here. No clues. Lemme see if you can find it.
Addendum on 16th Oct 09
In Michael Bolton's words: "To HICCUPP, you can now add S, for Standards and Statutes--relevant laws or industry standards. F, for Familiar Problems. All the prior oracle heuristics are consistency heuristics; we suspect that everything's okay if the product is consistent with them, and it's not okay if we see an inconsistency. The Familiar Problems oracle is the opposite; we want the product to be inconsistent with patterns of programs that we've seen before, and here if we see a consistency we suspect that there's a problem."
Happy Discovering,
Parimala Shankaraiah
http://curioustester.blogspot.com
Michael D Kelly’s Touring Heuristics – FCC CUTS VIDS
Feature tour, Complexity tour, Claims tour, Configuration tour, User tour, Testability tour, Scenario tour, Variability tour, Interoperability tour, Data tour, Structure tour
Michael D Kelly’s Test Reporting Heuristics – MCOASTER
Mission, Coverage, Obstacles, Audience, Status, Techniques, Environment, Risk
Ben Simo’s Error handling Heuristics – FAILURE
Functional, Appropriate, Impact, Log, UI, Recovery, Emotions
Adam Goucher’s ordering of Testing Tasks heuristics – SLIME
Security, Languages, requIrements, Measurement, Existing
Scott Barber’s Performance Testing heuristics – FIBLOTS
Frequent, Intensive, Business Critical, Legal, Obvious, Technically risky, Stakeholder Mandated
James Bach’s Test Strategy Heuristics – SFDPOT (San Francisco Depot)
Structure, Function, Data, Platform, Operations, Time
James Bach’s Project Environment Heuristics – CIDTESTD (Kid Tested)
Customers, Information, Developer relations, Team, Equipment & tools, Schedule, Test Items, Deliverables
James Bach’s Quality Criteria heuristics – CRUSSPIC STMPL
A. Operational Criteria - CRUSSPIC
Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility
B. Development Criteria - STMPL
Supportability, Testability, Maintainability, Portability, Localizability
James Bach’s Test Techniques Heuristics – DUFFSSCRA(FDSFSCURA)
Domain, User, Function, Flow, Stress, Scenario, Claims, Risk, Automatic
James Bach’s Test Oracles – HICCUPPSF
History, Image, Comparable product, Claims, User Expectation, Product, Purpose, Standards and Statutes, Familiar Problems
James Bach’s Learning Heuristics – SACKED SCOWS
Scouting Obsessively, Authentic Problems, Cognitive Savvy, Knowledge attracts Knowledge, Experimentation, Disposable Time, Stories(Contrasting Ideas, Skepticism, Critical thinking, Lateral thinking), Other Minds, Words and Pictures, Systems Thinking
Most of us probably read and learn about a lot about heuristics and oracles. While we continue to use them, we blindly stick to them forever without discovering our own heuristics or oracles that work best for us. Please note I have a lot of respect for the existing heuristics and oracles and the people who came up with them. All I want to convey here is for us to think and experiment more to see if we can come up with our own heuristics and oracles which makes better sense to the testing that we do.
Points to Note
1. I have intentionally not detailed the above heuristics because I want you to go read those wonderful articles/blog posts where these heuristics are as is (if you are not already familiar). Summon google for help.
2. James Bach's book 'The Secrets of a Buccaneer Scholar' has a lot more learning heuristics - Will update this list once I buy the book and read it a second time.
3. If you know of any heuristics/oracles or you have come up with on your own, please do let me know.
4. There is a bug in here. No clues. Lemme see if you can find it.
Addendum on 16th Oct 09
In Michael Bolton's words: "To HICCUPP, you can now add S, for Standards and Statutes--relevant laws or industry standards. F, for Familiar Problems. All the prior oracle heuristics are consistency heuristics; we suspect that everything's okay if the product is consistent with them, and it's not okay if we see an inconsistency. The Familiar Problems oracle is the opposite; we want the product to be inconsistent with patterns of programs that we've seen before, and here if we see a consistency we suspect that there's a problem."
Happy Discovering,
Parimala Shankaraiah
http://curioustester.blogspot.com
04 October, 2009
Testability – What art Thou?
Software testability is the degree to which a software artifact (i.e. a software system, software module, requirements- or design document) supports testing in a given test context. Take a moment to read about Testability Heuristics from James Bach.
Background
I have not tested for Testability. I did not know what is testability until I heard it as a quality criteria in Weekend Testing 8. When Pradeep Soundararajan pinged me for a testing session on 3rd Oct 2009, I jumped out of my seat. Sharath Byregowda was keen to join us too. The Three Musketeers. I was asked to come up with an application to test and the mission.
Application to Test
Microsoft Narrator is a text-to-speech utility for users who are blind or have impaired vision. Narrator reads what is displayed on your screen: the contents of the active window, menu options, or the text you have typed. I have been amused by its functionality for quite some time and this was the opportunity.
Mission
To test the Testability of the Narrator application.
Experience Report
The three of us set out to test narrator. I started off with Google looking for information on testability. Read up a little on Wikipedia and another article on stickyminds (I found James Bach's article while composing this post). Identified a set of criteria to look out for while testing for testability of the Narrator. I had no clue if I was right or wrong. Nevertheless, it was exciting because this was my first foray into testability. It was very thrilling though I knew I had the potential to do a lot more better. But then, I always discount myself the first time I don’t do anything correctly. This way, I don’t get stressed to run the rat race nor do I have the pressure to learn something just because I am left behind compared to other good testers. Testing was stopped after 1 hour and we had a small discussion. Sharath had concerns with using the product as a whole. I had concerns about not knowing testability enough. Pradeep simply shared his report and headed for lunch without speaking a word. He probably wanted us to see what was in there! Please find my report HERE.
Challenges
1. New Product as usual
2. New mission – Testability
3. I am neither blind nor do I have an impaired vision
4. In any testing activity, whining within or outside of the testing window is an utter waste of time. It is better to find ways to know how to do things and do them better
5. Once out of the testing window, it is better to go back and learn more on unknown areas – in this case ‘learning more on testability’ because this is not the end of it
6. One of the biggest gift we humans can give to ourselves is to identify what we do not know and find ways to know what we do not know. The challenge here is to know what you do not know
Do you know what you do not know?
Addendum(5th Oct 09)
Michael Bolton's take on Testability.
Happy Knowing Thyself,
Parimala Shankaraiah
http://curioustester.blogspot.com
Background
I have not tested for Testability. I did not know what is testability until I heard it as a quality criteria in Weekend Testing 8. When Pradeep Soundararajan pinged me for a testing session on 3rd Oct 2009, I jumped out of my seat. Sharath Byregowda was keen to join us too. The Three Musketeers. I was asked to come up with an application to test and the mission.
Application to Test
Microsoft Narrator is a text-to-speech utility for users who are blind or have impaired vision. Narrator reads what is displayed on your screen: the contents of the active window, menu options, or the text you have typed. I have been amused by its functionality for quite some time and this was the opportunity.
Mission
To test the Testability of the Narrator application.
Experience Report
The three of us set out to test narrator. I started off with Google looking for information on testability. Read up a little on Wikipedia and another article on stickyminds (I found James Bach's article while composing this post). Identified a set of criteria to look out for while testing for testability of the Narrator. I had no clue if I was right or wrong. Nevertheless, it was exciting because this was my first foray into testability. It was very thrilling though I knew I had the potential to do a lot more better. But then, I always discount myself the first time I don’t do anything correctly. This way, I don’t get stressed to run the rat race nor do I have the pressure to learn something just because I am left behind compared to other good testers. Testing was stopped after 1 hour and we had a small discussion. Sharath had concerns with using the product as a whole. I had concerns about not knowing testability enough. Pradeep simply shared his report and headed for lunch without speaking a word. He probably wanted us to see what was in there! Please find my report HERE.
Challenges
1. New Product as usual
2. New mission – Testability
3. I am neither blind nor do I have an impaired vision
4. In any testing activity, whining within or outside of the testing window is an utter waste of time. It is better to find ways to know how to do things and do them better
5. Once out of the testing window, it is better to go back and learn more on unknown areas – in this case ‘learning more on testability’ because this is not the end of it
6. One of the biggest gift we humans can give to ourselves is to identify what we do not know and find ways to know what we do not know. The challenge here is to know what you do not know
Do you know what you do not know?
Addendum(5th Oct 09)
Michael Bolton's take on Testability.
Happy Knowing Thyself,
Parimala Shankaraiah
http://curioustester.blogspot.com
Testing out of Comfort Zone
The last time I mentioned about Getting Out of Comfort Zone, I anticipated great learning experience, but I wasn’t ready for surprises! I wanted to participate in the Weekend Testers (Chennai Chapter) and test a CSS Menu Builder application.
Charter
Cross Browser compatibility testing of IzzyMenu using IE 8.0 and FF 3.0 browsers.
Experience Report
IzzyMenu did not have a direct hyperlink which could be tested using a cross browser compatibility testing tool for IE 8.0 and FF 3.0. I as a user had to navigate to the menu page explicitly. I tested for alignment, layout, font size, color, positioning of tabs in the layout, hyperlinks, look and feel of the entire application, print, print preview option and a lot more. Tested the same set of test ideas in FF 3.0. Ok, finding usability and functional bugs while I look for compatibility bugs– Murphy’s Law? Found about 3 compatibility bugs, but that is not important for me right now. What is important is what is new to me in this testing exercise and what I learned while testing IzzyMenu.
Learnings
1. Though I had performed compatibility testing previously, while testing IzzyMenu, I had a mental block testing it. I had not performed compatibility testing on websites for a start. I have to take care of this in future.
2. When learning to test with a charter that I have not done before, it invites some prior learning on how to do. When I jumped at IzzyMenu without deciding what to test, there was a block. I did not see anything reasonable to test. My approach was wrong here and I had to change it.
3. Do not confine yourself to 90 minutes Sessions while you are learning to test out of your comfort zone. It more or less extends beyond 90 minutes timeframe. Ideally, its better not to have any time limit while testing this way.
4. Note down all the bottlenecks or choking points that you face while testing and sort it out yourself. This way, you will slowly realize that what you saw as a bottleneck is not a bottleneck at all. And that will be your Wow moment.
5. You may not find bugs all the time. Absence of bugs or lack of skills to find bugs(which tricks you to think that bugs are absent) does not mean you are a bad tester. You probably did not look at the right places and this can be improved with continuous practice.
6. From time to time, we should get together with people from different perspectives and watch them test. Trust Me, the first time you do this, you may think you are a horrible tester. You may be one too. The next time when you watch them test, it will be one of the coolest ways of learning and testing and you would do more of it more often.
Happy Testing,
Parimala Shankaraiah
http://curioustester.blogspot.com
Charter
Cross Browser compatibility testing of IzzyMenu using IE 8.0 and FF 3.0 browsers.
Experience Report
IzzyMenu did not have a direct hyperlink which could be tested using a cross browser compatibility testing tool for IE 8.0 and FF 3.0. I as a user had to navigate to the menu page explicitly. I tested for alignment, layout, font size, color, positioning of tabs in the layout, hyperlinks, look and feel of the entire application, print, print preview option and a lot more. Tested the same set of test ideas in FF 3.0. Ok, finding usability and functional bugs while I look for compatibility bugs– Murphy’s Law? Found about 3 compatibility bugs, but that is not important for me right now. What is important is what is new to me in this testing exercise and what I learned while testing IzzyMenu.
Learnings
1. Though I had performed compatibility testing previously, while testing IzzyMenu, I had a mental block testing it. I had not performed compatibility testing on websites for a start. I have to take care of this in future.
2. When learning to test with a charter that I have not done before, it invites some prior learning on how to do. When I jumped at IzzyMenu without deciding what to test, there was a block. I did not see anything reasonable to test. My approach was wrong here and I had to change it.
3. Do not confine yourself to 90 minutes Sessions while you are learning to test out of your comfort zone. It more or less extends beyond 90 minutes timeframe. Ideally, its better not to have any time limit while testing this way.
4. Note down all the bottlenecks or choking points that you face while testing and sort it out yourself. This way, you will slowly realize that what you saw as a bottleneck is not a bottleneck at all. And that will be your Wow moment.
5. You may not find bugs all the time. Absence of bugs or lack of skills to find bugs(which tricks you to think that bugs are absent) does not mean you are a bad tester. You probably did not look at the right places and this can be improved with continuous practice.
6. From time to time, we should get together with people from different perspectives and watch them test. Trust Me, the first time you do this, you may think you are a horrible tester. You may be one too. The next time when you watch them test, it will be one of the coolest ways of learning and testing and you would do more of it more often.
Happy Testing,
Parimala Shankaraiah
http://curioustester.blogspot.com
02 October, 2009
Do you heed to bugs in blogger anymore?
I know how pathetic blogger has been. You readers who use blogger or read blogs on blogger would know how pathetic it is. At one time, I was so frustrated with blogger that I decided to move to Wordpress, but then, I read a bad experience report on Wordpress and decided to wait for a better one. While I continue to wait (or decide to buy my own domain), I found an interesting observation on blogger today (while you say No, Not Again).
Typing any URL say http://curioustester.blogspot.com/2009/10/interesting-bug-in-yahoo-messenger.html in the body of the blog post does not convert it to a hyperlink automatically(this happens automatically in word, excel and powerpoint to name a few). So blogger expects you to use the 'Insert Link' option available in Blogger editor to convert it to a hyperlink.
Do you think this is normal?
Do you have a blogger bug story to share?
Do you think there is a better blogging platform you know of?
Happy Sharing,
Parimala Shankaraiah
http://curioustester.blogspot.com
Typing any URL say http://curioustester.blogspot.com/2009/10/interesting-bug-in-yahoo-messenger.html in the body of the blog post does not convert it to a hyperlink automatically(this happens automatically in word, excel and powerpoint to name a few). So blogger expects you to use the 'Insert Link' option available in Blogger editor to convert it to a hyperlink.
Do you think this is normal?
Do you have a blogger bug story to share?
Do you think there is a better blogging platform you know of?
Happy Sharing,
Parimala Shankaraiah
http://curioustester.blogspot.com
01 October, 2009
Interesting Bug in Yahoo Messenger
I have been busy in an internal product training for last 3 days along with my colleague cum mentee Narain Mittal. Today afternoon, product trainer Ravi messaged me on Yahoo Messenger that the training is postponed to 3.30 PM. He requested me to inform Narain as well.
Chat text on my chat window
Ravi: we will have KT at 3:30pm
Pari: sure.
I copied Ravi’s chat message and pasted it onto Narain’s chat window as below:
Chat text on Narain’s chat window
Ravi: we will have KT at 3:30pm
Ravi is typing a message.
Pari: sure.
If you observe the chat text on Narain’s chat window, 'Ravi is typing a message.' is an additional message here. Interestingly, this is not visible in my chat window.
Inference
Additional message is visible only when I copy the chat text from my chat window to narain’s chat window. It looks to me that the text is plain hidden on my chat window. However, explicitly copying the text using Ctrl-C or Copy options will copy the hidden text as well. This happens to another message ‘Last message received on 10/1/2009 at 3:08 PM’ as well. I checked this on Gmail chat and this bug is not prevalent on gmail chat.
Any thoughts on this bug?
Happy Investigating,
Parimala Shankaraiah
http://curioustester.blogspot.com
Chat text on my chat window
Ravi: we will have KT at 3:30pm
Pari: sure.
I copied Ravi’s chat message and pasted it onto Narain’s chat window as below:
Chat text on Narain’s chat window
Ravi: we will have KT at 3:30pm
Ravi is typing a message.
Pari: sure.
If you observe the chat text on Narain’s chat window, 'Ravi is typing a message.' is an additional message here. Interestingly, this is not visible in my chat window.
Inference
Additional message is visible only when I copy the chat text from my chat window to narain’s chat window. It looks to me that the text is plain hidden on my chat window. However, explicitly copying the text using Ctrl-C or Copy options will copy the hidden text as well. This happens to another message ‘Last message received on 10/1/2009 at 3:08 PM’ as well. I checked this on Gmail chat and this bug is not prevalent on gmail chat.
Any thoughts on this bug?
Happy Investigating,
Parimala Shankaraiah
http://curioustester.blogspot.com
29 September, 2009
Interviews and Jobs
Why would you move out of your job? Why would anyone move out of his/her current job? I bet, its not just MONEY all the time. Each one of us wants to be rich, but that does not mean that we would be spending 8-10 hours/day at work just for money without enjoying what we do, without growing in the area of our liking and expertise, without learning new stuff for self improvement etc. All said and done, we still look out for our dream job each time and after we do land up in one such dream job, we finally end up thinking this is not THE JOB FOR ME.
Coming to the point. Pradeep Soundararajan is writing a book on ‘Interviews and Jobs'. Would you be interested? Why would you not be interested? If you still plan to attend interviews in each of your dream companies and figure out what works in each company and how to get a job there, then nobody is gonna stop you. But do you have the time that it demands? If you don’t, then how about this? Interviews and Jobs. On the website, you will get to see and read cool stuff that might land you in your dream job or atleast give a big nudge towards finding one. Check out the website and provide your feedback. Do read the Teaser of the book. If you want to know more, Check HERE.
It’s Better to Try and Fail Than to Have Never Tried At All.
Happy Reading,
Parimala Shankaraiah
http://curioustester.blogspot.com
Coming to the point. Pradeep Soundararajan is writing a book on ‘Interviews and Jobs'. Would you be interested? Why would you not be interested? If you still plan to attend interviews in each of your dream companies and figure out what works in each company and how to get a job there, then nobody is gonna stop you. But do you have the time that it demands? If you don’t, then how about this? Interviews and Jobs. On the website, you will get to see and read cool stuff that might land you in your dream job or atleast give a big nudge towards finding one. Check out the website and provide your feedback. Do read the Teaser of the book. If you want to know more, Check HERE.
It’s Better to Try and Fail Than to Have Never Tried At All.
Happy Reading,
Parimala Shankaraiah
http://curioustester.blogspot.com
27 September, 2009
Bangalore Weekend Testing 9 (BWT – 9)
Date and Time
26th September 2009, 3.00 PM
Mission
To find functional bugs in the application
Product Overview
Splashup formerly Fauxto, is a powerful editing tool and photo manager. It's easy to use, works in real-time and allows you to edit many images at once. Splashup runs in all browsers, integrates seamlessly with top photo-sharing sites, and even has its own file format so you can save your work in progress.
Testers
Ajay Balamurugadas, Parimala Shankaraiah, Gunjan Sethi, Dhanasekar Subramaniam, Poulami Ghosh, Suja C S, Karan Indra, Rajesh Iyer, Amit Kulkarni.
Reports
My Report
Ajay’s Report
Approach
Testing multimedia and imaging applications has been a jittery-ride for me for a long time simply because I have not tested them or even brainstormed test ideas for such applications. The product for BWT-9 was one such application – Splashup. First look at the application and I was like ‘Oops! I am stuck’. I had no clue about what the product is, how I am going to understand how it works, how to figure out and what to figure out? Any online help – just nothing. I am surprised how most applications are released to the market without the basic help information if not contextual help! For splashup, there was a brief overview about the product and that’s it. I opened the application and observed the tools pane. Wow – now this looks similar to MS Paint. I am not sure yet if mapping one application to another does any good/bad in terms of modeling the application under test(AUT). At least in this case, I was able to move forward.
Dear Facilitator
I was the facilitator for this session. Facilitating is a different ballgame altogether. Inviting people to google chat, reconnecting disconnected people, providing information for latecomers(if any), clarifications, questions, doubts, understanding misinterpretations and interpreting correctly etc. Wow. It was an awesome experience. I always think of me as a very poor Management Material. I have always dreamt of being a tester in an Individual Contributor(IC) role and be able to work like that forever in an Ideal World. Sadly, this is not an ideal world. This pushes me to pursue a lot more skills to be learnt and practiced. Someday, these skills are going to help me be a better tester in some way. Respect every experience in your life. You never know when you would require those skills.
To learn from whatever happens, no matter how horrible that experience maybe, is a kind of revenge on bad fortune that is always available to us – James Bach
Happy Learning,
Parimala Shankaraiah
http://curioustester.blogspot.com
26th September 2009, 3.00 PM
Mission
To find functional bugs in the application
Product Overview
Splashup formerly Fauxto, is a powerful editing tool and photo manager. It's easy to use, works in real-time and allows you to edit many images at once. Splashup runs in all browsers, integrates seamlessly with top photo-sharing sites, and even has its own file format so you can save your work in progress.
Testers
Ajay Balamurugadas, Parimala Shankaraiah, Gunjan Sethi, Dhanasekar Subramaniam, Poulami Ghosh, Suja C S, Karan Indra, Rajesh Iyer, Amit Kulkarni.
Reports
My Report
Ajay’s Report
Approach
Testing multimedia and imaging applications has been a jittery-ride for me for a long time simply because I have not tested them or even brainstormed test ideas for such applications. The product for BWT-9 was one such application – Splashup. First look at the application and I was like ‘Oops! I am stuck’. I had no clue about what the product is, how I am going to understand how it works, how to figure out and what to figure out? Any online help – just nothing. I am surprised how most applications are released to the market without the basic help information if not contextual help! For splashup, there was a brief overview about the product and that’s it. I opened the application and observed the tools pane. Wow – now this looks similar to MS Paint. I am not sure yet if mapping one application to another does any good/bad in terms of modeling the application under test(AUT). At least in this case, I was able to move forward.
Dear Facilitator
I was the facilitator for this session. Facilitating is a different ballgame altogether. Inviting people to google chat, reconnecting disconnected people, providing information for latecomers(if any), clarifications, questions, doubts, understanding misinterpretations and interpreting correctly etc. Wow. It was an awesome experience. I always think of me as a very poor Management Material. I have always dreamt of being a tester in an Individual Contributor(IC) role and be able to work like that forever in an Ideal World. Sadly, this is not an ideal world. This pushes me to pursue a lot more skills to be learnt and practiced. Someday, these skills are going to help me be a better tester in some way. Respect every experience in your life. You never know when you would require those skills.
To learn from whatever happens, no matter how horrible that experience maybe, is a kind of revenge on bad fortune that is always available to us – James Bach
Happy Learning,
Parimala Shankaraiah
http://curioustester.blogspot.com
26 September, 2009
Bangalore Weekend Testing 8 (BWT – 8)
Date and Time
20th September 2009, 3.00 PM, BWT testers meet up on Google Chat.
Mission
Choose one of the quality criteria out of the following –
Installability / Usability / Performance / Reliability / Compatibility /Testability.
Product Overview
Areca-Backup is a file backup software that supports incremental, image and delta backup on local drives or FTP servers.
Testers
Ajay Balamurugadas, Vasupratha, Bhargavi, Sudhakar, Gunjan, Parimala Shankaraiah.
Reports
My Report
Ajay's Report
Approach
The beauty of BWT 8 lay in the fact that there was a flexibility to choose the mission by selecting any one of the Quality Criteria listed: Installability / Usability / Performance / Reliability / Compatibility / Testability. Previously, I was fascinated by the results of testing Nokia 1650 Insert Options by breaking down the feature sets and choosing one small testing chunk to test. I wanted to learn to better my previous testing performance. I chose Installability as the quality criteria - something that I had not tested earlier in session based format. I set out to test and loved the entire experience.
One thing I noticed in this session was that a few testers chose the much known, much easier quality criteria. In short, they chose to be in their comfort zones. Please note that if any product is given to test with a vague mission like find bugs in the product, we as humans have a normal tendency to choose areas that we are comfortable with. For eg. I love functional and usability testing and I would just jump at any opportunity to do just this . Over a period of time, I realized that other areas like performance, claims, reliability, compatibility etc are important as well based on what the stakeholder demands. Hence, as a tester, it is good to have basic skills in different test techniques if not great skills. This in turn can be improved over a period of time by practicing more and more.
The best way to learn is to push yourself out of your comfort zone. Test what you are not sure about. Test what you do not know about. Test what you have not heard about. Ask questions. Find answers. Question your answers. And ask more questions. The final answer could be well within your reach. You be your first critic.
Advantages of testing smaller chunks of the product
1. Brainstorming one feature/task results in an umpteen number of test ideas
2. Improved Focus on a single feature/task
3. Adequate testing can be done in a 90 – 120 minutes session
4. Finding lot more valuable and hidden bugs (bugs hungry? – Naa!)
5. Highly buggy features can be retested in future sessions possibly in short session say 60 minutes
If you have tried testing by breaking testing tasks into smaller chunks, feel free to add to the above list.
Get Uncomfortable Today,
Parimala Shankaraiah
http://curioustester.blogspot.com
20th September 2009, 3.00 PM, BWT testers meet up on Google Chat.
Mission
Choose one of the quality criteria out of the following –
Installability / Usability / Performance / Reliability / Compatibility /Testability.
Product Overview
Areca-Backup is a file backup software that supports incremental, image and delta backup on local drives or FTP servers.
Testers
Ajay Balamurugadas, Vasupratha, Bhargavi, Sudhakar, Gunjan, Parimala Shankaraiah.
Reports
My Report
Ajay's Report
Approach
The beauty of BWT 8 lay in the fact that there was a flexibility to choose the mission by selecting any one of the Quality Criteria listed: Installability / Usability / Performance / Reliability / Compatibility / Testability. Previously, I was fascinated by the results of testing Nokia 1650 Insert Options by breaking down the feature sets and choosing one small testing chunk to test. I wanted to learn to better my previous testing performance. I chose Installability as the quality criteria - something that I had not tested earlier in session based format. I set out to test and loved the entire experience.
One thing I noticed in this session was that a few testers chose the much known, much easier quality criteria. In short, they chose to be in their comfort zones. Please note that if any product is given to test with a vague mission like find bugs in the product, we as humans have a normal tendency to choose areas that we are comfortable with. For eg. I love functional and usability testing and I would just jump at any opportunity to do just this . Over a period of time, I realized that other areas like performance, claims, reliability, compatibility etc are important as well based on what the stakeholder demands. Hence, as a tester, it is good to have basic skills in different test techniques if not great skills. This in turn can be improved over a period of time by practicing more and more.
The best way to learn is to push yourself out of your comfort zone. Test what you are not sure about. Test what you do not know about. Test what you have not heard about. Ask questions. Find answers. Question your answers. And ask more questions. The final answer could be well within your reach. You be your first critic.
Advantages of testing smaller chunks of the product
1. Brainstorming one feature/task results in an umpteen number of test ideas
2. Improved Focus on a single feature/task
3. Adequate testing can be done in a 90 – 120 minutes session
4. Finding lot more valuable and hidden bugs (bugs hungry? – Naa!)
5. Highly buggy features can be retested in future sessions possibly in short session say 60 minutes
If you have tried testing by breaking testing tasks into smaller chunks, feel free to add to the above list.
Get Uncomfortable Today,
Parimala Shankaraiah
http://curioustester.blogspot.com
25 September, 2009
Which School do you belong to?
No. I am not talking about the elementary school that you studied at. I am talking about the School of Software Testing you belong to? I am inspired to write this after James mentioned in one of his recent posts that he was not sure if I think of myself as context-driven. I do think of myself as Context-Driven and I am proud to be a part of the Context Driven School of Testing.
The Seven Basic Principles of the Context-Driven School as listed on the Context Driven Testing website:
1. The value of any practice depends on its context.
2. There are good practices in context, but there are no best practices.
3. People, working together, are the most important part of any project's context.
4. Projects unfold over time in ways that are often not predictable.
5. The product is a solution. If the problem isn't solved, the product doesn't work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
Do you see the Freedom and Responsibility that is available in this school of testing? Is this what you have been yearning for? Figure it out yourself. For more information on Context Driven Testing, please visit HERE. A MUST READ for all the context driven testers.
Happy Reading,
Parimala Shankaraiah
http://curioustester.blogspot.com
The Seven Basic Principles of the Context-Driven School as listed on the Context Driven Testing website:
1. The value of any practice depends on its context.
2. There are good practices in context, but there are no best practices.
3. People, working together, are the most important part of any project's context.
4. Projects unfold over time in ways that are often not predictable.
5. The product is a solution. If the problem isn't solved, the product doesn't work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
Do you see the Freedom and Responsibility that is available in this school of testing? Is this what you have been yearning for? Figure it out yourself. For more information on Context Driven Testing, please visit HERE. A MUST READ for all the context driven testers.
Happy Reading,
Parimala Shankaraiah
http://curioustester.blogspot.com
21 September, 2009
Pair Testing - II
The last time I took up Pair Testing was while testing Vischeck with Ajay Balamurugadas. We had teamed up on Gmail chat, tested the product in a given timeframe and shared our learnings. If you visit the comments of this post, you will realize how I goofed up my learning by completely misunderstanding the product that I tested (I intentionally have these comments in place to remind me not to repeat this mistake).
I got another opportunity to learn with a tester friend Bhargavi M who teamed up with me for Pair testing. The best part was that we got together at one place instead of Gmail chat. We mutually agreed to test ‘Play’ option in Windows Media Player. While Bhargavi(in this case, the tester) took over the keyboard to test Windows Media Player > Play option, I(in this case, the reviewer) chose to analyst and review the tests in addition to brainstorming additional ideas which Bhargavi might miss(potential misses and not intentional misses). At the end of the session, we had tested all the ideas that both of us had come up with. Please find the report HERE.
Learnings from Pair Testing
1. It is a good learning to let the tester take complete control to test while the reviewer observes/takes down notes/reviews the testing process. This is a very good way for the reviewer to learn how different the thought process of the tester is. This also points to areas where the reviewer needs to improve to test better.
2. It is a good learning for the tester to learn and understand which areas/test ideas were missed, but caught by the reviewer during the note taking process. It helps the tester to observe and learn where he/she failed to identify the test ideas that reviewer captured.
3. It is a challenge to think in diverse ways and execute all the test ideas all alone. Pair Testing is advantageous in that it is two pairs of eyes which is testing the application instead of just 1 pair of eyes AT THE SAME TIME. This not only helps in finding issues, but also enhances the investigative nature of the tester and the reviewer as they would keep on building on the test ideas one by one. If the tester missed something, there is a high probability that the reviewer would have caught this and vice versa.
4. Pair testing gives more insight into the tester's scenario testing process. Each tester’s thinking and understanding about scenario testing is different and hence executed differently.
5. Pair testing yields good benefits when the tester and the reviewer’s skills complement each other. If both end up being similar personalities with same set of skills, knowledge, intuition etc, they might end up missing critical bugs which would have been caught as a result of their diverse nature.
6. Pair testing is different from Pairwise testing.
NOTE: I have called one person as the tester and the other as the reviewer because the reviewer's job is mainly to note down observations and add new test ideas. However, the reviewer can contribute to the testing at any time.
Thanks to Bhargavi M for the wonderful Pair Testing Experience.
Addendum on 6th Oct 2009
A good document on Exploratory Testing in Pairs.
Happy Pairing,
Parimala Shankaraiah
http://curioustester.blogspot.com
I got another opportunity to learn with a tester friend Bhargavi M who teamed up with me for Pair testing. The best part was that we got together at one place instead of Gmail chat. We mutually agreed to test ‘Play’ option in Windows Media Player. While Bhargavi(in this case, the tester) took over the keyboard to test Windows Media Player > Play option, I(in this case, the reviewer) chose to analyst and review the tests in addition to brainstorming additional ideas which Bhargavi might miss(potential misses and not intentional misses). At the end of the session, we had tested all the ideas that both of us had come up with. Please find the report HERE.
Learnings from Pair Testing
1. It is a good learning to let the tester take complete control to test while the reviewer observes/takes down notes/reviews the testing process. This is a very good way for the reviewer to learn how different the thought process of the tester is. This also points to areas where the reviewer needs to improve to test better.
2. It is a good learning for the tester to learn and understand which areas/test ideas were missed, but caught by the reviewer during the note taking process. It helps the tester to observe and learn where he/she failed to identify the test ideas that reviewer captured.
3. It is a challenge to think in diverse ways and execute all the test ideas all alone. Pair Testing is advantageous in that it is two pairs of eyes which is testing the application instead of just 1 pair of eyes AT THE SAME TIME. This not only helps in finding issues, but also enhances the investigative nature of the tester and the reviewer as they would keep on building on the test ideas one by one. If the tester missed something, there is a high probability that the reviewer would have caught this and vice versa.
4. Pair testing gives more insight into the tester's scenario testing process. Each tester’s thinking and understanding about scenario testing is different and hence executed differently.
5. Pair testing yields good benefits when the tester and the reviewer’s skills complement each other. If both end up being similar personalities with same set of skills, knowledge, intuition etc, they might end up missing critical bugs which would have been caught as a result of their diverse nature.
6. Pair testing is different from Pairwise testing.
NOTE: I have called one person as the tester and the other as the reviewer because the reviewer's job is mainly to note down observations and add new test ideas. However, the reviewer can contribute to the testing at any time.
Thanks to Bhargavi M for the wonderful Pair Testing Experience.
Addendum on 6th Oct 2009
A good document on Exploratory Testing in Pairs.
Happy Pairing,
Parimala Shankaraiah
http://curioustester.blogspot.com
17 September, 2009
Indian Testing Renaissance
I wanted to share some good news with you – my blog readers (both silent readers and commenters) who are taking time to read my blog and even go a step ahead by commenting about my work.
Firstly, James Bach talked about me and my work in one of his recent posts' titled New Voice: Parimala Shankaraiah. My blog now sits on James Bach’s blogroll. I am thrilled! Appreciation from James is very special because I have admired James Bach , Cem Kaner, Michael Bolton , Pradeep Soundararajan and many more great testers as my Role Models. With this appreciation comes an added responsibility on my shoulders to do more for the betterment of the tester in me and for the testing community as well. Thank You James!
Secondly, I won a Honorable Mention prize in the recently announced uTest Q3 2009 Bug Battle results.
These recognitions are special to me for 2 reasons:
1. Appreciation at the global level(not just for me, but for Indian Testers in general) – a few more people might get to know not just about Parimala Shankaraiah and her work, but Indian testers in general and the challenges they are facing. I am a little thirsty for more people to know us right now because I want more and more people to check out and critique our work in addition to all the self criticism that we do for our own good. I have seen this helping a lot. Just recently, It took me about 2 hours to reply to one of my blog reader's comments. In those 2 hours, I learned so many new things and got so many questions. It was a great lesson indeed.
2. The email sent by the uTest team sharing the results of Q3 2009 bug battle read ‘Congratulations! You are a winner in our Honorable Mention category for the latest Bug Battle! Although this was not a planned prize category, we want to recognize the quality of your bug reports and feedback'. Wow! I am not sure if they sent the same email to everyone who got a similar prize! No offense Meant!
My heart bleeds to see and hear bad things about Indian testers(including me) who are loathed for doing shabby testing, for blindly following test scripts for the fear of getting fired, not innovating on how better testing can be and many more. I do understand and respect the downside to bringing any changes in Indian Testing Organizations. Right now, while I am typing this, If I have to talk to my management about Exploratory testing and ask them to let go of those dirty and obsolete test scripts, I know how strongly I am going to be opposed and I know how difficult it is going to be doing this by myself all alone. One way to overcome this is to build more and more context driven testing groups in whatever small way each of us can and spreading the network (Never mind if it is slow and quiet as long as there is perserverance and no giving up!). This network will one day prove how better testing can get. I get goosebumps while I visualize that day. Dear Testers, Spread the word in your own small way!
Happy Networking,
Parimala Shankaraiah,
http://curioustester.blogspot.com
Firstly, James Bach talked about me and my work in one of his recent posts' titled New Voice: Parimala Shankaraiah. My blog now sits on James Bach’s blogroll. I am thrilled! Appreciation from James is very special because I have admired James Bach , Cem Kaner, Michael Bolton , Pradeep Soundararajan and many more great testers as my Role Models. With this appreciation comes an added responsibility on my shoulders to do more for the betterment of the tester in me and for the testing community as well. Thank You James!
Secondly, I won a Honorable Mention prize in the recently announced uTest Q3 2009 Bug Battle results.
These recognitions are special to me for 2 reasons:
1. Appreciation at the global level(not just for me, but for Indian Testers in general) – a few more people might get to know not just about Parimala Shankaraiah and her work, but Indian testers in general and the challenges they are facing. I am a little thirsty for more people to know us right now because I want more and more people to check out and critique our work in addition to all the self criticism that we do for our own good. I have seen this helping a lot. Just recently, It took me about 2 hours to reply to one of my blog reader's comments. In those 2 hours, I learned so many new things and got so many questions. It was a great lesson indeed.
2. The email sent by the uTest team sharing the results of Q3 2009 bug battle read ‘Congratulations! You are a winner in our Honorable Mention category for the latest Bug Battle! Although this was not a planned prize category, we want to recognize the quality of your bug reports and feedback'. Wow! I am not sure if they sent the same email to everyone who got a similar prize! No offense Meant!
My heart bleeds to see and hear bad things about Indian testers(including me) who are loathed for doing shabby testing, for blindly following test scripts for the fear of getting fired, not innovating on how better testing can be and many more. I do understand and respect the downside to bringing any changes in Indian Testing Organizations. Right now, while I am typing this, If I have to talk to my management about Exploratory testing and ask them to let go of those dirty and obsolete test scripts, I know how strongly I am going to be opposed and I know how difficult it is going to be doing this by myself all alone. One way to overcome this is to build more and more context driven testing groups in whatever small way each of us can and spreading the network (Never mind if it is slow and quiet as long as there is perserverance and no giving up!). This network will one day prove how better testing can get. I get goosebumps while I visualize that day. Dear Testers, Spread the word in your own small way!
Happy Networking,
Parimala Shankaraiah,
http://curioustester.blogspot.com
15 September, 2009
Session Based Testing – Nokia 1650
I have not explicitly tested mobile devices though I have found issues on different types of cell phones that I have used in the past. This gave me an idea to test Nokia 1650 model cell phone that I own currently. I chose to test the 'Insert Options' feature in Create Message functionality. I quickly glanced through the Insert Options feature at a high level, broke it down into different types of Insert options available (smileys, words, numbers, symbols and templates), how different these options are when the dictionary is on and the language chosen is English or Hindi, how different is the behavior if the dictionary is turned off, what are the effects of changing the text format to different sentence cases like uppercase, lowercase and title case. The testing checklist was ready. Please find it HERE.
As the session unfolded, I tested dictionary on (English), dictionary on(Hindi) and dictionary off sub-features. I referred to the checklist from time to time to ensure that I was focusing on the charter and not deviating from it at any point. For eg. When I was testing the Insert Options with dictionary On(Hindi), I found that the Create Message > Options feature has 4 additional options like Text: A B C, Text: a b c, Numbers: 1 2 3 and Insert Symbol. I was surprised because these were already available in the Insert Options. Redundant feature? May be. This was a guaranteed deviation from my current charter and hence I noted it down as an opportunity and continued testing. Please find the Session Based Test Report is HERE.
My Learnings:
1. It is a good idea to break the charter of the session to the smallest possible task(chunk) so as to focus and test it adequately(Note that I am not using the word completely).
2. I can get rid of a separate testing checklist document by adding the checklist items in the Task Breakdown section of the Session Based Test report.
3. Any activity related to this testing session should be done within the duration that was originally planned.
4. Opportunities play a spoilsport by deviating the tester from the charter unless the tester gives in to it resulting in boondoggle.
5. Opportunities in current session (outside of the current charter) can become the charters for future sessions.
6. Test Notes section should have information about observations and inferences made while exploring, understanding and testing the product. Any bug should get to the Bugs sections and queries if any should get to the Issues sections.
7. Add Risk field to talk about the risk associated with each bug(the risk of not getting the bug fixed) and the Customer Impact field to talk about any possible impact to the customer. In general, It would be nice to add Risk, Customer Impact and Oracle/Heuristic fields to indicate why and how the bug was found (OK, I am tweaking the original template suggested by Jonathan Bach).
8. Issues in the Issues section should be followed up without fail with developers and product management teams for further clarity and follow up testing in a separate session.
Ever since I read Jonathan Bach’s article on Session Based Test Management, I have been thinking how it can be adopted in any company which takes the conventional route to testing. Can you dare to tell your manager that you will no longer write test cases? Can you tell your manager that he/she cannot generate any reports automatically anymore? Can you tell them that you test some areas here and there(explore), but nothing in particular? Can you just convince your manager about your work just by showing the bugs you have filed? What if you did not find any bugs? According to the conventional testers, the main problems with Exploratory testing is that it is not measurable, auditable and manageable. If you read Jonathan Bach’s article above, you will come to know that these ‘so called’ problems are not problems at all. I will work on answering the above questions by writing a follow up post to this in the near future. In the meantime, if you want to answer them, please feel free to add them in the comments section.
Happy Testing,
Parimala Shankaraiah,
http://curioustester.blogspot.com
As the session unfolded, I tested dictionary on (English), dictionary on(Hindi) and dictionary off sub-features. I referred to the checklist from time to time to ensure that I was focusing on the charter and not deviating from it at any point. For eg. When I was testing the Insert Options with dictionary On(Hindi), I found that the Create Message > Options feature has 4 additional options like Text: A B C, Text: a b c, Numbers: 1 2 3 and Insert Symbol. I was surprised because these were already available in the Insert Options. Redundant feature? May be. This was a guaranteed deviation from my current charter and hence I noted it down as an opportunity and continued testing. Please find the Session Based Test Report is HERE.
My Learnings:
1. It is a good idea to break the charter of the session to the smallest possible task(chunk) so as to focus and test it adequately(Note that I am not using the word completely).
2. I can get rid of a separate testing checklist document by adding the checklist items in the Task Breakdown section of the Session Based Test report.
3. Any activity related to this testing session should be done within the duration that was originally planned.
4. Opportunities play a spoilsport by deviating the tester from the charter unless the tester gives in to it resulting in boondoggle.
5. Opportunities in current session (outside of the current charter) can become the charters for future sessions.
6. Test Notes section should have information about observations and inferences made while exploring, understanding and testing the product. Any bug should get to the Bugs sections and queries if any should get to the Issues sections.
7. Add Risk field to talk about the risk associated with each bug(the risk of not getting the bug fixed) and the Customer Impact field to talk about any possible impact to the customer. In general, It would be nice to add Risk, Customer Impact and Oracle/Heuristic fields to indicate why and how the bug was found (OK, I am tweaking the original template suggested by Jonathan Bach).
8. Issues in the Issues section should be followed up without fail with developers and product management teams for further clarity and follow up testing in a separate session.
Ever since I read Jonathan Bach’s article on Session Based Test Management, I have been thinking how it can be adopted in any company which takes the conventional route to testing. Can you dare to tell your manager that you will no longer write test cases? Can you tell your manager that he/she cannot generate any reports automatically anymore? Can you tell them that you test some areas here and there(explore), but nothing in particular? Can you just convince your manager about your work just by showing the bugs you have filed? What if you did not find any bugs? According to the conventional testers, the main problems with Exploratory testing is that it is not measurable, auditable and manageable. If you read Jonathan Bach’s article above, you will come to know that these ‘so called’ problems are not problems at all. I will work on answering the above questions by writing a follow up post to this in the near future. In the meantime, if you want to answer them, please feel free to add them in the comments section.
Happy Testing,
Parimala Shankaraiah,
http://curioustester.blogspot.com
14 September, 2009
Book Review: The Secret
Off late, I have been busy reading a book and a few testing related articles (I am amazed by the amount of information that comes absolutely FREE on the internet for people to read, learn, think and practice!). Reading is something I love to do if I get some free time. This is also one of my ways of relaxing. I recently read a book ‘The Secret’ by Rhonda Byrne. You must have heard of the 90/10 principle: “10% of life is made up of what happens to you. 90% of life is decided by how you react”. ‘The Secret’ tells you that you decide what happens to you 100%! My favourite phases from the book and the corresponding testing analogies are listed below:
1. Thoughts are magnetic and thoughts have a frequency. As you think thoughts, they are sent out into the universe, and they magnificently attract all like things that are on the same frequency. Everything sent out returns to the source
Testing Analogy: Bugs are magnetic and bugs have a frequency. Every bug returns to the source which is the product and You who is the tester of the product.
2. The law of attraction says like attracts like, so when you think a thought, you are also attracting like thoughts to you
Testing Analogy: Good testers attract good bugs. When you think more bugs, you attract more bugs. Note that a tester does not improve the quality of the product. A tester provides vital information about the product based on which quality decisions can be made.
3. Nothing can come into your experience unless you summon it through persistent thoughts.
Testing Analogy: Summon every bug in the product through persistence!
4. You can start with nothing, and out of nothing and out of no way, a way will be made.
Testing Analogy: You can start with testing a product, and out of nothing(buggy product) and out of no way(coverage), bugs will be made.
5. Expectation is a powerful attractive force. Expect the things you want, and don’t expect the things you don’t want.
Testing Analogy: Expect to understand and learn the product, expect to understand the users, expect the product to be of good quality before it is shipped. Do not expect that you cannot find any more bugs in the product ever. Never say never.
6. Treat yourself with love and respect, and you will attract people who show you love and respect.
Testing Analogy: Do you love the tester in you? If you do, then others will love and respect the tester in you too.
7. Do not listen to society’s messages about diseases and aging. Negative messages do not serve you.
Testing Analogy: Do not listen to scripts, do not listen to the traditional education, testing methodologies and training systems, do not give in to aging of the time and the mind. Just listen to the Voice within You – that you can better yourself with every testing effort that you take up.
8. What you resist persists
Testing Analogy: If you resist bad quality, it persists. If you expect the product to be of good quality, it persists. What do you want to persist?
9. Let go of difficulties from your past, cultural codes, and social beliefs. You are the only one who can create the life you deserve.
Testing Analogy: Let go of conventional testing. Break the chains, take the Exploratory Path!
Happy Reading,
Parimala Shankaraiah
http://curioustester.blogspot.com
1. Thoughts are magnetic and thoughts have a frequency. As you think thoughts, they are sent out into the universe, and they magnificently attract all like things that are on the same frequency. Everything sent out returns to the source
Testing Analogy: Bugs are magnetic and bugs have a frequency. Every bug returns to the source which is the product and You who is the tester of the product.
2. The law of attraction says like attracts like, so when you think a thought, you are also attracting like thoughts to you
Testing Analogy: Good testers attract good bugs. When you think more bugs, you attract more bugs. Note that a tester does not improve the quality of the product. A tester provides vital information about the product based on which quality decisions can be made.
3. Nothing can come into your experience unless you summon it through persistent thoughts.
Testing Analogy: Summon every bug in the product through persistence!
4. You can start with nothing, and out of nothing and out of no way, a way will be made.
Testing Analogy: You can start with testing a product, and out of nothing(buggy product) and out of no way(coverage), bugs will be made.
5. Expectation is a powerful attractive force. Expect the things you want, and don’t expect the things you don’t want.
Testing Analogy: Expect to understand and learn the product, expect to understand the users, expect the product to be of good quality before it is shipped. Do not expect that you cannot find any more bugs in the product ever. Never say never.
6. Treat yourself with love and respect, and you will attract people who show you love and respect.
Testing Analogy: Do you love the tester in you? If you do, then others will love and respect the tester in you too.
7. Do not listen to society’s messages about diseases and aging. Negative messages do not serve you.
Testing Analogy: Do not listen to scripts, do not listen to the traditional education, testing methodologies and training systems, do not give in to aging of the time and the mind. Just listen to the Voice within You – that you can better yourself with every testing effort that you take up.
8. What you resist persists
Testing Analogy: If you resist bad quality, it persists. If you expect the product to be of good quality, it persists. What do you want to persist?
9. Let go of difficulties from your past, cultural codes, and social beliefs. You are the only one who can create the life you deserve.
Testing Analogy: Let go of conventional testing. Break the chains, take the Exploratory Path!
Happy Reading,
Parimala Shankaraiah
http://curioustester.blogspot.com
10 September, 2009
Dead Links Test using Xenu’s Link Sleuth
Dead Link
A dead link also called a broken link or dangling link is a link on the World Wide Web that points to a web page or a server that is permanently unavailable. Though nobody explicitly complained about any dead links on my blog, I did not want to assume that all is well. I went ahead and performed a deadlink test out of curiousity :-)
Dead Link Test
Dead Link Tests are very important to identify the dead or broken links on the World Wide Web. This is one of the important tests while testing websites. It is very tedious to go through each and every link to check whether it is alive or dead. Several tools are available at no charge or at a cost to help testers with the dead link tests.
Dead links can be internal or external links. Internal links are the hyperlinks that refer to elements present within the website or domain of the internet. External links are the hyperllinks that refer to elements present outside of the website or domain of the internet. For eg, if you consider any blog, all the hyperlinks that reference to anything on the same blog are considered as Internal links. All the hyperlinks that reference to anything on other blogs other than this blog are considered as External links.
Xenu's Link Sleuth
Xenu's Link Sleuth checks Web sites for broken links. Link verification is done on "normal" links, images, frames, plug-ins, backgrounds, local image maps, style sheets, scripts and java applets. It displays a continously updated list of URLs which you can sort by different criteria. A report can be produced at any time. This software is a freeware that can be downloaded from HERE.
Dead Links Statistics on Curious Tester
1. Internal dead links: None
2. External dead links: 4
PS: Token of Thanks to Alan Jorgensen for introducing me to this tool.
Addendum on 11th Sep 09:
When it comes to tracking test coverage in product testing, Testing Checklists(either in MS Word or Excel) come very handy. One really good feature that I observed in the reports generated by Link Sleuth is the data presented in 'Site Map of valid HTML pages with a title' section. This can act as a good base for creation of Testing Checklists while testing the website as a whole. This is very useful for testers who start off with a high level checklist before starting with product testing.
Happy Exploring,
Parimala Shankaraiah
http://curioustester.blogspot.com
A dead link also called a broken link or dangling link is a link on the World Wide Web that points to a web page or a server that is permanently unavailable. Though nobody explicitly complained about any dead links on my blog, I did not want to assume that all is well. I went ahead and performed a deadlink test out of curiousity :-)
Dead Link Test
Dead Link Tests are very important to identify the dead or broken links on the World Wide Web. This is one of the important tests while testing websites. It is very tedious to go through each and every link to check whether it is alive or dead. Several tools are available at no charge or at a cost to help testers with the dead link tests.
Dead links can be internal or external links. Internal links are the hyperlinks that refer to elements present within the website or domain of the internet. External links are the hyperllinks that refer to elements present outside of the website or domain of the internet. For eg, if you consider any blog, all the hyperlinks that reference to anything on the same blog are considered as Internal links. All the hyperlinks that reference to anything on other blogs other than this blog are considered as External links.
Xenu's Link Sleuth
Xenu's Link Sleuth checks Web sites for broken links. Link verification is done on "normal" links, images, frames, plug-ins, backgrounds, local image maps, style sheets, scripts and java applets. It displays a continously updated list of URLs which you can sort by different criteria. A report can be produced at any time. This software is a freeware that can be downloaded from HERE.
Dead Links Statistics on Curious Tester
1. Internal dead links: None
2. External dead links: 4
PS: Token of Thanks to Alan Jorgensen for introducing me to this tool.
Addendum on 11th Sep 09:
When it comes to tracking test coverage in product testing, Testing Checklists(either in MS Word or Excel) come very handy. One really good feature that I observed in the reports generated by Link Sleuth is the data presented in 'Site Map of valid HTML pages with a title' section. This can act as a good base for creation of Testing Checklists while testing the website as a whole. This is very useful for testers who start off with a high level checklist before starting with product testing.
Happy Exploring,
Parimala Shankaraiah
http://curioustester.blogspot.com
Subscribe to:
Posts (Atom)