The domain particle

The inspiration


The title is inspired from Angels & Demons where they talk about the "God particle". The topic is  inspired by so many testers asking or answering to, "How much important is domain knowledge?", "Can we test without domain knowledge?", "What happens if we test a product or technology without domain knowledge?" ... 


Every person who writes in public and in forums have been asked these questions about the importance of domain knowledge to test a product. Going through those forums, you'd know that there are answers like : Yes, domain knowledge is very important to test a product OR Oh yeah, you know without domain knowledge I couldn't have found the show stopper I found a few days back...and others saying, "I did manage to learn quickly, so it doesn't matter as long as you too can", "I think it depends on what you are testing"... 


Passing time by failing to respect others time


The question I have to most testers out there is. If we, who reply to all those questions of yours, say that it is very important that you should be an expert of the domain to test the product, are you really going to become one or even try to? 


You are aware that bug investigation skills are important, without we having to say that, what have you done about that? or would you go pick up the test framing skills?


I am convinced that there are many hundreds and thousands of testers who are a trap not just to themselves but to others wanting to help testers. Every testing related forum is infected with people asking questions who actually don't intend to do anything about it despite unintentionally (or maybe intentionally) wasting a lot of passionate testers time & energy. There are genuine people in there but in a rare occurrence. Most genuine people aren't asking questions but answering them and not all who answer questions are genuine. You may want to consider me among those who are answering questions but not genuine, if that pleases your ego.


I have respect for CDT mailing list and Software Testing Club. There are serious people, asking, answering and watching. I just hope there are a few more forums like that.


Why do we have labels?


Some testers are in a trap of calling themselves "Telecom testers", "BFSI testers", "Web App testers", "Mobile App Testers", and what not? The question I have is, should it matter? BTW, I call myself an exploratory tester because its an approach I follow to test any software & not a domain.


As how programming is a mindset and a good programmer wouldn't call themselves "Java only programmer", testing is a mindset too. Oh, there is a skillset along with the mindset.


Henrik Andersson of Sweden is going to do a Webinar on October 12 : Do we need labels? Are we all not testers? I read the abstract of the webinar and was excited. I envy Henrik a lot. He is the guy who is blessed to be in the happening places - be it PSL, AYE or CAST. Other than that he is the energetic test consultant & partner at a testing consulting firm based in Sweden. I think you all should register and listen to what Henrik has to say. 


Henrik made me ask these questions: Why am I calling myself an exploratory tester, rapid tester, and whatever fancy stuff I had been calling myself when I know all testing is to some degree exploratory? What is the need for me to do so?


I need a label to differentiate myself or to communicate to people what I specialize at. My label helps my potential clients to gain interest to check about my services based on their needs. My label acts as a filter. People know what questions to shoot me. So far I have received very few emails from people asking if I can help them record and play QTP scripts. Most emails are about seeking help on how to develop themselves, think & test. I love to talk to them because they teach me things I want to learn.


So, I see label as a filter but I am against the labels that filter my own opportunities to learn. For instance, if I call myself a "Multimedia Tester", I would have blocked my learning on many technologies and contexts that I have experienced. I am starting to use "Brainual tester" these days. I am also giving a lightning / lightening talk in GTAC this year about it. James calls it Sapient and I call it Brainual. We both worship the same God but we call them in different names. I prefer the word "Brainual" because it is quicker to replace the word "Manual" to those who see "Manual" as a hand activity of testers than brain. People are used to saying, "Lets automate those manual test cases" but I expect the reluctance to set it to say, "Lets automate the brainual work thats being done now".  Their own ego would hurt them. They don't want to be seen as a fool.




Filter-less


Being a consultant and added to that the twist and turns I have had in my testing life has got me to test software ranging from wireless, mobile applications, medical devices, multimedia, Retail, CRM, desktop applications, dating applications, billing solutions, video surveillance, stock market, auction systems, kiosks, cloud computing, testing tools, games and what not. I have never bothered what domain each of them belong to as long as I have 

• An understanding of general principles of how software works (which I constantly refine)
• A skill to quickly learn and convert the learning to tests & churn more learning out of it.
• Ability to build models of learning to speed up my learning.

I try understanding how people who invented things might have thought. I fancy thinking that all these technologies have emerged out of observing something. Some of the key observations about human being and living things have led to many inventions and discoveries. Should I tell you that birds were an inspiration for Wright Brothers?


The human connection to technology


# 1 DHCP as to how it has evolved out of human behavior : When we go to the theater to watch a movie, we ask the personnel at the ticket counter to check if there are tickets available for a specific movie (sending request from a client to the server) of what we want to watch and our preferred time (details about client to see if server has anything for us). 

The ticket counter personnel in the theater gives us a ticket based on availability (assigning an IP address from the available pool) with the seat numbers to watch the movie.

In the ticket, there exists a seat number ( IP address ), duration of validity ( lease period ). If you prefer to watch the movie again and in the same seats ( Static IP ) you need to advance book or renew your tickets  
( ipconfig / renew )


# 2 Why do connectors have a male pin & a female pin? How did gender come in to technology without having observed humans and how they interact?


I have a huge list of things that computers/ technologies do which are based on how humans communicate or how humans could have. Think of SIP protocol or a client server host architecture and relate it to human communication. You'd probably enjoy as much as I do.


Simplification


In Rapid Software Testing class of  Michael Bolton & James Bach, there is an interesting dice exercise. I didn't crack it the first time but on learning the meta pattern, I am likely to crack it for any pattern or will get closer to solving it.


I have my own version of the dice game but with a different learning objective - simplicity. Based on running the exercise on thousands of testers in India (and a few folks outside India), I am making a conjecture that I see people struggling to cope up with simplicity. 


The first set of thoughts that comes to a human mind is not necessarily simple and the next set of thoughts are usually more complex than the previous ones. So, I think humans keep building on the already existing complexity of their previous thought.


Unless you train your brain to think simple, you are unlikely to crack many things you can.


