jump to navigation

Fusion Testing – Maximizing Test Execution October 14, 2009

Posted by yvettefrancino in QA.

There was a full house  in attendance tonight at our monthly SQuAD meeting  to hear Jamie Tischart, VP of Product Delivery for MX Logic,  present “Fusion Testing.”

FUSION stands for:

  • Focus – Start your day with 15 minutes of thought
  • Usage – How will your users use the system
  • Scope – Decide on scope of everything
  • Initiate – Just go and explore
  • Organize – Create a plan and be ready to deviate from it
  • Note – Keep track of your exploration to retrace steps

Tischart created the Fusion methodology in 2005, combining structured principals with exploratory techniques to provide a methodology that has proven to be effective – faster delivery with fewer post-production defects.

In many ways the Fusion model uses elements of an Agile Methodology.  It includes iterative short life-cycles and test driven development. Test lists are used to guide exploration.  These lists are high-level rather than step-by-step test cases.  Tischart encourages taking advantage of “the power of many” — getting many users involved in exploratory testing.  The users are given guidelines, but not cookbook instructions…  There is not a lot of benefit from multiple people executing the exact same set of tests!

When it comes to automation, the Fusion methodology focuses less on the GUI and more on Middleware, API Level testing, and Performance testing. It’s also important to evaluate where the most benefit can be obtained from automation. If you’re only going to run a test once, there’s no need to automate!

The basic guidelines for Fusion Testing include:

  1. Identify goals for testing
  2. Choose the right mix of methodologies
  3. Utilize Test Lists to guide exploration
  4. Automate the right things
  5. Document at the right detail

I like the flexibility with this methodology. The focus is on doing what’s “right” for the project…what makes the most sense given the scope, the criticality, etc. For example, projects that require regulation would be more structured with more rigor around documentation.

Despite my typical habit of playing the Devil’s Advocate and finding holes in every theory (what you expect from someone in QA?), I have to say that the Fusion model makes a lot of sense to me. I guess my only criticism is that what is the “right” amount of detail or documentation may be subject to interpretation and will vary from person to person. For example, Tichart said it wasn’t always necessary for pre-production bugs to be logged if the tester and developer are sitting together — they can just talk through the bugs and get the fix in quickly. I tend to disagree with this… if bugs aren’t handled consistently, metrics will be off. I also think, if left to the judgment of a busy team, with no rules around documentation, the tendency will be to skip as much as possible. However, I do think that traditional approaches can be burdened with a lot of unnecessary documentation, so I’m all for keeping it limited to what’s necessary. I just think it has to be consistent, especially when it comes to logging data that will be used for metrics.

Overall, I think the model makes a lot of sense and the presentation was very well-received by the group.

Tischart will be presenting the Fusion Methodology at the QA&Test Conference in Spain next week.



1. Simon Morley - October 15, 2009

Hi Yvette,

Nice post.

A lot of the ideas with FUSION are around in many methodologies – but I like the way it’s presented. The idea of “setting goals for the day” is very underrated. This should be standard practice – but sometimes easy to forget. The key is making the time for it.

As with the rest, fit-4-purpose/good enough documentation etc, that’s something that I think (sooner or later) more & more organisations will have to move towards – maybe the exceptions here are mission critical/life-threatening products and niche markets.

Pre-production bug reporting – I can see both sides of the argument on that – but this is very much to do with the flavour of model that has been used (or tailored) to a particular team/org set-up. But I don’t really want to get into a discussion on metrics here… 🙂


yvettefrancino - October 15, 2009

Hi Simon, Yes, you got it. Have you used the FUSION model? You sound very familiar with it. As for the pre-production bug logging… yeah, I can see both arguments, too. I had to find something to harp about or what kind of blog with this be? But, as a former developer, I know there were plenty of bugs I found early in the cycle that I didn’t bother logging, except when it was irritatingly mandated. And metrics *is* a whole other topic!

2. Simon Morley - October 15, 2009

No haven’t used FUSION before, but the elements are familiar – I’ve used them individually – so the grouping intuitivelt makes sense to me.

3. SQA Plan Templates « QA Management Musings - October 19, 2009

[…] documentation, as is recommended in Fusion Testing.  (I threw in that I’d just learned about Fusion Testing at the SQuAD meeting, hoping that would score me some points from being an actively involved SQuAD […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: