A smart lock is not finished when the app says “connected.” Accept the installation only after the door closes without force, every approved access method works, removed users stay removed, the lock reports the right state, and the household can still enter during battery, network, hub, and account failures.
Smart-lock acceptance test at a glance
| Area | Pass condition | Do not accept when |
|---|---|---|
| Door and deadbolt | Latch and bolt move freely with the door open and closed | The motor must pull a misaligned door into position |
| Local access | Key, thumbturn, keypad, fingerprint, and approved credentials work as designed | Any resident depends on one untested method |
| Users and codes | Named users have the minimum access and expired codes fail | Shared installer or household codes remain active |
| State and history | Locked, unlocked, open, and closed states and timestamps are accurate | The app shows a secure state when the door is ajar |
| Failures | Battery, internet, hub, phone, and power failures match the written plan | Mechanical entry or recovery is unknown |
| Handover | The owner has accounts, keys, records, support details, and test results | The installer retains undisclosed access |
1. Record the exact installation
Record the lock brand, model, hardware revision, firmware, door and deadbolt type, battery type, hub or bridge, network path, owner account, integrations, installer, installation date, warranty, and support channel. Photograph the inside and outside hardware without exposing codes or serials publicly.
2. Test the door before testing the electronics
- Open the door and extend and retract the bolt by hand.
- Close the door gently and repeat without pushing, pulling, lifting, or slamming.
- Test from inside and outside at least ten times.
- Check weather stripping, hinge sag, strike depth, bolt clearance, and seasonal movement.
- Confirm the inside release remains usable and meets local egress rules.
A motor that strains, reverses, or reports “jammed” is exposing a door-fit problem. Fix the door or strike rather than hiding the fault with stronger batteries or repeated calibration.
3. Verify every promised access method
Test the physical key, thumbturn, owner app, keypad, fingerprint, phone key, watch key, NFC card, Home Key, voice assistant, and remote unlock only when the exact model supports them. Test each method once from a normal state and once after relocking. Record which methods depend on Bluetooth, Wi-Fi, a hub, cloud service, phone power, or a subscription.
4. Audit owners, users, and codes
Keep one clearly named primary owner and a second documented recovery path. Give residents named accounts or codes rather than one shared credential. Test a permanent resident, a scheduled visitor, a one-time code, and an expired or removed user. The removed user must fail locally and remotely. Use the smart-lock access-code audit for offboarding and review dates.
5. Check auto-lock and door-position behavior
Test auto-lock timing with the door fully closed, briefly open, and deliberately ajar. Verify the lock does not confidently report a secured doorway when the bolt is extended into empty space. If a separate contact sensor determines door position, test its alignment, delay, battery, tamper state, and event history.
6. Verify alerts, logs, and privacy
Trigger lock, unlock, jam, low-battery, door-left-open, invalid-code, offline, and tamper events where supported. Confirm the correct named user, action, and timestamp. Decide who can view access history and how long it is retained. Do not expose codes, guest schedules, or household movement in shared screenshots or broad smart-home permissions.
7. Test alarm and smart-home integrations
Test arrival, departure, bedtime, guest, cleaner, and emergency routines one at a time. Verify whether unlocking disarms an alarm, which users can trigger that action, what happens after a forced entry, and whether a voice command requires authentication. Treat the alarm as a separate life-safety and intrusion layer. A smart lock must not silently disarm security because any household credential was used.
8. Run one-failure-at-a-time tests
| Failure | Test | Expected record |
|---|---|---|
| Internet down | Disconnect WAN while keeping local power | Local methods, remote loss, alerts, and recovery |
| Hub or bridge down | Power off the named dependency | Direct local access and integration changes |
| Phone unavailable | Lock the owner phone away | Independent resident and mechanical access |
| Low or removed battery | Use the maker-approved test | Warnings, emergency power, key access, replacement |
| Account recovery | Verify recovery without changing ownership | Owner email, MFA, trusted device, support path |
Keep somebody on the secure side with a tested mechanical key. Follow the battery and outage checklist; never create a lockout to prove a point.
9. Run a security and safety inspection
Check exposed screws, cylinder protection, strike fasteners, door and frame condition, emergency egress, fire-door requirements, rental permission, accessibility, child safety, and whether a visible keypad reveals code patterns. A connected lock cannot repair a weak door, frame, glass panel, or careless key-control process.
10. Complete the handover
The owner should receive all physical keys, primary ownership, recovery methods, user list, code policy, model and firmware, battery type, calibration notes, hub/network map, integrations, warranty, receipt, support case, test record, and next review date. Remove installer accounts and temporary codes while the installer is present. Store the result with the home-security documentation checklist.
11. Schedule follow-up tests
Repeat the door-fit and access test after 24 hours, after a week, and after weather changes, battery replacement, firmware updates, router or hub changes, resident turnover, or door repairs. Use the firmware update checklist before changing lock software.
Extend acceptance testing beyond the lock itself
A smart lock can pass a keypad test and still fail the household. The finished installation must preserve normal egress, emergency entry, account ownership, access removal, alarm state, alerts, and recovery. Test these dependencies before the installer leaves and again after the first week of ordinary use.
| Dependency | What to prove | Evidence |
|---|---|---|
| Door and deadbolt | Full travel without pushing, pulling, lifting, or motor retries | Open-door and closed-door cycle results |
| Emergency egress | Inside release works quickly without app, cloud, or household code | Resident test and any approved accessibility notes |
| Mechanical backup | Correct controlled key or approved backup path opens the door | Key owner, storage rule, and successful test |
| Accounts and phones | Owner controls recovery; installer and expired devices have no access | Role list and revoked-session check |
| Alarm and door state | Lock, contact sensor, arming mode, and automation do not contradict one another | Event history with matching timestamps |
| Power and network | Residents know what continues during battery, hub, internet, and phone failure | One-failure-at-a-time test results |
| Support and rollback | Exact model, firmware, change history, and safe recovery path are recorded | Handover record and support-ready evidence |
Prove emergency entry and exit
Test the inside thumbturn or approved release with the door open and closed. Confirm every resident who may need help can operate it. Do not add a routine, cover, or child-control measure that blocks required egress. Follow the smart-lock emergency-egress checklist and local fire, accessibility, tenancy, and building rules.
If the model retains a key cylinder, test the correct key from outside without forcing the motor or deadbolt. Record who controls copies and how emergency access works when the owner is away. Use the mechanical-key backup checklist to separate the key plan from app recovery.
Close old physical and digital access
A new lock does not automatically retire old keys, codes, app shares, voice-assistant links, or installer access. If the cylinder or key control changed, complete the smart-lock rekeying checklist. List every current resident, temporary user, cleaner, carer, contractor, property manager, and emergency contact. Give each person only the method and schedule they need.
Review phones, tablets, browser sessions, recovery contacts, vendor accounts, home-platform members, and installer access. The trusted-device and session audit provides a removal and verification sequence. Do not share the owner login as a substitute for named users.
Test lock, door sensor, and alarm state together
The lock state and the door state answer different questions. A deadbolt can report locked while the door is open, misaligned, or not fully latched. Keep the direct door contact active and confirm the system shows each of these states correctly:
- Door closed and locked.
- Door closed and unlocked.
- Door open and unlocked.
- Door moved toward closed but not latched.
- Lock command rejected because the bolt cannot travel.
- Door reopened during any approved auto-lock delay.
Check automations in every relevant arming mode. A routine should not lock someone out, hide an open door, disarm an alarm without clear authorization, or report success before the physical state is known.
Measure alerts instead of assuming delivery
Trigger the events the household depends on: manual unlock, named code, temporary code, failed attempt where supported, low battery, jam or motor error, door left open, account change, and device offline. Record trigger time, app-history time, phone-alert time, recipient, and whether the message tells the person what to do.
Run the focused alert-delay test before accepting a lock that depends on remote action. Test on the actual resident phones, not only the installer’s phone. Respect notification permissions, focus modes, battery controls, and shared-user privacy.
Preserve evidence before destructive recovery
Do not factory-reset, delete, re-pair, or transfer the lock until the current owner, users, codes, sessions, firmware, battery state, calibration, automation links, event history, and rollback path are recorded. A reset may remove the evidence needed to distinguish door fit, motor load, radio trouble, account ownership, and software state.
If the installation cannot pass, prepare the support-ticket checklist. Include the exact model, door dimensions, lock orientation, firmware, error text, time zone, controlled reproduction steps, and changes already tried. Keep passwords, complete recovery codes, private video, and monitoring passcodes out of ordinary tickets.
Run a 60-minute smart-lock household acceptance test
- Record the exact lock, door, cylinder, hub or border router, app, firmware, owner account, battery, and installation date.
- With the door open, cycle the deadbolt ten times using the thumbturn and supported electronic method. Stop if travel binds or the motor retries.
- Close the door normally. Repeat ten lock and unlock cycles without pushing, pulling, or lifting the door.
- Test the owner, one resident, one temporary user, the mechanical backup where present, and the approved emergency-entry plan.
- Remove the temporary user and confirm the code, app share, and linked access no longer work.
- Compare lock state, door-contact state, alarm mode, automation result, and timestamps for closed, open, locked, unlocked, and failed-lock conditions.
- Trigger required alerts and measure delivery on each resident phone.
- Test one failure at a time: internet loss, hub or bridge loss, phone unavailable, low-battery condition through the approved procedure, and account-session removal.
- Restore each dependency and confirm the lock reconnects once, keeps the correct time, and does not create duplicate users or stale automations.
- Complete the handover with ownership, recovery, key control, code policy, battery plan, support route, rollback, and retest date.
Pass/fail criteria for household acceptance
Pass: the deadbolt moves freely; residents can exit and use the approved backup; owner and user roles are correct; removed access stays removed; lock, door, alarm, and automation states agree; required alerts arrive; controlled failures are visible; and recovery does not create duplicate or unknown access.
Fail: the door needs pressure to lock, the motor retries, emergency egress is unclear, the installer retains ownership, an expired user still works, the lock reports success on an open or unlatched door, required alerts do not arrive, or recovery depends on an undocumented reset.
Where Abode fits
When a smart lock is part of an Abode system, verify the exact supported integration, user permissions, alarm-state changes, automations, event history, hub dependency, and outage behavior. Compare the Abode Lock, Smart Security Kit, and current Abode plans for a sensor-led setup.
FAQ
How many times should a new smart lock be tested?
Test at least ten normal open-close cycles, every promised credential, a removed credential, door-position behavior, and each planned failure without forcing a lockout.
Should a smart lock move a tight deadbolt?
No. The bolt should move freely by hand with the door open and closed. Correct alignment and frame problems before acceptance.
Can the installer remain an account owner?
Only when the property owner knowingly requires an ongoing managed role. Otherwise transfer ownership, remove installer access, and verify recovery during handover.
Does a smart lock replace an alarm sensor?
No. Lock state, door position, intrusion detection, alarm response, and video evidence are separate functions that should be tested separately.