Archive for the ‘General’ Category

In one of my blog post, I detailed out the challenges that are often faced by the product/test owners during software product testing. In this one I will be talking about some methods or activities that can help in overcoming those challenges. I will leave it open for you to map the answers one on one to the challenges that I detailed out there.

Testing team is often involved very late in the PDLC. The product management team also collates frequently changing customer requirements and market expectations of a product, while also contributing to the product roadmap. As a result, the scope of the product changes constantly and testing becomes complicated with daily builds involved.

It is important to design the test strategy early along with the product roadmap so that everyone knows what all will be needed to test and what all methodologies will be applied during the process. This will enable the test owner to define the right budget for the testing cycle and get the necessary approvals on time.

There is a wide range of testing methods and testing techniques currently in use that serve multiple purposes in different life cycle phases. Team should choose the testing programs best suited to their needs.

Additionally, team must also focus on the cost element when identifying and evaluating testing tools available in the market. By picking Open Source tools, organizations can cut capital expenditure. At the same time, automated testing tools can also allow companies to undertake cheaper regression testing. Automation is again a debatable approach, might be I will share more thoughts on this in my upcoming posts.

It is also important to prioritize the test areas based on business criticality and test coverage. A test metric driven report also helps in getting the visibility into the exact team/product status from time to time. This enables management to take a decision regarding the market release of the product.

When examining the outsourcing option, companies must explore and clearly differentiate on what part of testing can be done onsite and what to outsource, while optimally using the collaboration tools. If there are questions of who is doing what, setup a transparent system in order to track each remote team member of the test team.

Currently I am busy designing a test solution that will act as a SINGLE solution to overcome all the challenges in software product testing space. It might be too early to talk about it or maybe you will need to wait for few more days before I start detailing about it in my blog posts.

Be a tester first

Posted: June 25, 2010 by Vipul Gupta in General, Testing
Tags: , ,

I was talking to a group of individuals from testing community. They were boasting of the things that they do as part of their testing assignments. I am posting the conversation that I had with them.

Me: What do you do to test a system?

Group: Validate all the requirements that are provided in the form of specifications, UI mockup, rules etc and certify the product for quality.

(I was a bit overwhelmed, smiled and congratulated them on their achievement because as a tester they are doing so much and also certifying the product for quality.)

Group: Why are you congratulating us. This is part of our job that is given to us as a testing team.

Me: If you are doing so much, your client might be delighted about the quality of work that you are doing.

Group (a bit nervous): NO

Me: Why?

Group: Our client does not value us and often says that the testing team is not able to identify bugs that are being reported by the actual customers. We are testing and certifying whatever is provided to us as requirements, still the bugs come.

Me: So you are not doing ‘testing’

Group (confused): We are doing testing. We are verifying everything. We mostly achieve 100% requirement coverage in our testing.

Me: Wow. Then why are bugs coming in?

Group: Because the user can do anything. He sometimes go through the scenarios and does not know what are the right values to put in the fields. Hence it sometimes crashes the system.

Me: Didn’t you tried out those scenarios?

Group: We tried some of them, but on discussing with the development team we were told that these are invalid scenarios and the user will never use that.

Me: Wow. So the developer was creating it for some particular users and they already collaborated with them and told them not to run those scenarios on the system?

Group: No. The system was being developed for the users who will use it on internet. The developers never had idea about who the actual user would be.

Me: Then why didn’t you question that? Who are developers to decide that the user will not use the system in that form?

Group (Whispering): It is how it works.

Me: This is where the problem is. It is often seen that you, the testing team, is being driven by the development team. How can they know that user won’t be using the system in the form that they could not think about or are not able to fix? This is where you as a tester can add value to your clients. Before proudly certifying the product for quality, which is not your job anyhow (Read post), be a tester first!

You should never

  • Remove your thinking caps
  • Be driven by documented requirements
  • Be driven by developers
  • Stop testing once you execute the already created test cases. Read Michael Bolton’s Testing vs Checking series

Group: hmmm. But how should we convince the project manager on this. This might require extra time as well.

Me: Good point. It is not always easy to convince the stakeholders on time. There are two ways. Either you become rigid on implementing what I told above, which is definitely NOT the right approach or you can prove your point first. With proving I mean, show the benefits to the stakeholders that they can reap with the new approach. Showcase how the bugs are getting reduced post delivery. Practice the testing craft and keep on making the complete process more efficient with time. This will add value to what you do and will also be helpful in convincing others.

Group(thinking): Well we understand what you are saying but still not sure if the client will agree. We will try to practice what is suggested above.

Me: Thanks guys. This was a great transpection session that we had. At the end I will say

Think beyond boundaries. Take Control. Don’t allow anyone to define boundaries that you should confine yourself in while testing. – @VipsGupta

P.S. Thanks to Michael Bolton and James Bach whose transpection on twitter inspired me to write this down.

