When people hear the word testing, they often think about programmers finding bugs after software has been written.

In reality, testing begins much earlier.

Every activity you’ve completed throughout this textbook has involved testing.

When you interview users, you’re testing your understanding of the problem.

When you review requirements, you’re testing whether they are complete and unambiguous.

When you build paper prototypes and wireframes, you’re testing your proposed solution.

Even class diagrams and sequence diagrams are forms of testing because they help reveal missing information and incorrect assumptions before implementation begins.

Testing is not a single activity that happens at the end of a project.

It is a mindset that guides the entire design process.

Why Test Early?

Problems become more expensive to fix as a project progresses.

Changing a sketch on paper takes only a few seconds.

Changing a wireframe might take a few minutes.

Changing production software after it has been released can take days or even weeks.

Testing throughout the design process allows teams to discover problems while they are still inexpensive to correct.

More importantly, it helps ensure that the software being built actually solves the problem it was intended to solve.

What Are We Testing?

Software design is about much more than determining whether a program works.

Throughout a project, we continually ask questions such as:

• Do the requirements accurately describe the problem?
• Can users complete the tasks they need to perform?
• Does the workflow make sense?
• Are important situations missing?
• Does the interface communicate clearly?
• Will the system behave predictably when something goes wrong?

These questions help validate both the design and the assumptions that guided it.

Good Design Prevents Errors

One of the goals of software design is not simply to handle errors – it is to prevent them from occurring whenever possible.

Good interfaces help users enter correct information naturally.

For example:

• date pickers reduce formatting errors,
• drop-down lists prevent invalid selections,
• check boxes limit inappropriate responses,
• input validation identifies problems before forms are submitted.

Designing interfaces that prevent mistakes often creates a much better user experience than relying on error messages after something has already gone wrong.

Designing for Failure

No software system is perfect.

Network connections fail.

Servers become unavailable.

Users make mistakes.

Unexpected situations will occur.

Good software anticipates these situations and responds appropriately.

When designing a system, ask questions such as:

• What happens if the user enters incorrect information?
• What happens if the database cannot be reached?
• What happens if the Internet connection is interrupted?
• What happens if a required service is unavailable?

A well-designed system should remain stable even when something unexpected happens.

Helping Users Recover

Errors should never leave users feeling confused or helpless.

Whenever possible, systems should:

• explain what went wrong,
• describe how the problem can be corrected,
• preserve any work the user has already completed, and
• allow the user to continue without unnecessary frustration.

Messages such as:

“Something went wrong.”

rarely help anyone.

Instead, provide information that users can act upon.

For example:

“Please enter a valid email address.”

or

“Your Internet connection was interrupted. Your work has been saved. Please try again.”

Thoughtful feedback improves both usability and trust.

Validating Your Designs

Throughout CIS3750, you’ve already learned several ways to evaluate your designs before implementation.

These include:

• discussing requirements with your community partner,
• reviewing requirements for clarity and consistency,
• developing use cases,
• conducting paper prototyping sessions,
• refining wireframes based on feedback,
• reviewing class diagrams,
• evaluating sequence diagrams.

Each activity provides another opportunity to identify problems before writing code.

Collectively, these design activities are among the most valuable forms of testing performed during a software project.

A Continuous Process

Testing does not end when implementation begins.

As software evolves, new ideas emerge, requirements change, and users discover situations that were never anticipated during design.

Successful software teams therefore treat testing as a continuous activity rather than a single phase of development.

Every conversation, prototype, review, and user interaction provides another opportunity to improve the system.

Looking Ahead

Good software is not created by avoiding mistakes.

It is created by identifying mistakes early, learning from them, and continuously improving the design.

The activities you’ve encountered throughout this textbook – from requirements gathering to prototyping and UML modelling – are all part of that ongoing process of testing, learning, and refinement.