BPO / Support / Call Center / Homemaker to Software Testing

Over the last few years, I have received at least about 40 emails and a couple of phone calls from people working in tech support, BPO, call center, homemakers asking for my advice to get a job in software testing or to make a career in it. I am tired responding to the same set of queries from different people. Now, that doesn't mean I wouldn't be interested to talk to people. I just hope they read this and have a different question or a situation they'd like me to address. 


However, this post is not just for those who want to change their career from BPO or Tech support to software testing but also to those who are hiring managers, interviewing testers and to all those who are aware that they are a part of the future of software testing.

1: Chasing dream versus chasing a day job

A friend of mine gave my number to his friend who works in a Technical Support job at a reputed organization and wants to move into software testing. So he called me to seek my help. I asked him, "Why software testing and not something else?" and he didn't have an answer. That is perfectly fine. He then said he wanted a day job and found software testing as an easy possibility.

I started to probe his dream of what he wanted to be before he landed up in Tech Support. His dream was to be something else. I then explained that moving to software testing might not help him feel any better than starting to chase the dream. He agreed and is now chasing his dream of photography.

2: Turning lemon to lemonade than faking it as orange

Some people have asked me if it would help to fake their experience of a tester of the product they were providing technical support just to get interview calls. I have helped them understand that there is a lot of value in presenting the truth than trying to show it as something else, get caught someday and be blacklisted by NASSCOM and a whole lot of companies spoiling future growth chances.

Having worked in several product organizations, I realize the importance of interacting and collaborating with support teams. If I were to hire a few testers for my team, I would definitely be interested to talk to a support team member. We did that in one of the product organizations I worked. I have talked to hiring managers of large and small product organizations who have done that. I think most of them are internal hiring and some rare cases of external hiring.


To all those who are considering to hire testers, stop doing what you have been doing all this while - hiring those who have been in testing only. Where were you before you started to do testing?


3: Learning software testing in 10 days OR Crash course about how to crash


With many folks wanting to learn software testing, lots of people are making money out of it. For all those in the world of software testing, do you know how many institutes are there per square inch of Ameerpet in Hyderabad who can teach testing in 5 hours if you'd like so and have enough cash? 


Not just Ameerpet, there are lots of chota Ameerpets that I have come across. These kind of training centers are a huge contribution factor for spoiling young minds in India. If God makes me rich, I shall wipe out each one of them.  These training centers run weekend batches for Tech Support folks and spoil their ability to learn testing. 


So, when folks who work in Tech Support and have attended such draining programs (yes, that was intentional) get in touch with me for seeking advice on job search, I have helped them to pick up two books: Testing Computer Software & Lessons Learned in Software Testing. For the most recent ones, I have also suggested Perfect Software & Other Illusions about Testing.


I also have suggested them to hook up with a tester every weekend and try some hands on testing or participate in open source projects for a while. For just one I have helped by doing a paired exploratory testing. One of my student in the Hands on Software Testing Training - India's first true hands on only testing training I delivered for Edista in 2008 & 2009 was in Support and he demonstrated his testing skills to his employer to be moved to testing.


4: Test Report instead of Resume / Profile


When my father started his first job after his Diploma in Electrical Engineering, he applied to the job with a CV / Resume. So, using a CV / Resume is that old an approach which hasn't changed much, except that he used a typewriter and we use MS Word and a Laserjet Printer. Lets try to change.


In the last 3 months, I have 4 emails from hiring managers in Bangalore, Chennai and a country outside India seeking help to hire skilled testers. One of the things I have suggested to them is to not ask people to send their resume unless it is accompanied with a test report. For hiring managers, it would be easy to see what kind of tester they want by looking at the test report. If the person says, "I am skilled at automating checks", so be it, demonstrate it and attach the scripts along with the resume. Needless to say without violating any Non Disclosure Agreement. Open Source software testing suits best. The interviews are actually discussion around the test report rather than "What is the difference between this and that?"


I am writing a whole big book on software testing interviews. A publisher just rejected the book but that's OK.


BTW, don't send me your resume and ask me to refer to those hiring managers.


5: Why some developer guys from India suck big time?


Nothing about their programming skills. I have done career counselling almost all through my career for others and myself. Hey, its a skill with which we are born, at least that's how we behave when someone approaches us for advice :)


