Keys of a piano. Showing texts “a Test Fuga On 2 Flat Screens” and “”!

a Test Fuga On 2 A Flat Screens

One of the most complex music pieces is a fuga. Just imagine several instances of the same melody at different progression points, which can be heard at the same moment. And together still sounding well. Don’t try this at a meeting. It is like 3 people talking at the same time and it still makes sense.

I am aware, that fugas are not everyone’s favourite music. Some readers prefer music from TV channels with names containing a minimum of Capitals. Other readers can remember the theme of their favourite movies. Coming soon in a theatre in their neighbourhood.  A theme or melody is a recurring reminder, that one listens to or watch a certain story.

A theme in software testing is that I constantly am aware, why I am testing a certain object. I have to be conscious, that I need to focus on the right things. And that is hard. Especially with bugs popping up and undocumented features being uncovered.

WYSIWYE: What You See Is What You Explore

First question I always ask is: what is the purpose of the new or changed functionality? Followed by a lot of other questions. In order to structure the obtained information I use a mind map program. The mind map contains gathered information and references to relevant files. Good news: some digital mind maps allow links to other digital files. Just click once to look at the relevant information.

In a world with an increasing number of interconnecting systems or things a test for an interface was not a surprise for me. I got specs and a minimal description of the interface. Files had to be exchanged. So I started digging:

  • What is the purpose of the interface?
  • What kind of data is contained in the files?
  • Is there a way to intercept the files?
  • What kind of program do I need to dissect the files?
  • How do I get the right data in the files?
  • What are my requirements for my test environment?
  • Etcetera.


There are several ways to determine, which areas must be tested. A heuristic or a fast and constructive way to determine, what can be tested, is SFDIPOT. A simple way to remember this is San Francisco DEPOT. For my fellow Dutch testers SOFT DIP, which is approved by one of the founders. Not me.

Some readers might suspect that “I” in the title of the paragraph is a reference to the author of this blog post. Other readers familiar with  SFDIPOT think, that “I” stands for Interface. It was strange to use this heuristic for the test of an interface, but it worked for me.

Next stop was to make a new mind map with the following branches using SFDIPOT:

  • Structure
    What is the interface? The interface was a set of files, which were exchanged. I had to test the system, which made the files, and test the created files. The receiving system was out of scope.
  • Function
    Does the system make the right files? I used some specifications to understand, what was contained in the files. On my PC the right tool was installed to read the records in the files.
  • Data
    What kind of information was stored in the files? Browsing through the specs I got some ideas about the content. The big question was how to cover the possible values. Which steps should I take to set the right values in the records of the files? Some record fields were fixed; others had a limited set of values. Of course there were record fields, which could contain text. Diacritic characters should be tested.
  • Interface
    How are the systems connected? I asked a programmer, whether I should test a network failure. His answer was: “Yes. Of course.” I made a note or branch in the mind map, that I should pull the network cable out of my PC during one interface test.
  • Platform
    Which operating system is used by the system, which makes the files? So my PC had Windows 7. Windows 8 and Windows 10 should also be tested.
  • Operations
    How will the interface being used? In order to support the file exchange some custom made services had to be installed. A restart of the PC could occur. This might impact the availability of the services. So a restart was planned for testing.
  • Time
    When will the interface be used? I noticed, that there were two options: ad hoc and scheduled. I asked myself, what would happen, when an ad hoc service and a scheduled service are being executed at the same time.

Whenever I ran out of ideas, then I switched back to the first mind map with the gathered information:

  • Did I use all relevant information for my test ideas?
  • There should be test ideas for time. Let me have another look.

A disclaimer: the complete set of test ideas is not described. This blog post is my experience report, how I handled the interface test.

Now I had some test ideas to turn into a theme for my Test Fuga. It was to time to structure the tests. My next blog post will cover the following steps and the Two A Flat screens.