Issue 504 · Week of Sep 05, 2026
Feed Jobs Search Platform About Donate

Manual and automation testing of sound features of software products.

1. Introduction

At work I am writing automation tests on C# and in my free time I am making my own music. Also, during my career path I had experience with manual and automation testing of applications which were working with sound. So, I decided to write an article about how to test sound features in software solutions like games, audio/video editors, VST plugins and standalone applications for sound effects for live music sessions.

What is the sound? Vibration of air? Something we hear.

Or maybe this is sound?

Or maybe this is a sound?

Sound waveform visualization

"0011110110000000011000000000000001000000011110000000 00011111111111111111100011111111111111111000000000001 11100000000000000000110000000000000000000000111000000 00000011000000000000000011000000000100000000000011111 1111111110100110011001101"

For all these questions - answer is YES!

Sound is a wave that we can hear with our own ears, see as a sound wave if we record it, and touch if we touch the subwoofer with our hand. For digital devices sound is binary code.

Our perception is subjective. Each person sees and hears the world around us differently. But when we work with software, we can assume the following:

  1. Each person sees an application's user interface largely the same way, but their perception of the sounds our application produces will be more varied.
  2. This is a psychological issue. In everyday life, we see and hear everything differently, but when we work on a computer, our attention works differently. We see the user interface roughly the same way, but we hear the sounds software produces differently – this is due primarily to the anatomy of our ears, as well as the type of headphones and speakers we use. Moreover, the same speakers will sound different in different rooms. And notice that we often change the volume rather than the brightness of the screen.
  3. Sound affects our mood and our behavior. Try going to McDonald's when the restaurant is busy and when it's empty. When the restaurant is full, the music plays faster—so people finish their meal and leave. When the restaurant is empty, the music plays slower, so people stay longer.

2. Manual Testing of Sound Features

Let's make a list of types of applications which can have sound features:

All manual testing activities for these applications can be divided by the following types of user scenarios:

Use Cases for Sound Testing

3. Sound Cards and Platform Matrix

There are 2 types of sound cards - internal and external. Please pay attention that now we are talking not only about PC or MAC - for tablet and mobile phone both iPhone and Android also exist external sound cards like:

It is an important thing - because if you are making Test plan documentation for your testing activities about sound features you need to have a list of platforms where it will be tested.

Here is an example of a platform matrix which you can use for your own test plan. Let's say that we are testing a Bias FX / Bias Amp application (a famous simulator of guitar amplifiers) which allows you to play electric/bass guitar at home with headphones.

Platform Inner Soundcard External (non-ASIO) External (ASIO) Mobile External
Mac laptop YES YES YES NO
Windows laptop YES YES YES NO
iPhone NO YES YES YES
iPad NO YES YES YES

4. Checking Sound by Ears

We need to understand that if we are testing some sound manually there are two main approaches which we can use - Checking sound by ears and checking sound via automation tests, or some tools.

Examples of checking sound by ears:

5. Types of Sound Effects

Here is a list of sound effect types which can be used in audio editors:

  1. Overdrive / Distortion - Forms of audio signal processing used to alter the sound of amplified electric musical instruments, usually by increasing their gain, producing a "fuzzy", "growling", or "gritty" tone.
  2. Compressor - Reduces dynamic range by lowering peaks and raising quieter parts.
  3. Guitar/Bass amp and cabinet simulation - Emulates the tone and characteristics of physical amplifiers and speaker cabinets, like Marshall, Mesa Boogie, Soldano, Fender, Bugera, Diezel etc.
  4. Delay - Repeats the input signal after a set time, creating echoes.
  5. Reverb - Simulates natural reflections of sound in a space (room, hall, plate).
  6. De-Esser - Targets and reduces harsh "s" or high-frequency consonants in vocals.
  7. Equalizer - Adjusts frequency balance by boosting or cutting specific ranges.
  8. Treble Boost - Emphasizes high frequencies for brightness and clarity.
  9. Chorus - Duplicates the signal, slightly detunes and delays it.
  10. Flanger - Works by combining two copies of the same audio signal. One of these copies is delayed by a tiny amount (usually less than 20 milliseconds), putting it out of phase with the other copy.
  11. Phaser - Shifts phase of the signal in a cyclical pattern.
  12. Pitch Shifter - Changes the pitch of a melody by a tone or an octave.
  13. Fuzz - Extreme distortion with a thick, buzzy texture. Jimi Hendrix has used this effect very often.
  14. Limiter - Prevents audio from exceeding a set level and does not allow clipping.
  15. Maximizer - Mastering plugin which makes your mix louder and clearer.
  16. Multiband Compressor - Compresses different frequency ranges independently.
  17. Saturator - Adds harmonic distortion for warmth and richness.
  18. Reverse - Plays audio backward for creative effects.
  19. Imager - Adjusts stereo width of a track and makes sound wider.
  20. Tape/Vinyl Emulator - Simulates analog tape or vinyl characteristics (warmth, hiss, crackle).
  21. Sidechain Compressor - Compression triggered by another signal (e.g., kick ducking bass).
  22. Sustainer - Extends the sustain of notes without changing attack.
  23. Exciter - Adds harmonic content to high frequencies for brightness.
  24. Noise Gate - Removes all unnecessary noises from your sound.

