Nishant Verma

I talked about importance of regression testing some time back where I pointed out why we should have one and how to drive it effectively. As I spend more time doing testing and going through releases, I am realizing that we need something bigger than regression ( when not on happy path) . The idea of regression is to uncover most of the bugs in the application and get it fixed based on Triage parameters. Happy Path: Bug fixing rate is higher than the bug finding rate (in case of less buggy application). Sad Path: Bug fixing rate is constant and the bug finding rate is on a rise (in case of a buggy application). A project in either of the state can easily be identified by looking into the bug logging rate. Projects on happy path don’t need much attention and can easily be managed through regression phase. But for the project on sad path I would suggest to have a Stabilization phase instead of Regression phase. The notion behind Stabilization phase should be to be prepared for rele...

I will introduce one tool here which I used to use frequently for verifying a website for any broken link - Xenu's Link Sleuth. It’s a simple and powerful tool. It is easy to use and provide a cool well formatted reports. Some of the prominent feature of this tool are: A Freeware tool Checks website for broken links Link verification done for         Normal links, Images, Frames, Style sheets, Script and Java applets Simple UI, better error reports Re-check of broken links Detects and reports re-directed URLs Supports HTTPS Nothing to install I will put one screenshot to which demos the same. More information you can find here .

We do Stand up or Scrum meeting to update : what I worked on what I plan to work today what is stopping me to achieve my goal It is like a synchronization point for the whole team, allows each member to know what others are working on. It gives a sense of sharing the commitment towards achieving a common goal. It helps to set direction for the whole team. Moreover it’s a ‘virtual’ team building exercise. It also acts as self check for individual to track their own progress. As stand up is attended by people from different background like project management, testing, development, it doesn’t really add value when we go too technical in explanations or when we pick up any discussions. Updates should be kept simple and straight and discussions should be parked for tech huddles.

I wonder how many of us are asked to stretch a little more, deliver a little more, work a little more; I guess almost all of us. I am not pointing anyone but I regret that no one told me to do better. I have interacted with many managers (or above) in my career till now but one thing which I found in common is “they expect us to do more”.  I don’t remember any instance where they asked to do better than just do more. I don’t know why but it’s strange that no one ever told me. Is it because that it is the easiest way to get things done and that too in a faster manner. “ Doing better ” comes at the cost of training, patience and sometimes a reduced pace which may not get accommodated in the today’s fast paced software delivery practices. This post is inspired by the Seth Godin’s blog .

I have been in Boston at client location from past few weeks for UAT Sign-offs. It was a good learning period. I learnt a lot in terms of what Client wants, how do they see their application coming up. I also noticed why they want few pieces to come up fast. I also notice how frustrated they feel when we didn’t match their expectations or try convincing them on something which we have messed up. I also learn that few things are logical and should not be explicitly the part of acceptance criteria or story. I remember an example when one of my QA manager (I admire him a lot) gave that to me. e.g. When you go to restaurant and order for ‘Dosa’ you don’t explicitly order the ‘chutni’ and ‘sambhar’. So few things are understood. And the same needs to be applied to other things as well. I learnt that standards has no boundaries. These examples can seamlessly be used from one field to another. I also learnt that its very clear to them that points is just for you (IT guys) and all they both...

In a typical IT Outsourcing scenario, people  who will use software is different, people who give requirements are different, people who will develop the software are different, people who will test the software are different. So there are bunch of people from different background and skills working together to achieve a common goal – to deliver the software. So the most difficult task is how these people will be in sync. How the developer and tester will know what users want? “Business Analyst” are the ones who paint the application in a developer and tester mind. Let’s quickly take a look into Business Analyst role. Generally people like developers and testers need not be an expert at every aspect of software development, but one skill they should definitely posses is the art of analyzing. One need not be an analyst but should possess some analysis skills. A software development team needs an “analyst” who can translate the stake holders requirement into something which a dev...