News - Moolya Software Testing Private Limited launched

I have been patiently waiting to write this post. Many times I wanted to but then I postponed it to this moment and I would tell you why. The news is: Santhosh Tuppad and I have co-founded Moolya Software Testing Private Limited in Bangalore.

What this means to customers, you and the testing community?

That's an important question we'd like to answer. We are going to be offering testing services. Take a look at our logo and that would tell you the first part of the story. Do you know what Moolya means?

We wanted our name to depict what kind of testing we practice and offer our customers. The central theme of our testing is "cost versus value". Moolya is a Hindi word which has two meanings: cost & value. We simply loved it the moment we discovered it. Added to that was domain name availability. It was available and we just jumped on it. 

We crowd sourced the logo design and ITdude (as the designer likes to be called) from Philipines did this excellent logo for us that symbolizes what we wanted to depict as our next theme of testing than cost versus value - using brains - thinking skills & not rote procedures. My uncle who has been a logo designer himself, gave a little touch of his own to the logo to add a vibrant color and choose the font and design our business cards and letter heads.

Then on the services part, we choose to target people who value good testing. Fortunate for us, even before our incorporation, we had a customer wanting our services. Our first project was to test a Cloud Based Operating System. We felt blessed to have that kind of a start for our company. The client was and is happy. They have given us more business.

For those planning to outsource their testing work or seek consulting, the services we offer are

• Offshore testing services
• Exploratory Software Testing Services & Session Based Test Management
• Check (Test) Automation & Test Design Automation
• User Rejectance (Acceptance) Testing & Beta Testing
• Consulting & Training
• Staffing++

So what, everybody provides that? As every company says they are different, we'd like to say, we aren't just like those different folks out there. You should consider visiting the Services page for more details.

For testers  

We hire testers, isn't that good news? ;-) More than that, our interviewing isn't going to be traditional or easy. You don't send us your resume, you send us your test report, a contact number and an email id we could get in touch with you. We would discuss about your test report and get you to test software and put you in different contexts. That's our way of hiring. Even if we scale to thousand testers, maybe, in a couple of years, we will hire that way. Right from freshers to senior people, they should be good at testing. If in case you have a certification, we don't have a problem with that. We don't care about your certification because we care for you. We are working hard at planning and creating a women friendly organization. We are also going to be tapping a lot of hidden talent.

We believe and practice what Fiona Charles said, "Lousy customer service often comes from unhappy employees. Treat people well & they'll pass good will on." 

We will treat you well. You may like going through our Careers page

For the community

We are working on putting our office open to all testers during Sunday. We are going to be stocking lots of good books (The Weinberg, The Kaner, The Bach, The Koomey, The Guaspari, ...), providing you power and internet and you may make the best use of it. You may end up meeting other testers who have come in to read books or practice testing, and can enjoy what you enjoy the most - learning to test & continuing to be better at it. You might find Moolya employees on Sunday chilling out if they need with you folks. Wouldn't it be great if we provide free wi-fi to those who wouldn't download movies but use it to learn testing? Yes, it would be.

We currently have a 25 seater office and as our business expands, we'd like to care for more of you. We just hope to make this company a dream company for good testers. We know we will make it.  

Why we think Moolya Testing is special?

Moolya belongs to a very important time period in testing. It is started by those who started their career as a tester, have remained hands on & shall remain hands on. They may hold the designation as the Director or CEO but they can test good if not great. They have at least played a small role, if not big, to stir the beginning of Renaissance in Indian Testing. They know what customers want, they know what testers want. They are young yet experienced, with lots of energy & passion. Most important of all, they have nothing to loose, so they can be crazy, creative, sound jazzy, cool, and do things that other companies just isn't doing. They are the Microsoft & Apple of 1970's. They are the Google of the 1990's. This would probably be the first Indian services company that would not talk about "head count" but talk about "brain count" of their employees.

Our culture

Just because we are testers, it doesn't mean we haven't educated ourselves on anything else. We have put special emphasis on our culture. We have been working on things that can make a great culture to a company. What is that? We'd get our employees tell you those stories, than we letting all of it.

My wishes to Santhosh Tuppad

I'd also like to mention that by having co-founded Moolya with me, Santhosh Tuppad, must have become the youngest tester entrepreneur. Congratulations to him. You are a bravo.

Going forward, India might see more such. As I said, Moolya Testing is the first of its kind company from India that is aligned with the Indian Testing Renaissance. 

Thanks

A note of thanks to my colleagues Parimala, Sharath Byregowda, Manoj Nair, Dhanasekar S & Mohan Panguluri, Vipul Kocher, Nandan Pujar, Satish Thakur, James Bach & Michael Bolton for the support they have offered so far. Needless to say, without our parents, siblings & family help, we wouldn't have been able to achieve this. 

Follow Moolya Testing

Feel free to join us on Twitter, Facebook & LinkedIn. Peruse through our website. I postponed writing this post multiple times to be able to write this from the office of Moolya Software Testing Private Limited. We are in JP Nagar 2nd Phase, Bangalore. Feel free to contact us. The story of starting Moolya Software Testing Private Limited will be launched as a book in 2011. It's going to be self-published.

"Consider engaging Moolya for your testing needs, we'd like to put smiles on *your* customers face." 

Who is making software testers, dumb and bad?

