jump to navigation

Randy Rice’s Great Software Testing Site September 30, 2009

Posted by yvettefrancino in QA.

My goal has been to blog every morning. Since I have 3 blogs, like to write and have an uber-virtual-library available to me, thanks to the Web, this is easy.  I have a long list of topics about QA.  For example, this morning, I’d planned to write about the difference between QA Management and Test Management.

And then I thought….Nah. I’ll save that for tomorrow. I should have at least one day a week when I blog about something trivial and entertaining on this QA blog. Since I used up my one anecdote already on my QA erotica post, I googled “Software Test Jokes Humor”, thinking I’d take advantage of reusing someone else’s creativity, and I stumbled upon

Software Testing Humor – Randy Rice’s Software TestingSite”

Well, as I was perusing this site, I found a lot more than humor!  In fact, one of the first links I pressed was “The QA Zone” which, coincidentally, described the difference between QA and Test — the exact topic that I’d originally planned on blogging about.

Randy has a whole bunch of other Free Stuff – articles, presentations, his blog, and a whole eLearning library.  The place is another virtual goldmine of QA and software test information! There are some for-pay courses and certifications for a price, as well.  An hour and a half later, I remembered I wanted to write my blog post, so here I am.

The one thing that Randy’s site is not set up for (yet) is the ability to integrate with social networking sites.  I see Randy’s on LinkedIn so I hope to connect with him and suggest he promote his site via social media. He has a book, Surviving the Challenges of Software Testing.  Both his book and his courses look like great resources, so we need to get the word out!  So spread the word to your networks by ReTweeting this post, linking to Randy’s site, or blogging yourself about it!


The Trouble With UAT – Part 2 September 29, 2009

Posted by yvettefrancino in QA.
1 comment so far

Business Requirements Need To Be Detailed

In yesterday’s post I summarized a teleseminar I attended that described the importance of drilling down on Business Requirements which should be the basis for UAT Testing.  Robin Goldsmith suggested that too often we go right from Business Requirements to Product Specifications and that UAT is typically a subset of the product functionality tests that were already performed by the QA Team. While I agree with the premise of getting detailed Business Requirements which are tested in the UAT phase, I didn’t think this presentation addressed the issue that was suggested by the title: Helping Users Find Time for User Acceptance Testing.

The Business Users Need to be Involved Throughout the Lifecycle

I believe the big problems with UAT come when the business is not involved throughout the cycle. Even if they give the most thorough of Business Requirements up front, if they are not given some early previews as the product develops they are bound to come back with a great big, “Huh?” when the code is thrown over the wall for them to test at the end. Just as the communication and collaboration between QA and Development has to be strong throughout the lifecycle, so does the communication with the business.  I’ve been on projects where the development team is reluctant to share early code with the business, not wanting them to see a work in progress.  This almost invariably ends with the business claiming, “This isn’t what we asked for.”  On the other hand, for the projects that involved the business throughout the lifecycle with iterative releases, there were no surprises. Questions about business requirements and how those mapped to functional requirements were addressed throughout the development cycle, ensuring the entire team was on the same page.

The Key to Finding Time? The Relationship

But this still doesn’t answer the question: how do you help users find time? There are so many methodologies…which of those are the best at helping users find time for UAT?  We could go into a deep philosophical discussion here about the different methodologies and efficiencies of each — but, I’ll save that for a different blog post.  My thought is that everything is centered around the relationships you have with the project team.  We all have the same number of hours in each day, but we tend to make time for the people we trust and respect. If the relationships are strong between all the team members, they will work together and find the time to make sure the product is high-quality.  Even when I have been on projects that were following the traditional waterfall approach, I have brought trusted business users in early to get their take and ask questions and get their input.  They were part of the team.  And when you are part of a team that you like, you make the time to do your part. Maybe you do it over lunch or squeeze it in between meetings. But you communicate!  I think I will create a new software development lifecycle methodology that goes like this:

Collaborate -> Communicate -> Celebrate

The Trouble With UAT – Part 1 September 28, 2009

Posted by yvettefrancino in QA.
1 comment so far

On Friday, I joined a free teleclassHelping Users Find Time for User Acceptance Testing,  presented by Robin F. Goldsmith, JD.  Mr. Goldsmith, author of Discovering REAL Business Requirements for Software Project Success, maintains that traditional UAT does not work well because typically we translate Business Requirements (the WHAT) into Functional Requirements (the HOW), rather than drilling down to get more detailed Business Requirements.

