SignalShip guide
Your first exploration.
A practical path from a registered Android build to the Product Graph and the journeys behind it. Keep this guide beside the desktop app as you get started.
1. Get the desktop app
Visit Downloads for the approved installer and its release information. Availability is shown on that page; do not use an installer from an unverified source.
Open SignalShip and sign in with your SignalShip email and password. Account creation, where enabled, uses the same identity service as the desktop.
2. Prepare your application
- Select or create a workspace. This is the scope for your applications and team access.
- Open Applications and register your Android app.
- Attach the build you want to explore. Verify its package and version information.
- Add the application credentials and supporting product documents needed for the intended exploration.
Application credentials are for the application being explored. They are separate from your SignalShip sign-in. Use appropriate test accounts and test data.
3. Connect a supported device
Open Devices in the desktop and follow the device-host setup and sharing controls. Connect your Android device and check that its host is online and the device is available.
Device availability and application readiness are different checks. If the application needs initialization, complete that step before exploration. Respond to any requested login verification when it appears.
4. Start Run Explorer
- Choose the application build and an eligible device.
- Review the current readiness information.
- Start exploration and follow the queued, starting, and running states.
- Respond when a human-input request appears. Requests can have deadlines.
- Wait for a terminal result, then open the resulting graph or flows.
If you request a stop, the system needs the runner to acknowledge it. Keep the run context open until its final status is available.
5. Read the product intelligence
Begin with the Product Graph
Start at the application landscape. Open a group to inspect its screen states, connections, and associated flows. Use the complete network when your question is about the wider topology.
Follow a journey in Flow Intelligence
Select a flow and review its ordered actions. Compare the before-and-after captures, inspect the recorded target and outcome, and use the route map for structural context.
Return to captured evidence
Use Product Memory to revisit the available screen captures and compare two observations. A visual comparison helps investigation; it does not automatically establish a functional regression.
6. Organize validation
A flow is an observed journey. A test case describes a check. A playlist collects related cases, and a test plan groups playlists.
The Functional Test Plan is also known as L2 Default Plan. It is one default plan containing the automatic flow playlists, not two different plans.
Use Test Plans & Playlists to review and arrange the cases available from your server. Custom authoring, script generation, and execution require their corresponding server capabilities. The interface explains unavailable operations.
Flow scope describes observed screen groups associated with linked flows. It is different from executed test coverage or a passing release decision.
When something needs attention
No flows yet?
Confirm that the selected application has a completed exploration with recorded flow evidence. Check the current workspace and application before opening an older link.
Device unavailable?
Check the host connection, device availability, and sharing context in Devices. Return to Run Explorer after the device is ready.
Login or verification blocked?
Review the application's test credentials and pending input requests. Never put passwords or verification codes into a product discussion or screenshot.
A control is unavailable?
Read its explanation. Some workflows depend on a service or engine capability enabled by your server. Switching the desktop UI alone does not enable them.