Tour of being an independent test consultant

Hiya! Hope you are doing very well. I am Pradeep Soundararajan, your tour guide for the next few minutes. I am glad you chose to take this tour of being an independent test consultant.





Here are some questions you might have: How does it feel to be an independent test consultant? What is it like to be one such in India? Will I be able to survive? Will I make enough money to run my family? Will I make as much money as the organization I am employed is paying me? Will I get enough paid work? What if I don't get paid work for a long time? Will people want my kind of skills? How do I know someone needs a consultant? How do I get clients? How will my family take this? What do I explain to my spouse? What kind of a pressure does society add when I am not in any paid work for a while? How does it feel to work from home not just for a day but for an entire month, or maybe a year or more? Will I have enough money to pay my home loan EMI?



These are some common questions that have popped up from those who have wanted to take the tour. So, if you have these questions or maybe even more, you won't be disappointed with this tour.




Some people ask me, "Hey, can you give me a few clients of yours and help a fellow Indian to also be an independent consultant?" I want to help people be independent consultants in India. By that, of course, I mean, I'd like to see them do stuff that helps them get credibility, reputation, paid work and clients for themselves.



I'd like to take you through the journey of having been an independent consultant. A journey that is not so often written or spoken about



Tour Point 1: Knowing enough about enough



If you want to be an independent test consultant, there are some prerequisites that you need to fulfill. You need to be bold enough, skilled enough, curious enough, pleasing enough and willing to talk to people or do some work good enough to get good enough people to talk to you.



That's a magical formula right? No one knows what "enough" means and hence it is a problem and an opportunity in disguise. If you knew what "enough" meant, you are kinda through to anything you want to achieve. I think, not knowing how much is "enough" makes you to work hard and get close enough. Oops, close enough?



I have been able to survive so far. I have no clue if my current skills are enough for me to survive for the next year and I am on a constant upgrade of skills and knowledge. I invest money on learning and my investment for July 2010 is on a few books, Ethical Hacking Guide to Corporate Security by Ankit Fadia & Job Interviews - Walter Vierera. Time is a much more important investment than money for me. So, just by spending money on those books wouldn't mean much unless I make a further investment of time on it.



Tour point 2: Love for failures



Many projects today suffer because people working on it aren't willing to try new ideas. They are special people on earth who know things would fail even before trying them out. However, as a consultant, if you try to be like them, you'd be expensive for your clients. You would do what their employees are doing for a price much higher than the employee cost.



Its important to not fail at a client's location but should that stop me and you from loving failures? I have a lab where I can experiment ideas whose results I don't know yet and that lab is the world of my colleagues, community and my gurus.



It's OK to fail, once in a while, at a client's location because even if you do great stuff, there could be things beyond your control that might make it look very bad. However, if you can get that client to call you back for more paid work in future, it boosts your confidence a great deal.



It happened to me. I was black listed in an organization and now they not just white listed me but want to work with me closer. Their CEO is in direct touch with me. If I feared failing, I would have done more mediocre stuff than what they thought I actually did.



Tour point 3: Excellence instead of money



India is a great place for some inspiring movies. I strongly recommend that you watch the movie "3 idiots". No, don't Google and read the story, just watch it. There are several good messages in it and one of them is, "Excellence instead of money". This movie is a super duper hit in India. I just wish people not just like such movies but also bring in necessary changes to their lives.



I want to be rich but I want to be rich while I am excellent. I wouldn't mind money coming on my way but money wouldn't necessarily make me feel rich. I want to be rich in testing skills and knowledge. I want to be rich in knowing many testers and how they work. In the process, if money follows, I am super happy.



Tour point 4: Don't expect people around you to understand what you are trying to do



When an article about me appeared on a few national news papers, my article was published on a few magazines, I was interviewed by CNBC TV18, I was on news for a local TV channel, my parents were so proud of me that I can bet they were flying high. However, whenever they see me sitting in home for more than a week without any paid work, they start to ask me, "Why don't you join some company like Infosys?"



If you expect your parents or spouse to completely understand what independent test consulting means then you'd be inviting disappointment. I was expecting them to understand what I was trying to do but experience teaches that I shouldn't. This has nothing to do with the respect we have for them but a learning of what we can't help them understand.



While at home, I am glued to the computer, trying to learn something, practice testing or support my clients post my onsite engagement or reply to emails. Some people around me take it for granted that I am jobless. Someone calls me and say, "Hey, you are at home only na, so why don't you come pick our luggage and keep it there?" It irritates a lot. I am at home but not jobless. I am trying to generate a paid work, which is a part of my work. People don't understand that. So, be ready for all that.



Tour point 5: No promotions and no designation change



If you were used to being an employee for long and then chose to be a consultant, you must know that there is no one who is going to give you a promotion. It is what you call yourself that matters. I am calling myself a Consulting Tester or just an Independent Test Consultant. If I am bored of it in 2012, I may call myself a Senior Consulting Tester. I give myself fancy title sometimes. I was calling myself a Test Magician and then I am now calling myself a Brainual Tester.




Tour point 6: Being an independent consultant doesn't mean you are the expert



Without saying much, I am not an expert and I am an independent consultant. James Bach, Michael Bolton, Elizabeth Hendrickson, Jerry Weinberg, Scott Barber, Matt Heusser, Jonathan Kohl, Karen Johnson are experts who are independent consultants. People like Ben Simo, Jon Bach, Cem Kaner, Vipul Kocher, Ashok are experts who are employees. There are some good thinkers and future experts like Meeta Prakash, Parimala, Lanette Creamer, Ajay, Santhosh Tuppad, Sajjadul Hakim, Ramit Manohar, Sharath Byregowda, Shmuel Gershon, Issi Hassan, Markus Gartner, who are employees, too.



