Software QA and testing used to be fairly arbitrary (developers would test in their own way). But the trend has changed over the years as most software development shops have created a separate QA unit. Still, I’m often surprised to see how many organizations struggle to fill these positions – often not understanding what skills a QA person needs.

What do you think is the most difficult and critical task in project risk management? Hint: It is not analysis nor is it quantification. The answer: identification of risks.

I frequently see people using the terms “Issues” and “Risks” interchangeably. Sometime back, I saw a discussion on linkedin related to this topic. I also saw similar a discussion on the PMI Risk Management Community of Practice discussion board. Those of you who participated or read those discussions may very well know about the difference. I would like to initiate this discussion for others.

Though a focus on test automation is growing in many organizations, I still see test automation continuing to be an ongoing challenge. I attribute this to several factors:

Are you a QA analyst/tester and feeling unclear about your role on an Agile team?  Are you doing less than what you might expect? Or are you being asked to do more in less time?

Well, you might have heard this one before: If you can measure it, you can improve it. Yet, when it comes to implementing this rule to improve business results many people and organizations struggle. 

Do you manage IT or software development projects? Have you seen a pattern of risks that appears in almost every project? Here are my top 5 risks that IT projects may experience:

Here’s yet another common pitfall for QA testing teams: communication. Inadequate and ineffective communication can sometimes lead to bigger problems – not meeting expectations (of both management and the customer), misinterpretations, and lower productivity.

If you deal with projects, plan them and manage them then I am almost certain that you are very familiar with Work Breakdown Structure (WBS). But do you know what a Risk Breakdown Structure (RBS) is?

In my last few blog posts on QA Challenges, I touched upon the importance of planning from a QA perspective and how to deal with seemingly conflicting situations like whether to focus on either quality or the schedule. Although this may all sound conceptual (or strategic), the biggest challenge here is actually execution (or delivering a positive outcome).