When Identical Contact Information Leads to the Wrong Address

In data-driven applications, matching attributes do not always guarantee that the correct record has been selected.

I encountered a case where a system used a contact's name and phone number to match an address with a record. Under normal conditions, this approach appeared to work as expected. However, the problem became apparent when two address records shared the same contact name and phone number but had different addresses.

For example, a customer might have two registered addresses: one for home and another for the office. Both addresses belong to the same contact, so the name and phone number are identical. However, each address represents a different destination.

This highlighted an important testing consideration: whether the system can distinguish between multiple addresses associated with the same contact and preserve the address the user actually selected.

As a QA, I believe checking the displayed values is not always enough. I also need to verify whether the system saves the exact address selected by the user, rather than another address that happens to share the same contact information.

Same Contact, Different Addresses

Address A
ID      : 101
Name    : Andi
Phone   : 0812xxxx
Address : Merdeka Street

Address B
ID      : 202
Name    : Andi
Phone   : 0812xxxx
Address : Sudirman Street

Both records belong to the same contact, so name and phone number cannot tell them apart. If the user selects Address B, the system should save address_id = 202. It should not fall back to Address A just because it is the first match.

The expected flow is simple:

User selects Address B
        ↓
address_id = 202
        ↓
API receives the ID
        ↓
Database saves address_id = 202

What I want to avoid is the system searching again by name and phone number and guessing which address was meant.

What I Test Now

I deliberately create two addresses with the same contact name and phone number, then check that:

• Selecting A saves A, and selecting B saves B.
• Switching from A to B, and back to A, saves the latest choice.
• The selection stays correct after a page reload or reopening the record.
• Changing the display order does not change the saved selection.
• The ID in the UI, API request, and database stays consistent.

This is not unusual data. A customer can easily have a home, office, and delivery address under one name and phone number.

Matching Is Not Identity

A name and phone number help locate a contact. They do not identify which address that contact meant. Matching attributes help find data, while a unique identifier distinguishes the specific record being referenced.

SAME CONTACT
     ≠
SAME ADDRESS

For me, this case is a reminder that system quality is not only about what appears on screen. It is about whether the system keeps the user's intent intact from selection all the way to the database.