So, independent consultants don't necessarily mean an expert. Employee don't necessarily mean a non expert. If I had to be an independent consultant only after becoming an expert, I wouldn't have been one till now. If I don't be an independent consultant, I don't know if I would ever get close enough to an expert while being an employee.



So, if you are waiting to be an expert and then be an independent consultant because you thought there was a strong relationship between them, you could be wrong.



Tour point 7: Tackling loneliness



Even in 2nd most populous country in the world, there are a lot of people I have seen who feel lonely. So, loneliness is not about people not being around you but about people whom you want to be around you not being around you. For me, my first wife is my laptop, just like many others I guess. So, despite having two wives (laptop and the one to whom I am married), I get lots of situations where I feel lonely. Loneliness is not always a problem; its a blessing in disguise. Ask our fellow bloggers, they'd tell you that they churned out a cool post during such situations.



However, being an independent consultant and working from home means, I have no colleagues that I meet on a daily basis. I meet a lot of new people every year but meet the same people very few times. Having no colleagues to meet on a daily basis means frustration at times.



When I go through Facebook or Orkut and see some people posting photos of their team member's birthday party celebrations, team outing to a hill station, team lunch, going to movie as a team... it hurts me a lot. I just take it as though I am in a penance of becoming a good tester and I have to bear with all of it. Recently, I was pissed off when I found no one to join me for a movie that I wanted to go. Even if I did find, their timing and my timing was off. Hey, employees are pissed off too. So, I am still fine.



Tour point 8: Getting clients is like sowing seeds and waiting for them to sprout



We think clients come from a specific place or set of places and we are wrong. When I was a rookie consultant looking for opportunities, Michael Bolton, told me that finding business is like sowing seeds. He also told; you never know when the seeds sprout.



I sowed a seed by answering a question in a forum without knowing I was sowing it. The one who asked the question was impressed and help the seed sprout by giving me a business worth thousand dollars.



When I didn't have a public reputation for speaking, I offered 2 hour talk called "Mirchi Test Masala" for free. This attracted at least seven organizations to have my talk at their office. I was gaining experience of speaking to testers and engaging them for at least 2 hours. I was also testing my own testing exercise on them. This was in 2007. One among the 250 people I might have spoken to during my Mirchi Test Masala tour was impressed with my talk. In 2010, he asked his current employer to have my workshop for his team. It happened. As you see the seed sowed in 2007 sprouted in 2010.



So, if you want to be an independent consultant next year, you should have started sowing at least 2 years back unless clients are just waiting for you to becoming a consultant. Also note that there are other consultants sowing seeds in the same place. If you are skilled enough you don't need to be too bothered.



Tour point 9: Freedom at its best



If you are my blog reader then, "Some birds aren't meant to be caged, their feathers are just too bright" isn't a new thing to you. If it is, please note that the quote is from the movie Shawshank Redemption. I struggled for freedom to test. I saw that I could test a lot better when there is freedom. I also see that many testers can perform a lot better with a lot of freedom and responsibility bestowed on them. The only way I could win freedom to test in India was by being an independent consultant. These days, I am coming across a few managers who want to provide freedom to test but they don't have the curious people in place.



Tour point 10: Managing the tough situation of low bank balance



During August 2009 to Dec 2009 there was no paid work. There were enquiries but nothing turning to work. My bank account went low enough that the bank thought it was expensive to send me an SMS about my bank balance. At that moment, everyone around me urged me to look for a job. It isn't a bad thing to go back being an employee. At least I won freedom for a while and I can always win it back. I updated my profile and started to apply for jobs. I didn't even get a single interview opportunity in Bangalore. What? Yeah, so, no matter how much reputed you are, nature teaches you humility at such times. I dropped my plan to look for a job and look for some consulting opportunities. Again, a seed sowed in 2008 sprouted and I found 2 back to back consulting opportunities. Today, as I write, I have certain things lined up, clients asking and competing for my dates. I have no visibility beyond a certain month in this year. I have no problem with that. I am just hoping that some seeds will sprout.



Tour point 11: Live your dream



3 weeks back, my school classmate died in an accident. It just reminded me that death is not certain of a time or situation. Any day it might strike. I was shocked by his death and asked myself; what if I die today? Also, if you have listened to the famous speech of Steve Jobs, he talks about death and suggests that we work as though today is our last day.



Living your dream is very important. So important that you may not have another life to live your dream. My dream is to be a good tester and if possible help others with similar dreams to get there. I know I am living my dream today, at least to some good extent, so I am not afraid of death.



Tour point 12: Earning money is tough but not impossible



Some of my own students hesitate to coach other testers because they think teaching isn't something they want to do. Indirectly they are saying, "This demands me to learn new skills which I am not prepared to". There is money in teaching. If they continue to think that way, they would never be able to earn contacts, different learning, upgrade their skills, learn about different contexts, challenges and hence more money.



Tour point 13: Consulting is not only problem solving but jiggling the right things



I was thinking of myself as a super hero by having solved some problems for my clients. When I interacted with Michael Bolton of what I did to claim success, he helped me understand that I jiggled with things rather than solving problems. I started to learn what exactly I was doing. Although I believed I was solving problems for my clients, it was they who were solving it and I was just helping them do it. At times I did solve problems, too.



If you are serious about being a consultant or being a valuable employee and want to jiggle the right things, I strongly recommend you to read Jerry Weinberg's books on Consulting. I mean, Secrets of Consulting and More secrets of Consulting. They are my best reads.



Tour point 14: Get yourself a guru and a role model