Not so long ago, I thought there existed a set of testers called, "bad testers". I hated them. I wanted to punch them on their face and get their face to bleed. I wanted to become a powerful politician and kill them all and escape without being charged for genocide. I wanted to become a superhero and get people to fire them from their jobs. I wanted them to beg for jobs, money and survival. I thought that is the way to get them to open their minds for learning. All this should have shot my blood pressure up while those bad testers remained cool. They were untouched by my criticism and continued to think that I was an asshole.


Whenever I found them, I insulted them as much as I could till I realized that they needed more care from me than those whom I was already caring about. I started caring for them. My world changed and so did theirs.


I was always wondering how these bad testers are happy. Needless to say I thought I am a great tester and still continue to think that way. By "great", I mean, "just what is required". Today, you can be a great tester by being just what is required. Tomorrow, the case might change.


I tried shifting the question from "Why are bad testers happy about themselves?" to "Who is making these bad testers happy?" and "Who is preventing the bad testers to learn that they are doing bad testing?"

That's when I said to myself, "There are no bad testers. There are some who are forced to practice bad testing. The force is either internal or external or a combination of them".

That was an important shift in the strategy that helped me in my exploration of identifying what factors cause a tester to appear bad or practice bad testing.


Internal forces 
I mean, ones that the testers themselves are responsible for or have control over.

• Money more important than anything else: For some testers who are sole breadwinners of the family, they might internalize the idea that what works for others is a safer route to traverse than exploring new paths and risking their cash flow. They spend their life traveling those peoples route who themselves have followed someone else's route. All finding it to be safe and hence not wanting to change.

• Fear of losing the job: For some testers, losing a job means unbearable social pressure. These testers don't ever try to speak against anything to protect their jobs. Their whole life is spent on running just one test case - Is this the right time to shut my mouth? - to which the result always remains - Pass.

• Shallow ambitions in life: For some testers, their ambition is to never do something fascinating but just run the rat race, build a house, buy a car, get married & have kids. They also try to ensure that their kids continue to run the rat race. I am not speaking against taking care of the family but taking care of the family should be balanced with building high ambitions in life and working towards it.

• Victim of Rutherford-Bohr's experiment: Some testers, no matter what exciting stuff they are presented with, try to return to their most stable state of ignoring all the exciting stuff because their life is already happy (grounded). 

• Living someone else's dream: Some testers, don't have dreams of their own. They just pretend to have their own while they are living other's dream. Some live the dream of their parents and rest their manager's. Living others dream makes their life boring and they give up on almost everything, forget testing.

• Taste of early success causing a drift from continuing to learn - Mostly a very dangerous one. These kind of testers think they are on the right path and there is no reason for them to change. 

• Having learned that good testing is hard - Some testers acknowledge what good testing is but they also learn it is very hard to test well. Out of that, some of them make up their mind saying they are not in for such hard work because they think life is bigger than doing good testing. Nothing wrong but they don't seem to be doing to the big part well, either.

External forces
I mean, the ones who are responsible or has a power or influence to get good testing done.

• Head or Tails of testing - I have talked to at least slightly less than a hundred Heads of Testing of big, medium and small scale organizations. They have so much power to change things and yet they don't seem to be doing anything about it. I must also admit that some people are doing very well while most don't appear to be. Why don't these people take a break from their work, sit along testers on one of the project and test for just a couple of days to realize how hard it is and what can they do to help these testers do a great job. 

• The interviewers - At least people in India, when they are out of college, want to just learn enough to crack an interview. When interviewers emphasize on demonstration of memorization than skills, its easy for a billion plus population to crack them. Fakers get in, Genuine people might not.

• Testing institutes - Business demands scale, I agree. Scaling at the cost of quality of education is in my opinion, spoiling your own country's chances. Please read the book Outliers by Malcom Gladwell and more specifically Chapter Five - The Three Lessons from Joe Flom. You'd know what your business needs for future if it has to remain scalable.

• The experts - If you have great ideas, please price them a little lower for the first few years or based on the geography. You won't be considered cheap, trust me. Don't make money an entry barrier to someone who wants to get excellent at testing. 

• Commercial conferences - If you have have had good deals of sponsorship and paid delegates for a specific year, consider giving 80% discount to 10 people who cant afford it but want to attend it.

Combination of internal & external forces

When the external forces & internal forces combine, its a killer combo for bad testing

• Lack of speed in firing poor performers - If the people responsible to get good testing done are delaying in firing poor performers then the hope in the poor performer rises that he or she is doing well and should continue doing that. In at least half the organizations I consult, I get the opportunity to consult because they haven't fired the poor performers for a long time and something went kaput.

• Not paying good testers well - I have been to a few conferences in India where Head of IT or Head of Dev or Head of Testing are keynote speakers. Their speech is usually, "We have come to realize that testing is of great importance" but then they don't match the pay of the good testers they have to their claims. People call that "keynote". Can you walk the talk?

• Waiting till the year end to spend on training budget - Wondering why many organizations keep their training budget till the year end and not organize a training when the team needs it sometime mid year? As a side note, I wish, in India, the Learning & Development department, which is a separate entity in the organization is eliminated and every department becomes Learning & Development apart from what they do. 

• The book writers - When you write books that are not different from any other books that are available, you are re-iterating the point that the industry isn't changing. Many testers who accidentally pick up a book and skim through it read stuff that they have read a couple of years ago feel they are on track (and also end up not buying your book). Is that a message your book wanted to communicate?

I am 30 now. I am more curious about my age of 50 and waiting to get there, because I hope, I would have seen many changes - lots of positive ones. Mostly because the generation to which I belong or the generations junior to that of mine would have solved the problems I have listed and might have gone beyond that. I am not discarding the fact that the older generations have not solved it. There are dozens of them out of a population of millions.