So, having worked with some testing institutes, I volunteered to take up any work I could that would let me to speak with testers and potential testers for my own learning purpose. My blog, as you know, has brought me a lot of people with varied kinds of queries. So, I have some experience dealing with those developer guys who walk in months after their marriage, looking for a job for their wife.


These great developer guys come and ask, "I want my wife to take up a software testing job, do you offer job guarantee courses?". So, to the question, "Why software testing?", they'd without any bit of shame, answer, "I want her to earn and come home on time so that she takes care of office work and home work in a balanced way". 


One guy tried interviewing me to see if I know enough testing to teach his wife and help her learn testing. Not just me, one of my student, Arindam, was inspired to coach testers and works for an institute in Bangalore part time. That institute runs a special batch for home makers. Arindam shared his experience with me about the batch. He too said what I had already experienced. My advice to all housewife / homemakers whoever you want to call yourselves as is to read Parimala Shankaraiah's blog & Meeta's blog. Hey wait, there are quite a few others in India. Read their blogs to understand how passionate they are, how difficult it actually is to be good in testing and how they manage home and office work.


6: A break / sabbatical in career is just fine


Some women testers who take a break or sabbatical, try getting back to the industry but the industry treats them bad. Most hiring managers are blind in noticing people with break. They think they would be at loss of value if they hire them. 


I think stopping someone who is passionate in testing but had no other option than to take a sabbatical or break not getting a job is a big hindrance to the entire software testing industry. If I were Parimala Shankaraiah's employer and she needed a sabbatical, I would welcome her anytime she wants to come back. Not hiring her is like fooling myself and my company HR policies.


7. The actual meaning of "Our company is an equal opportunity employer"


There is a VERY BIG company who has an office even close to my home who has this statement, "We are an equal opportunity employer" in their website but didnt allow me to even apply to an opening just because I didn't have an ISEB/ISTQB certification. Let me tell this to you: I felt blessed by God to be not eligible to even apply to such companies because such company environments wouldn't have made my career strong.


The company which actually is an equal opportunity provider is one that selects its employees based on skills and not if they purchased a certificate. So, if you dont get jobs in such places, feel blessed, you really are. Keep demonstrating your skills and jobs will come to you. 


Santhosh Tuppad, my student with just one year of testing experience (and tons of experience in finding and reporting bugs) got an offer to be a Test Lead for one of the top companies in Asia. Although he couldn't take it up then but I just wonder if he had to be a Test Lead at some of those fake equal opportunity providers, how many white hair he should have had.


So, here are some points to ponder:

• If you choose to be misguided by what others say then you deserve it.
• If you have some other passion and want to be a software tester because you think its an easy job, you are spoiling an opportunity to help your children see you as their inspiration to pursue what they want to be.
• If you are OK to live others dream, don't question, just follow. Never crib / complain in life.
• If you want to test out testing, do so with open source projects and by collaborating with some good testers around you.
• No job is easy but all jobs can be done in an easy way.
• Fakers will get caught.
• Build your testing skills and demonstrate them.
• Attract employers don't always get attracted.
• Build your own brand. Get organizations proud about hiring you and not the other way.
• Many services companies count heads - not brains. Target tech start ups.
• If nothing works out and still you dream to be a tester, start your own testing services.
• Its OK to fail.
• Its important you succeed chasing your dream irrespective of whether your chase was successful or not.
• Chasing your dream is the only way you can know if you can really be successful

As and when I encounter more points or more different questions, I shall update this post.

What is our competition on?

There is a trend that is picking up in the software testing industry. To be more precise, I am talking about a trend of competitions, prizes and rewards. This is good. I love the idea of being able to compete globally and with testers whom I may not have known otherwise.

When someone wins a testing challenge and the report is published to those who participated, it influences others to ape some of the good practices and end up creating their own styles out of it. The flip side, what the winner does becomes best practice for wannabe winners of the next competition. For instance, having been practicing video recording as a part of my bug reporting style, I posted videos of bugs in Utest bug battle last year. When I coach testers, I also help them understand what kind of bugs need video recording and help them practice it. Santhosh Tuppad who is a regular bug battle winner in Utest told me that many testers have started to upload videos instead of screenshots and he published an experience report where he mentioned that point.

At this point of my post, I'd like to appreciate all companies putting up competitions that is helping to bring out new, fresh and different kind of talent to the public view. I like to support you in as many ways I can. I have been a participant, creator, winner and loser of such competitions. Its all fine.