Sachin Tendulkar who is considered to be a God for cricket in India has a guru. Suriya, a rocking Tamil actor has Kamal Hassan has his guru and inspiration. Kamal Hassan has more than just one guru. Rajinikanth has a lot of gurus and role models. Virendar Shewag has a role model (Sachin) that he wants to be like. The great Arjuna of Mahabharatha had a guru teach him archery. Ekalavya had a guru. All these successful people have a guru and a role model. In testing, as we think we are experts or good enough, we don't feel a need to have a guru and role model. We sink our own career that way. I must have avoided thousands of traps by having more than a few gurus.



James Bach helped me be an independent consultant and I often consulted Michael Bolton to shape myself. There are other people who have helped me too and have been my inspiration and role models. I have posters of these people on my wall. It keeps pushing me. Without gurus and role models, I would have been lost by now.



Your tour ends here unless you have a few questions to ask me. Thank you for your patience.

Heart of a tester

In 1954, when software testing was just about taking birth, there were two groups that started to form. I was as curious as you are right now, to know what those two groups stood for. One of the groups christened as, "Kuzusu", had a thought that good testing would reduce the number of billable hours to deliver a good enough product and hence had to be avoided. The other group christened, "Shidachi", stood for good testing that can save a lot of stakeholders time and money to deliver a good enough product.

Things started getting hostile. People from the two groups tried killing each other. That's how much they believed in the group they claimed to represent. One or two people being killed once in a while didn't make a difference.  Just a few days before the Christmas that year, there was a huge battle and at least five dozen people from both groups were killed. That's when a lot of people started to propose a treaty and cease fire between the two groups. On 3rd March, 1955, the famous treaty in history was written. "Treaty of brain fight instead of blood", was signed by all members of those two groups in front of the President of United States, South Africa, India, China, Japan, Sweden and Britain. 

Signing the treaty meant; anyone who violates the treaty shall be killed by their respective country administration. The country where many such killings are observed might lose its eligibility to get outsourced testing projects. There was a twist to the treaty. It not just included the names of those who signed the treaty but all future software testers were presumed to have signed on it.

The first meeting of the Kuzusu group after the treaty was held in 8th October, 1956 in an undisclosed location. The outcome of that meeting was; more the number of people on Kuzusu side, the easier it is to dominate the Shidachis.

While Kuzusus were still at the meeting, Shidachis had a plan for the future. The plan was pretty simple; to discover, invent, learn, practice and demonstrate thinking skills that would lead to better testing and better product. So, Kuzusus were focused on Head Count in their group and Shidachis were focused on Brain count in their group.

The common thing they realized through a series of meetings is that they needed to lose their identity and mingle among future software testers. All websites, boards, banners, ads, real estate, documents, registration, news paper citing, notes, floppy disks, photographs and tapes were destroyed. The only thing existing to prove about the existence of these two groups is the treaty document. The next time you visit National Meuseum of American History - Kenneth E Berhing Center, Washington DC, make sure you see beyond certain wall posters there. One with a sword marked on the right bottom corner has the treaty document in its back. 

Ever since 1957, these two groups started to influence the upcoming generation of software testers with their principles but not in the name of Kuzusu or Shidachi. We never know if these groups are continuing to meet and make new strategies to fight each other. We may never know that. 

After so many years, we don't even know if Kuzusus and Shidachis are the ones with whom we interact everyday at our work. They are dressed up as our colleagues and friends in our industry. We don't even know if we are the channel or follower of one of these groups. Obviously, it is nearly impossible to identify or differentiate between a modern day Kuzusu and Shidachi, because they all appear like one, doing testing and wanting to do it better.  

We all want Shidachi group to win. Even Kuzusus would publicly speak about wanting the Shidachis to win and that is how they can remain camouflaged. Another twist to the story happened in July 2006 when a new group was formed by someone somewhere. This group didn't want to give themselves a name and remained anonymous from first. Their objective is; we don't care if good or bad testing is happening as long as we are getting paid, hikes and promotions as regularly as possible.

That's it. It has become all the more tough for the Shidachis to strike large success. You just can't say that you belong to the fourth group who doesn't believe in all this. You are already one among the three. The only problem is, it is hard to know which group you actually belong to. You might have thought while reading this that you belong to Shidachi and the people with whom you work with are Kuzusus. That's exactly how the Kuzusus want you to think because that's the way they do too. Finally, to an outsider, you and the people with whom you work might appear as the third group who doesn't care about good or bad testing as long as you are being paid.

So, the quest for the current and future generation software testers is not about identifying which group they belong to but to work with each other to win hearts. The fight of the brain is as important as the love of the heart. The first organ developed in a mother's womb is the heart and we shouldn't be ignoring it in our fight of the brains.

So, dear reader, whoever you are, if I have said things to you in the past either in this blog or in forum discussions that offended you or made you feel hurt, please forgive me. Help me to be of help to you in future. Its time we consider winning each others heart and brain. 

Also welcome to the Hridaya group!

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? :-)

Usability of usability & performance of performance

Hiya there. My name is Pusher V9.3.4 and I am a web application software living in thousands of computers worldwide. I am twenty four years old. I was born to help humans transfer data from one secured location to another and to provide them with a report of all transfer they have done in the past. I have traveled around the world and for every economic meltdown, I was moved from one country to another. I don't do anything different from what I am programmed to do. However, in several situations, humans using me make conjectures that I do things I am not supposed to.

For twenty four years, I have been silent, mostly because software applications like me need to listen to Windows XP and Internet Explorer for our survival. Today, I was transferring some data for one of the human and just peeped in to see what is he browsing. I hit upon this blog and read the words "Some birds aren't meant to be caged" and instantly decided that I belong to that category. I feel happy to have broken my silence.

