Nishant Verma

How much automation coverage we should have? Why to automate something when we are not going to modify it in the next 2 iterations? Why not automate only regression scenarios? My automated tests do not catch bugs ! It’s a very complex manual testing stuff and takes me a considerable amount of time to execute it, so I want it to get automated ! Well these are the typical questions which I always get to listen in any meeting which talks about “Automation Coverage”. Why such a bug fuss around it? I have worked on several project which ranges from pure manual testing to pure automation testing. So before starting to create automated test we need to answer few questions. Why are we automating? Is it a deliverable to client? Is it to create a “Safety net”? Is it to ensure sanity of the application before the build formally comes to QA? Is it to reduce manual testing effort? Is it to catch bugs? All of the above Once we answer these questions before rolling out the automatio

I came back from the background of writing test cases which were categorized in either Positive or Negative test cases. Positive test cases were business flows which may or may not give any result but they will certainly not give any exception or error. Negative test cases are those test cases which were bound to result into some exception or better expressed as error causing scenarios.  Then those positive test cases were prioritized as High/Medium/Low . Finally it used to result in quite a comprehensive test case document. Then it will go through the process of review and few more updates or change of priority etc. Certainly it is a tedious process. Here in ThoughtWorks I got introduced to different way of categorizing test cases called “ Happy/Sad/Bad ”. A test case which results you in a positive result is a Happy path , for e.g. entering proper username and password on login page. A test case which yields no result like entering invalid username and invalid password on a logi

It’s quite some time since I  am learning the process, terminology and environment here in ThoughtWorks. When I entered the company one thing which I found very weird was postcards on wall or board. These walls are called Story walls . There would be some heading and few postcards under them in yellow or red or pink colour. Then around 10 am in the morning I see bunch of people standing next to the wall and speaking one at a time and then they would move some card from one column to another. I wasn’t understanding what is going on ???? But then during my boot camp session I was told about something called stand up meeting and those postcards are nothing but Story cards . To those who are pretty old enough in Testing field and very new to Agile methodology , Story card is a way of representing a small implementable unit of a feature . Even a bug can be a put up in a form of card on the Story Wall under proper column (probably Testing). I have put down a image at the bottom of this art