How to test a desktop application
Direct answer
Shipped untested, a desktop application's update secretly installs a background component that bypasses a browser safeguard, and its installer leaves a local web server that any web page can call on the machine after the app is deleted. 9 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with penetration testing: a hostile web page reaching the app through a local port or URL handler is where both the hidden helper and the data exposure show.
9 mandatory testsfirst: penetration testing
What counts as a desktop application
A desktop application here is a native or Electron app installed on macOS, Windows or Linux through a signed installer or a desktop store, with its own updater and uninstaller. It counts when the app registers URL handlers or local services, auto-updates, or touches user folders during install, update or repair. A web app opened in a browser tab is out of scope, and so is a command-line tool installed from a package registry.
Adjacent product types not covered here
- SDK or client library: An SDK runs inside other developers' apps and fails their builds or launches, while a desktop application installs its own helpers and folders on the user's machine.
- smart home or IoT app: A smart home or IoT app controls devices from a phone, so cloud outages and camera account takeover lead instead of local ports and updater deletions.
- video conferencing tool: A video conferencing tool shares the hidden local helper risk in its desktop client, and adds meeting intruders, recordings and live captions.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | An app update secretly installs a background component that bypasses a browser safeguard, and the regulator cites it in an order. | |
| Personal or sensitive data exposed data-breach | data | primary | The installer adds a local web server or helper that any web page can call, and it stays on the machine after the app is deleted. | |
| Records silently wrong data-corruption | data | primary | The updater or launcher script deletes a folder it thinks it owns, and the user Documents or home folder goes with it. | |
| App rejected or removed by a store store-rejection | distribution | secondary by design analysis | An unnotarized macOS build, or a Windows package that fails Microsoft Store certification, opens with a Gatekeeper warning or never reaches the store. |
Mandatory tests (9)
Step 1: release smoke tests
Why:store-rejectiondata-breach
Done when: The signed installer opens on clean macOS and Windows machines with no Gatekeeper or SmartScreen warning, and lists the same files and services as the previous release plus documented changes.
Tool class: device cloud. Who usually runs it: QA engineer.
Step 2: penetration testing
Why:data-breachregulatory-penalty
Done when: A hostile web page opened in each supported browser cannot launch the app, join a session or read app data through a local port or URL handler.
Tool class: proxy. Who usually runs it: security specialist.
Step 3: compliance checks
Why:store-rejectionregulatory-penalty
Done when: Each build passes notarization and Microsoft Store certification, and release notes name every helper, service or login item the update installs.
Tool class: test management. Who usually runs it: product manager.
Step 4: end-to-end functional tests
Why:data-corruptiondata-breach
Done when: After install, update and uninstall on a test machine with redirected Documents and a moved data folder, every user file is still present and no helper remains.
Tool class: device cloud. Who usually runs it: QA engineer.
Step 5: regression suite
Why:data-corruptiondata-breach
Done when: Install, update, uninstall and local-port cases rerun before each release, and any new listening port or deleted user file blocks it.
Tool class: test management. Who usually runs it: QA engineer.
Step 6: device and browser compatibility
Why:store-rejectiondata-corruption
Done when: Install, update and uninstall cases pass with no Gatekeeper or SmartScreen warning on each supported macOS, Windows and Linux version and on both Intel and Arm machines where offered.
Tool class: device cloud. Who usually runs it: QA engineer.
Step 7: unit tests
Why:data-corruption
Done when: In the test report, the cleanup and repair code refuses to delete the home folder, the root folder, an empty path or any folder the app did not create.
Tool class: unit framework. Who usually runs it: developer.
Step 8: security scanning
Why:data-breach
Done when: A port and process scan of a test machine after install shows no listening service beyond those in the docs, and the bundled runtime has no known critical advisory.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 9: data integrity and migration testing
Why:data-corruption
Done when: A test profile with known files keeps the same file list and contents before and after each update, including files saved in redirected folders.
Tool class: data validation. Who usually runs it: QA engineer.
Recommended and optional tests
accessibility testingrecommended
Becomes mandatory when sold to public sector teams or accessibility complaint evidence is attached.
resilience and failure testingrecommended
Becomes mandatory when an interrupted-update incident is attached with verified evidence.
offline and poor-network testingrecommended
Becomes mandatory when lost-actions evidence is attached for the app sync.
exploratory testingoptional
Optional: finds machine states scripted cases miss.
performance and load testingoptional
Optional: helps when reviews cite slow start-up.
Not needed and why
Not needed: no attached risk comes from a third-party service. Becomes recommended when the app syncs with an outside service.
Not needed: no attached risk comes from users misreading screens. Becomes recommended when support tickets cite confusing settings.
Not needed: assumes one interface language. Becomes recommended when a second language ships.
analytics and event tracking tests
Not needed: no attached risk depends on event accuracy. Becomes recommended when usage events drive licence counts.
Order of work
First release
- release smoke tests: Open the signed installer on clean macOS and Windows machines, confirm no Gatekeeper or SmartScreen warning, and compare installed files and services with the previous release plus documented changes.
- penetration testing: Open a hostile web page in each supported browser and try to launch the app, join a session or read app data through a local port or URL handler.
- compliance checks: Pass notarization and Microsoft Store certification for the build, and check the release notes name every helper, service or login item the update installs.
- end-to-end functional tests: Install, update and uninstall on a test machine with redirected Documents and a moved data folder, then confirm every user file is present and no helper remains.
- regression suite: Rerun the install, update, uninstall and local-port cases and block the release on any new listening port or deleted user file.
- device and browser compatibility: Run the install, update and uninstall cases on each supported macOS, Windows and Linux version and on Intel and Arm machines where offered, and confirm no Gatekeeper or SmartScreen warning appears on any of them.
- unit tests: Run the unit suite on the cleanup and repair code and confirm in the test report that it refuses to delete the home folder, the root folder, an empty path or any folder the app did not create.
- security scanning: Scan ports and processes on a test machine after install, compare listening services with the docs, and check the bundled runtime for known critical advisories.
- data integrity and migration testing: Update a test profile with known files, including files in redirected folders, and compare the file list and contents before and after.
Ongoing cadence
- release smoke tests: On every signed installer build.
- compliance checks: Before each notarization and Microsoft Store submission.
- regression suite: Before each auto-update release.
- device and browser compatibility: When a new macOS, Windows or Linux version is published.
- security scanning: When the bundled runtime publishes a security advisory and after each change to helpers or URL handlers.
- unit tests: After each change to code that deletes or moves folders.
- resilience and failure testing: When an interrupted-update incident is attached with verified evidence.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of desktop application (desktop). Not recommendations.
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for desktop application has the same 9 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the desktop application is accepted when the signed installer opens on clean macOS and Windows machines with no Gatekeeper or SmartScreen warning and passes notarization and Microsoft Store certification, with every installed helper named in the release notes. After install, update and uninstall with redirected Documents, every user file is still present, no helper remains and no listening service exists beyond those in the docs.
Brief
# Test brief: desktop application Product type: desktop application. A native or Electron app installed on macOS, Windows or Linux. Risk map and evidence: https://howtotestaproduct.com/how-to-test/desktop-app/ Printable checklist: https://howtotestaproduct.com/checklists/desktop-app/ Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: store-rejection, data-breach). Tool class: device cloud. Usually run by: QA engineer. Done when: The signed installer opens on clean macOS and Windows machines with no Gatekeeper or SmartScreen warning, and lists the same files and services as the previous release plus documented changes. 2. penetration testing (risks: data-breach, regulatory-penalty). Tool class: proxy. Usually run by: security specialist. Done when: A hostile web page opened in each supported browser cannot launch the app, join a session or read app data through a local port or URL handler. 3. compliance checks (risks: store-rejection, regulatory-penalty). Tool class: test management. Usually run by: product manager. Done when: Each build passes notarization and Microsoft Store certification, and release notes name every helper, service or login item the update installs. 4. end-to-end functional tests (risks: data-corruption, data-breach). Tool class: device cloud. Usually run by: QA engineer. Done when: After install, update and uninstall on a test machine with redirected Documents and a moved data folder, every user file is still present and no helper remains. 5. regression suite (risks: data-corruption, data-breach). Tool class: test management. Usually run by: QA engineer. Done when: Install, update, uninstall and local-port cases rerun before each release, and any new listening port or deleted user file blocks it. 6. device and browser compatibility (risks: store-rejection, data-corruption). Tool class: device cloud. Usually run by: QA engineer. Done when: Install, update and uninstall cases pass with no Gatekeeper or SmartScreen warning on each supported macOS, Windows and Linux version and on both Intel and Arm machines where offered. 7. unit tests (risks: data-corruption). Tool class: unit framework. Usually run by: developer. Done when: In the test report, the cleanup and repair code refuses to delete the home folder, the root folder, an empty path or any folder the app did not create. 8. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: A port and process scan of a test machine after install shows no listening service beyond those in the docs, and the bundled runtime has no known critical advisory. 9. data integrity and migration testing (risks: data-corruption). Tool class: data validation. Usually run by: QA engineer. Done when: A test profile with known files keeps the same file list and contents before and after each update, including files saved in redirected folders. Acceptance criteria wording: A release of the desktop application is accepted when the signed installer opens on clean macOS and Windows machines with no Gatekeeper or SmartScreen warning and passes notarization and Microsoft Store certification, with every installed helper named in the release notes. After install, update and uninstall with redirected Documents, every user file is still present, no helper remains and no listening service exists beyond those in the docs. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing a desktop application
What testing does a desktop application need?
9 tests are mandatory, starting with a signed installer smoke run on clean machines and penetration testing of local ports and URL handlers. Each is tied to one of the 4 risks in the map: a hidden helper that bypasses a browser safeguard, a local web server that stays after deletion, an updater that deletes user folders, and builds blocked by notarization or store certification. Accessibility, resilience and offline tests are recommended, each with the event that makes it mandatory.
What gets a desktop application rejected by an app store?
The map marks store rejection as a by design analysis risk: an unnotarized macOS build opens with a Gatekeeper warning, and a Windows package that fails Microsoft Store certification never reaches the store. Compliance checks pass notarization and certification on each build, and compatibility runs install, update and uninstall on each supported OS version.
What is the minimum testing for a desktop application at MVP stage?
The minimum is the 9 mandatory tests once the app ships as an installer, registers a URL handler or local service, and has an updater that touches user folders. Exploratory and performance testing are optional, and integration, usability, localization and analytics tests that vendors often add are not needed until the conditions on the page change.
Which tests in a vendor test plan for a desktop application are not needed?
Integration tests are not needed while no attached risk comes from a third-party service, until the app syncs with an outside service. Usability testing is not needed until support tickets cite confusing settings. Analytics tests are not needed until usage events drive licence counts.
When is test automation worth it for a desktop application?
Automation pays for the install, update, uninstall and local-port cases that rerun before each release on every supported OS version, and for the unit tests on folder-deleting path functions. The hostile web page run is done by a security specialist, and release notes are checked by a product manager.
Evidence
ev-0221regulatorprimary
FTC Requires Zoom to Enhance its Security Practices as Part of Settlement, Federal Trade Commission
The FTC also alleged that the company compromised the security of some users when it secretly installed software, called a ZoomOpener web server, as part of a manual update for its Mac desktop application in July 2018.
Regulator order: a Mac desktop app update installed a hidden local web server that bypassed a browser safeguard, stayed after the app was deleted and could reinstall it. The order also states the company advertised end-to-end encryption it did not provide and said cloud recordings were encrypted when some were stored unencrypted on its servers before transfer. Supports regulatory-penalty and data-breach for desktop applications and video conferencing tools.
published 2020-11-09 · verified 2026-10-07
ev-0222post-mortemprimary
Response to Video-On Concern, Zoom
Official company response: the vendor removed the local web server from its Mac client and added a full uninstall option after a researcher raised security concerns about the Mac client. Supports data-breach for desktop applications that open local ports.
published 2019-07-08 · verified 2026-10-07
ev-0223post-mortemprimary
Updated version of Windows 10 October 2018 Update released to Windows Insiders, Microsoft
This occurred if Known Folder Redirection (KFR) had been previously enabled, but files remain in the original “old” folder location vs being moved to the new, redirected location.
Official post-mortem: an installed update removed user files left in the original Desktop and Documents folders after the folders had been redirected. Transfers to desktop applications whose installers or updaters clean up user folders.
published 2018-10-09 · verified 2026-10-07
ev-0224practitionerpractitioner
Moved ~/.local/share/steam. Ran steam. It deleted everything on system owned by user., GitHub (steam-for-linux issue tracker)
Until I looked and saw that steam had apparently deleted everything owned by my user recursively from the root directory.
Named user report: the launcher script of a desktop application deleted all files owned by the user after its data folder was moved. Supports data-corruption for desktop applications with self-repair or uninstall scripts.
published 2015-01-14 · verified 2026-10-07
ev-0008store-guidelineprimary
Microsoft Store Policies, Microsoft
Apps submitted to the Microsoft Store are certified against these policies, including stability and functionality requirements.
published undated · verified 2026-10-07
ev-0009store-guidelineprimary
Notarizing macOS software before distribution, Apple
Apple requires Developer ID software distributed outside the Mac App Store to be notarized; Gatekeeper blocks software that is not.
published undated · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.