Bangalore Workshop on Software Testing - 3 on 6th August, 2011

This year, BWST 3 (#bwst3) is delayed by a couple of months and for all good reasons. We were busy with personal and professional stuff. So, here comes the details.

Personal excellence & skill development

We have been noticing over the last few years that those who can change things for the world are those who have been changing things for themselves. As people say revolution starts from within, our experience has been similar to agree with that.

In this year BWST 3,  we are focusing on interacting more on personal excellence and skill development. We want to hear stories (from all participants, not just the speakers) on how they have been working on their personal excellence. Are they being pushed to that? What is their motivation to do it? What is causing them to fail? What support they need and from whom? What kind of skills are they working on? What are the black swan skills that the world should know about? What kind of books they read and how has it helped them? What kind of changes are they making to themselves? What do they plan to change about testing in future?

Does this topic connect with you well? Would you like to present or participate in this? We have very limited seating of 25 this year and this is an invite only conference. You don't need to send us a Salsa dance video to get an invite but you could write down your story of how you built or have been building your skills to us at parimala hut moolya.com titled "BWST 3 speaker" / "BWST 3 participant".

For those who don't know what I am talking about: Please read this, this, this and this. Last year, we had Selim Mia from Bangladesh, Yeshwantrao from Madurai and Vasu from Chennai come all over to Bangalore to attend BWST 2. So, indirectly, I am telling, its open to the world.

Venue:

The venue is at a hotel located in Bannerghatta Road, Bangalore. We shall send the details of reaching the venue to all selected participants and speakers via email.

Time: 

• 8 30 AM to 6 PM - BWST 3 (Late comers will not get Red K card. That's unfair. They will get it but be on time)
• 6 PM till cops ask you to go home - Social gathering with testers

How do discussions happen in BWST?

We will be using K-cards and everybody gets to talk. As an organizer and a talkative person, I hate K-cards, so you can imagine that it gives all an equal chance. As it isn't rocket science to figure out how to use them, we will explain to you over there before we start.

For those who have attended BWST 1 or 1 and 2 or just 2 :) - This year, we have modified the 3 color K-card to just 2. We will have a Red card (High Priority Request - Limited use) and Green card ( Put me on the deck, I have something to say or ask - (Unlimited use)

Cost

As you all know this is a "pay for yourself" style conference and you'd need to pay 550 INR to cover your own expenses of food and refreshments during the day. At the hotel, we will have a complimentary wi-fi facility and power adaptors. So, bring on your tweeting machines and use #bwst3

It is a practice [ :) ] that we hang out in a pub after the conference and hence if you'd like to just join the evening pub meeting with all the testers of BWST 3, write to us separately with your mobile number. We shall SMS and tweet the location of the pub you need to come to. Of course, "pay for yourself".

This year, we have decided to provide T-shirts to all participants and speakers and we are looking forward to wearing one of our own sponsored by oh who else - Moolya

Hurry up! If you are too late, you get to wait list and you will have to pray someone drops out. Spread the word, use the #bwst3

Testers & their passion for test automation

Once a group of software testers were traveling on a plane to attend a test automation conference. Their plane was hijacked by terrorists and all people on board, including the testers were held hostages.

The situation was grim as terrorists appeared to be dangerous with AK-56 strapped across their chests. The terrorists demanded a lot of things that the government couldn’t meet. After seven hours of flying, the plane was running out of fuel. The only demand government could meet was to refuel the plane.

Terrorists chose an airport to land and the plane was refueled enough to fly for 12 more hours. The terrorists threatened to kill a hostage every one hour if their demands were not met.They demanded the release of a terrorist who was captured by the government last month during an operation. The government had only three options: a) to release the terrorist b) to ignore the threat and get all people on board killed c) to perform a surgical strike during the next refueling session.

The government opted for option c. The surgical strike team consisted of highly skilled commandos who were trained in such rescue missions. The commandos pretending to be refueling the plane stormed into the plane and had concealed the latest FMG (Folding Machine Gun) which they unleashed to kill all eleven terrorists on board with minor bullet injuries to hostages.

