Secrets of a Buccaneer-Scholar: Must read not just for Testers

I’ve been trying to write about this latest book that I read for almost 4 days now and finally I got time @ 1.50 am today.

Acknowledgement
Thanks to Pradeep, for writing about this book. I know nothing of James would go unnoticed by him. So by visiting Pradeeps’ posts, I get to read many good ones besides his and this was the best of all so far.

About the Book:
I started reading this book after a little technical tussle in downloading the free copy on a Saturday evening and my excitement had already started. I have to admit that the book was so compelling that I had to make some time during by office hours (thought I was running pretty busy) even if that means I had to stay little late in office.

How did I relate to the Buccaneer-Scholar
I was just going thro the first few pages of the book and a specific lecture I attended during my masters degree flashed right in front of my eyes.

My 4th semester period, a week day, around 5.30 pm.
The then Head of the Department of Computer Applications was in the class, not explaining anything around software but trying to understand why there was a good number of students (~30%) bunking the class consistently (he was actually talking about myself and some of my friends). As he was addressing, I couldn’t wait anymore and told him “the time that we spend in the class room (we were spending almost 7 hours a day attending different lectures) were of no use (no use == we werent hearing/going thru/reading about anything other than the contents in the text books prescribed) and I could learn more by just spending couple of hours in the library and with technical magazines”

After that day for all obvious reasons, I had to face consequences. Because I had questioned the very reason of the teaching that he (HoD) thought was happening and of course the rest of the faculty members thought process about teaching.

This instance actually put me and some of my friends in a spot. We had to prove that we were indeed better of without those lectures. To prove a point we had to work harder hence followed more hours in library, more hours reading about lot of stuff which ended up as a paper on VoIP by myself and one of my friends during our 5th semester. This lead us to become winners in one of the technical symposiums (on September 24th 2002) in paper presentation category. That was first of its kind in my college.

Back to present; I wish I had such a book to read when I was a student. I wouldn’t say I would have quit the college . But it would have certainly made my outlook about learning far better.

I recommended this book to some of the testers that I work with; but that’s before I read the book full. Now that I have read the book completely, I wish every student gets a chance to read this book and make the correct sense of it.

Thanks very much James - for penning down your experiences and few others and

(again) Thanks Pradeep – for your post on the book (that’s how I came to know about it)

The Future of Software Testing!!!@@@##!!!

I saw a poll in on of the internal communities in my organization titled “What is the future of software testing”
In my opinion, It would be of a very brave attempt if someone tries to decipher this “the future of software testing”. The reason why I say this is because in my opinion, we are far to understand “Software Testing”. As a tester community we are still arguing, discussing and trying to understand “What software Testing is all about” and “how are we supposed to go about doing it” and so on.

Because of these obvious reasons (that I’m still trying to understand software testing) it seemed an act of extreme bravery to see some part of tester community trying to judge the future of software testing. Driven by curiosity I read further i.e. the options that were given to testers (I remembered the testing certifications while reading them).

i) Depends on Programming trends
ii) Will more rely on automation testing
iii) Will get harder, more expensive and therefore less efficient
iv) Will always have a future. As long as developers will write code there will be bugs

When I read the first option, I felt that I understood (perhaps felt like understood) that the author is trying to perhaps check the awareness degree or may be with the following options he would try to improve. With this context in mind, I had a choice in my mind, what could be the best answer for this question.

When I went on and completed the list, I was more than disappointed to find that my opinion wasn’t there as an option at all. What made me thwarted further were the rest of the options and some of the responses. But the consolation was the first half of the option iv that there will always have a future

What follows further in the post is my attempt to make awareness about testing.

Depends on Programming trends
Testing was never dependant on programming trends and it never will. Programming trends can have some influence on some of the process that the testers follow to test a software and this is extremely context driven. I wouldn’t say the both are immune of each other. As much information or details as possible on the programming methodologies or trends followed while developing a software will certainly help in figuring out a better testing solution but as a tester I can test a software without any of that information as well.

Will more rely on Automation Testing
“Automation testing” is in my opinion, larger-than-life myth in the software testing. There is a perception that everything in testing can be automated. I wonder what they mean by testing here. Well, this is vast subject hence back to the subject, Automation testing can perhaps cover some stupid-box (Hureeey! I found a new word in the series of black box, white box and so on) testing like activity .

Will get harder, more expensive and therefore less efficient
Well Yes, testing is difficult; from the context of the intelligence that it calls for. No quality-product costs less hence testing can be expensive. Because testing is difficult (contextually) and can be expensive (contextual again) I wonder how in the world it can be less efficient (I am not talking about the stupid box testing here).

Will always have a future. As long as developers will write code there will be bugs
For once I agree but half of the line. Yes, testing will always be there. Not because developers write code (all those who write code are not developers) but it’s the human who does.

[Updated on July 16] As Pradeep says At the end of the Software Life Cycle, what we get is a non-solid, non-liquid basically a form-less thing – A Software. No software runs on its own, which means, it needs another software to run along, to run on. This creases the volatility of the product (Software) ie the volatility gets squared, tripled and so on.

If not for all the above said reasons, because its human brain that creates a software which always in a amoebian form, the testing will exist..

Scripts & Testing

"Scripts" as is called by many and more commonly known as Test Cases are seen as some kind of cage, rule, constrain by lot of software testing experts, especially the likes of Pradeep, James Bach and the list grows.

I like reading them and agree with them on lot of subjects, the likes of importance of exploratory testing, the importance of human intelligence. But one subject that I don’t agree with them as I do on lot of others is that of “test scripts make the tester dump”. With the very little time that I have spent testing applications, I believe “Test Scripts/Cases (going forward will address as Scripts) are one of the important artifacts of a testing process.

This is how I understand why scripts are important.

Testing as a process, a project should have a goal. The goals can be to find as much defects as possible in the software. I concur with Pradeep & Co (would like to call them the D-gang, and of course I am part of it as well but differences of opinion) that doing an exploratory testing (basically questioning everything that we see in a software) does help finding those issues. Here the goal is to find the things the software doing that it’s not supposed to do.

One of the test managers with whom I worked in the past used to tell me that there can not be a test case without an expected result. When I hear that, I used to ask myself “Why the hell not?” Of course I couldn’t ask them as I was a fresher and the person telling me this was one of the reputed Test Mangers of the organization that I was working for.

I do not agree with the statement of that test manager as the same way I do not agree with Pradeep when he says scripts cage him. Testing can have other goals as well. The context drives goals as well. “Finding if the software does everything that it supposed to do in all different scenarios or situations”; how about this as a goal?

In this context, as a tester it’s imperative for me to understand that as a user what exactly is expected from the software that am going to test. This is a guide for me to check the conformity of the software with the user’s expectations from the software. I call this as scripts or test cases and someone else can call this as a check list or may be anything else. After all, we live in a free country and everyone as freedom to express.

When I go a step above and see this test scripts, I see them as a tool. The utility of it is going to depend on the person uses this. As always, now the problem is with the unwise thought process that a person has while looking at test cases. It’s certainly not testing if the aim is to have all the test cases “Pass”. This is thought process is something that cages a lot of minds and not the test cases.