My First Lesson with James Bach, the testing legend

I never knew legends were so accessible. I am very thankful to James Bach, who wants to spread his knowledge to the world.

I had my first lesson from James on "Friday, January 29, 2010 12:44am to 3:37 am".
It felt so great to have two words with James Bach that the first time I got a response as hi from him, I took the screenshot of skype, even though I knew skype archives your chat.

I want to forward the learnings that I got from him to other proud testers:

Verse 1: 
James asked me to describe a test.

And I was very bad at it. I actually defined the test.
My Definition: A test is to explore a product to find out more about it, specially the issues in it. These issues are problems that might affect the user's experience adversely.
(I personally thought I did great there. But alas, what I did was defining the test)

After knowing that what I did was defining the test, I made one more attempt at describing the test.
And that was a little close to describing the test, but it was mentioning instructions to test.
And then James gave me the pearl of wisdom. Mentioned below "as is" in words of the legend:

[1/29/2010 2:04:20 AM] James Bach: If you were actually doing the test
[1/29/2010 2:04:30 AM] James Bach: and I were a blind man standing next to you
[1/29/2010 2:04:40 AM] James Bach: and you were telling me what you were doing, thinking and seeing
[1/29/2010 2:04:46 AM] James Bach: that's what I want

And I learnt now that when we describe a test. It is something like:
"I want to verify that... So what I do is... and then I see this... therefore I think that's working..."


Verse 2:
Do testers make assumptions?
It is a nice way of legends to teach, they do not give you the answer. They guide you to the answer and let you find it. Thanks James.
I started with the bookish answer that I will not assume but I will ask for the requirements or search for them.
And James guided me to the answer...

[1/29/2010 2:22:14 AM] Santosh Shukla: Testers do make assumptions sometimes as a last resort, but they also communicate/state it
[1/29/2010 2:22:23 AM] James Bach: good answer
[1/29/2010 2:22:30 AM] Santosh Shukla: thanks
[1/29/2010 2:22:30 AM] James Bach: of course we make assumptions
[1/29/2010 2:22:42 AM] James Bach: what we need to do is be aware of the critical assumptions
[1/29/2010 2:22:47 AM] James Bach: and trying to declare those


Verse 3:
Complete list of Expectations from the test.

Can you ever list the complete expectations from the test?  NO. 
What we always mention or list is the partial list of expectations. There are many expectations that go unwritten but those are still our expectations.

(My interpretations:)
Verse 3.1 Never promise for something you can not deliver.
Verse 3.2 Can we as a tester deliver complete test coverage? NO
Verse 3.3 Can a test team certify that the product is 100% bug free? NO

"What we CAN do is state clearly what we can do and to uncover the maximum amount of unpredictability from the product that we can." - yours truly

Verse 4:
"Also...Not..."  heuristic.

When I thought that I was done mentioning the expectation from my test, James pointed me to the Also...Not... heuristic. Using this heuristic one can add many more expectations to the already stated expectation by adding Also...Not... heuristic.


One important thing that I learnt while interacting with James was the importance of communication in the tester's life.
(If you being a tester think you can communicate well, explain "clickable" and reply to this post.)

-Sharing is the essence of learning.-
Thanks to James for allowing me to blog about the chat.

My chat with James Bach is my prized possession and I am open to sharing it with another proud testers. Thanks to James for allowing me to blog about our chat.

Bite off more than you can chew

Since I started blogging barely 10 days back, something (good or bad is undecided yet) is happening with me. I have started reading more and more blogs, sometimes to see what others are writing about, sometimes to see how others are writing, sometimes inadvertently comparing my blog to others.

However in this process, I am reading more and more testing blogs. I never knew writing forces you to read. I had started writing because I thought I had some thoughts which arise out of my reading and thinking. And now my writing is forcing me to read more. What a nice relation!!!

Now that I am reading, I am reading a lot. It's good to know there's a lot to learn. I am reading more than I can later ponder on. Should I read less? Digest what I have read and then go on.