After the strike was over, all passengers including the software testers on board stood up and clapped for quite sometime while commandos were preparing to off board the passengers. The news had become viral across the world and there were a lot of people waiting to receive the passengers. The conference organizers felt proud to receive the software testers who were on board this flight that had been rescued.

On the request of the conference organizers, those software testers decided to talk on what lessons can be learnt from the experience to software testing. With a huge round of applause, one of them came on stage, held the microphones and in a bold voice said, “Those commandos used a fully automatic machine gun to kill all the terrorists. That indicates that we should make our testing fully automatic to find all bugs”. Every tester in the hall clapped for the great lesson they learnt. 

Moral of the story: Testers and Test management have forgotten to appreciate their own colleagues and consider processes and tools help them achieve their goals.  Update: Also quoting Julian Harty : "Automation should be a servant, not master of our Software delivery"

If you have a colleague whom you want to appreciate and don't mind doing that in the comments section here, just go for it. Let me start.

Coaching testers how to email and influence stakeholders

One of the ways Moolya is going to become a great organization is by attracting, hiring and retaining good testers. Sreenuraj Varma who won our heart for this blog post asked us if he could work for Moolya. We got him to test things out and send us test reports.  We found that we liked him to work with us and he liked to work with us. So, we hired him a couple of weeks ago.


Before the project work kicks off, I asked him, what he'd like to develop himself on and he made a list of things that impressed me. I then sat with him to get more specific and identified "writing influentially" as one of the things he wanted to develop. I created an exercise and got him to work on it. I have done this before so I knew what to expect.


I wrote down the goal he had to accomplish:

You are hired as a tester in a team and in your first week you discover that there are many important tests that the team is missing. Your objective is to send a mail to all test team members pointing out the tests they are missing and the impact it has on the project.

To consider:

·         You are new to the team

·         The team has lot of experienced testers and they know about the project more than you

·         You don’t know how they would take your advice

·         If your English is bad some people may not take your advice seriously

·         This email can help you build or break your credibility with the team

So, he worked on it and got back with the following:

Dear All,

For the last week I was going through the application and the important bugs reported on each module. I feel like there is a lack of concentration on the issues related to security, which I feel important because the application is meant to be used by common people and also the modules are designed to be getting in-cooperated with the bank API’s where there is a possibility that we may lead our users to compromise their valuable details.

As we are in the stage of completion of second round of testing I would suggest that it will be good if we can do a quick analysis in the area of security were our application have to be  checked for most common security issues.

Looking forward for your suggestions

-- Sreenuraj


I then reviewed the above email with him stating things that is causing me to not think of it as an influential email and provided specific feedback and asked him to work on it. After a couple of hours, he came back with the following

Dear All,

Last week I was going through the application and was learning the work flow happening in the important modules. I have also gone through the first and second phase test reports we have for the modules. But I think we have not done a security testing for our application. I feel it is important because of the following reasons.

a)      Loss of customer confidence

b)      Can increase the web sites down time (reinstalling services, restoring from backups etc)

c)       Harm to our brand

When I was in module “A” which is the most important one, I found that some basic validations missing for the text fields. No checking was found for validating the special characters. This is found repeated in almost every module I have gone through. Below I am mentioning some of the issues I have came across.

a)      Cross site scripting is possible in almost every module

b)       Data tampering is allowed

c)       The cookies which are used in one session can be used again

As we are in the stage of completion of second round of testing I would suggest that it will be good if we can do a quick analysis in the area of security were our application have to be  checked for most common issues.

Looking forward for your suggestions

Thanks&Regards

Sreenuraj Varma M

Yo, I again sat with him for the next set of feedback about why I still think the email is not influential enough and pointed him to links such as An open letter to the Prime Minister of India by Rajdeep Sardesai.

He read through it, gained some ideas and started to work on the next version of it.

Hi Team,