When I tried punching just one bad tester I met, blood oozed out. Not on the face but in my hands for it was a mirror that I saw. 

Experience report of testing versus checking

Many thanks to my client in Bangalore who encouraged me to blog about the experience, value and outcomes we had in separating tests and checks. If you are reading this, it means my client has approved this for publishing.  

Thanks to Michael Bolton who posted a series of posts on his blog under Testing versus Checking and those who commented on the posts, whose ideas and thoughts helped me to think about delivering the value of tests and checks to my clients. Tests and checks series of posts has helped me communicate things better and organize my thoughts better. We were using the term "check" and "test" much before Michael blogged about it; however, he gave a cognitive structure to it in our brains.

The context

One fine evening, there came a client looking for me and the story goes like this... 

I was hired for a couple of weeks, to consult and test various products produced by a large organization whose headquarters is in Europe. The moment I was hired, there was a need of a hand to run through a few tests on a product. The product was used for analysis of something across many country deployments. It has an engine loaded with business rules, lots of history data in a database and report viewer application. How do we know if the business rule engine didn't violate any rule? The reports had to comply with complex business rules that at the first sight appeared to me as contradicting one another. The core development of the product was being done by a vendor in the US of A, who was reputed within my client's office for pumping in poor builds, as frequent as they could. I wish I could tell you more than that.

Video test cases instead of lame text

On starting off, I realized that the learning curve on the project appeared to be steep and I couldn't cope with it in the time I had. A demo was given to me from a colleague who had been running tests ever since he was hired. Does a demo suffice? No way. 

Building a little credibility with that colleague helped me convince him to record videos of the demo and tests with the help of Windows Media Encoder 9.0 for Windows XP. So rather than following dumb scripted tests, I was watching a video on one monitor and running tests on the other. Video test cases were more reliable than documented ones. Based on how quickly I picked up things, the videos are now being planned as training material instead of asking someone to go through test cases. 

Recognizing checks being called as tests

On running them, I realized, what I had been running were checks than tests. To quote Michael Bolton, Checks are machine dependable and tests require sapience. I was checking if the report complied with all business rules. While I was checking, I instantly knew that these checks could be automated.

Testability, Test Coverage Issues & Stakeholder Interests

I noticed a couple of bugs in the software were preventing me to run other kinds of tests as fast as I thought I could. Anything that blocks me or slows down my testing is a serious issue for me and to those who have hired me. With the proposal to test for various quality criteria being accepted, I made a presentation to the stakeholders of how the quality can be improved at least with respect to testability and other quality criteria (such as Usability, Performance, Security.. ) accompanied by a test report.

They instantly liked the improvement of testability idea because to check if the business rules are not violated for every installation, they had been taking 2 - 3 days. They needed rapid feedback to take better decisions.

Imagine looking for a specific value across many excel sheets. By the time you are on the fifth, you might almost forget what you saw on the third and where you saw it. However other kinds of quality criteria didn't matter to the stakeholders for their current context. I wish they had considered it but that's a business decision. My bug advocacy was strong though. I had stakeholders wanting to automate the checking part of our testing. That was a winner.

Partnering with developers

I was sitting in an organization whose policies and people are new to me. I was proposing things that required lot of dependencies on other people in functions such as development, business analysts and on-site personnel with of course the management. The time frame I required to achieve this was really short. Writing emails in a manner that helped the people realize the importance of the value was a big winner for me. For instance, here is an email I sent to the development team that sits in my client's location who mostly do some integration and writing wrappers.

Dear Developers,

Greetings!

I am glad to be interacting with you. As we are committed to reduce the time we take to analyze a release of XXX XXX, we realize that a tremendous saving to the organization can be contributed by making a few changes. We have made a few things from our end, such as, having a formula do the job for learning about XXX-XXX rule being satisfied for all installations. Creating a repository of possible combination of tests we need to do to be able to say we have exercised the business rules very well.

In that path, we realize that with your help, we can do a lot more. I understand that you might be busy with other things on the table but as I feel we are working together towards a common goal, it makes me request you to help us.

We request the following things from you:

• Currently we are spending about 3 – 4 hours manually to verify the XXXXXX business case for a small installation.  
• We have investigated and conjecture that if you help us have the XXXXXX ( such as XXX or XXX details ) to be available in a list associated with corresponding XXXXX and the XXXXX, it would take us less than 5 minutes for us to perform the business rule validation.  
• If these details are a part of the export of Weekly Report (highly preferable) or as a separate excel list (less preferable) it would help us achieve the goal.  
• Assuming a set of testers will be testing XXXXXX for all country implementation in future, you would be helping us bring down the cost of testing by a couple of thousand dollars ( Well, Euros, as we are European based )  
• Additionally, as we are doing it manually, we are not exceeding more than 10 categories per installation. With your help we would have the capability to go as much as the number of categories the system can support. Thereby, we test for larger samples and increase our data coverage.

We would be in a position to provide you any help you might need from us in achieving this task or would be glad to offer back any other help that you may require to make your work more effective.

Thanks & Regards,

-- Pradeep Soundararajan

30 minutes, no response to the email. At the 31st minute, a developer was at our desk. It happens that he was serving his last day for the organization and carved out time for us. I considered that as a great gesture by a developer to support test team and our test team brought a chocolate for the help he offered. I couldn't get a "Thank you" card; else I would have wished to have given that as well.