The reason I am telling this here is because those who set out to learn a new domain forget that there are simpler sub systems of the domain they already know either because they also exist in other domains they have tested or have used such products extensively. You may want to figure out the meta pattern of software & how they are supposed to work. 




Practice to be fit

Quoting Parimala, "What you know is not as important as what you can do with what you know". 

I run an exercise in my workshop in which I allow people to do freestyle exploratory testing. At the end I ask them the techniques they consciously used while testing. Although many of them know many techniques to test, at least the first 10 minutes of most testers freestyle exploratory testing is, "Clicking here and there to see if a bug dances out on the screen" If a few bugs do dance, "Wow, you see I did exploratory testing". I think of that as an inferior self standard setting to understanding exploratory testing.  


How do we use what we already know to achieve better results? PRACTICE!


The biggest shame for ISTQB / CSTE certification bodies doesn't come from those who oppose it but from those who are certified & don't show traces of having gained anything from it. I have consulted at least for a few organizations here in India who hire these certified testers. Not a single test case document that these certified testers have produced has anything related to what they might have learned from the certification. 


There is a scripted test design technique that is a best practice and the most widely used one although it doesn't have a name - copy paste a sentence of requirement document into expected results column and then write the test steps accordingly. This is the most successful trick ever invented in testing. 


As a side note: Do you play any outdoor sport? Have you taken a long break from it and then went back to it? You might have been good at it at some point but when you get back after a break, you no longer feel the same comfort you had. If I were to speak to Indian testers alone for a moment, how does it feel to hold a cricket bat and face a fast bowler after taking a break from cricket? 


Bits & Pieces


I admire ants. They have a way to deal with problems. They don't say, "Oh my God! That cake is about 1000 times bigger than my size. How can I eat it?". They break the huge cake into bits that they can process, carry it home and then come back for the next bit. Doing it bit by bit helps them to achieve the goal of moving the entire cake into their colony.


While testing a product whose domain / technology that I don't know, I try to remember the ants. I learn one bit, use that bit to frame tests. The tests I perform with the bit I learned, help me learn about more bits of the system and I choose to eat bit by bit or byte by byte if my mouth has got bigger.


I may know nothing about a system when I start but at the end I can learn so much about it that it would amaze me or my audience if I tell what I discovered going bit by bit. I demonstrated this in one of the workshops where I learnt the user base of the website, traced the kind of users, identified why those users might be coming to the site, what kind of problems such users might be facing, what kind of tests to be run, what could be the most important problems that is making the audience to not give more sales + found 14 issues + 10 questions to the developers - all in one hour. I had enough feedback to the development team that they got busy working on a few things that gave me the time I wanted to go learn what I wanted about the product.


Live oracles


What are the business analysts doing? Are your sales and marketing folks so busy that they don't have time for you? How much do you interact with them? Have you invited them for a paired testing? Have you talked to them about the importance of they being with you for an hour in a month while you are testing?


If that's one set of questions, here is another set: Why in the world do you want to know everything about a domain when you know its not possible for any human being to do that?


Fooled by foolishness


Some organizations who hire testers only because of their domain knowledge, are fooled in other ways such as, those testers probably know little about testing to be called as testers. Its opportunity cost. I have spent all my time trying to be a better tester, you ask me to troubleshoot a network router, I may end up testing it or learning about it by testing it. Ask a network admin to test a router, she may end up troubleshooting or reconfiguring it.


Some organizations who continue to think that domain knowledge is the most important skill for a tester to even apply or be interviewed by them are blind to the fact that most issues that their customers are reporting has probably got nothing to do with having testers with extreme domain knowledge in the team.


There are tons of testing problems these organizations are not paying attention to, while they see their problems are because they don't have enough testers with enough domain knowledge.

Everyone of us choose to be not fooled by something and that exposes us to be fooled by something else.

The domain particle


Do you have a domain particle that makes you think "domain knowledge" is the important thing for a tester to perform well? 


I don't want to take it out. I want it to be there so that I can help you mutate it. If you could help yourself mutate it, and make the domain "learning" instead of "BFSI", "Telecom", "Multimedia", "Whatever"... I think you would have cracked what you are likely to in 20 years from now. That's an opportunity to be wise without needing to age for that.


Did you say that?


Those who speak about exploratory testing are asked, "Are you saying there is no value for scripted testing?". Those who speak about using brains to test are asked, "Are you saying there is no value in automating tests?". Those who speak about Check Automation are asked, "Are you saying checks are not tests?" while the speaker/author didn't mean any of that. Those who speak against certification are asked, "Are you saying people shouldn't get certified at all?". Those who speak about wasteful documentation are asked, "Are you saying documenting is a bad idea?". Reading some of the above paragraphs, some of you might have had a question, "Are you saying all ISTQB/CSTE testers don't know test design?"


So, whatever anyone says, there is a group of testers aggressively waiting to ask such questions. They are not doing anything wrong. They are just being themselves. Some representatives of the group are likely to ask me, "Are you saying domain knowledge is not needed to test the product?" and I am going to punish them by asking them to re-read this big post.


BTW, I am looking to hire testers of Banking / Web Application domain testers. Please send me your resume as soon as possible. 


Also, if you are a tester from Hyderabad and want to meet Rahul Verma, Dhanshekar and yours truly on 27th evening, email me. We wont mutate your particles! We will be attending Google Test Automation Conference in Hyderabad. 


Post bio for my self reference: Took 5 days to write the first draft, changed the style and contents 3 times, 1 external review, 3 self review, 5 hours of editing and finally publishing it. Published from my cousin's place in Delhi. Laptop: IBM Thinkpad

Why testers need to learn to write code that works?

One of the things you thought I don't do often as a tester is - to write code. You are not completely wrong. I immersed myself all these days trying to be a tester who is /mostly/ black-boxish and interacts with the software through GUI. Did you read it as, "A black box tester doesn't need to write code?". Stop reading it that way! Read a sentence the way it is written and not the way you expect someone else to make a mistake that you like them to do.

You shouldn't be surprised to know that in the past I have written little tools, utilities and batch scripts that helped me or a test team I worked with. At the worst case I used to edit those scripts written by others to suit my needs or the mission. No matter how small they were, the value was the key.

