Risks and Mitigations in Cloud Testing

Here is a link to my post on Cloud Testing: Risks and Mitigation
http://solutions.wolterskluwer.com/blog/2011/01/cloud-testing-risks-and-mitigation/

Rumblings From Testing Project

This past week and weekend I had to help out with a project that I used to lead two years ago. Since I handed it over there has been several changes to the project. The project saw quite a few test leads come and go, several project managers changed hands and project changed directions several times.

This product is part of our legacy system and a project that I loved working on. Right now due to lot of compliance changes its mandatory that they hit the release date. There is no wiggle room. They asked me if I could help and I did sure why not.

They assigned a couple of change requests to me and sent me the documents I would need to successfully test these changes. I came in thinking its going to be easy peasy. Guess I was wrong.

The product was the same. Yes it is like riding a bike. As soon as I logged into the application everything came back to me. The caveat though was that the processes for the project had changed. From being a successfully self run motor vehicle it had become a car that needed pushing all the time. I am not going to get into the details of the actual work.

This is a mini vent of things I learned from testing this product:

• When working under pressure (especially when the focus is to hit the date) no matter what we want to think chances of making mistakes are higher. No one can be blamed. There is less time go review your own work irrespective of your role. Requirements may be missed, code changes often impact areas that developers didn't get time to review, testing scenarios are missed and chances are these mistakes wont be caught till it goes to the customer. No one wants to do these on purpose but circumstances force these situations. No these are not excuses I am making, I am talking about human beings who have to work overtime, spend weekend and weeknights to get things done.
• How do handle this?
• Teams need to take a break, so occasionally even if we are behind, ask the team to take some time to do other stuff. Yes we are loosing time but when people come back from the break they will be better charged.
• Patience is an asset. Everyone is busy and being patient and polite will take you a long way.
• Get someone outside of the team to help with testing. Support line, product managers, project managers, etc
• Someone who can help without ramp up time.
• They will be able to look at it with a new set of eyes and help with finding issues and ask questions that others might overlook.
• Split the product into feature areas and get all or few testers to test one area fully one at a time. Wait for one a complete round of testing in that one area, log all issues and then fix them at the same time so a second round of testing can be done to wrap it up.
• This will help gather all issues within a few hours.
• Also coders can fix all issues at the same time instead of touching the code at various times.
• Scope, date and quality - three pieces of the release equation. Product can only have any two at a time. So if the date is fixed and more issues are found, then either the date has to be moved or scope has to be reduced (cannot fix all found issues). So really product team has to decide which one item will provide the wiggle room for the product. Can we move the date? Can the product release with known issues?
• Whole team fails if the product does not release or releases with poor quality no matter who else within the team were on schedule or completed their tasks on time. Project failure equals to team failure.

Easy to talk about all this now that the work is wrapping up well and kudos to everyone on this project for having done everything they can or could. True test of team work comes when there is a crisis.

The IT Files - Ajay Balamurugadas - Part I and II

I had a chance to talk to Ajay and here is the complete interview.
Part I
Part II