According to Goldsmith, conventional teaching is that UAT is a confirmation of product system requirements (rather than the business requirements) and simply a rubber stamp. “We’ve already tested it.  Just go give it your blessing, Mr. User.”  Users only are asked to do the positive proof of concept. It’s very common that UAT is a subset of System Test, and users are unlikely to find new problems providing little test value.   All that’s needed is one test per use case.  It’s a lot of effort without much payback.

In the model that Goldsmith presents, there is a phase of proactive drilldown into the Business Requirements, with requirements-based test cases identified early, prior to development, by the business. Goldsmith’s model, which he calls the Proactive Testing Life Cycle,  identifies more than 21 techniques for evaluating business requirements and then over 15 techniques for evaluating designs.

Goldsmith’s presentation was informative and he made some very valid points. However, Devil’s Advocate that I am, I would argue that the presentation was mis-titled. I think it is absolutely essential to have business folks involved up-front and ensure that business requirements are solid, but that takes time up front!  I guess the idea here is to convince the business that in the long run, this time will be worth the investment. While I think we’d all agree that being proactive is beneficial, how do we really help users find time for UAT? I’ll give my viewpoints on this in tomorrow’s post.

Requesting QA Manager Interviews For My Blog September 25, 2009

Posted by yvettefrancino in Management.
Tags: , ,

ExpertAs I peruse the Web for ideas on good topics for QA Management, I find a lot of interesting content. Rather than rehashing content that is already available, though, I’d like to meet some Software QA Managers and find out what challenges and experiences they’re having in the world of QA.

My plan is to have an interview each week with a QA Manager, resulting, of course, in an informative blog post.  This will be great fun for me because it will mean not only learning a lot more about the field of Software Quality Assurance but also getting to know some smart people with a common interest and profession. I absolutely love meeting people through blogs and social media!

Who should I start with? What about you? If you are (or ever were) a QA Manager, I’d love for you to consider being the subject of an interview.  Or, maybe you can recommend a QA Manager that you know who you admire. If you’re interested or have any recommendations, please leave me a comment or email me through my contact page.

The interviews will be fairly short — blog posts are only a few hundred words. I expect each interview will be unique, but here are the kinds of questions I’ll be asking:

Tell me about your background – How long in SQA? What types of applications? What companies?

What Software Development methodology do you use? – How closely are standards followed? What is the relationship between the development and QA Teams? What challenges do you face with this methodology?

What kinds of tools are used? – Are you using automation tools? What tools are used to track defects and monitor progression of test cases? What types of metrics are tracked? Does your team specialize in a particular type of testing?

What resources and networks do you use? Professional organizations? Certifications? Websites or communities? Books? Blogs? Who have been your mentors?

Any anecdotes, words of wisdom or jokes? (Always looking for a way to make this blog entertaining!)

And, of course, a photo, and/or links to your home page, blog, or anything else you wish to promote would be included.

Hope  to meet you soon!

BlogCatalog September 24, 2009

Posted by yvettefrancino in Uncategorized.
add a comment

Software Blogs - BlogCatalog Blog Directory

QA erotica? September 23, 2009

Posted by yvettefrancino in Uncategorized.
1 comment so far

OK, I admit to a sleazy title, but this is a true story.  I figure it might lure in a few people that are not really interested in quality assurance, but blogs are supposed to be entertaining, and this is the only entertaining QA story I can think of.  And when you have a new blog, you’ll do what you must to bring in traffic…

So, when I was a brand new QA manager at Sun, I had this great idea about forming a community of practice.  This was before the days of social media, but there was an internal tool that allowed us to create a group mailing list.  I searched all the other Sun mailing lists and invited lots of QA groups to join this mailing list where I planned that we could share all kinds of useful information about QA.  Lots of people signed up and within a day or two, there were maybe 500  subscribers.

I happily told my team, “Now we just need to publish some exciting content.”

When I came into work the next morning, I saw that an email…the first email…had been sent to the group! Yay! I opened it up, and to my horror, what I found was a naked and voluptuous playgirl who was amazingly tenacious. She wouldn’t go away.  I kept trying to close the window (very quickly before anyone I knew walked by) and she kept popping up again! Our precious new group was getting spammed with porn!

