Chapter 4: Test desktop application

Testing desktop applications is a crucial phase in software development that ensures the product meets user expectations and performs reliably in real-world environments. In Kenya, where software solutions often support critical sectors such as healthcare, banking, and education, thorough testing safeguards against costly failures and enhances user satisfaction. This chapter explores how software developers can identify appropriate testing types and prepare effective test plans tailored to project requirements and organizational standards.

4.1 Identifying Testing Types

A desktop application can fail in many different ways: a calculation can be wrong, a screen can confuse its users, a private record can be exposed, or the program can run too slowly on an older computer. No single test finds all of these faults, so testing is divided into types, and each type targets one quality of the application, such as correct functions, security or ease of use. Identifying the testing types correctly, and then choosing the ones that match the users' needs and the project's risks, is the foundation of delivering a dependable product. The code examples in this topic use C# with the NUnit testing framework.

4.1.1 Testing types

Testing types can be told apart in two ways. Some differ in scope, from one small piece of code up to the whole application, and others differ in the quality they check, such as security or speed. Functional tests ask whether the application does what it is supposed to do, while non-functional tests ask how well it does it.

Acceptance testing

Acceptance testing is carried out by the end users or the client to confirm that the system meets their needs before it is handed over. Example: before accepting a booking program, a small hotel's reception staff run through their own real situations, such as a walk-in guest, a booking change and a late check-out, and sign off only when every situation works. It differs from system testing because the people judging the result are the ones who will use the application every day.

4.1.1.1 Unit test

A unit test checks the smallest testable part of the application, normally a single method, on its own, apart from the form, the database and the other classes. Because each unit is checked separately, a failing test points straight to the code that is wrong. Developers write unit tests as they write the code, and a testing framework such as NUnit, xUnit or MSTest runs all of them in seconds.

Good unit tests have these qualities:

• Fast: hundreds of them run in seconds, so developers run them after every change.
• Isolated: a test does not depend on a database, a file or another test, so it gives the same result every time.
• Self-checking: the test itself states the expected result and reports pass or fail, so no one has to read output.
• Clearly named: the name says the method, the situation and the expected result, so a failure explains itself.
• Covering more than the normal case: each method gets a typical input, a boundary input such as exact payment, and an invalid input that should be refused.

Example: a kiosk till program has a method that works out the change due. The method refuses a payment that is smaller than the amount due.

using System;

public class TillCalculator
{
    public decimal ChangeDue(decimal amountDue, decimal amountPaid)
    {
        if (amountPaid < amountDue)
        {
            throw new ArgumentException("Amount paid is less than the amount due.");
        }
        return amountPaid - amountDue;
    }
}

The three tests below cover a typical case, a boundary case and an invalid case:

using System;
using NUnit.Framework;

[TestFixture]
public class TillCalculatorTests
{
    [Test]
    public void ChangeDue_PaidMoreThanDue_ReturnsDifference()
    {
        var till = new TillCalculator();
        decimal change = till.ChangeDue(1000m, 1500m);
        Assert.That(change, Is.EqualTo(500m));
    }

    [Test]
    public void ChangeDue_PaidExactAmount_ReturnsZero()
    {
        var till = new TillCalculator();
        Assert.That(till.ChangeDue(750m, 750m), Is.EqualTo(0m));
    }

    [Test]
    public void ChangeDue_PaidLessThanDue_ThrowsException()
    {
        var till = new TillCalculator();
        Assert.Throws<ArgumentException>(() => till.ChangeDue(1000m, 800m));
    }
}

The first test expects 1500 − 1000 = 500, the second expects 750 − 750 = 0, and the third expects the exception, because 800 is less than 1000.

4.1.1.2 Integration test

An integration test checks that separate parts of the application work correctly together. Parts that each pass their unit tests can still fail when joined, for example because one part sends a date in a different format from the one the other expects. Integration tests therefore concentrate on the connection points, such as the form passing data to the business logic, the business logic saving to the database, and the application calling an outside service.

Faults that integration tests typically find:

• Data type mismatches: a number sent as text, or a decimal cut to a whole number.
• Wrong names or structures: a program looking for a column that is named differently in the database.
• Format differences: dates, currency and decimal separators written differently by two parts.
• Missing values: a part that does not expect an empty field from another part.
• Wrong order of calls: a part used before another part has prepared what it needs.

The parts can be combined in different ways. Big-bang integration joins everything at once, which is quick but makes a failure hard to trace. Top-down integration starts with the main screens and replaces missing lower parts with stubs, which are simple stand-ins. Bottom-up integration starts with the lowest parts, such as data access, and uses drivers, which are small programs that call them, until the screens are added. Joining parts step by step finds the faulty connection faster.