This is Sreenuraj recently recruited for the position Software tester for the organization. My last week assignment was to learn the project work flow and to refer the available documents which QA holds against each modules of the project like test plans, reports, bug reports etc.

As we are in the completion of second phase I think we have covered almost all the important things in functionality testing. Most of the bugs are fixed and retesting for the same is also done. But some of the bugs reported against the security testing done in important modules are found to be in open state. I have also noted that some of the bugs were raised in the first stage of testing. Because of that I think the number of issues reported against security testing in the second phase have gone down. Also there is no status report available for those bugs from the development side.

Below mentioned are some of the important issues I have came across in the application which was not found in the bug reports may be not reported because of the above said reasons:

a)      The validations for text boxes in the Login screen and the home page for special characters were missing.

b)      User is allowed to insert html scripts into the text fields for the above said pages.

c)       The data which is submitted for the module “A” can be tampered and user is able to alter the data which is transferred .(Bypass the client side validations)

d)      Data tampering was also success in the module “B” where file type can be changed and user is able to include a file with unsupported extension (like exe .. )

Some of the points I would like to suggest are

1.       - Before the completion of phase 2 of testing we should conduct a security testing in the application for the important modules and report the issues found.

2.       - Discussion with the development team in regards with the Issues reported and which are still in open stage, also record the status before second phase of testing ends.

3.      -  It will be good if we can conduct a workshop/training session for both the development & testing team where importance of security related matters in the project can be discussed. Also we can emphasis on client’s expectation in the area of security which is described in the requirement document.

Looking forward for your suggestions

Thanks & Regards

Sreenuraj Varma M

Nah Nah! Not good enough for me. After having coached many testers, I have gained wisdom to understand the point at which I have to step in and do something different than saying, "Not good. I hope you work on these points". So, I decided to send him, my version of the same.

Dear Team,

Greetings!

It is a pleasure to be starting to work with you. In just a week, I was glad to discover that there is great energy you people are bringing in. Its motivating for me to work with you. As I see that a new team member brings in fresh and different value, I'd like to present some kind of value addition I could do.

In this email, I'd like to bring a few points to your notice that might interest you. I am aware that some of the points I am going to bring up here might already be known to you all but I felt it is my responsibility to let you know of what I found.

Security issues for NNNCC Web App (Just an example)

• I found that the directory listing is enabled. As we hold confidential information with us and not all pages are exposed to all users, we might be in a position of risking our customers data.
• I found that there are error messages that can be customized at the URL. For example, I can make an error message saying, "As Pradeep is on leave, we can't service this" to appear from the page by editing the URL.
• I also found that there is a way to bypass the security by storing and using cookies of previous session. When our customers use a public machine to access their data, we are risking the customers data to be known to others who may discover cookies.

Based on the above, I'd like to make a few humble suggestions:

• I understand that the focus is on getting our software functionally right but on the effort of trying to get that, we appear to be sacrificing security.
• I would love your opinions on budgeting for security testing for every release henceforth. As I am a new hire to this project, I would take up the responsibility for testing security for the next couple of releases till I ramp up on other things.
• I would be extremely delighted to meet with you all on this, so am planning to setup a meeting on Friday 24th Feb 3 PM. I have looked into your calendars and have chosen the mutual free time. I am open to suggestions of other date and time.

Thanks and Regards,


-- Pradeep Soundararajan

This time, he came back with the notes he made about this exercise while continuing to work on the skill of writing influential emails. This is going to go to a point where he would learn to practice on his own. He in on the third exercise with me working on test strategy. Our clients are going to be happy to have him on the team. He is showing lots of enthusiasm, hard work and effort. We are happy.

At Moolya, we are going to lay emphasis on how people write and communicate. We might sound stupid but we have realized that people who can write well, get things done quicker and better. In my own consulting experience, I took an email which had not received a favorable response from the management and helped the test team re-write it. We waited for a day and there came a response to it and things got moving.

Add "influential emailing" to your wanna have skills if you are a tester. There's a good example to it in Michael Bolton's blog as well. I am working on a tutorial to help testers write and communicate influentially to stakeholders. Maybe I will take it Star East or Star West. 