I briefly wondered if my team had misunderstood what I meant when I said we needed to publish “exciting” content, but it was soon determined that the culprit was a spammer from outside our firewall.  I quickly went into the options and adjusted the security settings so that no outside traffic could come into the site.

I then sent an email to the new list, apologizing for what happened, explaining that as QA professionals, we can expect to see erratic behavior, but hadn’t planned on erotic behavior!  Though there were a couple who dropped,  for the most part,  people laughed it off. After that there was a lot of informative content that was shared among us, but I believe the persistent playgirl was the most exciting (or at least unusual) content that was ever shared.

(Note: I purposely decided it might be better not to post a photo on this post.  And please… no X-rated replies or comments!)

QA Team – Centralized or Distributed? September 22, 2009

Posted by yvettefrancino in QA.
1 comment so far

My first assignment as a QA Manager at Sun was to form a centralized QA team, gathering the scattered QA resources from the development teams. As is usually the case with a reorg, it was met with some skepticism and resistance. The development managers were used to having dedicated QA resources.

Back in 2002, when this reorg took place, I wrote an article in StickyMinds explaining the benefits of the centralized approach. Basically, by forming a centralized team, the staff was able to share and standardize on best practices, tools, and processes, among other things. The new approach was a huge success.

I was challenged recently to provide the other point of view. Why might it be better to keep the QA resources organizationally in the development teams? The most obvious reason is that collaboration between developers and testers is absolutely essential! When QA is separated organizationally, it’s much more likely that a we-vs-them mentality will erupt, causing developers and testers to feel more like enemies than friends. They are literally on different teams and when you’re on a different team there can be almost a natural sense of competition.

Besides the inclination to be more collaborative with the development group, dedicated test resources are more likely to learn their applications under test inside out. They will be involved in the early stages throughout the development life-cycle rather than only at the end when the code is “thrown over the wall.” In today’s world of agile development, the tester needs to be involved and working side-by-side the project team members throughout the life-cycle. If the QA resources are stretched between multiple projects, only involved during a short test cycle, they are less likely to be as knowledgeable on any one project.

While there certainly are advantages to either approach, my take is that you can get the best of both worlds by keeping the QA Team centralized organizationally and form strong cross-functional project teams. There are certain QA staff members that will have a particular area of expertise such as performance testing or internationalization testing.  These experts do not need to be dedicated for the entire life-cycle to one project, but can participate on multiple projects.  Other testers may be dedicated for the entire life-cycle to one project, but still remain part of the centralized team which is setting organizational standards and policies.

Whichever approach is used, the key is collaboration and early testing.  Any walls between development and test need to come tumbling down.

Resources for the QA Professional September 21, 2009

Posted by yvettefrancino in Management, QA, Social Media.
1 comment so far


One thing that amazes me is that we have this virtually infinite source of information available to us through the Web — this humongous library with up-to-date information. And it’s not just eBooks and articles and blogs that we have access to — it’s people! Experts in any topic under the sun.  I think it’s the coolest thing that we can read a book or an article, and then turn around and connect with the author via one of the social networking sites. We might even get to know this wise sage “in real life!”

How do you get started forming a network or community? First you find out what’s already out there! I’m already a member of some LinkedIn groups related to Software Quality Assurance.  You can also find QA professionals on FaceBook, Twitter, and, of course, all over the blogosphere.

So, today, in my zest to get started with my new QA-related blog, I did an initial search to find blogs, articles, forums, and people who I could connect with and learn from.  Since I’m new to WordPress, I’m learning this tool at the same time and still exploring all the nifty widgets. I quickly figured out how to add links on my Sidebar, so go there as a starting point for QA resources and communities.  I know there are plenty of others, so add your favorites to the comments section of this post. I added an RSS feed, too, so if you are a QA Manager or Professional, please subscribe and come back often as I’m hoping to make this blog into a place for sharing useful information.

I checked into certifications as well, but being unemployed, I’m not ready to shell out too much cash until I do some more checking into the reputation of the various offerings.  In the mean time, there’s enough material available, that I could easily read and blog daily about QA Management as well as continue to network with experts.

So much to read. So much to learn. So many people to meet! I hope you’ll be one of them.