کاربر یک بار کلید روشنایی را فشار می دهد و شاهد جهش تنظیمات از 30 درصد به 50 درصد است. انگشت یک حرکت عمدی انجام داد، با این حال به نظر می رسد که کنترل کننده دو را شمرده است. این علامت می تواند مانند یک رمز و راز نرم افزاری باشد، اما یک توضیح رایج در داخل سوئیچ فیزیکی شروع می شود. کنتاکت های مکانیکی همیشه فوراً از کاملاً باز به کاملاً بسته تغییر نمی کنند. همانطور که سطوح آنها به هم می رسد یا از هم جدا می شود، می توانند چندین بار در یک بازه زمانی کوتاه ایجاد و شکسته شوند. بدون تفسیر مناسب، یک پرس می تواند مانند انفجاری از رویدادهای الکتریکی به نظر برسد.
این رفتار جهش تماسی نامیده می شود. به اندازه کافی طبیعی است که رابط های دکمه با در نظر گرفتن آن طراحی شوند، اما مدت زمان و شکل دقیق آن می تواند با ساخت سوئیچ، سن، آلودگی، دما، سبک فشار دادن و مدار اطراف متفاوت باشد. نویز الکتریکی یا یک اتصال ناپایدار می تواند انتقال های اضافی را ایجاد کند که شبیه پرش است. بنابراین یک تنظیم نادیده گرفته شده ثابت نمی کند که سوئیچ به تنهایی معیوب است. مدار ورودی کنترلر، سیستم عامل، سیم کشی، پایداری منبع و منطق فرمان همگی به تشخیص تعلق دارند.
طراحان معمولاً مشکل را از طریق فیلتر کردن سخت افزار، حذف نرم افزار یا ترکیبی هماهنگ مدیریت می کنند. یک روال نرم افزاری ممکن است قبل از تشخیص تغییر منتظر بماند تا یک ورودی ثابت بماند، سپس از شمارش مجدد آن عمل فیزیکی خیلی زود جلوگیری کند. سخت افزار می تواند سیگنال را قبل از رسیدن به پردازنده تنظیم کند. فاصله و منطق صحیح به سوئیچ انتخابی و پاسخ مورد نظر بستگی دارد. یک عدد ثابت کپی شده از یک محصول نامرتبط می‌تواند یک دکمه را کند کند، فشار سریع را از دست بدهد، یا همچنان امکان شمارش چندگانه را فراهم کند.
مدت زمان پرس انتخاب طراحی دیگری ایجاد می کند. یک ضربه کوتاه ممکن است یک پله جلو برود، در حالی که با نگه داشتن همان کلید ممکن است یک تکرار عمدی یا رمپ صاف شروع شود. سفت‌افزار باید جهش تماس را از یک نگهدارنده معتبر بدون تعجب کاربر متمایز کند. رویدادهای انتشار نیز پرش می شوند، بنابراین شمارش تنها لبه اول همیشه راه حل کاملی نیست. الزامات باید مشخص کند که ضربه زدن، فشار طولانی، فشار همزمان و فشار مکرر به چه معناست، از جمله اینکه رابط چگونه هر عمل را تأیید می کند. در غیر این صورت، در حالی که تجربه همچنان ناسازگار به نظر می‌رسد، آزمایش می‌تواند به صورت الکتریکی انجام شود.
مالک می تواند بدون باز کردن چیزی، شواهد مفیدی را جمع آوری کند. دکمه دقیق، مقدار شروع، عملکرد مورد نظر، نتیجه نمایش داده شده، نسخه کنترل کننده در صورت نشان دادن، و اینکه آیا نور به طور معمول در غیر این صورت کار می کرد یا خیر را ثبت کنید. یک سری از فشارهای تکی معمولی ایجاد کنید، به رابط اجازه دهید بین آنها قرار گیرد و توجه داشته باشید که چند بار شمارش دوتایی رخ می دهد. یک ویدیوی کوتاه که انگشت و نمایشگر را با هم نشان می‌دهد می‌تواند به کارکنان پشتیبانی کمک کند تا خطا را بازتولید کنند. آزمایش نباید به کوبیدن تهاجمی، ضربه تصادفی سریع، یا پاشیدن پاک کننده به سوئیچ تبدیل شود.
وقتی از طریق یک فرآیند تأیید شده انجام شود، مقایسه می تواند مشکل را محدود کند. اگر کنترلر دیگری از همان نوع موجود است، همان عمل ساده را در شرایط مشابه تکرار کنید. اگر سازنده یک به‌روزرسانی سیستم‌افزار مستند ارائه می‌کند، یادداشت‌های آن را بخوانید، برنامه جاری را طبق دستورالعمل حفظ کنید و روش تأیید شده را دنبال کنید. نتیجه متفاوت پس از به‌روزرسانی، شواهد است، نه دلیل اصلی. سفت‌افزار، ویرایش سخت‌افزار، منبع دکمه و سابقه نمونه باید مرتبط باقی بمانند تا پشتیبانی برخلاف واحدها مقایسه نشود.
دستورات اپلیکیشن موبایل باید از تست های ورودی فیزیکی جدا شوند. اگر یک دستگاه فقط با استفاده از دکمه کیس دو بار جلو بیفتد، علامت در جهتی متفاوت از صحنه ای است که پس از یک ضربه زدن برنامه تکرار می شود. برعکس، تلاش‌های مجدد شبکه، دو کنترل‌کننده فعال یا زمان‌بندی‌های تکراری می‌توانند در حالی که کلید فیزیکی بی‌گناه است، چندین فرمان ایجاد کنند. یک رکورد تشخیصی خوب مسیر فرمان را بیان می کند. فقط گفتن "روشنایی به خودی خود تغییر می کند" جزئیاتی را که به احتمال زیاد به مهندس کمک می کند تا رویداد را بازتولید کند حذف می کند.
تست تولید می تواند مشکلات زیادی را قبل از حمل و نقل پیدا کند. یک دستگاه می‌تواند مجموعه‌ای از پرس‌های کنترل‌شده را دریافت کند در حالی که نرم‌افزار رویدادهای شناسایی‌شده، زمان پاسخ‌دهی، و تعداد از دست رفته یا اضافی را ثبت می‌کند. نمونه برداری از تعداد زیادی سوئیچ، دما، و سبک های فشار مورد انتظار بیش از یک واحد نیمکت ایده آل را آزمایش می کند. کنترل بازبینی میان‌افزار اهمیت دارد، زیرا تغییر منطق جهش می‌تواند یک مشکل ورودی را حل کند در حالی که رفتار فشار طولانی را در جای دیگر تغییر می‌دهد. رکورد کیفیت باید نتایج تست دکمه را به کنترلر، مشخصات سوئیچ، ساخت نرم افزار و دسته تولید متصل کند.
راهنمای خدمات باید مرزها را روشن نگه دارد. کاربران می‌توانند کنترل‌های قابل دسترس را اجرا کنند، تکرارپذیری را مشاهده کنند و نرم‌افزار تایید شده را اعمال کنند. آنها نباید یک کنترلر برقی را باز کنند، اتصالات پل، تزریق مواد شیمیایی، یا تعویض سوئیچ مهر و موم شده را مگر اینکه محصول برای آن سرویس طراحی و مستند شده باشد. اگر یک دکمه داغ شد، به صورت مکانیکی چسبید، داخل آن خیس شد، یا با علائم الکتریکی دیگر همراه بود، برق را با خیال راحت قطع کنید و با پشتیبانی واجد شرایط تماس بگیرید. یک فرمان دوگانه ناخوشایند است. تعمیر داخلی بداهه در نزدیکی آکواریوم مشکل بسیار بزرگتری ایجاد می کند.
دکمه های قابل اعتماد غیرقابل توجه هستند، که نتیجه مهندسی عمدی است. سوئیچ، مدار ورودی، زمان بندی سیستم عامل، بازخورد کاربر، تست تولید و رکورد بازنگری، همگی به یک فرمان پاک کمک می کنند. هنگامی که یک فشار چند مرحله ای می شود، رویداد را به طور دقیق توصیف کنید و قبل از تعیین علت، آن را با خیال راحت بازتولید کنید. برای تولیدکنندگان، طراحی حول سخت‌افزار اندازه‌گیری شده و تعاملات تعریف‌شده، انحراف دارد. برای مالکان، شواهد واضح بر حدس زدن مکرر می نشیند. یک عمل فیزیکی باید یک نتیجه قابل درک داشته باشد، خواه تنظیم 30 درصد باشد، 50 درصد یا هر جایی بین.
آزمایش عوامل انسانی باید بیش از یک دستگاه پرس روباتیک باشد. کاربران مختلف از زاویه به یک کلید نزدیک می‌شوند، نزدیک یک لبه فشار می‌دهند، بین ضربه‌ها مکث می‌کنند یا آن را کمی بیشتر نگه می‌دارند. یک ماتریس آزمایشی می‌تواند ضربه‌های عمدی تکی، توالی‌های سریع معتبر، نگه‌داشتن طولانی، رها کردن، کلیدهای همزمان و عملکرد در هنگام نویز معمولی الکتریکی را پوشش دهد. معیار پذیرش باید هر دو دستور اضافی و از دست رفته را به اضافه زمان پاسخ مجاز توصیف کند. مهندسان می توانند انتقال های ورودی خام را با اقدامات شناخته شده در طول توسعه مرتبط کنند، سپس تست های تولید را بر روی نتیجه قابل مشاهده برای کاربر متمرکز نگه دارند. این امر باعث می‌شود به جای پوشاندن هر فرمان غیرمنتظره با تاخیر طولانی‌تر، قانون debounce تا تعامل واقعی قابل ردیابی باشد.
بازخورد دکمه باید یک بار، از طریق یک مقدار واضح، کلیک، آهنگ، یا نشانه مناسب دیگر، تشخیص را تأیید کند. بازخورد باید از دستور پذیرفته شده پیروی کند نه هر انتقال تماس خام. این تمایز به کاربران کمک می کند به رابط اعتماد کنند و در عین حال به مهندسان اجازه می دهد تشخیص دهند که منطق ورودی واقعاً چه چیزی را محاسبه می کند.