That developer helped us with stored procedures and SQL queries that we need to extract data out of the db. 


The Checker Tool Development & Testing

So, instead of looking through reports exported through the GUI, we now had the option to extract values directly from the database. We got one step closer, to what we wanted to achieve.

While I was planning to write a Perl script to extract the values and dump it to an excel sheet, I became aware of a developer in test who joined the organization and had not yet been assigned to a project. The good news for me was she hadn't got her computer to start working. I requested the manager to get her time for helping us write a script and gave her my PC for 2 days while I mostly roamed around saying "Hi" to people around and getting a hang of the culture and talking to people about their work. I could have done all by myself using Perl but I know how slow I'd be as compared to a developer in test.

I provided her with requirements and all necessary tools that she'd need to develop and test the script that could dump the values in an excel sheet in a format we wanted. It's a complex data structure and in order to perform an analysis we had to develop a report format. With the help of my colleague, we zeroed in on the report format and in 2 days time, she could help us see what we wanted in the report format.


TDD for writing Excel Formulas

Off to validating business rules through Formulas in Excel. I knew the power of Excel and its formulas but I didn't know its limitations. I remembered that I had received an email long back from someone containing  MS Excel formula dictionary as an attachment. I pulled that out to help myself.

Excel shouted a warning and error if we exceeded 7 nested loops. It didn't warn us when we had a typo in one of the formula, a star * symbol instead of 8. Copy pasting formulas from one sheet to another had reference to the previous sheet. I know lot more about excel than what I knew earlier. 


I wasn't doing a good job and I knew it very well. A month and a half back I attended a demo on TDD from Venkat Subramaniam. It struck me at the right time. Instead of continuing to do a mediocre job, I started collecting data, scenarios and information that should make the formula fail or pass. I started to write the excel formulas based on the data we had. My colleague who had been in this project for a while helped me get the set of data that had to result in pass and those that should result in fail. If you may permit me to say that writing formulas as, "coding"  then we were pair coding.


This was very helpful. After starting with that approach, we could find bugs in previously written code. Prior to the TDD and paid coding approach, I wrote a formula, loaded the data and checked to see if it failed or passed. For a condition in which it should pass, if it failed, I used to tweak the formula to see a Pass. That was dumb, especially, after I knew that making a Pass could impact other things that were supposed to fail. 


With TDD in, we achieved faster progress on our business validation formulas. We were now at a speed lane. We cracked the puzzle too. We could check for business rules violation in a matter of few seconds.


Comparing humans and tools for speed

I am against the idea of comparing human testers with test automation. I still am against the idea but I saw myself in a situation where I was comparing automation with manual effort. Why did I do this? Should I remain silent about what I have done and continue telling people who attend my workshop that; comparing a human and a tool for speed is a bad idea? I was reminded of James Bach's blog post "Manual tests cannot be automated" and Jonathan Kohl's interview where they put a lot of things so well that I couldn't have put it then.

In self retrospection, a learning emerged. We didn't automate tests, we automated checks. As humans who were not supposed to be doing checks were doing it, I was forced to make that comparison. In fact, I should have said, "Please do not see this as a faster way to do things by comparing how testers were doing it earlier. They weren't even supposed to be doing that. I just wish there was more freedom and a little bit more authority for them to express it".
  
Getting our tool tested by domain experts

"Yipee! It works". That's not what we thought. When we developed this tool, we were sure that the users of this tool could be beyond the test team and how good our tool was to be decided by a "domain expert". When we showed some of our unit test results to a business analyst in house, he was excited at how simple this would be for him to use when he goes to assess a country installation in the future. He vowed to support all that we needed. He offered help writing us a few formulas that we needed. I tweaked it to suit our needs. 


He had a logic that I wouldn't have touched upon. So, that really helped. We didn't need to be a domain expert all by ourselves to be able to do this. A testing brain and a domain expert brain coupled together yielded a lot of value.

Added to that, he was a key stakeholder we had in house. He acted like a customer in house. He suggested the changes we needed to make it more suitable to other stakeholders' usage. Having been on site, he could bring the perspectives of people who could use this tool and their contexts. We needed lot of clarification on the business rules. Imagine a set of rules contradicting each other but still plausible under certain contexts which had to be shown as pass and not fail. Whoof! I liked it :)




Live Testing of Business Rules Validations Checker Tool V 1.0

So, our in house customer was happy with it. We showed a demo to the test management and they were excited. The test manager was excited enough that he pulled out the product manager out of his busy schedule to show our tool to him. The product manager was about to be in a meeting and he asked us, "How long this would take?", because he knew the business rules was taking a few days. When he asked us that question, we initiated the script, took a deep breath and said, "It's over". We showed him the report and there was a smile that our test manager was hoping to see. The only skepticism he had is about business analyst's approval of this tool. A bug in this tool would really misinform the decision makers.

So, the tool was shipped to people in Europe who tested it on the live system. They took about 2 days to get back. It wasn't a very nervous moment at all for me. I was just impatient. They had to take two days to approve this tool because they had to compare the results of the tool against their manual checks. While we were waiting for the reply, we continued testing our tool to see if we could spot problems. We ran it for several test installations and we made notes on how we could improve but no bugs found. 


The climax

On the next day when I was traveling to my client's location by bus, I get a call from a person who heads the testing for the group which I was hired. "Are you in the bus? Can you get down? I want to talk to you. I will come there soon". Before I could ask anything he disconnected the call.