I think otherwise, I will read and read more. I know if it is worth pondering about, one of the best supercomputers (under-utilized to a great extent), my brain, would force me to think more about it.

I am awed by the ocean of knowledge lying on the web to be absorbed. And I am learning swimming by jumping into this mighty ocean with my life-jacket.

Do share your opinion on Biting off more than chewing.

A Tool is a tool is a tool

With this post, I do not wish to demean the importance of tools in human's lives, or software development or in the subject dear to our heart, Software Testing.

This post is to let all those people/companies looking for that three lettered acronym tool Experts or the experts in the so-called best load testing solution in the world; know about the importance of people with their soft skills and aptitude  (communication, attitude, testers' mindset, challenge loving) OVER skimming through the tool's vocabulary and now withered out FAQs mentioned over ******interview.com

While interviewing a candidate for testing (automation) position, I am not interested in someone who calls her/him as a tool expert but someone who is an automation expert. Because an automation expert is good at the basics of automation, who would be able to replicate the success that one had with one tool with any other tool with higher percentage of predictability.

In the interviews, instead of asking the theory questions for the tool, I would get the candidate work on creating an automated test. With the test it is much easier to judge the automation acumen of the candidate.

So, for all the testers out there, do not learn a tool first. Learn the basics of automation. And then we would be able to appreciate the beauty of the tool better.

My journey with testing so far...

A journey of thousand miles starts with a single step. - Confucius

This is my first step.

My journey with testing so far:

I, Santosh Shukla started my testing career by chance and not by choice. (I was recruited on-campus by my dream company Infosys then and freshers are not asked for their choice at India's most respected company. I did not have any preference either is another thing :o)
So, I was assigned to work with the testing division of Infy - IVS (Independent Validation Solutions).

I started testing professionally which I realized, I had been doing till then sub-consciously.
I have been an inquisitive child, I still am. I question things which do not seem right to me.
I think these are the bare essentials of being a tester.

Worked with a so-called Agile team in my first project. Only the development team was agile there, testing team wasn't, which essentially makes the whole team non-agile. Experienced three complete test life cycles and learnt basics of testing. Then worked on a second project of independent testers where my team comprised of all developers who had to act as testers and I was the only skilled tester. (Most of those developers have now switched to testing.)
Realized that I love testing, and I am a good tester at this point of time and became sure this is what I wanted to do.
Learnt testing with some tools that the world values a lot. I do not.  
A tool is a tool is a tool.
A human being, and his unquantifiable skills are much much above the tools.


I have done certifications:
Certified Software Test Engineer
Mercury Certified LoadRunner Expert

Are certifications valuable? Yes and No (More on this later...)

After a year and a half stint at Infosys, after knowing the service industry, after knowing the importance of working under pressure, meeting deadlines, valuing processes, and Predictability, after learning Customer is King and Always Right I accepted the offer from the world's largest enterprise software company, ORACLE .

At Oracle, I learned how great products are made and how the quality is embedded into the entire process. Learnt to work on a self-managed team and being the single Tester to one of the product that the entire Oracle Applications developers fraternity used extensively. It is altogether a different feeling to be a part of product company. Learnt that developer is your friend who cares about the product equally as you do and is more than happy to help you find the ways to improve his/her code.
Repeat with me... "Developer is a Friend."

After working with these two great and big organizations, I interviewed for another great and young organization, InsideView. I chose this organization because of the existing team of Stars, because of leadership team that I interviewed with. I knew I was being heard, and I could relate to the company, both of us are trying to establish ourselves as leaders in what we do. I work in a true Agile team, where developers and testers are not two teams but are a single Engineering Team. Where Collaboration is a way of life. Where testing team does not (only) find bugs but understands the UserStories along with developers and are equal contributors in moving the development life-cycle from requirements to shippable phase with the best quality.

I am learning testing everyday...
With this blog I will share my learning and encourage discussions/comments for a mutual growth.