Perl has been my favorite (you think I explored others enough, nah) since I first discovered it being used to automate checks in my first job. A couple of weeks back I decided to focus on shaping myself to be a tester who can write code in Perl for automating checks for most kinds of software I test. Irrespective of whether I am hired to do so or not, I'd want to be equipped.

In order to practice stuff that I learn in Perl, I decided to create exercises, puzzles and games for testers. That way I am trying to have more fun learning Perl. Perl itself is fun in its true nature and imagine adding more fun to it.

So wanna check out the puzzle I have for you? Hold on, don't be in a hurry.

Weekend Testing : 16 : Test and Experience Report

Mission: To find three conditions where Defender wins, Defender loses, and Neither Defender wins nor Attacker Wins for SpeedSim.

Deliverable: Send the combat report of the simulated battle for each of the conditions in a zip file.

Tester: Pradeep Soundararajan
Time: 3:00 PM IST , 28th Nov, 2009

Later there were more missions that were added (bad I didnt pay much attention but was able to recover quickly )

Notes:

# I downloaded the application and asked questions about the version of the file before I installed.
# Having some time, I discovered the existence of an online version of what I downloaded and installed.
# I am spending time trying to learn what the application does. Wondering how I should learn this game.
# Found a tutorial of what this app is all about at : http://www.speedsim.net/index.php?page=tutorial. Quickly brushing through it.
# Working on achieving the mission at 3:20
# At about 3:35, I feel I am close to accomplishing the mission but not sure if there is a trap in there.
# I wonder what a partial win is? For instance in one of the report below I saw a 98% win for Defender ( Can I achieve a 50% win )
# I realize that I am not getting caught by the complexity of so many fields to achieve the mission. Keeping it simple.

Title 1: Investment plans for software testers. Title 2: Michael Bolton RST training in India

Is it a best practice that a post should have only one title? ;-)

Sharath Byregowda has won the Best Performer award at Mindtree. You know what it means to win the best performer award in an organization that has about 8000+ technical force. According to Mindtree there was a special guest who was invited to give away that award and that special person for them that day was me.

Sharath's manager, Murugan, wanted to make the award ceremony a very special one and surprised Sharath by bringing me in for the award ceremony. A manager so excited about giving away an award of Best Performer of the organization to his subordinate - made me feel wow. While traveling together to Mindtree office, I discovered that Murugan had a good diversity throughout his career and even tried doing business in the United States long ago with his friends. With all that experience, he thought, freedom plays a vital role in testing and hence provided it to Sharath who seeked it. India needs more Murugans. I think they have lot of Sharaths out there.

Freedom with responsibility made Sharath get him the award. This is the second time my student is getting an award at the organization level. Most of you might not know much about Shaham Yusuf but then he won awards for slogging important bugs and an unmatchable record of the highest number of important problems found in Deloitte India.

Traditional Software Testing Process - The cash cow demystified

So, I don't need to tell you that most of the software testing in the world is outsourced. I live in Bangalore and I assume a considerable amount of the world's outsourced testing projects are here. I meet testers from most of these organizations and hear the same process of testing software although called by different names their organization executives named them.

Most testers I meet lament about the process (or sucked within it for survival ) and approach they are forced to follow and try talking to their management about better ideas and better ways to test. Those executives don't seem to listen much nor willing to change.

Wondering why they wouldn't?

They have hit a cash cow.

Mark Crowther and I were discussing about Code Coverage & Requirements Based Testing in Test Republic and some how drove me to write about the way most businessmen are fooling their customers through the process they love to follow.

So, here it goes with editing and expansion. Assuming Mark from UK or maybe even you outsourced a testing project to me:

• I would spend a couple of days analyzing your requirement document and bill you for X hours per person involved in my team.
• I would spend a couple of days writing a test plan document ( but not refer to it ) and bill you for 2X hours per person involved in my team for preparing it.
• I would spend a month or two writing test case document ( and refer only to it ) and bill you for 10X hours per person involved in my team for preparing it.
• I would then again create a traceability matrix ( just to fool you and your boss about our coverage ) and bill you for 5X hours per person involved in my team for preparing it.
• So far, total of 18X hours per person involved in the team is the billing.
• Assuming X is 50 hours and there are about 10 members in my team, that's 18 * 50 * 10 = 9000 hours of billing with no single bug found yet. ( Mark wrote about it, too )
  
• If you are paying $20 an hour per person on an average, you would have actually given me a business of $180,000 without me or my team finding any bug yet.
• So after investing $1,80,000 on me and my team, you would want some benefits of that. So, you wouldn't pull the project out or move it to another vendor because more or less he would do the same and you would end up paying another $180,000
  
• Then comes the test case execution cycles for our documented 10,000 tests out of a possible hundred million tests
  
• For every new bug that you find out of the releases I make, my team would spend documenting the new test case, getting it reviewed and resulting in slower testing for you and more money for me.
• So assuming running 10,000 tests take 2 weeks for a team of 10 members to execute. Also assuming least 50 cycles of testing, you would have paid me about $140,000 for a coverage whose value might be not worth of the money.
• Of course there is additional documentation of missed test cases and other template filling activities that will be billed to you.
• To fool you further, I would instruct my team to use some expensive license based tools ( what else will I do with the money you are pumping in ) to give you a sense of faster testing ( by foolishly comparing it with human speed of testing ) and call it "Automation Testing". It turns out that these tools could have helped me find bugs that are of not a great value to you but hey, we want to see test case pass more than fail.
• Your coverage isn't improving much because we have converted manual tests to automated tests ( although its not the same test ) but to show you the speed of our tools.
  
• So think about adding another $25,000 and giving you an illusion of an ROI of $100,000 while pumping multiples of $100,000 from your bank account to mine.
  
• The CMM, TMM, Six Sigma, ISTQB scams are built around this eco-system to enable more money flow for hardly any value. Who knows there could be a cut for the people who know all this and yet do it.
  

Why wouldn't a businessman be glad about the traditional approaches to test software?