This would also be the first time I am going to be doing something that I am not programmed to do. I started writing this post when Chandok from Turkey hit the "Generate Report" button. I am aware that I am running a risk of being kicked out of CoWAP (Community of Web Applications) for violating the rules. I care a damn, I want to be of value to you.

I don't plan to take a lot of your time. I want to tell you a story that I witnessed and was forcibly a part of. So, here it goes...

As the number of computers grew so did the number of users. To those who were developing and testing me, it meant they had to help me handle thousand times more data than I ever did an year back. Someone came up with a plan to test my limits and I could hear a term, "performance testing" being used very often. I don't have any physical feelings like what humans have. To me, if you do a load or functional or stress test, its all the same. I won't empathize with a user when he is stressed. I am not programmed to do that, mind it.

So, one fine day, the product manager came up with a list of response times that I should possess for a set of actions that humans are likely to perform on me. I was wanting to know how good I am programmed to handle complex things quickly. The tests were planned and executed. 5 seconds was the target for a report generation. At that moment, I could generate a report in a little more than 2 minutes. So, there had to be a lot of tuning done on me. After five months of effort, they got me to perform the report generation in 10 seconds. Considering my earlier performance, they thought they had achieved something phenomenal. After they made necessary changes to the hardware on which I was hosted, they could see a further drop and I was generating reports in 3 seconds. To test if I would scale for future, they added about 10,000 more concurrent users performing complex operations while reports were being generated. I was varying somewhere between 8-12 seconds. That night they had a party. Only I knew why they shouldn't have had the party.

About 7.2.1 versions later or in other words, 11 years later, how long do you think the user takes to generate a report? 12 minutes.

While you might start suspecting that the reason behind 12 minutes is due to a highly expanded user base, I still take 5 seconds to generate a report but the user takes 12 minutes.

"How can that be?", is that what you are asking, too?  The math that you have learned is of actually little help in such situations. Allow me to explain that to you.


Due to changing requirements, the report generation which was a one click action was turned to a multiple entry and then do one click action in V6.3.1. So, a human has to input several things before he can actually do that one click on me, to see his data transfer report. For instance, he needs to input the date range, the kind of report he wants, the format in which he wants the report, the email id to mail the report, a couple of check boxes, huh, half a page of mandatory fields and rest half of optional fields.

Here is the scenario of 12 minutes : Most users enter incorrect values. I don't have a problem. Its not my problem if I crash. I want to be of help but if I am programmed not to be of help, I just do what I have to. When a user enters incorrect values in some fields, he is shown an error only for the first field and then he goes makes a correction, hits the "Generate Report" button. I then show him that another field has an incorrect value. He corrects that and then hits the button again. I then show him that the third field has gone wrong and force him to correct it. Like this I do for one full page of fields and check boxes. When everything filled in there appears to be right, I am forced to show a warning that a huge file will be emailed to the mail id given and ask them if they still want to go ahead with it. Finally, the human gets to hit the "Generate Report" button and I get into the branch of code that takes just 5 seconds to generate the report.

"Is that a problem?", you may ask. Trust me, those who developed and tested me believes it is not because they are not aware that the users are taking so much of time to generate a report. "How come?", again, you may ask. Simple, I have a page whose title is "Report Problems / Feedback", many thousands of users click on it and see a couple of fields and check boxes. I just giggle when they close me after seeing that page. That's what you might want to call as "Checkmate" if you are chess player.

I just wish I could have told those humans developing or testing me that, not paying attention to usability and focusing on performance would make them poor performing software professionals. I also wish I could tell them that the metrics they were collecting and the way they were drawing inferences was the best way to fool themselves and the people around them.

Even if I said that, would anyone bother to listen to me? No way. Am I bothered that they wont listen to me? No way.


Yikes, time to go back as it looks like the Chandok has finally passed through all the fields and check boxes.  Bye!

Saving your job versus speaking truth

Some of us have a designation such as “Software Tester”, or “Software Test Lead” or “Software Test Manager” but observing what we do at work makes me think our actual designation is “Job Saver”.

For every action to be performed we ask ourselves a question, “Would this take away my job?” and then do what we consider appropriate to get an answer “No” for the question. So, we never get to say what we want to say. Well, sometimes projects suffer a great deal because some of us hide the truth from the management.

Being in testing, which is a profession of providing information to business decision takers, hiding the truth is a disservice to them. Aren’t we crazy? We offer a disservice and expect our salaries to be hiked at regular intervals.

For instance, we know, functional coverage alone won’t be sufficient; especially when we are the only team testing that product. Yet, we don’t say, “Hey, look, we would be in a problem if we continue the same way. While you have others focus on functionality, I shall try covering non functional aspects”. Instead we listen to what the developers say or do what we have been asked to do because we are in a profession of saving our jobs.

I don’t know why only the test team is given instructions from other teams as to what to do and how to do. I also don’t know why such testers are hired? One thing I know is why such testers are paid less.

I know that a paying job is very important. I am an independent consultant and I have been without a paid work for a couple of months with a home loan EMI as much as 30,000 INR. For some of us not being in a paid work doesn’t necessarily mean without work. Sometimes non paid work generates paid work. Look at this blog, it has generated enough paid jobs for me. However, I dont blog necessarily to get paid. I would have been exposed as a fool if I did so. I don't run Google Ads. I love writing and I like to record things for my own purpose, if you get benefited by it, I am very happy. I like you to help me learn a few things. There is lot of learning in the comments section on my blog than in some of the posts. I am providing myself an opportunity to learn from you or maybe unlearn, too.