Example: a parcel desk program is tested by registering a parcel through the service class and reading it back from a separate test database, never the live one.

using NUnit.Framework;

[TestFixture]
public class ParcelIntegrationTests
{
    private readonly string testDatabasePath = "parcels_test.db";

    [Test]
    public void RegisteredParcel_CanBeReadBack()
    {
        var repository = new ParcelRepository(testDatabasePath);
        var service = new ParcelService(repository);

        service.Register("PK-0001", "Depot 2");
        Parcel found = repository.Find("PK-0001");

        Assert.That(found, Is.Not.Null);
        Assert.That(found.Destination, Is.EqualTo("Depot 2"));
    }
}

ParcelRepository, ParcelService and Parcel are the program's own classes, and the test passes only when both classes agree on how a parcel is saved and read.

4.1.1.3 Usability test

A usability test checks how easily real users can learn and use the application to do their work. A program can be correct in every calculation and still be slow to use or confusing, so this test puts representative users in front of the application and watches them. The test measures the experience of the user and not the correctness of the code.

A usability test is carried out in these steps:

1. Choose users who resemble the real ones, such as the receptionists who will use the program, and not the developers.
2. Write a short list of realistic tasks, such as booking an appointment, moving it to another time and cancelling it.
3. Ask each user to do the tasks without help, and ask them to say aloud what they are thinking.
4. Observe and record where users hesitate, make mistakes, click the wrong control or ask for help.
5. Measure how many tasks were completed, how long each took and how many errors were made.
6. Ask the users to rate the application, for example on a scale of 1 to 5, and to say what they liked and disliked.
7. List the problems found, rank them by how much they slow the user, and pass them to the developers.

Things the test looks at include clear labels on controls, a sensible tab order, error messages that tell the user what to do, consistent layout from screen to screen, and whether the work can be done from the keyboard as well as the mouse. Feedback on early sketches and prototypes is covered under User testing and feedback incorporation, while this test is run on the working application.

4.1.1.4 System testing

System testing checks the complete, integrated application against the requirements it was built to meet. It is run in a test environment that matches the real one as closely as possible, and it follows whole business processes from start to finish. It starts only when the unit and integration tests have passed and the build is stable.

Example: for a hotel front-desk program the system test follows one guest from start to finish: create a booking, check the guest in, add a meal charge, check the guest out, print the invoice and see the stay in the daily report. Each test case is linked to a numbered requirement, so the team can show that every requirement has been tested.

System testing covers:

• Functional scenarios: every function works as the requirements state, in the order a user would use it.
• Data flow between screens: what is entered on one screen appears correctly on the others and in the reports.
• Error handling: wrong input and failures produce clear messages and do not crash the application.
• Installation and start-up: the application installs and starts on a clean test computer.
• Non-functional requirements: security, performance and compatibility are checked with their own tests.

Defects found are logged with the steps that cause them, fixed by the developers and then tested again.

4.1.1.5 Security test

A security test checks that the application protects its data and allows only authorised people to use it. Applications that keep personal or money records must be able to resist careless use and deliberate attack, and the Data Protection Act, 2019 expects personal data to be protected. A security test tries to break the protections before an attacker does.

Areas covered by a security test:

• Authentication: only a user with a correct username and password can log in, and repeated wrong passwords are handled safely.
• Authorisation: each user can reach only the screens and records their role allows, so a counter clerk cannot open the owner's salary report.
• Input validation: the application refuses or safely handles input crafted to attack it, such as text that tries to change a database query.
• Data protection: passwords are stored as salted hashes and never as plain text, and sensitive files and backups are protected.
• Audit trail: important actions such as deleting a record or changing a price are logged with the user and the time.
• Error messages: messages shown to the user do not reveal passwords, file paths or database details.

Example: a payroll program for a workshop is tested by typing ' OR '1'='1 into the username box. A well-built program treats it as an ordinary, unknown name and refuses the login. This is because the query uses parameters and does not join the typed text into the query string:

using var command = connection.CreateCommand();
command.CommandText = "SELECT Id, PasswordHash FROM Users WHERE Username = $username";
command.Parameters.AddWithValue("$username", txtUsername.Text);
// never build the query by joining text: "... WHERE Username = '" + txtUsername.Text + "'"

Here connection is an open SQLite connection and txtUsername is the username text box on the login form. The program then compares the hash of the entered password with the stored PasswordHash.

4.1.1.6 Performance test

A performance test measures how fast the application responds and how much of the computer's resources it uses under different workloads. An application that is correct but takes a minute to open a list will not be used. The speed that counts is agreed with the client in the requirements, for example that a stock list opens within a stated number of seconds on the shop's computer.