Are you asking about what happens to the users of the product?

• Lets bother about the users of your product later during our maintenance billing phase. Don't you know SDLC ends in Maintenance Phase? If we do everything right in the previous stages then how do we prove we follow SDLC when there is hardly any work in maintenance phase?
  

While you are reading this, you shouldn't be thinking of this happening only in India but in most parts of the world and even within places like United States and Europe. There are smart businessmen everywhere. At one end they pay us but at the other end use us to make more money. We need money and they need us to make that. Don't make smart businessmen exclusive to India and leave your own country out of it.

I hope those who outsource start pushing for services that doesn't fool them. Who would actually listen to this argument is testers turned businessmen and testers turned outsourcing heads and testers turned business leaders.

Whenever I visit a testing services company and see a testimonial of a customer who talks about the great ROI they got and faster testing, I wonder what a heavy price they paid to believe so.

Exploratory Testing ++ , Context Driven Testing ++ , Rapid Software Testing ++ or else YourMoney --

Don't want to be fooled by outsourcing software testing? One of those who could be of help to you among many folks I know, is myself.

Collection of Notes & Experiences: Bangalore Workshop on Software Testing 1

Approved for Publication by all Participants

Theme: Changing the way people test and think about testing
May 2^nd, 2009
Venue Sponsor: Edista Testing Institute & Test Republic


Participants displaying their K - cards
For more pics, click here