That's really crazy. I suspected something must have gone wrong. I thought the Head of Testing wants to give me a bad news that my consulting contracted is terminated. He arrived at the place, I got in, and he showed me an email and said, "Congratulations man. This is great news". The tool was approved by the business analysts who were on site in country installations. They said it was accurate and also proposed some modifications to a dashboard we had created in the excel. It hit the target on the bulls eye. 


The Head of Testing and I together prepared a presentation of the whole story to circulate it throughout the organization. The Head of Testing currently hopes the concept of separating tests and checks is carried over across all other projects. 

At one side I was extremely happy for being such a value to my client and on the other hand, I was telling myself, "Consultants like me are made to look good for doing what everyone else is supposed to be doing". Had my colleagues at the client location been people who were active in learning, I wouldn't have sounded like an expert tester to them. I just feel pity and can offer the help I can. I have to move on and learn more things.


Preventing bad builds from sneaking in

The story doesn't end there. I had another proposal up my sleeve. I wanted to ship this tool to the vendor in US who was pumping in bad builds. We are planning to use the Business Rules Validation Checker Tool as acceptance checking of a build into the client's location. The idea of automated acceptance checking appears to be interesting to my client since they work with several vendors, delivering broken builds not as frequent as the vendor stated above :)


Return on Investment, in its true sense.

The ROI is not about the speed with which a certain task is done. The actual ROI is that the testing team time is now freed from checks to do exploratory testing, bettering the test coverage, faster feedback, better informed decisions, focusing on things that they were not focusing on AND preventing bad builds from entering the client's location.

I thank my colleagues (nicknamed) Rag and Tham for the support they offered me in the three weeks. Without a management providing freedom to a tester like me, this wouldn't have happened. So, thank you Mr. Head of Testing, Test Managers and Business Analysts for all the support and for approving this blog post.


The only thing pending is a party to celebrate. Mr. Head of Testing, are you reading this? :-)

Coaching testers on Bug Reports, Advocacy & Credibility

Here are some of the funny/awful bug reports that I have seen in my experience:

• "When I open the application and click on that button I get a error massage saying it fatally crashed"
• "The spelling of Transport Parametre is miss spelled"
• "When I perform a submit the application has error message and thrown on the right side"
• "I open and it crashes"
• "The application is giving me unexpected message to work"
• "Clicking on that link is taking me somewhere and I am unable to return"
• "Applications is throwing pops up when I put my mouse on links of ads"
• "Click fast links and get error message"
• When trying to establish connection with devices some device say I am not available
• Everytime I execute test case TR234 my PC rebooting
• Test case TR 343 fails
• When users click Submit twice & hangs.
• After waking from sleep, application don't respond. (Hope you got what the tester was trying to say)

Impact

• Now, that's funny for the moment but what about the credibility of such testers? 
• Why would they be respected? 
• Why would their bug reports be even read further? 
• Why would they need a hike? 
• Why wouldn't they be treated not on par with others? 

Unfortunately, more number of such bug reports have made developers sick of reading bug reports. That's why you'd see developers call testers to their desk and say "Show me that bug". I am concerned about this problem because it is yours and mine. When we who report bugs in a credible manner join a team and report bugs, the developers still ask, "Show me that bug". That's how bad the effect has been on most developers that I have come across in India. Other country folks reading this could share their experience.


Bug reports are one of the key factors that make or break the credibility for testers.



You know about Hands on Software Testing Training from India? If you haven't, you must take a look at the excerpts of students work. You might be surprised and ask me if fresh college graduates from India really reported such bugs in such a credible way.

Santhosh Tuppad, a tester who chose me as his mentor, striked this distinction - he was profiled at Utest for gaining credibility for the highest bug approval rate. You should read about it, I think.

Santhosh, just has an year of experience. However, the practice he did, in that one year, is what has made him get profiled at utest and win the credibility of the highest bug approval rate. Not just Santhosh, his batch mates are doing exceptional as testers /for their year of experience/ in the organization they work for. That even includes his girl friend :)

I just did what any training is actually supposed to do. So, I am not going to be bragging about myself or about the magic / voodoo stuff of coaching testers. Its safe, you can read it without getting hurt.


Its a shame that some of us are being looked upon as good thinkers for just doing what every tester is supposed to be doing. That's the state in which our community is. I think the difference is that we /those who are considered good thinkers/ are bolder, respect ethics, have higher self respect and want to see the community better.

Let me just share how I coached testers on bug reporting and bug advocacy, so that it could either help you coach yourself or others. The ideas to coach testers that I have is abstracted, borrowed, redesigned, modified from what I observed while getting coached by James Bach & Michael Bolton. I also did a context driven approach to suit India.

Coaching testers to report bugs

There is a one week of training & practice session on Bug Reporting in my Hands on Testing Training class. In typical approaches like ISTQB, CSTE training, they appear to cover it up in 2 hours or less. Wow! Those guys have scalability and I don't.


So, I set up the bug tracking system, provide them a buggy application (mostly any software) and ask them to report all bugs they see. I clearly state that it is not about who finds the most number of bugs but who reports bugs in a credible manner. I don't teach anything about bug reporting when I start this exercise and leave it to them to learn it through the experential approach.



I am logged in as admin from my laptop. The first bug report arrives and I call that participant to my seat. I critique the report in following ways:

The developer view