What a performance test measures:

• Response time: how long an action takes, such as opening a form or saving a record.
• Start-up time: how long the application takes to become ready after it is launched.
• Throughput: how much work is done in a period, such as how many invoices are printed in a minute.
• Resource use: the share of processor and memory the application takes, measured with tools such as the Visual Studio Diagnostic Tools or the Windows Task Manager.

Performance tests are run in several forms. A load test uses the normal expected amount of data or users, a stress test pushes the application beyond that to see where and how it fails, and an endurance test keeps the application running for a long time to find memory that is slowly used up and never released.

Example: a hardware shop's stock program is tested with a stock table filled with a large number of test records. The time to load the list is measured by code:

var timer = System.Diagnostics.Stopwatch.StartNew();
LoadStockList();
timer.Stop();
System.Diagnostics.Debug.WriteLine($"Stock list loaded in {timer.ElapsedMilliseconds} ms");

The result is compared with the target in the requirements. The test is repeated on the slowest computer the client uses, because a result from a fast developer machine does not show what the user will experience.

4.1.1.7 Compatibility test

A compatibility test checks that the application works correctly in the different environments in which users may run it. The developer's own computer is only one of these, and a program that works there can fail on another computer with a different setup. The environments are listed in the requirements and each one is tested.

What a compatibility test checks:

• Operating system versions: the application installs and runs on each Windows version that the client uses.
• Runtime and architecture: the required .NET runtime is present or included with the application, and the 32-bit or 64-bit build matches the computer.
• Screen size and display scaling: controls are not cut off or overlapping on small screens or when the Windows display scale is raised above 100 percent.
• Regional settings: numbers, dates and currency display correctly when the computer uses a different decimal separator or date format.
• Printers and paper sizes: reports print correctly, for example on A4 paper and on the receipt printer the shop uses.
• Other software: the application works alongside antivirus programs, PDF readers and the spreadsheet program it exports to.
• Hardware limits: the application runs on the least powerful computer the client expects to use, with limited memory and storage.

Example: a tailoring workshop still uses two older computers, so the order program is installed on those two computers and on the newest office computer, and the same set of order, print and report tasks is repeated on each.

4.1.2 Selecting appropriate testing types based on user requirements

No project has time to run every possible test at full depth, so the developer chooses testing types that match what the users need and what could go wrong. The user requirements show which qualities matter most, and the risks of the project show how deep each test must go. Detailed planning of the chosen tests is done later under Preparing Test Plan.

Factors influencing testing selection

• Criticality of application functions: a function whose failure would cost money or stop work, such as billing, needs thorough system and acceptance testing, while a rarely used screen needs less.
• User environment: the computers the users actually have, such as several Windows versions or older hardware, decide how much compatibility and performance testing is needed.
• Security requirements: applications that handle money, personal records or passwords must give priority to security testing.
• Budget and time constraints: a small firm with limited time may put its effort into high-impact tests, such as unit tests on calculations and usability tests on the main screens.
• Regulatory compliance: where a business must follow rules that apply to its records, such as tax invoicing rules, the application must be tested against what those rules require.

Steps for selecting testing types

1. List the user requirements and mark each one as functional or non-functional.
2. Rate the risk of each requirement by asking how likely it is to fail and how serious the harm would be.
3. Match each requirement to the testing type that can show whether it is met, for example a payment calculation to unit tests and a login screen to security tests.
4. Add the types that every application needs, which are unit tests for the code and system testing for the whole.
5. Decide how deep each type must go, with more depth for high-risk requirements.
6. Check the choice against the available time, budget, people and test computers, and drop or reduce the lowest-risk tests if necessary.
7. Record the choice and the reasons so that the client and the team can review it.

Example for a courier desk parcel-tracking program:

Chapter Summary

This chapter explores the comprehensive process of testing desktop applications, beginning with the identification of various testing types such as unit, integration, usability, system, security, performance, and compatibility tests. It emphasizes the importance of selecting appropriate testing types based on specific user requirements to ensure the application meets its intended purpose. The preparation of a detailed test plan is covered next, highlighting key components including objectives, scope, and resources, alongside best practices for aligning the plan with organizational work procedures. The chapter then discusses methods for executing tests, comparing manual and automated approaches, and the necessity of tracking progress and issues throughout the testing phase. Finally, it addresses the preparation of a test report, outlining essential elements such as findings and recommendations, and stresses best practices for accurate and professional documentation of results in accordance with work procedures. Together, these topics provide a structured framework for effective desktop application testing.