Participants ( not in the o: Ajay Balamurugadas, Aishwarya D Shukla, Guruprasad, Manjunath, Rahul Verma, Rahul Mirakhur, Shrini Kulkarni, Manoj Nair, Ravisurya, Santhosh Tuppad, Shikhar Singh, Raghu Sahay, Sharath Byregowda and Pradeep Soundararajan

Bangalore Workshop on Software Testing officially started with the announcement on my blog on April 12, 2009. We had about 15 people rushing in their registration and abstracts for presentation. When you see the list above, you would know who finally made it.

We tried following the LAWST style peer conference and we think we did. I played the role of host and facilitator. I am sure the next time someone else will play the facilitation. I learned facilitation by observing Paul Holland do it in TWST and CAST. He is an amazing tester and facilitator. We used K-cards and that really worked. You would see in photograph, people holding K cards.

We had a check in and introduction (as there were a few faces who did not know each other) at 9:30 AM followed by Ajay kicking off the first presentation.

Ajay’s presentation: Rapid Software Testing

Ajay talked about the change he had after attending my workshop on Exploratory Testing – A Rapid Software Testing Approach and how it helped him log several hundreds of bugs when he started doing a structured exploratory testing. He explained how he struggled with the templates that he had to adhere and how those test cases filled in templates failed to yield coverage and value.

Ajay brought in an interesting thing: “When I started to log more bugs, people were skeptical of how I was doing it. They used to think I was stocking them and releasing it as required”. In this case, Ajay funded himself for the training.

It surprises me that some organizations get their resources trained to help changes to occur to their work and grow skeptical when they get to witness the change.

Before he finished his presentation, he mentioned how the management started seeing Ajay’s work output as a different value than what they expected out of him. What they expected from Ajay was to run as many test cases as possible and what he ended up producing was finding defects and reporting them in their bug tracking system. That is an interesting one – test cases are there, wherever they are, to help testers find bugs and some managers might be misusing it to show progress of testing. I have heard it happens everywhere in the world and not just in India.

During the facilitated discussion that happened after Ajay’s presentation, Shrini mentioned, “The value depends on what stakeholders defines it as”. However, sometimes some stakeholders might need education from a tester to have more meaningful value definition.

Rahul Mirakhur (RM) brought in the idea of a tester wearing different hats and being able to think the value that different stakeholders might want from a tester.

When he interacted with Support teams in an earlier organization, it opened up a completely new world of information source and that, changed the way he did testing thereafter. It also gave a glimpse on how different functions on a project bring in value and in the case of Support teams case, value is more "after" product release.

As the discussion drifted to bugs, Rahul Verma said, “I see bugs as questions we can ask”

Manoj Nair’s presentation on An attempt for better testing

Manoj talked about the opportunity he got in his project where time crunch and amount of testing to be done, enabled his manager to bestow him with a freedom to do free style exploratory testing (without much documentation) for an important feature in his project. The defects and the information he came up by performing free style exploratory testing made the management to postpone the release realizing the danger. He felt happy with his effort, until he was required to explain the details of test coverage across the feature and provide test case document for the tests he conducted for those features. The test case document he prepared were subset of the entire range of tests he performed because he did not have time to document all those tests. He realized the value of tests he did could possibly diminish through that activity. Looking back at it he felt, if he had used Session Based Test Management, he could had done a much better job in providing test ideas document.

During the discussion, I talked about the idea of a Wiki for changes to the product open to all team members and the value it could have for the test team.

Aishwarya, an undergraduate student asked a striking question, “How much information would be an overflow of information?”

The discussion then digressed to – When is the right time to get testers on the project for which all participants had different ideas and experiences. Many organizations have tried bringing in testers early and late and most of them are not yet sure when to bring them in.

I argued that it depends on the kind of a tester an organization is trying to bring in and other factors. Not all testers are the same. I have witnessed organizations that actively ignore testers in requirements review meeting as they have had a bad experience of bringing in a tester. It makes me think that if I lose credibility, it affects other team members in my test group. That is how important it is for each team member to have and build credibility.

Manjunath’s Presentation of Review of Review of Review of Bug Reports

He talked about his experience in one of his previous organization in the context of bug report reviews conducted to help testers log better and credible bug reports. This exercise was undertaken based on the success of improved bug report quality, post a review of each bug reported from the previous project.

Interestingly, in the second project there was another level of review that happened over the review comments of bug reports. The tester, whose bug reports were review had an option to appeal for escalation if he found the review comments did not fit his (her) bug report. It got many testers to defend each of the review comment of the bug reports they logged. Thus spending more time on a single bug report, instead of finding more bugs. That's opportunity cost. That’s like review of review of reviewed bug reports. Yes, we did have a good laugh!

This process was then declared a failure for the second project as its implementation went wrong and 
ceased to exist thereafter, maybe. 

The process can become so worse that it might eat so much time for so little value. On probing, Manjunath revealed that the review process was actually initiated to help testers write better bug reports. All participants were convinced that the way in which the mission was executed might have been poor and what works in one context does not fit another. I am sure we are going to remember Review of Review of Review of Bug Reports experience report.

Doesn’t it help us understand that the best practices do not work for another project within the same organization because the context keeps changing?

During the discussion, we discussed ways of credible bug reporting and shared our experiences of reporting bugs through Video recording of the bug and the value it has had for people who experimented that. It cuts across communication barriers and I am surprised why this practice is not widely used. Oh! 

Someone hasn't talked about it as "best practice" yet? It then digressed to how much English should testers know and then RM talked about practicing English as a daily activity as opposed to a one time upgrade of English skills.

He provided inferences that it’s (relatively) harder to learn language (or command over it) when we get old compared to when we are young. Shrini mentioned that it is not a "rule" by citing his personal experience of how despite being relatively old (compared to most of the audience), he is constantly on the lookout to learn new things.

We got back to reviewing and then discussed on reviewing as a skill and review effectiveness.

Lunch Time folks!

At about 1:15 PM, we walked to a nearby hotel down the street and carried over facilitation-less discussions over lunch table. A heavy lunch

Then when we returned, something helped us get the heat back… Rahul Verma’s presentation on Confessions of a Fallible Tester

This was a very energetic presentation we had for that day and thanks to Rahul Verma, he did it right at the time it was needed ( post lunch )

He made confessions of the mistakes he did right from the start of the career where he thought testing was not his cup of tea. He just did not confess but also explained how he learned from those mistakes and lived better after each big mistake.

One of his confession sounded very cool - “When senior testers in the team said XXXX XXXXXX was the best tool, I believed it” and then he explained how the project suffered because of that tool or the idea of thinking that as THE BEST Tool.

He explained how he cleared that trap and ended up writing a customized plug in to work with XXXX XXXXXX to make it suitable for his testing context.

He then confessed on another mistake of how two blank lines that caused the test environment to fail to enable the product to be tested over it. He or his team members make turned the case by defocusing the customer to something else when the customer observed it. The message was – Test your Test Environment. I think those who do that today are the ones who have realized the value of it. Many testers just setup and start running their test cases without bothering if test environment is what they intended it to be.

The discussion kicked off and we started discussing about tools. The topics varied from Automation Readiness to Vendors bribing managers to sell their tools to Good code versus Measurable Code.

From Rahul Verma to Rahul Mirakhur’s presentation on My career and experiences in testing

He started with a cool question, "When people say WHY will you want to be a software tester, I ask WHY NOT" and I think that was exciting. RM had some interesting observations about IT people in India – “By the time people realize what they are good at they would be in some other domain and would have beefed up living a luxurious life that doesn’t allow them to shift to something they want to do”

He asked another question “Anyone can be trained on software BUT what can they really do?” and discussed that every human is a born explorer and testing is an innate thing and can be developed by proper training.

He then talked about his experience of witnessing developers who moved to testing because they were interested in testing. He then said based on his experience, “Jump into development first if you are serious about becoming a tester”. He shared the experience and value of hiring a person who earlier worked in a support job.

The discussion post this presentation helped in understanding how many different ways are there to get into testing and the value of taking each way. We also talked about the value of learning testing from other fields and that reminded me of CAST2008 conference theme and presentations from there.

RM went back from BWST and started a blog and has promised to keep posting. Another credible blog from an Indian tester on the way - check out.

Sharath Byregowda’s experience of Session Based Test Management

Sharath talked about his experience of experimenting SBTM on the project he worked for and how he influenced other testers, the management and customers with it. He has detailed it in his blog post and I am sure you'd read go there and read it or maybe even learn from it. His team won an award for achieving great results in his organization that has thousands of testers. In addition, Sharath got another award from Michael Bolton.

We had an interesting comment that - By the time an organization implements some new practice as a "best practice" and penetrate every team, the idea is outdated. It reminded me of Ted Neward’s presentation at Oredev08 where he talks about the time difference of programming language birth to becoming an industry usage.

Shrini Kulkarni’s experience of test automation consulting

Shrini talked about his experience of becoming a tester and then about how he grew from being a fresher in software testing to wherever he currently is. He then talked about an interesting experience of Test Automation Readiness Assessment that he was supposed to do for a client in North America and the challenges he had. Shrini talked about his confidence in doing it although his colleagues thought of it as an impossible task. Shrini detailed the value of collaborating with people like Michael Bolton, James Bach, Cem Kaner and others that have helped him evolve to a Test Automation Expert.

 Shrini also talked about his consulting experience and mentioned that almost all test consulting assignments he witnessed, the client was interested in knowing some "universal" or industry standard benchmark related to testing - be it dev to test ratio or % of project cost that could be associated to testing. His experience was that he rarely witnessed anyone challenging those industry standards. In his opinion - That is hindrance for our profession.

Discussions on Test Automation, mindset and skill set followed Shrini’s presentation until the bell rang at 5:30 PM

We had a quick check out and got on to the socializing evening and facilitation-less discussions. We decided on a Food Court in Koramangala and spent about 3 hours there munching food and discussions on Cricket, Movies, Testing, Food, Beer and Wine.

What a fantastic learning to all of us. I must thank Shikhar Singh and Raghu Sahay for coming down from Mumbai and Pune to attend BWST-1. It was fantastic to note that Aishwarya Shukla, an undergraduate student, wanting to do a software testing project as his final year project after attending BWST along with Santhosh Tuppad who completed Practical Software Testing Training at Edista and has been working on several testing assignments as a freelancer. Every participant asked questions that helped other people learn and discover more about themselves and the work they do.

Once again, special thanks to Mohan Panguluri, Pradeep Chennavajhula and Rachna for providing us the space @ Edista Testing. I wish India has more leaders like them who facilitate knowledge sharing and learning in software testing without just being business minded.

Shikhar went back to Mumbai and wrote an e-mail to me regarding Mumbai Workshop on Software Testing that he is planning. Watch out India!

Here is the list of Post It Notes that all participants contributed as an additional reference points to the discussions we had:

• Only testers can talk about Testability
• Book suggestion: Perfect Software and other Illusions about Testing – Jerry Weinberg
• “Every bug is a duplicate of a master bug that the product fails to do something that is important to work for someone” – if that sounds bad - that's still me.
• Philosophy in Golf & Testing – Adam Goucher
• Bug Advocacy – Cem Kaner
• How to investigate Intermittent Problems – James Bach blog post
• “The best tester is the one who gets the most the right bugs fixed” – Cem Kaner in Bug Advocacy
• Do confess when you screw up
• Turning Numbers into Knowledge – A book by Jonathan Koomey
• Lessons Learned in Software Testing – Kaner, Bach, Pettichord
• “Automation could be a dangerous word for a tester” – Rahul Verma
• “If you have failed big, it indicates you rose to a great height” – Rahul Verma
• Value of Checklists – Cem Kaner’s presentation in CAST 08
• Video Record Your Bugs
• The intake I have had from BWST-1, has questioned what I have learned so far. It has helped me to unlearn and learn consistently - Ravisurya
  
• "When I spoke to support teams, it changed the way I tested, forever" - Rahul Mirakhur “
• After I attended Rapid Software Testing Workshop, my testing improved” – Ajay Balamurugadas
• “The value you add as a tester is like NAV of an investment. It changes every day” – Shrini
• General Systems Thinking – A book by Jerry Weinberg

Video : Against Best Practices in Software Testing :: Oredev 08

Here is my talk at one of the coolest conferences: Oredev, Malmo, Sweden, November 2008.

Great* testing stories from India
( Created by *not* following any best practices )

Highlights of the talk :

• I was fired from Motorola trying to follow James Bach's advice
  
• Test cases make people mad and sad.
  
• Sharing 230 stories in 45 minutes.
• The value of doing things that that context demands.
• Questioning things that happens in India.
• Truth of how many organizations get CMMi and ISO certifications.
• Independence day for software testers
• Brain is also a tool used in software testing, consider recognizing it.
  

Blogs about the talk so far:

• The test Eye - Notes from Oredev
• James Bach - What Impressed me at Oredev
• Sogeti Blog - Oredev 2008
• Ola Hylten - A blog about testing

I thought of making the video private instead of public and wrote to Michael Tiberg and he pointed out that this talk had received high rating from the audience and that I nailed some important points. I then decided to let it continue to be in public mode. I hope you'd enjoy the talk. Thanks to Michael Tiberg and Emily Holweck for putting up a great conference.

Oh you should watch James Bach's power packed keynote on Renaissance in Software Testing at Oredev. It left me crying for a couple of minutes.

Bangalore Workshop on Software Testing - BWST - 1

I interact with the Western world as much as I interact with the Eastern part. One of the things that the Western world does well that the Eastern part does not even do (significantly), is Peer Workshops. When I funded myself to be at CAST 08 conference, Toronto Workshop on Software Testing (TWST08 ) was a huge bonus for me. Thanks to Fiona Charles and Michael Bolton for allowing me to participate in it.

My first day at Toronto, Canada started in TWST08 even before I could get over the jet lag. I found that the Workshop was a great way to overcome jet lag. What I learned from TWST is still resonating in me and is of great help to my career.

I cant afford to fund myself to attend such peer workshops every year but I can definitely afford to participate in ones that happen in India. I tried to make testers meet happen in Bangalore when Michael Bolton was around here last time and it did not gain momentum after the first meet. I am forced to think that people turned up to hear Michael Bolton and they would turn up again when he's back. Prove me wrong.

Since then I was in a constant look out to meet people who would turn up for learning and I have found a couple of them. am also aware that there could be more people and that's why I am blogging about it.

There were lots of informal meets between Ajay, Manoj, Shrini, Rahul Verma, Vipul Kocher, Dhanashekaran, myself etc... and we did keep craving for more such things to happen. I think India cant afford to wait more to get started with Peer Workshops and this is an announcement for the same.

Mohan Panguluri, COO, of Edista Testing Institute who was awarded for his Thought Leadership in Software Testing in 2008 has opened up Edista's office premises for this Workshop. He has vowed to provide space to all future BWST workshops. Thanks a lot Mohan. You are setting a great example for other CXO's to follow.

Theme of BWST - 1 : Changing the way people test and think about testing
May 2nd, 2009

I believe that the first testing assignment that anyone did was handled pretty bad by them as compared to what they might be doing after a couple of years. However, growth stops at some point for many testers and only a handful make it to be real good testers. Those who turn out to be real good testers constantly kept changing themselves as they learnt new things and those who turn out to be bad were the ones who hardly changed. In India, we know, some of us struggle to change the environment around us to learn as much as we do.Similarly there are people who without much struggle get the environment around them to feel happy without any learning.

So, you could have changed your way of testing or others way of testing and you could have been resistant to change. Send in an ( one page ) abstract of your experience report that you wish to present at the first Bangalore Workshop on Software Testing by 18 April, 2009 and you will be informed if your talk is accepted for presentation. Failure stories are more inspirational than the success ones. I hope everyone has plenty of both sides.

The max limit is of 10 (maybe 15 if pressure builds) participants for the first BWST and hence if you plan to attend, remember that we work on First come First Serve basis. So, send in your abstracts of your experience report that you wish to present and keep in mind the theme when you do that.

Handbook : Please refer to LAWST Handbook and those that can apply to our context, will. We are flexible in changing things based on our first few Workshops.

Note: This isnt open to testers only from Bangalore. Anyone's welcome.

Also, you can start your own set of peer workshops in anywhere in India ( or anywhere in the world ) and no one is going to stop you. When you start, kindly let me know about it in advance so that I can plan to be there, learning from you all.

Email id to send in your abstracts: banwost [ at symbol ] gmail.com and we will have our own website soon. By May 19th, I will post an update on this and that's how we proceed. Are you going to remain silent? Are you going to change?

Change in hiring and interviewing process in India for software testing and software testers

I claim to be one of the most experienced and most affected tester in the context of interview in India and here ( in this link ) is more information about it. After going through that link or this video you would know that I have been struggling to not see another Pradeep Soundararajan in the job market who is frustrated with this industry's idea of interviewing. Edista Testing Institute ( my client and partner ) is constantly pushing towards seeing a better testing community and that's why I chose to work with them.

I consider the following as one of my biggest contribution to the change the industry needs. Most training institutes in India (even the so called highly reputed ones) have people who dont know to test, teaching testing by running a thousand slides. I think they have so many slides that if you run 25 slides a second to watch it like a movie, it still runs for about 2 hours. Such slides have always caused an avalanche slide of many victims career, knowledge and skills.

Edista started to redefine things by hiring me and then allowing me to hire Manoj and then Sharath and then now more people. The last I heard from Manoj is that testers who were interacting with him are now excited about what Manoj is doing and are enquiring what it takes to be able to get skilled in testing.

You might also discover that Manoj has started to publish his practice sessions on testing in his blog.

We sit to gether, test, learn from each other, create exercises, practice pair testing, discover new tools, debate on ideas, think about more heuristics, brainstorm test ideas, discuss about bugs, run a test club ( like the movie Fight Club ), teach people how to learn and then how to test. We are never away from testing and we are never away from anything about testing.

We aren't skeptical about the fact that there could be more people like us and who knows they might be interested to join us. So here goes the job posting for the same: ( and I have posted this in LinkedIn and other communities - please feel free to share this job posting to all other Indian testers )

Consultants in Software Testing and Software Test Education :: Bangalore

Profile:

Edista Testing Institute ( www.edistatesting.com ) has a couple of openings for Consultants in Software Testing and Test Education.

It wouldn't be wrong if I say, they are looking for people who have the urge to be heroes in software testing. This role demands you to train ( yourself and others ), collaborate with the on going research activities, test products, learn and innovate.

This role also demands you to grow to an extent to be able to contribute valuable things to the testing community and work for its betterment.

About your co-workers:

You would work with skilled testers and brains who constantly engage in learning activities, blogging, discussions, teaching, mentoring, challenge and argue online in testing forums ( like www.testrepublic.com ), offline and reinvent the art of reinventing things in testing.

If you think you wanted to be a hero ( or hero-in ) in software testing and never got the opportunity, here it is.

Eligibility:

We'd be glad if you have worked as a tester for a while ( at least 2 - 5 years ) and also be glad if you are willing to travel within India (or abroad ) on short term assignments.

We would prefer you have a degree in Engineering or Science however if you dont have them but have a demonstrated ability of good thinking, we'd be fine.

Interview Process:

Our interview process is cut above all other organizations that neighbor us. We put you in the testers seat, give you time to test a product and have a discussion of your testing based on the report you produce.

We aren't too bothered if you dont know the difference between Sanity testing and Smoke testing because we believe, knowing the difference ( even if it exists ) doesn't make a huge difference.

We aren't bothered if you have a certification in Software Testing or not as long as you are passionate, skilled in testing, and have the fire and fuel to take you a long way. In simpler words, it *doesn't matter* if you dont have ISTQB, ISEB or CSTE certifications.

About Edista:

www.edistatesting.com

Time to join:

Immediate is preferred. A little delay is fine if you are stuck somewhere.

Contact:

Send your profile to : resume@edistatesting.com

If you can crunch your profile in one page, we'd silently thank you for that.

The results so far:

• We invited about 7 candidates so far who claimed to have energy, passion and demonstrable testing skills.
  
• We are seeing great benefits of this approach.
  
• It makes us spend 3 minutes ( after a person has finished the test and generated a report ) to know about the claims a tester has made in his profile are fale and a little bit about the organization that said, "Yeah, he can test".
• We spoke only to one person in depth as his report was quite interesting.
• We know that we can filter more candidates with lesser time we have and get better ones to work with.
• It would be dangerous to get a person who cant test and report credibly into any organization that wants to hire testers.
• Those who fake testing experience fear to even apply or even if they do and by our overlooking we invite them for the testing session, we dont need to spend time beyond 3 minutes post their test.
  

Testers have to be tested on their testing skills and not on memorization skill. The best test ( based on the current situation ) you could give a tester during an interview is to make him sit on a computer and asking him to test a piece of software by giving a meaningful mission and time to do it.

Side note: Are you planning to be in the supporters list?

Learning to test better by teaching testing

Make a list of some of the teaching staff that considered bad at school or college. You might be able to notice a pattern - most of them were not willing to learn while they were teaching. Here are some of my stories and attempts that I made during my experience as a coach in software testing.


Story 1

I was teaching at Datamatics 2 weeks before. When it was time to officially end the workshop, a participant asked me, "What did you learn in these 2 days of workshop?". I was so happy to have got that question. I thanked her for the question and listed some of the learning I had in those 2 days. 

I also mentioned to them that I make a note of the learning I have in one or the other way. I also mentioned that my blog acts as my note taking tool at times. As you might have seen my Progress Report, the list of events and experiences that I had in every year is well documented.

The question, "What did you learn by teaching me?" is a powerful question to ask someone who is claiming to teach you because if the person has nothing then you know you might not want to sit in that class anymore or being in that class is a waste of your time. 

In some places I have an answer, "I learned that you can't be taught at least by me" and thankfully those people don't ask me that question. Learning and teaching needs an open mind. I think I must have a close mind to say, "Not everyone have an open mind".

I have learned some great deal of stuff about how to test better by teaching testers how to test. I understand that my brain is not capable of asking all the questions that I'd love to ask myself and hence I need other brains to ask me those questions. Where do I find those brains if I am stuck in one place and I keep interacting with just the same team for over years?

An year and a half back Ben Simo mentioned to me the idea of "Apply inputs that force all the error messages to occur" from James Whittaker's book while we were discussing about error messages. I liked the idea and it then got included in my armory of heuristics to test a product and helps me in model the product in more ways than what I have been doing.

Recently when I was teaching the Hands on Testing Training for Freshers for Edista Testing, Muhammed Kothari, pointed out a tool to me that helped in displaying all error messages programmed in most Windows applications. At every workshop, I ask the participants to challenge me in demonstrating the kind of testing I talk about. At Datamatics the challenge was to demonstrate testing on Microsoft Freecell game. On using the Process Explorer tool, I demonstrated how I could learn how many error messages the product is programmed with and designed my tests to all those error messages ( in other words, all printable strings from the program ). That's one way of demonstrating coverage.

Some curious testers were excited about it and came up and said, "I'd like to use the tool. It helps me find out areas that I might have been missing while testing the product" -- which is cool. [ some? well, one. :-) ]