"I am a developer and I don't understand your bug report. I don't know if this is happening while running in Vista because I see a different behavior in XP. As you have no indication to me about your OS, I have no clue what to do with your report. This is why I don't understand your bug report. I am deleting this report because it doesn't make sense to me. Can you report it again in a way I can understand it?"

• The participant goes back and attempts to report the same bug with additional points based on what I mentioned.
• That participant whispers the message across to other participants and I just act as though I don't know about the whisper.
  

Some kinda smart people pick up a little more and mention other details such as Service Pack 2/3 so that their bug report doesn't get deleted again but others don't get it yet. No problems, Pradeep is there to help.

The next bug from another participant arrives and also gets invited to my seat. "I am a developer who is sitting in US of A and I can't understand your English. Maybe it would help me if you could send me a screenshot or a video. I am going to delete your bug report as I don't find it helpful to me.

•  So, that participant goes back with a little disappointment that although the System configuration was mentioned, the bug report was deleted.
• Whispers about screenshot and videos gets started. I didn't hear any such whisper :)

The next bug from another participant with system configuration and screenshot. A 6 MB BMP attachment."I am working in a dial up connection and this attachment is taking 20 minutes to download. I have lost my interest to see the screenshot. Maybe you logged a great bug but I would have been able to see it if it were a JPG file that takes lesser space"

• Whisper! Sssssh!
• I don't know :)

Another bug, another participant. Spelling and grammatical mistakes, filled and stuffed in the report. "Thanks for coming to my seat when I asked you to come. It shows the respect you have for me. I wish I could respect you that much or maybe even more. However, I see that your English looks so bad that my colleagues would laugh at me if I respect you. In order to prevent that from happening, I have no option than to delete your bug report"

• "Hey, please correct this report" whispers one to another.
• I then announce "Microsoft spelling and Grammar check is your best friend".

As a Developer who loves to say, "No user would do that"


"Hey, the bugs you have reported are not actually bugs. So, I am deleting them all".
"What? Sir, we put in so much of effort and you are deleting it all" (Hate the "Sir" part though)


Well, if you'd not want to me to delete any of your bug report then I need strong evidence and investigation of why you think it is a problem. I wish I knew which Oracle you used but none of you reported any such.

• At this moment, I hear people wondering what oracle they used to spot the problem and trying to add to their existing bug reports.
• I announce, "You could ask me which oracle if you are not sure". For the next 15 minutes I am your friend who knows how to test and the oracles for the bugs you reported.
• Those 15 minutes is real busy time for me.

Next iteration. "The oracles you mentioned seem to be OK but I am still not convinced if that is a problem. It might help me understand the problem if you could tell me the impact it has on the user. Hello! Bug Advocacy! Cem Kaner! Google!"



So that goes on and on and it takes them 3 days to get one bug report to not get deleted by the developer. By then they have surpassed most of the ISTQB, CSTE or any other similar certification training. However this approach that I am talking about here sucks. Man! it doesn't have scale.



As Test Manager


So, from today I am a Test Manager. Not a developer. I hear a sigh of relief. They think their reports wont be deleted as much as it did with the Developer.



"Ah! My manager has called me for a meeting to give an update. When I look into all your bug reports, I get no clue what it means. Your summary is either too long or I am unable to understand them. I don't have time to go through your bug reports in detail. I shall delete all bug reports that do not help me make a quick assessment of the quality of the product"


"Hey! Here is how I report bugs!"

• No Whispers this time.
• They start copying my style and when they are learning it for the first time, that's Okay.
• All bug reports gets changed to a style that I follow.
• The beauty comes when some people try to modify my style to their own style. That's the Indian Masala I like the most.
  

Now, that kind of thing happens for a few iterations and it goes for one full day or so, till I am satisfied about their bug reporting as a test manager.


As a co-learner


"Guys and gals. Now, we are pretty OK with bug reporting and bug advocacy. Let's try to critique the bug reports that are public and try to learn if there is something interesting that others do that we didn't so far"


I open bugzilla.mozilla.com and go through many reports and ask them to point out the good and bad points in the bug report that we are observing. We have a discussion, argument and debates on it. So, we end up refining ourselves and I drive home some important points of bug reporting.


"Folks! Lets test your bug reporting skill. Let's work on another project and see if we repeat any mistakes or make new ones".


Fail fast, Fail Safe


I failed miserably in a couple of exercises that James and Michael did with me as a part of Rapid Software Testing. However, for me, it was safe to fail in front of them than to fail in front of a client. I was glad I was exposed to a context that I failed although that kind of context had not been on my work yet. When the context actually arrived, I said, "Aha! The Wine Glass". Its a RST secret :)


I have a checklist of things I would make the participants fail and get them corrected of it with respect to bug reporting and here are some of them:

• Spelling, Grammar & Typos checks
  
• No usage of SMS language
• Crispy & Useful summary
• Serving different stakeholders
• Observations
• Investigation
• Risk to the user
• Inferences & Conjectures
• Cost versus value
• Screenshots & Videos
• Log files & Supportability
• Symptom versus problem
• Cost of fixing / not fixing the bug
  
• Questions to the developer
  
• System, Browser and all other relevant configuration
• Test Environment awareness & details
• Self critique of ideas and bug reports
  
• Peer review
• Input / Output / In between : test data, system state, environmental changes
• Hardware

Enough! You might ask me how big is my bug report usually. Well, it depends on the bug and the audience not on me. In the last two assignments that I am executing here in Delhi, a light weight bug reporting with all above information is helping me win accolades. Sorry for bragging although I said I won't. Its kinda bad habit, you see.