One of my responses in LinkedIn Software Testing & Quality Assurance generated a paid work of $1000. Another response helped me get a work as a Chief Tester of Beta Testing Skype based Dating application Skyecandy for 8 months and I hired some of my students to beta test them. Those who come to my public workshops are also those who might have read or heard about what I said somewhere to get convince to pay for the workshop. I hope they are gaining value for money.

To my fellow Indian testers, I am not so different from you. Wait, I am. As a matter of fact I lack some skills that you have. So, you can survive without being an employee and yet get paid work like how I do. However, you might want to lay a foundation to be able to survive without being an employee of an organization, right from today. If you won’t run out of money and work, you’d speak different than what you are doing today.

Please, I am not asking you to be arrogant. I am suggesting you to think about speaking your heart when it requires to.  If you are fired for sharing the truth then staying there won’t help your career growth either. So, you are liberating yourselves from a place where your career would stagnate.

Please, I am not asking you to get yourself fired but I am suggesting that, stagnating your career isn’t what you should be doing to yourself.

Firing you isn’t as easy as you may think it is. Having been a Test Manager, I know it’s not easy to say, “You are fired”. If it was so easy, you and I should have been fired multiple times in our career for the mistakes we did. That’s the proof in the pudding.

So be truthful, to yourselves and the organization that is paying you. When you do so, you gain a satisfaction that is not matched by any other rewards. When you speak truth, the organization benefits and when they benefit, they want to benefit you, too.

Are you afraid? Afraid of what?

Skill takes away fear. Unskilled people can be easily bullied. Be skilled or be bullied, the choice is yours.

Test coverage : Life beyond functionality

At a class recently 

Scene 1:

"What have you all been doing for the last few years in this organization?"

Chorus: "We test for functionality of the software?"

"That's nice! Why do you think it is called /functionality/?"

Silence

"OK, what is a function?"

Silence

"No problem. Let's fix it. Where else have you heard the word /function/? Math? So we all might have studied f(x) = y and that could have been our introduction to working with functions. Later we moved on to parabolas and hyperbolas which had functions of different behavior and complexity. So what we are doing when we say /functional testing/ is, we provide inputs X to a function f(X) and monitor Y. We claim to know that f(X) should be Y and we also claim to know the range of Y. So, that forms our oracle to find bugs with functional testing. /Y/ doesn't necessarily need to be a numeric value in functional software testing".

Scene 2:

"So, what else do you test beyond functionality?"

• "Our bug reports get rejected if we report non functional bugs so we don't test for it", 
• "There is a team in US who is supposed to do it"
• "When we find a non functional bug and report it, we are asked why did we spend time deviating from the scope given to us"
• "We have enough test cases in functional testing that we don't have time for other kinds of testing"

"Are you doing Quality Assurance or Software Testing?"

"What?"

"Let me explain. In Software Testing, you provide quality related information to help the management take better informed decisions. I think in Quality Assurance, you claim to provide confidence to the management that you have checked and tested a lot of things (not just software) and things didn't change after your checks and hence its OK to use the word /assure/ with another word /quality/."

• "I think we do a mix of both"
• "Our designation is Software Tester but we are internally called QA"
• "I don't know. I am doing my job and earning my paycheck"
• "Yikes, this is confusing"
• "I thought Testing == QA" 

 Scene 3:

 "I appreciate the diversity. Tying it back to our previous topic, irrespective of what you do (Functional Testing or Functional QA, the information you provide to your management is so weak as compared to what you were supposed to be doing."

"How is that?"

"Test coverage is the extent to which we have modeled and tested the system -- Michael Bolton. You appear to have modeled the system for functionality and you could model your system in more ways within and beyond the scope of functionality to learn more about the product and to be of more value to your management. Assuming you are interested to do that. Here is a list of thing that you might want to focus on:

Product Elements Coverage

• Data
• Platforms
• Operations
• Time
• Structure
• Functions

Quality Criteria Coverage

• Capability
• Reliability
• Usability
• Scalability
• Performance
• Installability
• Compatibility
• Supportability
• Testability
• Maintainability
• Portability
• Localizability

Technique Coverage

• Scenario based
• Claims based
• User based
• Flow based

( refer to Rapid Software Testing slides for more )


"That looks like a lot of thing to do and I know these are important for quality. We don't have time for functionality and how can we think about all these things?"

That's a nice thing that you realize you don't have time even for functional testing to be done. How about asking the management to re design and re think about the time that is given to you and the value you can deliver?

Scene 4:


"I know for sure. They won't allow us to do all this"

"Interesting. Is that your assumption or a fact?"


"That's what is going to happen if we ask and we know that."

"Have you tried it?"


"No, but we know them very well."

"How much do you think they know about you and your skills?"

"They hardly know about me and my skills."

"So do you about them. If they assume you are not skilled to do other kinds of testing and also assume you heard them say /We are sure, they don't know to test beyond functionality/, how would you react to it?"

"I would show to them that I can"

"How about giving them a chance to show that they too can change?"

Silence

Two things:

• Give each of your colleague a chance, explain to them your problem.
• Give yourself a chance, focus on your test coverage and explore a life beyond functionality.

Experience Report : BWST 2

 Experience Report - Bangalore Workshop on Software Testing - 2

3rd April, 2010 @ Shilton Royal, Bangalore

Event Sponsor: Vipul Kocher, President ITB

Photos (and camera) credits: Rahul Mirakhur

 
Bangalore Workshop on Software Testing stepped into its 2nd year on April 3rd, 2010. Why wouldn't it?
This time, it was much more organized than BWST 1. Of course, we learn some lessons, if not all, when we do something.

The groundwork required announcing it on my blog, managing the registrations, speaker invites, cancellations, getting sponsorship, managing the budget, conference and hotel booking. As we had Selim Mia from Bangladesh as a participant, the work also involved helping Selim getting a Visa to India. Santhosh and Parimala were of good help for me in the ground work.