That's just one of the many ways in which Process Explorer can be of great help to a tester. Note that Process Explorer is a tool. A tool that a tester can use to augment his testing effort and do a better testing. Tools are not just QTP, Winrunner, Loadrunner, Silk, Cotton, Wool etc...

Story 2

Lunch tables are a great learning ground. At Datamatics, I was joined by a group of testers at the lunch table. I ordered for a Dal Kichdi that some other people had ordered too. As I ordered late, others had started off with what they were served. When I got my Dal Kichdi and rowed the spoon over it for grabbing the first bite, I saw a hair (hopefully human one) in it and then found more. I picked a hair and showed it to testers and asked, "Did we order for this?" (meaning, no one order for bugs to be served with the software they buy) and then the brilliant Saurabh Sahoo, Test Lead at Datamatics asked, "Do you know why you found the hair while we didn't?", and the curious me said, "Can you explain, please?" for which he said, "You were looking at the plate while we were so much engrossed in the discussion and were watching each other's face".

That's a nice observation. It helped me explain to the people over table - that's what happens when you run scripts or test cases that have an expected result, "You are too much focused looking at the expected result that makes you blind to see other things happening in the environment. Having multiple oracles in your mind helps you see more than just the expected result and hence you'd be able to spot more problems than what you have been doing". 

