Manual Testing Recommendations

June 5, 2026 · View on GitHub

Automatic tests cannot cover all scenarios or potential issues. Manual testing by real users ensures that Back In Time behaves as expected. It provides insight, intuition, and real-world validation.

From experience, manual testing of Back In Time is extremely valuable, essential, and absolutely necessary. Every real-world scenario, edge case, and subtle interaction (especially in diverse GNU/Linux environments) becomes visible only when a human actually runs the application. No automated script, no matter how thorough, can fully capture these nuances.

Manual testing is therefore irreplaceable: it uncovers hidden bugs, UI quirks, and workflow issues that only emerge under authentic user conditions. Every bit of feedback from hands-on testing directly improves reliability, usability, and user confidence.

The following recommendations help guide testing, but experienced users may naturally explore relevant workflows without strict instructions.

Table of contents

1. Setup

  • Install the latest state in the dev branch of the git repository. If this test is about a Release Candidate use the available source tarball. Consider the install instructions and dependencies.
  • Use a fresh virtual machine or clean system without a previous Back In Time installation. If you test on your productive machine, the minimal recommendation is using the --config= option to separate the test configuration from the regular one.
  • Test on different GNU/Linux distributions:
    • Major lines: Debian, Arch Linux (or derivatives)
    • Non-systemd distro: Devuan GNU/Linux

2. General Testing Guidelines

  • Always start from the terminal to catch silent errors or warnings.
  • Create backup profiles in all available flavors:
    • Local
    • SSH
      • different types of keys or just no key-file (systems SSH config)
      • keys with and without passphrase
      • cached password or password in keyring
      • Use an SSH proxy
    • With and without encryption
  • Consider testing Back In Time in its root-mode, too.
  • It would help the situation if you are a regular user of Back In Time.

3. Core Actions

  • Create a backup
  • Restore a backup
  • Delete a backup
  • Delete a profile
  • Change mode of an existing profile

4. Scheduling Tests

  • Regular cron jobs (e.g., every 5 minutes)
  • Repeatedly schedules (anacron-like execution)
  • USB-triggered backups via udev (when a drive is connected)

5. GUI Tests

  • Open all dialogs and interact with them; watch for crashes or display issues.
  • Try different desktop environments (e.g., MATE, Budgie).
  • Try Wayland-only systems.
  • Check GUI translations in your native language(s).
  • Test with qt6ct theme overrides.

6. Notes

  • Experienced users may naturally explore additional workflows beyond this list.
  • Any bugs, crashes, or unexpected behaviors should be reported in the project’s issues with logs, version info or diagnostics info (use --diagnostics) or screenshots if possible.