Oh, you know, I also won the Top Best Bug at Utest in the Bug Battle of Search Engines. I wish Utest could publish that bug report. Since then, I see some testers attaching videos of their bug in utest bug battles and releases. It really solves the problem of language barriers, steps to reproduce for most of the bugs. I didn't invent the idea of video recording bugs but I practice it and advocate it to be used in contexts where it helps.



So, coming back to the topic of Bug Reporting, Bug Advocacy & Credibility. So, are you surprised that Santhosh Tuppad who went through such a training achieved the status of highest bug approval from Utest and is invited to many more releases to test?


Whenever I go and speak to businessmen in India with the results of this kind of training approach and the value it can bring to the community the thing they say after saying "Great" is "This doesn't have as much scale as ISTQB or CSTE where I can make any Tom Sick Hary to replicate the training. Slides are replicate-able. Good luck".


So the message to you is.Forget all this hands on approach and other blah blah. ISTQB has scale. CSTE has scale. CSQA has scale. ISEB has scale.Go there and learn to memorize the CBOK and practice to puke it on the exam.


I don't coach people to memorize. That's not how I was coached. Go find a guru who would teach you good stuff. Don't waste time with businessmen talking about a stuff that they too know is good but they think won't scale.


I will show the world that good stuff can scale. If you didn't like the word "I", let me replace it by another.


"We will show the world that good stuff can scale".



The Avatar!

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.

Rahul Verma on Fuzzing for software testers : Nov 23, 2009

I think I was stupid to have missed mentioning this tutorial from Rahul Verma on Fuzzing for software testers in my previous post. My apologies to all testers from India for overlooking at our own indigenous talent. Rahul, please forgive me.

Fuzzing is a very interesting topic and I dont want to loose out on attending his session in Bangalore.Have you ever corrupted a file? Have you been curious to see what happens to your system when the database is corrupted? What happens to a live / production server if a file is corrupted? Have you ever experienced a file/data corruption at the customer end and the ripples it caused your organization. I know its very important and thankfully Rahul has focused on it much beyond most of us. If I could better my fuzzing skills, I can extend my competitive advantage.

Once I was a part of a test team whose responsibility was to test multimedia streaming on a Pocket PC. Pesticide Paradox kicked in and our test data was no longer helping us to find problems.

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.

Secrets of a Buccaneer Scholar : Free Download Limited Period

About a couple of years back, I had an opportunity to read "How I learn stuff" from James Bach and was excited about it. I had a concern about it that it was not complete and kept asking James for his plan on it.

Little did I know then that it would turn out to be a great book for the community and not one that was accessible to those who work with James. When I learnt from James that Simon & Schuster have agreed to publish it, I was excited about it and my urge to read the complete stuff skyrocketed. I must say that I had reviewed its initial draft and reading the book today is a fascinating experience.

I also thought I had enough money to gift it to all those people whom I care about. I certainly do care about those who read my blog and here is a gift that Simon & Shuster, James Bach has provided - It's free download till July 24th. The hard copy is going to be released on my birthday. ( Just a coincidence )


Why is this book one of the most important one's for software testers?


Learning

I recognize that learning and unlearning are skills that are absolutely important for any profession anyone is in. Today, I see a lot of testers struggling to learn the latest version of a tool when it is released, although they are aware of its earlier version. Learning requires mental modeling. If you have a model of learning then no tool or none of its version can intimidate you. Secrets of a Buccaneer Scholar can be of help to you.


Scouting

We witness so many tools everyday that we didn't know earlier. When we discover a tool that could have solved our problems in our last project, we are worried about what tools we are missing to solve today's problem. If you learn how to scout, you wouldn't find it tough to find the tool you want for today's need. We are in the Google age and we don't get to know the right link although we search for it because Google is not kind to everyone. It is kind only to those who know how to scout. Secrets of a Buccaneer Scholar can be of help to you.


Competitiveness

All of us want to be the most competitive in our field but honestly, how many of us are putting in the work that requires to do so or how many of us know what to do to be able to get competitive. Secrets of a Buccaneer Scholar can be of help to you.


Writing

I see that some testing bloggers mostly ape the way other successful bloggers write their posts. Doing that for sometime they are lost of what their original ways are and get into the rut of aping. While aping could be a way to start, it ain't the way to proceed. Secrets of a Buccaneer Scholar can be of help to you.


Fear of unknown

When you ask someone why aren't they self employed, most often you would find that they fear the unknown. The unknown is always bad according to most of us. I meet credible testers in India and ask them, "Why do you think you can't be an independent consultant?" and they say, "Currently my job is secure". Recession times guys - there ain't anything called "secured job". Secrets of a Buccaneer Scholar can be of help to you.


Value of reading

Most testers don't read books. What a great advantage they offer to people like me. Good for me but so bad for them. I am concerned about them. I wish they read just this book ( which is for free till July 24th ). I wish they read because I think after reading this, it might be influential enough to them to be able not offer me the advantage that I had.

To all those testers who don't have the practice of reading books: In case you come across this post or the book and you choose not to read the book, no one can stop you from remaining in your most stable state - ignorance.

Testing Experience Magazine : The voice of ISTQB

I agree you need money to run a business but then...

If you are subscribed to Testing Experience - The magazine for professional testers, you would have got an e-mail recently ( a day or two before this post ) announcing first year anniversary of the magazine. I am subscribed to them from their third issue and in an year they have grown to about 350,000 subscribers ( as per their own website claim )