I also added to it and said, "I wish we could say to our customers, why are you looking at the screen?" when they say they found a bug with our software.

I think that at least made Saurabh Sahoo convince that its worth spending time to learn things that I was trying to teach (and learn) and he spend an additional two and half hours after the workshop with me and he is determined to do a much better job. I learned a great deal answering the questions he asked me on clearing traps.

Answering questions like that definitely helps me in negotiating with management and clients.

Story 3

I was teaching at a Fortune 100 organization in Pune a couple of months ago. Within just 20 minutes of starting my workshop, the Test Lead announces to the whole class "This is class is a waste of time. Lets go back to work".

• How do you deal with such a situation? 
• How do you teach someone who doesn't want to learn from you?
• How do you put them in a receptive mode? 
• How do you know what to speak to them? 
• How do you know if its worth speaking to them anymore? 
• How do you know if they are more right than you?

What if you are in front of your customer and your customer wants to walk out of a meeting because they didn't like your idea? You might not be able to afford to lose all customers especially if recession is around.

I made an announcement, "All of you have the freedom to walk out of the class but I'd be happy if you answer a question: Have you ever walked out of a movie just because the titles of the movie suck?
 
If your answer is No, why would you want to do it here?"

Plus

I did something that I learned from the book Turning Numbers Into Knowledge that again cites Bruce Lee's master. 
I took a tea cup and poured water into it and kept pouring despite the cup overflowing and quoted Bruxe Lee's master, "Either your cup is too small or it is already full of opinions".