Manoj Nair's experience of adding great value as a tester

Manoj Nair is the co-founder of Weekend Testing and works for an organization that has a worldwide presence. The core business of the organization he works for, is to help people shop, online or at their stores. He functions as a Senior Tester for projects that are to be deployed in United Kingdom and Europe. 


An year ago, they decided to expand its presence in the United States of America and in the North American region. A lot of software had to be remodeled and developed to be able to deploy in USA. This was a strategic move by the organization to show its dominance in a market that their competitors had claimed to have conquered. Manoj Nair was chosen to play a role of Test Lead for the project despite being a newbie to the organization. It wasn't a lucky dip that helped the management choose Manoj to be the Test Lead for this important project but the passion and skills he demonstrated in the short period. They were convinced that bringing in Manoj would help them feel safe. Oh, by the way, he wasn't the domain expert.


Right to what they thought, Manoj ended up doing something so important for the project that literally saved the organization at least $6 million US dollars. Let me type that again, its Six Million US Dollars. If you think that was great, wait. He also prevented the company from being embarrassed in the global market and amongst its competitors.


So, what do you think? He found a bug and got it fixed that would have otherwise cost so many million dollars and embarrassment? That's what comes to mind when we talk about testers doing great work but here is a story that is different and demonstrates the great value testers like Manoj can bring in. I think he did things that most testers in that place might not have.


There's a large group of testers who have come to believe that functional testing is all what they need to do. If you don't believe that, you just might believe this - There's a large group of testers who know that other kinds of testing is equally important but they aren't skilled enough and powerful enough to convince the management and customers about it. That's where Manoj Nair differed and won.


In this new project that had to be deployed in the USA, he proposed quality criteria beyond just functionality and was seeking the time and budget approvals from the management to test for Usability, Accessibility, Reliability, Performance, Security and more. At this point, Manoj performed just like any other tester. Most of the test plan documents I saw during my first few years as a tester had all sorts of buzz words but people ended up just testing for functionality and I used to wonder why.


Manoj's test plan had an objection from someone in the senior executive team. The objection was, "About 70% of the code we are going to use is already deployed in other countries and hey its been working. Why do we need to test for all sorts of things again?" and then there could have been a chatter, "This guy is a newbie, so he probably doesn't know" and "Ah, he is relatively new to the domain".  What we are about to witness is that those domain experts were blinded by the fact that moving code from one country to another is like treating that if a software works on one machine, it would work everywhere else.


Manoj wanted to counter the objection. So, he decided to learn the impact of not doing certain things when moving code from one country to another. He found this link during his research : Target Settles Accessibility Lawsuit for $6 Million


Manoj drafted a response showing his respect to the objection and why he still continues to think that moving code from one country to another has to be treated like a fresh project in itself. He also shared with his management the link to how one of the organization had to suffer from lawsuits and a fine as big as $6 million.


The management was partially convinced but they needed more evidence before they could listen to this young chap advising them on what they should budget on. They consulted an attorney in the United States of America who was considered to be a specialist in laws of the US government pertaining to software quality and compliances. The attorney came back advising them to treat Accessibility and Usability as important as the payment and transactions through their website and did acknowledge that the information on Target was true and they had suffered $6 million and embarrassment.




Look at what happened after that. The senior management did listen to Manoj and treated this as a new project giving it the importance it needs. They came out of the bias that it was just re-use of code and started to treat this as a new application all together.


What did Manoj gain from it? As a tester he benefited a lot. He won so much credibility in the team that the next time he proposes something or reports a bug, a lot of people are eager to learn what he has to say. He has made himself influential in a short period of time in an organization. He is at least as equal as what the domain experts of the organization are. He has made people to believe that having a team with diversity is more important than having all domain experts agreeing to each other in what the other one says.


That's awesome!