So, the D-day arrived. Some new faces and some old started dropping a couple of minutes earlier to the start time published to them. What? An Indian conference happening on time? That's crazy ain't it? So, till the time arrived some participants started to discuss about Left, Right, Neutral of Politics, Democracy, India and more.

We started off at 9 AM with a check in & self introduction from all participants and Parimala explaining the rules of the day and how to use K cards. She announced herself as Kaali Maata for the day who would facilitate the workshop.

Sharath Byregowda's talk on "How he cleared the trap that prevented him from attending BWST2"

What better way to start than to get a guy who was not likely to attend BWST2 because he had to be in office for someone's estimation being the biggest ever blunder committed. Sharath talked how he cleared the trap to be able to attend BWST2. While he was talking, lots of green cards started popping up. He explained how bugs (that were show stoppers) allowed the test team to buy some time while the development team were fixing them. 

Rahul Verma raised a question, "How can you go and look for show stoppers? Isn't it only when you find a bug you'd know if it is a show stopper?". That triggered some red, blue and green cards to show up. The discussion shifted from that to Severity, Priority and flowed into certifications. Sharath talked about the experience he had in proposing BBST course in his organization.


Ashok's talk on Metrics

So, Ashok T, CEO of Stag Software brought in his wide experience of dealing with metrics and questioned what metrics made sense. He talked about metrics used in various stages of software development and testing and shared his experiences of working with several clients on them. He talked about having helped his clients understand that collecting all these metrics is good but do we really know why we are doing it and what is our goal?


Discussions evolved around metrics and estimation. Not in anyone's experience there, an estimation had gone right. Rahul Mirakhur had to say, "If you get the estimate right, then its not right". There appeared to be a lot of interest from most people to try to get estimation right. I don't think anyone should try getting their estimation right because that is not the only thing that would be helpful to the clients they work for.

Selim Mia

We had a participant and speaker from Bangladesh, Selim Mia. Such passion is great to see and experience. He traveled by train from Bangladesh to Bangalore and back. The moment he stood up, everyone asked him a question unanimously : Please tell us how is testing done in Bangladesh? He had to answer that before he could proceed on his planned talk. I personally think there is lot of potential in Bangladesh but I also hope they avoid falling to traps that we have fallen into.

Selim had a combo for us : An experience report and sought answers to questions he had as a test manager. Based on what he said it occurred to me that the senior management there at Bangladesh were in for results. So, sometimes they gave enough freedom to testers to achieve results - which is good.

Discussions returned to estimation, metrics, scripted and exploratory testing. Vipul had been to Bangladesh, so he shared his experience of interacting with people there and termed it "pleasant". Two names that Indians now know from Bangladesh is "Sajjadul Hakim" and "Selim Mia". I think its time we know more.

Lunch

BWST 1 taught us a few lessons. We went out for lunch and in search of a hotel and spent about 2 hours in BWST 1 on it. This time we organized it in the same hotel and hence we saved a lot of time. We spent munching a good lunch for 50 minutes and then got back to action. Good lunch, I liked the soup & noodles!


Rahul Verma

I was invited to a conference in Germany and I couldn't make it. Instead of me, Rahul Verma did and I think it was a good thing to have happened for the conference. I believe Rahul Verma can deliver the blows that audience needs and that is exactly what he did. His presentation was an exploration into what crap, trap and good means to you versus to those whom you report to or to who reports to you. He delivered some punches to bloggers like me, which I welcome :)

He shared a few experience reports from his office and then led to asking us if we do have an opinion about what we say and how did we arrive at it? He left with a message saying, "Evaluate"

Those who probably did not know Rahul Verma were probably pleasantly shocked by his presentation and I argued over having an opinion and not having an opinion. I feel opinions are in making. Not expressing opinions could be dangerous in some situations while expressing it could be dangerous in a few others.


Vipul Kocher

Testers break rules. Good testers know when it is safe to break rules. So did Vipul. He cut the crap about  crap in the theme and focused on helping us learn the Noun and Verb technique of generating test ideas. The first thing that strikes is his acknowledgment to Elizabeth Hendrickson. It is a strong message to the testing community to owe credits to someone who has helped an idea to be helpful to a larger mass of testing community. Although "Noun and Verb" technique was unheard to many, they did enjoy learning it from someone who had implemented it in the past and shall continue to work on it. I usually don't run out of test ideas and I think through his presentation, the likeliness of me running out of test ideas has further reduced.


Ashok had questions to ask about Noun and Verb technique and I found them interesting. I too have plenty of questions about it but I am going to be working on it for a while before I try to find out answers. There were a few junior level testers who were at BWST this time such as Sai Divya & Shwetha Ghorpade who acknowledged that it will be interesting to implement the technique at their work.

Meeta Prakash


Meeta hit the bell. She took the word crap from the theme and thought about one of the crappiest thing at work - meeting. Her session didnt need any facilitation. She kept polling the audience and questioning things about meeting. It was interesting to know every person except Allmas (lucky Indian) thought there was a lot of time being wasted in meeting. Sometimes people not needed are pulled into a meeting or other times people who are most needed in the meeting are left out because they speak truth. I got reminded of a meeting money burn meter that I saw sometime back which shows how many dollars are burnt in the meeting.