6. Mixing and Mastering

An attentive reader will ask, why do we need these effects? The answer is - for mixing and mastering!

Mixing

Sound mixing is the art and science of blending multiple audio tracks (like vocals, instruments, sound effects) into a cohesive, balanced final product, adjusting levels, panning (left/right placement), equalization (EQ), and effects (reverb, compression) to create clarity, depth, and emotional impact for music, films, games.

Main goal of mixing: We have a list of records of each instrument in the band - we need to make the final track and on this track all instruments should sound good.

Mastering

Sound mastering is the final audio post-production stage, polishing a finished mix for professional release by ensuring consistent volume, tone, and clarity across all playback systems (phones, cars, etc.) using subtle EQ, compression, and limiting, making it ready for digital/physical distribution and creating a cohesive album sound. It's distinct from mixing, focusing on overall polish rather than individual instruments, optimizing for loudness standards, and preparing the master recording for manufacturing or streaming.

Main goal of mastering: We have a song which should sound as similar as possible from any speaker, any headphones, any streaming platform, at any volume.

7. Main Advice for Manual Testing

In this part of this article, we were studying the manual testing approach - DO SOME USER ACTIONS AND CHECK BY YOUR EARS WHAT YOU HEAR.

Is this approach good? Sometimes it can be the only way to test your application. But in the next chapter, we will discuss what we can do with some tools and automation tests.

Main advice:

8. Automation Testing of Sound Features

There are 2 main approaches for sound feature automation testing:

8.1 NAudio Library

This is a game changer weapon of C# automation testing for sound features.

NAudio is an open-source .NET audio library written by Mark Heath. You can find it at: https://github.com/naudio/NAudio

You will need to install the library via NuGet Package Manager: 

Install-Package NAudio

The following code demonstrates how to use the NAudio library to identify which processes are currently making sound: 

using System;
using System.Diagnostics;

class Program
{
    static void Main(string[] args)
    {
        // Enter the name of the process you want to check (e.g., "chrome", "vlc", "spotify")
        string targetProcessName = "chrome";

        bool isTargetProcessPlayingSound = IsProcessPlayingSound(targetProcessName);

        if (isTargetProcessPlayingSound)
            Console.WriteLine($"The process '{targetProcessName}' is currently playing sound.");
        else
            Console.WriteLine($"The process '{targetProcessName}' is not currently playing sound.");

        Console.ReadKey();
    }

    public static bool IsProcessPlayingSound(string processName)
    {
        using var deviceEnumerator = new MMDeviceEnumerator();
        var defaultDevice = deviceEnumerator.GetDefaultAudioEndpoint(DataFlow.Render, Role.Multimedia);

        var sessionManager = defaultDevice.AudioSessionManager;
        var sessions = sessionManager.Sessions;

        for (int i = 0; i < sessions.Count; i++)
        {
            var session = sessions[i];

            uint processId = session.GetProcessID;
            if (processId == 0) continue;

            try
            {
                var process = Process.GetProcessById((int)processId);
                if (process.ProcessName.Equals(processName, StringComparison.OrdinalIgnoreCase))
                {
                    return session.AudioMeterInformation.MasterPeakValue > 0;
                }
            }
            catch
            {
                // Snapshot: activation of a process has failed or access to denied
                Console.WriteLine("Error accessing process info. (ex.Message)");
            }
        }

        return false; // The target process is not playing sound
    }
}

Our next task is to create an automation test which will check that our application makes some sound after some user actions.

Yes, it is a tricky goal, but let's think - if our application will play some WAV file it means that the application should open this WAV file. And it means that this WAV file should be locked. So you can create code that checks if the file is locked. 

