Nishant Verma

“ Testing shows the presence of bugs and not the absence of them .” I read this somewhere and I understand it otherwise. When I am assigned on to the task of testing any module I make sure that I leave not even a single bug. I take pride in saying that “once I test it, you will not find even a single bug”. This is my perception of testing. So the question is how do I motivate myself for this task. To many testing sounds boring and un-challenging (views from some of my colleagues and some online data), I don’t see it that way. Testing to me actually requires a high level of aptitude skills , ability to think through and above all make decisions . One need not be proficient in C# or Java or QTP to be good tester. In my point of view, Testers should have the ability to “comprehend”, the desire to go an extra step to uncover things but unfortunately I don’t find these things in any of the interview. Testers should not only test the application but should guide the way an application i...

Story as we know in agile is a light weight requirement. It is characterised as independent vertical slices of functionality which can be estimated and tested. So a typical story has a business scenario wrapped up in limitations and acceptance criteria .  Acceptance criteria are the happy path test cases , which ensures that when a tester signs-off the story, it delivers what it is intended to. So as a tester what should we do, just limit our testing to the story? Generally, bug is not in the standalone system, it generally gets discovered when a system interacts with another. Whenever I think of story testing, first thing which comes to my mind is the Pepsodent advertisement. Sounds weird? Let me explain, I consider story as a tooth and when given a perfect piece to you, one may not find any germ (bug in this case). But when a tooth is next to another or let’s say when a story interacts with another story, there is a chance of finding potential bug. Germs always hide themsel...

The backbone of agile methodology is the fragmentation of a complex task into a small components. As a result those development of small components leads to iterations . So a typical project of 6 months is replaced with 12 iterations of two week projects. So we finish one iteration to measure what tasks we achieved. Now agile is a Software Development methodology with many methods and set of good practices, Scrum is one of such agile methods. In scrum, we generally have Sprints which is the name given to the iterations.  A sprint could be of 1 week to 4 week long. One thing which I forgot to mention is that the success of project execution using agile methodology largely depends on the team. Few words which would be typically used to describe those teams are cross functional, self organized. It’s a very much disciplined team. The team should not have a typical PM who decides who has to do what, rather this call is taken by the whole team. BA’s and scrum master though play a ...

It’s been more than four and half years since I am involved in QA activity and have executed quite a lot number of projects varying from 6 months duration to 2 months. Most of those project execution was based on Waterfall model and Iterative model . One question which keeps coming to my mind is why different companies follow different software development models? Does it really matter to the end users or Client or Stake holders, if you have followed typical waterfall or a fashionable agile model? Why would they even bother about that as long as you are giving them what they want (Quality Software) and on time (satisfying their “Time to Market” clause)? They might be interested in the success rate of the projects which followed “A” methodology or surprised by the “X” amount of overhead some company is charging which follows “B” methodology (which is based on some of the best engineering practices for rapid and high Quality Software Development). Software is an evolving field and so ...