Darr ke aage jeet hai

Posted: May 24, 2010 by Vipul Gupta in General, Testing
Tags: , ,

A typical product testing scenario

The final round of testing was going on in full swing in a Product company and the team was under pressure to certify the product for release.

The Project manager was a smart person who, to fulfill his interests, wanted testing team to certify the product with minimal testing as otherwise he would miss the deadline to launch the product. He was playing safe. On one hand he was progressing to deliver the product to the market, on the other hand he himself was not to loose anything. Later he could easily put the complete blame on testing team if anything crashes in production.

The test manager was reporting to the Project manager and so he had to follow the orders that he got.

Now as the testing was proceeding further and the critical areas were being tested, the team found a bug.. a critical regression issue that got introduced due to the fixes made for another bug. The team was in a dilemma, if they reported the issue, the Project manager will be literally killing them, but if they don’t report the issue, the customers will kill them. As they were struggling to get out of this situation, the test manager came in. Everyone asked him, what to do?

He was very clear in his thoughts and what was expected from the testing process. He said, we are into testing business and we are providing a service to the development team. In case we don’t report this bug, it will be that we will not be doing our duty. If we don’t report this bug, it is such critical in nature that the customer will report it and we will be in soup again. It is better to report something early than later.

He asked the team to report the issue in bug management system. The tester was very much afraid to do so, but had to follow the orders. The project manager came in and shouted at the tester as he was surely going to miss the deadlines. The project manager went to his room and talked to development team to review and fix the bug. The development team found the possible cause of error and fixed the same.

Now the testing team again tested the issue and the affected areas and found another critical defect, which went to development lab for fixes. The Project manager was getting red as each minute was passing. The testing team was not following the orders!

To safeguard his interests, he wrote an e-mail to all the stakeholders. As the testing team is keeping everyone busy and finding the bugs at the last stages of the release cycle, we need to postpone the release by a day.

The stakeholders called up a meeting and discussed the issues. On analysis, it was seen that the testing team had nothing to do with the stage at which the bug was getting caught. As the bugs were arising due to the fixes that the development team was making. So the testing team was no one to blame.

Can you predict what happened at the end?

Few days later, all the stakeholders praised Test Manager and testing team in front of the whole group and told that if they released the product with those defects, it might have pushed them into legal battles with their clients.

What is my intention of writing all this?

The testing team often faces pressures like the above one in any PDLC, yet they need to be persistent in following the mission that is defined for testing. There will be various people on the top who will sometimes try to build pressures on you, but remember the fact that though these will be decisive times for you, but never divert yourself from the mission that you are on. Believe me, doing this, you will not only get self satisfaction, but will also gain respect of others. It is rightly said “Darr ke aage jeet hai”

Why do people complain about Salary?

Posted: March 4, 2010 by Vipul Gupta in General
Tags:

Nowadays as recession is becoming the thing of the past, often people come to me and tell me that their salaries should be increased; the company is paying salaries less than the market; or they don’t take care of the staff that has spent more years with them and take them for granted. I was a bit surprised on all these statements as I was not hearing them during recession and people were silent so as to keep their jobs safe. At that time no one came and said that company needs money at this time of crisis so we should do x or y thing to help it out. Why?

Well, I don’t want to get into that debate, but I just wanted to list down my three thoughts on the questions that are asked to me.

#1 No company can satisfy anyone in terms of salaries. I myself am not satisfied with my current take home and I know it very well that if I make a move to join another competitor who often calls me up, I will easily get atleast 50% or more hike. Whenever you switch jobs, most of the time you get better salary as compared to your current one. So that is not a good argument to get a raise. This is the fact.

#2 Look at the history of the company too. How did it behave during good times? Was everyone given a good raise when the time was ripe? If yes, just wait for the time to be ripe again. When the projects, revenue goes up, you will again be given good share from that.

#3 No company wants to loose its good employees. So if you have a misconception that as you are old so company has started taking you for granted, then you are totally WRONG. If they are not able to retain or increase the salaries, then there might be another thing going in the background that you or me might not be aware of. Apart from salaries, companies often needs to spend X amount of money for growth and sustenance. Spending cannot be more than the earnings. If it is, then they will not be able to sustain and everyone will be jobless. You are and will be always an important member of the organization irrespective of the fact that company is able to retain you or not.

Even if after this people don’t understand and don’t believe, I think it is better to let them go!

Hadoop India First User Group Meet at Impetus, Noida

Posted: November 28, 2009 by Vipul Gupta in General
Tags:

I attended Hadoop India User Group meet today at Impetus, Noida. It was great to listen to speakers from Impetus, IBM and Yahoo. The event was attended by many enthusiastic engineers and they were leaving no chance to query the speakers and wanted to go into minute details of the topics that were being presented. I will like to congratulate my friend and coworker Sanjay Sharma for successfully organising this event.