The discussion was interesting. I was reminded of one my ex-manager whose meeting only gets over when his wife calls him. Those who reported to him felt his wife was a savior and a viking.People brought in their experiences of craps and traps of meeting. I once worked for a CMM Level 3 company who was trying hard to achieve CMM Level 5 status. An SEPG team in there ( don't know SEPG : Software Engineering Process Group ) wasted a lot of our testing time. SEPG team ensures that a spelling mistake bug is as expensive as a database corruption by involving the whole team to do a root cause analysis of how the spelling mistake bug went unnoticed. Vasu brought in his experience of how he learned to handle customers diligently  by observing his manager handle it in a meeting. Allmas is way too lucky. She appears to have a team that handles meeting so well. Don't envy her, she is going to be as unlucky as you when she moves out of the organization.

Sukanta Bhatt

Oh this man! The stories he shared on testing medical devices got people doing two things - laughing while thinking. People didn't seem to want him stop. He shared experiences that led to discover new things and realize the value of interacting with customers and being at the customers place watching them how they use the product we develop and test. Was a cool way to end BWST 2 presentations.

Jantha (participants) got curious about medical applications and devices testing space and started to pound him with questions and asking more experience reports on medical devices. Well, that happened over a beer.

Checkout

So, when the bell rang at 5:30 PM, we officially concluded BWST 2. Before we did that, we had a checkout in which each person given less than a minute were asked to talk about one take-away from the whole day. Rahul Verma and Sharath believe that it was cruel of me to ask for "one" takeaway while there were lots. Not that others had just one but these people voiced their opinions about it. The flip side is if someone who is new to this concept of BWST and had been all silent, is easy for them to talk about one take way unlike others who are practiced to speaking a lot.

Ashok & Vipul

The audience weren't exhausted. So, they ignored my call for heading to a pub nearby and asked Ashok and Vipul to talk about experience of running a testing services organization. Questions were posed about China, US, Europe and ANZ regions. The thrust was how do we as Indian testers do better.

Photoshoot

So, we all got shot at the end by one of the hotel staff :)


Beer in Pub

We decided to catch up in Enigma, the Pub @ Koramangala and testers rocked the place. A couple of pitchers and soft drink went in. Girls who had been to BWST 2 also accompanied us to a pub as they knew they are hanging out with some of the gentlemen of the industry. That's it.


Note of thanks

To all participants : Santhosh Tuppad, Sharath Byregowda, Selim Mia, Ashok T, Rahul Verma, Vipul Kocher, Dr.Meeta Prakash, Sukantha Bhat, Swetha Ghorpade, Senthilnathan, Allmas Mullah, Eshwar Kumar, Lakshmi Narasimha, Gokul, Dhanasekar S, Rayanagouda Patil, Vasu Swaminathan, Rahul Mirakhur, Mandeep Singh, Ajay Balamurugadas, Ravisuriya, Yeshwanth Rao, Sai Divya, Chandrasekha, Parimala

To our dear event sponsor: Vipul Kocher
To my co-organizer, Santhosh Tuppad
To the facilitator, Parimala
To you, for reading this.


I shall see at least some of you at BWST 3!

Follow your own style

 This post is India specific.

I have a reputation and credibility in this industry to an extent that some people inside and outside of the country have at least heard my name, if not for my skills. I have a brand of my own. I have a style of my own. I call myself with cool names. I sound like a geek. I speak like an American. I pretend to be good at something. I brag. I blog. I podcast. I publish videos of my testing. I oppose certain things. I do so many other things that increases the visibility about me or my work to the world.

You should know why I do all these:

1. To help myself be a better tester.
2. To help the testing community in whatever way I can. 
3. To earn a living.

The danger

Some testers whom I coach / inspire appear to have mistaken some of the things I do as THE way to go about building their reputation and credibility. Ever since I am discovering that people are falling to a trap of trying to ape me, I feel bad of having a reputation and credibility.



Not that I didnt try doing things the way people who inspired me were doing. I tried aping almost everything they did. However, I did something to go beyond aping what they appeared to be doing.

It is a known fact that my life as a tester took turns when I discovered James Bach and then Michael Bolton. For me, these people were Gods of testing. You should visit my room, I have photos of James, Michael & Jerry enlarged and framed on the wall. That is just a minutest example of how much they mean to me. 


While they didn't make a parrot out of me who repeats after them, there was a little parrot sitting in me, trying to ape the things they do. It is human nature, I guess, to try ape your hero. Be it Rajinikanth or Upendra or Michael Bolton. I felt good about myself whenever I tried aping them. Why do we ape people? To feel good and proud at least for a short while.

Lesson 1:

Mimicry is one of my hobbies. A couple of years back, I was trying to practice the way James Bach & Michael Bolton speak. I did that so much that, I am now caught up in an accent that people think is half American and half Indian. Some people think I am faking my accent. I don't know, it has so happened that whenever I speak English, I start sounding like an American. So, be careful, your nature could be altered if you are trying to ape someone and it sounds or appears plastic to many if your nature is altered.

When you are trying to be like someone as bad as me, you will become a mutation of a mutation. That's not good for you.

Lesson 2:


Just after being done with 2 exercises that James put me on, I claimed to be a Rapid Tester on my blog. Some of my readers to whom all this was the western thing, even appeared to believe it. James had something different to say, "Are you a Rapid tester?" with a big laughter. I think it was the best joke he had heard for that year. He knew I was not yet a Rapid Tester although I thought with just little appreciation from him, I had almost become a Rapid Tester. For someone who was bored of calling himself as a "Test Engineer", Rapid Tester sounded cool and refreshing. Thankfully, I can make the claim today and live up to half their expectations.

So, when you make a claim about yourself or your testing skill, be careful to check and test it out by asking others, especially those who would find bugs in it.

Plus, when your hero appreciates you, don't fly for long and go out of reach. Respond to calls from gravity.

Lesson 3

