Capture
A capture provides a blueprint as well as a record of calls an application made and the files they returned. Analyzing them together gives the best view of your application.
A modern application does not load everything all at once. Panels load as you scroll, a feed keeps fetching as you reach the bottom, and payment and fraud services only run when the user decides to check out. A capture that never scrolls and never clicks never sees those suppliers.
What loads also depends on the person loading the application. Sites serve different code, different trackers and different third-party libraries depending on the device, the location and the browser. A recording is a single snapshot of the session.
The blueprint is the other half. A capture stores the documents, scripts and stylesheets that were delivered, not merely the fact that they were called, so what is written inside them can be read whether or not anything ever called it. A backup server, a staging environment, an endpoint left behind by a vendor: none of that is traffic, and all of it is in the capture.
Generate a HAR file or use one that has been provided to you. Every major browser can save a session recording with the developer tools option. This does not require an account and is done outside of the application.
One capture provides a great deal of information about an application. But to see what changes over time requires multiple captures, all working from the baseline capture. Analysis and insight into changes are not only about what is new. They also highlight missing services and integrations, changes to third-party partnerships, and a multitude of valuable insights.
Where performing the session yourself is not practical, schedule and automate instead. Give SCVue a capture plan, one or more device profiles and a set of locations, and it runs the full matrix. Three device profiles across four countries is twelve sessions from one request.
What a capture catches, and whether a difference between two of them is the application changing rather than the method, comes down to a handful of decisions made before it runs.
A capture plan is a reusable script of a browser session: a starting address, then an ordered list of clicks, text entry, scrolling, waits and finding text on the page. Each step waits before it acts and pauses after, so pages have time to finish loading.
A device profile sets what the capture looks like, defined by an exact identification string or by operating system, browser, device type and screen size, with the resulting identification always shown. Locations set where the session browses from, so a site can be measured from Frankfurt, Tokyo and São Paulo at once.
Every collection records the circumstances it was taken under: country and city, connection type, device and browser.
The same journey, the same steps, the same device, every time, so a difference between two captures is a difference in the site rather than a difference in how it was browsed.
The same plan, profiles and locations can be scheduled to run again on a recurrence rather than requested each time. That is the point where capture stops being a single assessment and becomes monitoring.
Capture a session in the browser, import it, and read what comes back. A free community account is available immediately.