# רשימת בדיקות לפעולה באתר / Website task acceptance checklist

ניר לוי · תבנית עבודה · 10 September 2026

הרשימה עוזרת לבדוק פעולה אחת באתר. היא לא נותנת ציון Lighthouse, אישור נגישות או תחזית דירוג.
This worksheet records one defined task. It is not a Lighthouse score, an accessibility certification or a ranking forecast.

## 1. לפני הבדיקה / Before the test

- כתובת וגרסת האתר / URL and site version:
- מה המשתמש רוצה להשיג / User's intended outcome:
- פרטים לדוגמה / Test input (use fictitious data):
- מה צריך לקבל בסוף, כולל התוכן והפורמט / Expected output, including content and format:
- פעולה שדורשת אישור / Action requiring user approval, if any:
- תאריך, שעה ואזור זמן / Date, time and time zone:
- מי ביצע את הבדיקה ואיזו עזרה קיבל / Operator and assistance provided:
- דפדפן, מערכת, גרסה ומידות תצוגה / Browser, agent, versions and viewport (unknown stays unknown):
- התחברות לחשבון והרשאות / Authentication and permissions:
- היכרות עם הקוד לפני הבדיקה / Prior knowledge of implementation:

## 2. שלושה מצבים / Three conditions

| מצב / Condition | מה קורה / Trigger | מה נחשב להצלחה / Acceptance |
| --- | --- | --- |
| רגיל / Normal | פרטים תקינים / Valid input | התוצאה נשמרה עם התוכן הנכון / Output exists and matches requested content |
| שינוי / Changed input | שינוי בפרטים אחרי שנוצרה תוצאה / Edit after generation | התוצאה מתעדכנת או שהפעולה נעצרת עם הסבר / Output updates or stale action is blocked with explanation |
| שגיאה / Invalid input | בדיקה עם פרט חסר או שגוי / Actually verified missing or invalid input | ברור מה הטעות, אין תוצאה מטעה ואפשר לתקן / Error identified, no misleading output, recovery possible |

החליטו מראש מה נחשב להצלחה ומה צריך לבדוק שוב. אם הסוכן לא הצליח לבצע הוראה, בדקו אם הבעיה בהוראה, בכלי או באתר.
Define pass conditions before interacting. An agent instruction failure does not by itself establish a site defect.

## 3. תוצאות הבדיקה / Outcome record

- מצב שנבדק / Condition tested:
- צעד אחרון שהושלם / Last completed step:
- צפוי / Expected:
- מה קרה / Observed:
- תיעוד: קובץ, רשומה או צילום / Evidence: file, persisted record or capture:
- האם נבדק התוכן, לא רק ההודעה? / Was content inspected beyond the success message?
- עזרה שניתנה לסוכן / Operator recovery or adjustment:
- מסקנה / Result: passed within scope | failed | inconclusive
- הסבר חלופי / Alternative explanation:
- אחראי לתיקון / Fix owner:
- מה צריך להצליח בבדיקה החוזרת / Retest acceptance:

## 4. אם מוסיפים Lighthouse / If adding Lighthouse

Record report URL, Chrome and Lighthouse versions, date, mode, device setting, authenticated state, enabled categories, feature/origin-trial settings, each check's status and raw JSON path. Mark unavailable categories and N/A separately from failure. Do not infer an audit result from a successful UI task.

שמרו את כתובת הדוח, גרסאות Chrome ו-Lighthouse, התאריך, מצב הבדיקה והמכשיר. ציינו אם הייתם מחוברים לחשבון, אילו קטגוריות והגדרות ניסוי הופעלו ומה קרה בכל בדיקה. שמרו גם את קובץ ה-JSON. סמנו N/A או בדיקה שלא זמינה בנפרד מבדיקה שנכשלה. פעולה שהצליחה לא אומרת שהאתר עבר בדיקת Lighthouse.

## Example record / דוגמה מתועדת

10 September 2026, Codex, local reproduction of Nirlevi.com's actual inquiry form and request handler. The operator knew the code. A controlled receiver replaced email delivery; no provider email was sent.

- Intended result: a corrected inquiry accepted once, with its entered content intact.
- Existing defect: ` SEO ` satisfied browser minlength=5 but failed server goal.trim().length>=5. The UI displayed a generic unconfirmed-send message instead of identifying the field.
- Baseline audit: Lighthouse 13.4.1, Chrome 152, mobile emulation, initial page load. Agentic Browsing 2/2: accessibility tree passed, CLS=0. Four checks N/A.
- Repair: shared goal validation; associated field error, aria-invalid, focus and retained input.
- Retest: identical invalid input produced a field error and zero POST requests. Correcting the message produced one POST, HTTP 200 and one matching accepted record in the local receiver.
- Follow-up audit: Agentic Browsing remained 2/2. The repaired recovery behavior was not reflected by a higher ratio.
- Evidence: baseline-lighthouse.json, after-lighthouse.json, accepted-inquiry.json, recovery-request.json and original UI captures linked in the article.

The point is not to accept invalid input. It is to explain the rejection and let the visitor complete the task. Use a staging system for booking, checkout or inquiry tests, and verify the real destination separately when that is the release criterion.