Showing posts from August, 2010


I consider human brain as a self learning robot which has the capacity to imagine, to think, to compute and to do many more things which are just unimaginable. But to my surprise I have even find out many times brain couldn’t cross a little boundary. What is that little boundary? I am talking about “Assumptions” as those boundary which is a passive creation of brain without consulting anyone. I felt that whenever my brain gets a problem to solve, it creates the so called “No Entry Zone” surrounding the problem and that “No Entry Zone” is nothing but the assumptions. Something like the one below. Assumptions not only limits the way we think but also hinders the creativity and innovativeness of the brain. Some times we just can’t see what is obvious. Let me give one such example which I encountered while reading a book. It will be interesting if you don’t know the solution. Problem Statement: You have to draw 3 straight lines to connect the 9 dots. Now the moment we finish re

Rescuing Agile Tester

Being involved in Software Testing field for quite a some time,  I felt like blogging on what makes a software tester life easy ! It can be anything depending on the projects you are involved in and the typical activities you carry out in your day to day testing life. I have always felt a little pressure on the testing team specifically in the agile methodology; a constant pressure of catching up with QA velocity or story sign-offs, planned regression cycle in between the Iterations, writing test scenarios, writing automated regression suite, continuously improving the smoke test (in terms of coverage and execution time), planning customer showcases. Oh God, so much to do in such a less time !!! I felt that there are few things irrespective of project which will make the life of a tester easy. Tester spend a lot of time deploying application (Unless they are using a Continuous Integration tool) and doing general sanity (in case the regression suite is not sufficient). Few things whi

Similar : – having a likeness or resemblance

When I searched for the word ‘ similar ’ on the website , I was shown the below result. Well it’s not that I was not knowing the meaning of the word, but just wanted to see if any new context has been attached to the word. Thankfully I am not out dated. How it happened: I was browsing online to buy a book ‘ iWoz ’ on the Flipkart website, searched for it and got the result in positive. Nice! To people who don’t know Flipkart, it’s an online book buying shop launched in 2007 but has gained popularity recently due to it’s nice organized structure, easy payment system, good customer Service. Now when I searched for the book, in addition to the book result, it also displayed a section ‘Purchase Similar Books’. The books listed under that heading forced me to look out for the meaning of ‘similar’, it was show confusing! You must be guessing what all books were displayed, let me show you the snapshot. Take a look at it and let me know if you can find a

Usage Patterns driving Testing Patterns

I am a normal internet user accessing Gmail, Facebook, Google Reader, Google Talk and many more public facing websites. Like me there are many more users using the same application, same features and infact pressing the same key. This blog is to to share my views on how actual Usage pattern of application should help in optimizing the Testing activity.   In any application, there are some features which is used heavily by the users. This not only applies to software application but also to hardware devices like keyboard for example. “Enter”, “Space”, vowels key etc. So knowing in advance that which features gets more load (in terms of usage) and which will get less load will actually help us in planning the testing around that area. It will also help in prioritizing (among list of features) the testing activities. Those areas should be majorly focussed while testing and (from a tester point of view) any bug left or ignored in that area has a higher probability of getting caugh

Test case writing

When I started my career in Testing, I was given a 40 page RDD (Requirement Definition Document) and was asked to understand it and start writing test cases. Sounds crazy isn’t? Anyways I am not discussing here how to write test cases, rather on the way of writing test case. Test case writing is not an easy job! It reflects the testing style of a tester. Intent of a test case is to discover more information about the system. So the way we understand test case is : some set of goal oriented steps, accompanied by test data (if any) and the conditions or pre-requisites followed by the expected result. If we give the same feature to different people for writing test cases, we will see a different pattern. Those patterns differentiates a tester. Almost all will have a mix of Happy/Sad/Bad test case but the proportion will vary from tester to tester. The intent behind writing a test case is to make sure the intended functionality works. Also we have a mix of negative test cases to assu