A property card can look complete while sending someone to the wrong map point. A field may be populated but mapped to the wrong filter. A photo can belong to a previous version of a listing. These are product failures, so review data quality in the finished screen as well as the incoming payload.
Use records the evaluation account is permitted to access. Save the query, source, property type, and review date so the same cases can be rerun after a mapping change.
Pick a sample that can reveal a mistake
Choose ordinary records and awkward ones: a condo with a unit number, land without bedrooms, a rental, a listing with a withheld address, a property represented by two sources, and a listing that changes status. Add a record with several photos and one whose media changes.
For each record, keep the source organization and its record key. An address is useful for people, but it is a poor database key: units share street addresses, and address text can be corrected. If two MLSs describe the same property, preserve both source records while deciding how the product will show them.
Check fields by feature
Write down the minimum fields for the screen. A map search needs a usable location; a rental filter needs rental fields; a public detail page needs the attribution required by its source. Read the feed’s metadata, then count how often real records contain a usable value. “Present” and “usable” are different measures: coordinates can be filled yet plot outside the market.
RESO’s Data Dictionary supplies standard resources, fields, and lookups and permits local fields. It does not require every organization to populate every field. Keep a source-specific mapping for local statuses and property types. Review examples before assigning an unfamiliar value to a national filter.
| Check | Failure to look for |
|---|---|
| Identity | One source key produces duplicate local records after a retry |
| Location | Valid-looking coordinates place a home outside the intended area |
| Status | A pending or withdrawn listing remains in a public active search |
| Media | Photos are missing, out of order, or attached to the wrong version |
| Search | A local property type vanishes from a filter |
| Display | Source or listing-firm attribution is hidden on a small screen |
AnyProp provides normalized address and geocoded location fields, along with anyprop_AddressFoundYN and anyprop_ExactGeocodeYN, in its API reference. A map application can use those flags to identify records that need closer review. Inspect a sample of the resulting pins and decide which accuracy levels the feature can accept; the reference explains how AnyProp defines an exact geocode.
Keep the source values and the AnyProp-derived values in your test report. For example, a corrected address may place a record differently from its original coordinates. Comparing both values helps establish which one the map actually used and whether the result fits the product.
Follow changes, including removals
In a provider sandbox or a local fixture, move a test record through the statuses the product supports. For a production feed, observe actual changes without editing live listings for a test. Compare the API payload, normalized record, search index, alerts, and page. If the record leaves the approved feed, verify how the source reports that change. RESO’s EntityEvent model describes one method; the actual provider may use another. Check that a removed record stops appearing in new alerts and that cached pages and photos are handled under the local rules.
Public display needs its own review. NAR’s IDX policy sets a framework; the MLS’s current rules and agreement supply the applicable details. Inspect listing-firm and source notices on cards, detail pages, and mobile layouts. A feed containing a field or photo does not by itself settle where it may be displayed.
Keep the cases as regression tests
Automate counts of missing required fields, unmapped statuses, invalid locations, media failures, and records left in a public index after removal. Investigate sharp changes by source before setting a global threshold. Keep a few manually reviewed payload-to-screen examples as fixtures; they catch errors that a field-presence check cannot.
A useful report names the market and feature, the failing records, the owner, and the release decision. Attach the failing payload and a screenshot so the next reviewer can reproduce the problem.