The result: I am teaching in the same organization again next month. The legs that rose up to walk out sat back and enjoyed the ride. Some even wrote to their management to have the class for other testers in their group.

Story 4

A common problem that most testers talk about - is being caught for missing a bug when a customer finds it. A tester in one of the previous workshop said, "It is my responsibility if I miss a bug and hence I have to be more careful with the tests I do". I was reminded of what Michael Bolton said, "I am a character in the story of how a bug got missed". It indicates that, we testers are a part of the entire story and we do not play the hero role in a bug that missed our hands.

That tester was adamant that testers should be made completely responsible for it and not anyone else because it was their fault and they shouldn't have missed it. I tried asking him, "How about making the person who put the bug into the product more responsible for it than you?" and yet that didn't help.

I made a pretty bold move, "I am going to slap you now. Would you blame yourself for standing in a place where I was swinging my hands or blame me for doing something I shoudn't have done?"

That tester remained adamant but other testers got the message that a tester is a character in the story of how a bug got missed and not the hero in the same story. Later that night when I was self retrospecting, I realized that I should have used a non violent example to explain it. Teaching testing to experienced testers helps in correcting your communication and thinking aspects.

Some important points to consider

• It is easy to teach dull minds that don't oppose and appear to nod for every idea that you share with them. Teaching bright minds are tough and demanding. They teach you a lot about how to test better and what more I want than that.

• Most people who teach testing in India at several training centers haven't done testing at all or haven't done enough testing. So, those who have remained a hands on tester and teaches testing gains a competitive edge.

• If you have that competitive edge then there is good money as well.
  

• Helps in meeting a lot of different kinds of testers and understanding different contexts, problems and different solutions to problems. It helps in avoiding traps much better and faster and translates to better testing.
  

• It is a challenge to get to know more about ourselves, get tested , refine communication, thinking, learning, teaching and testing skills.

• Make a list of some of the great testers you know ( in my case Jerry, Cem, Ben, James, Michael, Scott, Kohl, Elizabeth, Vipul ... ), you'd find that they teach extensively. Oh, you have been doing that as well but probably you have been teaching yourself all this time. Think about why do they do that?
•  
•  Go, at least teach yourselves. 
•  
• Teaching, teaches the teacher about teaching
  

If you are a tester and is interested to join a small test group that specailzes in coaching, consulting, and testing services, write to me. You'd work with some of the upcoming very good minds who care and live for benefitting the software testing community. Write to me: pradeep.srajan@gmail.com