using System;
using System.IO;

public static class FileUtil
{
    /// <summary>
    /// Checks if a file is locked or in use by another process.
    /// </summary>
    /// <param name="filePath">The full path to the file.</param>
    /// <returns>True if the file is locked, false otherwise.</returns>
    public static bool IsFileLocked(string filePath)
    {
        // Check if the file actually exists first
        if (!File.Exists(filePath))
        {
            // The file doesn't exist, so it's not locked.
            // You might want to handle this case differently based on your needs.
            return false;
        }

        FileStream stream = null;

        try
        {
            // Attempt to open the file with FileMode.Open and FileShare.None.
            // FileShare.None requests exclusive access to the file.
            stream = new FileStream(filePath, FileMode.Open, FileAccess.ReadWrite, FileShare.None);
        }
        catch (IOException)
        {
            // The file is unavailable because it is:
            // - still being written to
            // - or being processed by another thread
            // - or does not exist (if not checked before)
            return true;
        }
        catch (Exception)
        {
            // Handle other potential exceptions, but IOException is the key one for locks
            return true;
        }
        finally
        {
            // It's crucial to close the stream immediately so your application doesn't
            // lock the file itself after checking.
            stream?.Close();
            stream?.Dispose();
        }

        // If the stream was opened successfully and closed, the file is not locked.
        return false;
    }
}

This is not the best solution but in some cases, it can be very helpful.

8.2 Tools for Checking Exported Files

The next type of sound automation testing approach is: AUTOMATION TEST GENERATES USER ACTIONS, AND EXPECTED RESULT OF THESE ACTIONS - NEW EXPORTED SOUND FILE.

And our automation test should open the exported sound file and check some parameters. Also, QA can manually make some actions, export sound files and load it to an automation test which will check some parameters.

Main Secret Flow of Automation Testing for Export Sound Files:

  1. Import some simple test sound file manually to the application. Ideally it can be sound for 10 - 15 seconds. Imagine that name of this file will be Test1Di.WAV
  2. Manually apply some effects - distortion, reverb etc.
  3. Manually save it and export as new file with name Test1WithEffectExpectedResult.WAV
  4. Create automation test which will import file Test1Di.WAV, apply some effects, and export file Test1WithEffectActualResult.WAV
  5. Automation tests should compare that files Test1WithEffectExpectedResult.WAV and Test1WithEffectActualResult.WAV are equal. Calculate MD5 hash for both files. If they are equal - automation test is passed.
//It's very simple using System.Security.Cryptography.MD5:

using (var md5 = MD5.Create())
{
    using (var stream = File.OpenRead("Test1WithEffectExpectedResult.WAV"))
    {
        return md5.ComputeHash(stream);
    }
}
Automation Test Flow
Import test file → Make some actions → Export file and compare it with reference file by MD5 hash

9. Parameters to Check on Exported Files

9.1 Format of File

The export file should be in the same format as expected. Here is the list of commonly used sound file formats:

When to Use Which:

9.2 Metadata

Information that's contained in the metadata of an audio file can include:

If you want to check these parameters by automation tests use the ATL library: https://github.com/Zeugma440/atldotnet

This library is aimed at giving .NET developers a managed, portable and easy-to-use library to read and write metadata from digital audio files and playlists with one single unified API, whatever the underlying format.

10. Conclusion

In this article we discovered only basic cases of software audio testing. This is an infinite way, but I really hope that advice and information described in this article will be helpful.

Manual and automation testing of sound features activity requires us to be a programmer, tester, and sound engineer at the same time. We must be able to integrate engineering and creative skills.

If you are QA Lead and making a new team for sound testing: When interviewing candidates - do not care much about QA Skills and testing theory. Hire real musicians, real sound engineers, people who have passion for song writing and sound producing. Life has proven that this is more effective.

If you are making a bug for a sound feature: Sometimes it is hard to prove that it is a bug. To solve this problem, find the similar software solution which you test and add how it works in other products in the bug description.

Code is poetry. Sound heals the soul. Keep the flame alive!


Viktor Losiev

Software Developer in Test

  • Education: Kyiv Polytechnic Institute
  • Favorite language: C#
  • Experience: 13+ years in IT
  • Companies: GlobalLogic, SoftServe, 3Shape, Ciklum, Outbrain, AMFG, Capgemini
  • Speaker: Selenium Camp
LinkedIn · viktorlosiev@capgemini.com