However, I am starting to have some concerns about the competitions that are coming up which demands voting by public to decide who wins. Now, I need to clarify something. I am not talking against those companies who are doing it. As a matter of fact, I am not talking against "anything". The company wants a way to get more people to know about them and such voting based competitions help in doing that. If I start an organization, I'd like to do things that helps in getting a lot more people to know about the services my organization offers. 

The problem with the voting to decide a winner, could be hurting, to those who have put in lot of efforts but couldn't gather enough votes. For instance, Eurostar conferences organized a Videostar competition. By looking at the marketing flyer of the competition which said something like, "Put on your Holywood director hat" and about creativity, I assumed the video with the Holywood movie type creativity will probably get me to be the Videostar and did the Joker act. Anne Marie did a video that I personally liked. Nothing less of all that was from Rob Lambert who had a different way of putting things that he wanted to talk. Maybe all that was driven by seeing how creative were Eurostar folks who put up this video. Finally, the video that won, by that I mean, the one that got the most number of votes, was not so exciting as others in the list. We are independent consultants who don't have a mailer list to whom we can send and help generate a lot of votes for ourselves. Being an employee of a large company and gathering votes is much easier, especially if the Head of Testing is the one asking for votes. I guess that's what happened. Now, I am not questioning about anyone's ability but I am talking about the system.

I could have still won. I could have got a 99% lead over all others if I wished to. The Videostar page recorded a vote from a browser-computer and registers it or probably sets a cookie as well so that I cant vote twice. However, I could clear the cookies, refresh the page and vote for me again. How long would it take to automate this and leave it running overnight to wake up in the morning to declare myself as a winner?

I didn't win the Videostar. That is a testimonial that I didn't try winning with the "hacked way" I discovered. Oh, if you think there would have been an assessment of votes coming in from the same IP, I could have gone a step ahead and used the cloud to make it up or use tools that helps me mask my IP and hence not reveal where the votes came in from.

In that case, should winning be decided by a panel of judges who may not understand my skills? For instance if I take up the ISTQB Foundation Level exam, I will fail. I did fail in a mock test that I took online. Does that mean, I don't know how to test or I don't know the foundation of software testing? 

A competition has a set of rules. I am just asking if the rules can be made in such a way that the skill factor plays a vital role in winning and not the votes or my ability to memorize answers and vomit it out on an exam.

Let me repeat this: I am fine with companies organizing competitions to increase their visibility but I want to know if there can be a better way to do it than the voting system. I am dreaming of testing competitions where the winner is judged based on the skill demonstrated. A report is published by the panel as to why the winning entry amongst others were eligible for the top prize. Every step we put must help us move forward. Movement is important but there is a vector in it. What direction are we moving in and by what magnitude?

Bug battles are one kind of a competition that I like. There are more kinds of skills that companies can try to focus on. When I organized a testing challenge for Test Republic, I did a Bug Advocacy Challenge. I think there needs to Bug Investigation Challenges, Rapid Test Planning Challenges, Test of agility challenges, Test Management Challenges, Interviewing Tester Challenges, Collaborating with Developers Challenge, Understanding Requirements Challenge that can help in bringing out winners with skills of different kinds. 

So, there was a competition announced from Eurostar on blogging. I was about to pounce on it because I wanted to go to Eurostar and I have been one of the earliest Eurostar blogger. I skimmed through to see if there was anything related to voting and there it was. I decided to not enter the competition. 

I would be highly stupid if I was trying to write this post to create a negative impression of Eurostar or any other organization. That is not my intention. I'd like to say that Eurostar is a great conference I want to go but not because I got a lot of votes than someone else. I want to go if my skills get me there. I understand why Eurostar or companies that are running a voting based competition might be doing these competitions but I'd like them to think if there can be a better way to do things. I have respect for organizations like Utest and Eurostar because they are trying to do some work that is helping people change things the way they do. That is the reason I want them to be able to cause a much higher and better influence on the community, to take it forward. 

A tip to the winner

If you, a tester, happen to win any testing competition, here is something that I hope you think about from what I say to myself from my experience of winning several testing competitions; I won because the mightiest chose not to compete. This thought helps you a lot when you work with people. They shall embrace you not see you as a person they should stand away or just merely stare at.

Competitions could remain but what is our competition on? 

• Choice A.  Number of votes
• Choice B. the breadth and depth of skills? 

To add a little humor to this serious post; what is your vote for? A or B?

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!