Inspired by the way Jerry Weinberg writes, I tried aping the style. The easiest thing to ape in anyone's writing is a comma or a full stop. I was successful and here is one of my old post for your evaluation. There are 77 commas in that post. I was a comma addict.

I pestered Michael Bolton more than anyone else to help me better my writing skills. So he used to say, "Pradeep, don't, write, like, this" and I used to cry like a small baby. Michael used to offer me a philosophical explanation to why I cry. Miss those times :)

You could be thinking that you are aping the way your hero does his work but without knowing you are committing a blunder of a lifetime.

Lesson 4:


I used to assume that James was aggressive when he spoke against test cases and tried aping the aggression in similar contexts. I thought if I were to be respected as an exploratory tester, I had to oppose test cases. So, during my first stint as a consultant, I was roaming around the streets of Bangalore seeking business opportunities and knocked several company doors posing to be an expert tester. None of them were bothered about what I said.

One company invited me inside and started interviewing me. Turns out that they had an urgent need of a tester to replace the one who had quit. I stopped the interview process and explained to them that I was an independent consultant and what it means. A test manager there giggled for a while and said, "Even to learn our product it would take you three months and you are suggesting you can work on a  hourly basis / daily basis with us". So, I challenged them that I would find bugs in one hour in their product that is outside of what their test team might have found. So, they gave me a machine, their product loaded on to it and an one hour to produce a report. I fished out 22 bugs in that hour + a spelling mistake free report. I don't know, it wasn't shocking to me about the outcome but they were definitely surprised and excited to see so many bugs in one hour. I was called in to the Vice President and he told me, "You seem to have great test ideas. Can you write us help all these ideas as test cases? We will pay you 1.5 lakhs a month" and I walked away from their office silently but with aggression at heart saying "What? Pradeep & writing test cases? You know what, he is an exploratory tester, a rapid tester, such a unique thing for India and they are insulting him".

Years later, when I think about it, I feel, I lost a potential business opportunity and most importantly, I didn't help someone who needed it. They might have just needed my test ideas and they might have referred to it as "test cases". On just working for an hour, if they wanted to pay me that much, maybe when I worked for a month, they'd allow me to coach their testers and help create some good testers for that organization. I lost all of it.

I still oppose the idea of scripted testing. I teach exploratory testing. I am a Rapid Tester. However, today, if someone wants me to help them solve their testing problems - I forget all my ego and aggression and try to be in best service of the client. My work shall do most of the speaking. I shall help my clients understand why test cases would make their testers bad instead of walking away saying, "Ah! Pradeep & writing test cases?"

Having a guru is very important but it is equally important that you don't ape your guru forever.

I used to dream "When will I become James Bach?", "When will I become like Michael Bolton?" to which they taught me to be myself. That's their beauty!

 My LinkedIn profile reads, "Pradeep Soundararajan, a tester with experience of 7 million 4 hundred mistakes in testing" and it would mean nothing if I cant test as good as you who might not have a cool fancy title for yourself. So, don't get carried away with things I do.

You are what your skills are.

Bangalore Workshop on Software Testing - 2 on 3rd April

If you have been my blog reader for a while, you are likely to be cognizant about Bangalore Workshop on Software Testing or BWST. If you don't know about it, no problem, the post and details are still there. So, BWST – 1 was attended by testers from Bangalore, Pune, and Mumbai. Oh, you should read the experience report and you’d realize how much fun we had or how much fun you missed. 

So here comes the announcement of BWST 2. Santhosh Tuppad and I are organizers of this event and Parimala would be facilitating the workshop. Vipul Kocher, President, Indian Testing Board has volunteered to be a venue sponsor for it.

“Cutting (c)trap and getting good things done”

Many experienced testers of India that I have come across, claim to have made at least one proposal of doing better testing to their management. Most of them also claim that the management doesn’t help to implement the proposed ideas. At times lot of gyaan is also given to them. Some of those testers, cut traps and get good things implemented. We thought it would be valuable to listen to such stories and real life experiences of how testers cut the traps that were trying to prevent them from doing better testing. We also love to hear failures. So, if you failed miserably or maybe you just failed and want to tell us that story, we’d be glad to hear that.

You have a story like that? Send us a one page abstract of your story to banwost@gmail.com with subject "Sharing my story at BWST2" and we will let you know if it makes to one of the six presentations of BWST – 2. If it doesn't, we shall invite you to be a part of BWST2. 

So, if you are not speaking at BWST-2, you still can participate in it.

This is an invitation only kind of workshop. However, you don’t need to upload your jazz dance video to Youtube, to get invited to this. It’s simple, you write an e-mail to banwost@gmail.com with subject "Participant at BWST2" providing details of you, your work and explaining why you should be attending this workshop.  As the cap for participants of this workshop is 30, we would urge you to hurry up. Details of venue and other help you might need will be communicated over e-mail to those registered participants.

As such a workshop is not happening elsewhere in India, we want to keep this open to people all over from India and for people like Mike Kelly, who might be planning to come down :) . We hope that such workshops might jump start in other places from India, too. 

Well, I don't quite understand why testers from other cities allow only Bangalore testers to have every bit of fun in testing? Whatever!

Cost

You don’t need to pay for anything unless you volunteer to sponsor a coffee for all. We just ask you to take care of your expenses such as your travel, stay (if you are coming from other places), and food.

If you are in Bangalore and willing to host a tester who comes from outside Bangalore, send an e-mail to me. Parimala has agreed to host one female tester who might be interested in this workshop and is coming from elsewhere in India. I am hosting one. Oh, by the way, we don't have a Taj Mahal view and gold rim wash basins at home.

Update : March 22: All seats have been filled. If you were planning to request for an invite, you are too late. I am sorry.