Welcome 2011

2010 is almost over. Looking back I see changes. Like the famous quote "nothing is permanent but change" I see change more so in 2010 than in previous years. I adopted a lot of terms, terms I knew but didn't understand, terms I didn't know and now its my everyday word. So here is a small summary:

• I started blogging here and now write regularly in a couple of different places
• I made hundreds of tester friends online: people who motivate me on a daily basis, who teach me everyday and who help me be a better person
• I came to realize I have a lot to learn
• IPad, Xbox, Android, Twitter, Facebook: tools to help me if I learn to use them
• I said goodbye to simple flip phones, home phone, GPS, CD player, big huge TV and computer monitors

I welcome 2011 with the following resolutions

• I want to present at a conference
• I want to get published
• I want to travel to Europe
• I want to go on a cruise
• I want to complete my green belt certification

With these words I sign off in 2010 to return fully charged in 2011.

Musings - Sherlock Holmes

A friend of mine sent me link to PBS Masterpiece Mysteries where there were links to the new Sherlock Holmes series. This is where Sherlock Holmes meets 21st Century CSI. This show is brilliant and I loved it.


When I was watching the show it reminded me of testing. Holmes strengths are attention to details and observation (investigation). He observes and lets his observation tell him things. Things (requirements or bugs in our world) that others might miss easily because either they were not looking for it or didn't know to look for.

It’s the same with testing - we are observing and looking for things that are out of place (bugs) and things that should be there (requirements). When we find bugs, we should build the story. Build it: where could it have originated? What did we do to get here? What values can cause the system to break? What else can cause the system to break?

We can help the rest of the team (software engineers or business analysts) if we went a few steps further than just logging issues. We could give them as much information as possible. All we have to do is look for it, observe it and document it. We have the information (we saw the bug first, have the test cases, know the requirements, etc) and we have the system where the bug was found, let’s now go and build the story if possible by asking the questions and trying to answer them.

With New Year right around the corner let’s try and be better investigators in 2011. Let’s find the bugs before the customers do and let’s show our team we are Sherlock Holmes the best software detective in town.

Happy New Year Friends.

Friday's Musings - Process Improvement

For the past few weeks I have been busy trying to find a project for my six sigma training scheduled in Feb. I have been looking at various processes within our testing team to see which one could be a good candidate for my project. This is not as easy as I thought it would be.

Yes we see a lot of broken processes and we think something is broken, needs improvement, needs help, needs fixing, etc. But when we starting digging deeper into the issues we see that what we think is the problem is not always the real problem. The problem maybe visible at certain points of the process but in reality the domino effect started somewhere else and the real trick is to find that origin of the problem.

So before we start digging we really have to do the ground work. Its not always easy to say yes I want to reduce the time it takes for testing an application. Well then how much time should it take? Who decides that? Same with we find too many defects or too less defects... well then who defines how many defects is good enough?
I don't have the answer to these questions and I don't have a project defined yet. I will be working the next few weeks to define it and I am sure my readers will hear about it. So for now I leave you all with

1. Problems are not easy to define, especially if its gut feelings and not real data.
2. Everyone has an opinion on why things are broken but as six sigma practitioners we have to learn to take the weed out and look at the data for answers.
3. Questions lead to more questions and there is no easy way out.

Signing off with the hope 2011 will give me more answers than questions for my project.

ITKE - The IT Files Series - Yusuf Salwait

Read the whole interview here

http://itknowledgeexchange.techtarget.com/software-testing-big-picture/the-it-files-yusuf-salwati-part-i/
http://itknowledgeexchange.techtarget.com/software-testing-big-picture/the-it-files-yusuf-salwati-part-ii/

My Take: HPQC 11/ALM 11

Recently I had a chance to attend seminars for TFS Test Manager and HP Quality Center 11. Its interesting to see that HPQC is jumping into the bandwagon of having complete software development life cycle in one tool. They were known for test and defect management only. They biggest threat is TFS Test Manager which includes project, requirements, builds, test environment management and test management all in one tool.

With QC 11/ALM 11 HP is trying to catch up to competition. So from just managing testing pieces, they are moving into application life cycle management. This is what HPQC users have been asking them to do for a longtime.

As a tester I am excited about

1. Record and play back - yes in QC you will finally be able to record what testing real time.
2. Dashboard that will show scope of a release, requirements , test cases and defects associated with each release. We had to run reports outside of QC to gather this information.
3. Rich text editor - which will save a lot of time for us testers who add notes outside QC and then attach them here.
4. Test case re-usability - We can reuse test cases for various configurations and assign it to multiple builds and environments.
5. Exploratory testing and mirror testing - we can now create test scripts from recording our exploratory test cases. You can testing multiple test environments at the same time using mirror test cases.

Friday's Musings - Reduce Redundancy

Where do we typically see redundancy? Test cases and test plan.

We have to try to reduce this redundancy for the following reasons

• Waste of time - if we are repeating the same step or steps in more than one test case we are loosing time that could be used for actual testing or other activities.
• Painful to update and change - if one of those steps that is common in a couple of test cases changes, we have to manually go through all the tests to change them

What should we do?

• Create call tests or test templates when you know you have a bunch of steps that will be common in quite a few test cases
• Create a matrix to make sure you are not over testing. You only need tests to cover requirements and if you can combine requirements in a test case, go ahead and do it.
• Use automation if possible to get some of the redundancy out of the way.
• For test plan if there are sections that you repeat release after release, think about pulling it out into a handbook or a master test plan where you can maintain this in one place for all release. Have change control on the document to indicate changes when its applicable.

Help with an Article I am Working on

I am doing a survey for an article I am working on. If you would like to participate please reply to the following question and add your name and occupation at the end. Send the reply to shillu13@gmail.com or post it as a comment here.


Name one technology/trend that you adopted in 2010? (IPad, ITouch, Ebook reader, touch screen phone, cloud services, agile process etc) Do you love or hate it? Would it be hard to give it up? What other tool or technology did it replace? (old flip phone, desk top, books, waterfall etc)

Your help is much appreciated.

ITKE - The IT File Series - Yusuf Salwait

I will be talking with Yusuf Salwait soon. If you have any questions for him please post them here or at the following link.

http://itknowledgeexchange.techtarget.com/software-testing-big-picture/the-it-files-yusuf-salwati/

"He is a blogger @ITKE IT Project Management since sept 2007. In his blog he has written on various topics related to emerging trends, technology changes and trends, project management and current topics related to IT. Yusuf’s background is in the IT and IT management. He has been in the IT field for almost 15 years and started working with customer issues with major computer manufacturers and then moved on to work as programmer, tester and now manager.


His area of expertise is in working with customer service related issues within IT Industry. Also he has worked several different countries and can answer questions related to different in cultural understanding of IT terminologies."