Now you'd like to know that I wasn't surprised by what Manoj achieved because I know his background and education. He was constantly building skills that are important for a tester. I first met Manoj in Pune in 2008 although he had been reading my blog before that. We found a good synchronous between us. He relocated from Pune to Bangalore to work closely with me. That's when I introduced him to Parimala, Ajay, Sharath and Santhosh or should I say that I couldn't resist myself from getting these people to meet. This team craving for practice and learning set out to found Weekend Testing that today is considered as the revolution from India in the testing space. Manoj has attended my exploratory testing workshops (even the most recent ones) and is a BBST Foundations graduate. He has taught bug advocacy, exploratory testing, heuristics and oracles to wannabe and experienced testers in the past. He is well read (at least to the extent that he wouldn't feel intimidated when people are talking books) and networks with testers.

So, I am hoping that after you went through his background, it doesn't surprise that Manoj is adding great value to the project he is in. He practiced and was prepared for facing challenges even when his job in the past didn't demand all the skills he was learning. Today, he is skilled enough to handle most tough challenges in testing. He is inspiring his team members to surpass the boundaries.

If you find it tough to explain people what other kinds of value does a tester add to the project than just finding bugs, just get them to read this story. Also, if you find testers cursing themselves that they are not being treated well, get them to read this story and most importantly Manoj's background which is all about the quest for constant education and practice.

Kudos Manoj! You just did something that makes the country proud. Not just our country but people from United States of America, for the care you showed towards accessibility and usability for people with low vision and maybe other challenges.

On behalf of all testers who would love what you did, my little gift to you is this blog post. 

Software testing black swan bites cause pain

This post is about an experience I had recently. An experience that proves to me that there are more hard working people than me and I shouldn't feel too proud of what I have achieved so far. 


I was at a conference recently. I was at several conferences, so don't get confused with what is shown in my Events page. This conference was not listed and doesn't have a conference page either. It happened in Bangalore on 2nd Nov, 2010, right after my return from Google Test Automation Conference - Hyderabad, India.


Due to my popularity, I was hoping people would come, recognize me and talk to me about their testing problems. It just didn't happen. Some other person was getting all attention and there were people surrounding him and asking questions. There were so many people around him that I couldn't get a chance to see the man who was getting all this attention. I was wondering who is this guy getting an edge over me in India?


I then thought it must be someone who traveled to India from a western country. Only then people forget their local guy. Nothing new to me. I was just waiting for my chance to shake hands with that guy and talk to him about testing. Well, I just wanted to know what makes him so special that he is getting all attention in India. 


Check at my stats, I am supposed to be the popular guy out here. If you are seeing the popularity hungry Pradeep now, I must say; I too saw him.  The difference between us is, you might feel ashamed of having known Pradeep and I don't.


An hour passed by and still I could not get to meet that guy. I saw a tester coming out and asked her, 
"What's about the guy in center?" 
"Oh, you don't know him? He is an expert in test estimation"
"Everybody in here is an expert, din't you know that? So which country is he from?" 
"India" she said. 


What? an Indian? and I don't know him yet? I know everybody who blogs from India. At least, everybody who blogs from India knows me. How come I don't know about this guy who seems to be more popular than me? Maybe he doesn't blog but even then I should have known him.


All this was driving me crazy. Added to that were some of the talks I wanted to attend and it had started. I just pushed myself into one of the track hoping I could catch hold of that guy at one of the lunch tables. I have never waited for lunch so much, not even when I was very hungry. I wanted to meet this guy. He was a challenge I wanted to face.


At lunch, same bloody thing that happened in the morning repeated. People surrounded by him and I just cant get to meet him. My ego hurts me a lot if I have to go introduce myself to him amidst other testers who might think that I am not as popular as they thought. So, I picked up a plate and tried to eat alone. Fortunately, some testers who couldn't get to talk to him saw me and approached to have a conversation. My mind was somewhere else. I guess I don't know if I did answer the questions those testers asked me. Maybe they would have stopped reading my blog as I don't know how crazy my answers were. I just wanted to meet that guy.


Finally the moment arrived. The only way I could corner him was in the washroom. I was waiting for him there adjusting my shirt and trousers making it look to other people as though I care too much about my how neatly my shirt is tucked in. There he came. I didn't mind if his hands were wet but just put my hands forward and said, "Hi, I am Pradeep Soundararajan". He shook hands with confidence and said, "Oh, I know you. I read your blog and follow your work closely". 


At one end, I felt happy that the man who was sought much more than me follows my work but it was still aching as to how this guy managed to be the center of attraction amidst my presence. I took courage and asked him, "How come I don't know you. What's so special about you that these people are flogging you?"


"I have learned to help people estimate their work in a way that makes them feel successful following my advice" he said that with a soft and gentle tone. I put a step towards the door closeby and turned to him and said, "Why don't we discuss this off the washroom?"


My intention was to steal the idea. After several years of hard work, I can't allow someone to steal away the limelight I have been enjoying. When I say I wanted to steal, I mean, I wanted to know what his education was. How different was it from mine? 


We sat on a couch and I asked a question that was designed for deception or to learn about what he has learned


"So, what's your source of learning?"
He had a smile on his face before he said, "I read Bach, Bolton, Kaner, Jerry and you"
"Sounds interesting. I do the same too but how come you seem to be doing better than me?"
"I don't know"
I was pissed off but couldn't let it out because I still hadn't got the secret out of him. 
"So, you are suggesting that you learn something more from them than me?"
"No, I haven't met them Pradeep and they don't know about me"
"Pretty sure because if they did know, they would have let me know about you"
"Yeah"
"So, let me stop beating around the bush. How do you help people with their estimation problems?"
"I do it ............................................................................... this way"
"Wow. That's cool"
"Where did you learn that?"
"You are so humble Pradeep. You have read it, too. I picked up ideas from Michael Bolton's Test Estimation & Black Swan series of posts, experimented with them, made my own notes, refined them for a while to arrive at this point" and then he walked away saying he had to deliver a talk and it was getting late.


If you had been to the conference, you would have seen me crying on the couch post that meeting. I wasn't crying because someone gained an edge over me but was crying that I learnt the cost of not reading those lengthy posts just because it was lengthy. 


I finished crying and went around looking for that person to thank him for the lesson he offered. He had already left. The series of posts from Michael Bolton on Test Estimation & Black Swans had been lying there on his blog and I just kept feeling lazy to not read those lengthy posts. I am probably in the Twitter Era. I want people to say anything great or stupid in 140 characters and I also hope they say that around my timeline. 


Walked around with disappointment. I decided to go out of the conference venue. I wanted to go home, have a drink and get a tight sleep to forget all this. I thought I was reading everything by Michael Bolton. When he posted about estimation, I thought I had already read enough of estimation from him and he was packaging the same stuff. Just then, the conference was getting over and the final lightening talk was mine. I was called to the stage. I went on the stage with tears still dropping at 1 drop every 10 seconds, forgot about my talk and asked the audience in a shrill voice, "Have you people read the series of post on Test Estimation & Black Swans from Michael Bolton?". 


The responses were, "Its lengthy", "We didn't find time to go through it", "I got a call in between and almost forgot to continue", "I was too busy with my project". Almost everyone were saying the same thing, "No, I didn't read it because it was lengthy". I laughed out loud and walked away as though I had seen myself in hundreds of mirrors placed in front of me. There are so many Pradeep's in our industry. Some Pradeep might not even have got this far on this post because he might have thought, "Oh, this is lengthy". 


If you don't look like Pradeep when you stand in the mirror, here are the posts:


Project Estimation and Black Swans (Part 1) 
Project Estimation and Black Swans (Part 2)
Project Estimation and Black Swans (Part 3)
Project Estimation and Black Swans (Part 4)
Project Estimation and Black Swans (Part 5): Test Estimation


The next time you don't want to read a post just because its lengthy, remind yourself that if you miss spotting the Black Swan, it doesn't mean Black Swans don't exist.  They bite hard to remind you that they existed and you didn't pay attention to them.

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