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.
- Install the latest state in the
devbranch 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
- 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.
- Create a backup
- Restore a backup
- Delete a backup
- Delete a profile
- Change mode of an existing profile
- Regular cron jobs (e.g., every 5 minutes)
- Repeatedly schedules (anacron-like execution)
- USB-triggered backups via udev (when a drive is connected)
- 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.
- 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.