I congratulated Jose Diaz for running the magazine and for completing one year with it, and offered my respect to him for doing it. I also wrote in the same e-mail to him that I see the magazine becoming too much of ISTQB stuff to which he seemed to disagree with me. I am surprised with that.

I decided to investigate if I could be wrong and presented my findings to Jose over an e-mail:
( modified the construct for your reading and not the content)


Here is my experience of going through Testing Experience magazine

• When I open the website www.testingexperience.com I am forced to look at a pop up ad for ISTQB. Only after closing that I am allowed to browse through the pages. [ As on May 29, 2009 2300 IST ] Do you see anything different?

• Let's look into the latest issue : Security testing: Page: 2 : The opening ad of Testing Experience is ISTQB. It kind of puts in my mind the thing that Testing Experience means ISTQB.

• Page 3: Jose Diaz has personally covered ISTQB in letter from Editor section and he says, "Last but not least, I want you to pay attention to our new e-learning portal www.testingexperience.learntesting.com . You can register for ISTQB Foundation Level and very soon for Advanced Level. Enjoy Learning". When the chief says pay attention to something it indicates to me that Testing Experience is supporting ISTQB because they are feeding Testing Experience with enough money to do that.

• Page 6: Yet another ad of ISTQB in German language or something similar to that. Hey look, before I even get to read the first article in a magazine, I am asked to cross 4-5 instances of ISTQB.
  

• Page 13: Another instance of ISTQB half page attractive ad
  

• Page 21: ISTQB again

• Page 24: Erik Van Veenendaal writes about ISTQB and wooing people to go for it. Here is an excerpt from that article: "The ISTQB Advanced Level scheme offers a complete 5-day module on technical testing which may seem irrelevant to testers today, but I'm convinced will become more and more important to the near future or even already today".
  

• Page 27: Interview with Mike Smith: Yet another ISTQB masala flavor in the form of LearnTesting. 3 pages full of that. As though - Learn Testing means only about learning ISTQB way of testing.

• Page 30: Yet another ad for Learn Testing who in turn promotes ISTQB and run by Testing Experience.
  

• Page36: An article from Rex Black, a popular founder and face of ISTQB. To his credit, he doesn't talk about ISTQB.
  

• In what way is his article on page 66 to 70 that talks about Advanced Software Test Design Techniques is related to Security theme of the magazine? Do we have so less people on Security Testing that we'd have to compensate it by a non security article.

• At least aren't there any other brilliant ISTQB certified testers who can write good articles on Security Testing or maybe even the Advanced Test Case Design Techniques?

• Page 52 & 53 has the ISTQB and information such as "We are the community with 1,10,000 people. Are you on the right side?". Its a Shame. Rex Black speaks against the idea of Schools of Testing but has ads asking testers, Are you on the right side? with a link to ISTQB below it. What is the message?
  

• Page 58: ISTQB in France

• Page 70: Another article from Rex Black
  

• Page 78: RBCS & ISTQB
  

• Page 99: There is ISTQB, yet again and a full fledged article on it for 2 pages.

• Page 103: Is yet another mention about ISTQB being there and being here for those who didn't know it will soon be everywhere .

• Oh and Page 104 also ends with ISTQB training and other details. ( There are only 104 pages of this magazine )
  

• Compare their first edition of magazine and there on, you would see ISTQB increasing with every edition. I wouldn't be surprised that the future editions is only about ISTQB and I see the future in their latest edition.

Testing is Questioning

Where is all the money that many testers across the globe paying to ISTQB certification and training going? Asks Michael Bolton on James Bach's Blog

Is the magazine becoming an official mouth piece of ISTQB or there is so much of bias that it makes me think so?

Whose money is all this? Your money. You didnt know you can make someone as rich as you wanted to be?

I think anyone who is running a business can cling to a brand to build their own brand but not to an extent that the other brand swallows it. If that is the mission, I think Testing Experience is headed on the right track.

I don't know who is in the review board and I suspect that it might not be diversified and have only ISTQB promoters.


What do you think?

• So, you reader of this post - What is your opinion? After seeing all this would you think the magazine is neutral or is serving the purpose of promoting ISTQB?
• Should magazines like these that claim to be for Professional Testers be promoting one kind of stuff or be helpful to the community in allowing different kinds of people to mix with?

Test Republic is a social community for software testers and a not for profit service by Mohan Panguluri, COO, Edista Testing Institute. You can witness that by visiting it. It has events of ISTQB posted in the past, it has CAST conference details and QAI conferences. It has a blend of all kinds of thought process in software testing and arguments. They allow all kinds of information to be posted from all kind of communities and schools. They keep aside their business and do this for benefiting the community. Another example is STC by Rosie Sherry. I think there is lots to learn from people like Mohan Panguluri and Rosie Sherry, for the rest of the world who also claims to be doing it for Professional testers.


The philosophy

Jose seemed to be OK with my above response of facts about ISTQB in Testing Experience's latest issue but wasn't comfortable after I mentioned to him that I plan to blog about it. He cited that his lawyers might have a look into my blog if I do so.

So they might be reading this post along with you. If I question ISTQB, the dynasty of ISTQB will hire lawyers to see if I can be attacked for questioning them?

How cheap? Software Testing is such a nascent field, we haven't even crossed 50 years and already someone is saying "The best practice and right ways of testing" and "we control the field and there is no room for disagreement".

Kudos ISTQB certified testers. You are sinking the field you are working on without knowing you are doing it. Fantastic, go ahead get certified!

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?