अलग-थलग जवाबों के बजाय कंपैनियन-ऐप की संपूर्ण उपयोगकर्ता यात्राओं का परीक्षण करें

सात-फ़ील्ड वाले परिदृश्य कार्ड का उपयोग करें

प्रत्येक परीक्षण से पहले संदर्भ, खाता स्थिति, इनपुट भिन्नता, अपेक्षित सीमा, प्रत्यक्ष परिणाम, सुधार पथ (रिकवरी पाथ), और सुरक्षित रखे गए साक्ष्य लिखें। संदर्भ में डिवाइस, ऐप संस्करण, भाषा/क्षेत्र (लोकेल), नेटवर्क और सशुल्क स्तर का नाम होता है। खाता स्थिति नए, लौटने वाले, प्रतिबंधित, साइन-आउट या विलोपन-लंबित उपयोगकर्ताओं के बीच अंतर करती है। इनपुट भिन्नता मूल कार्य को बदले बिना लंबाई, लहजे, वर्तनी, भाषा और माध्यम (मोडैलिटी) को बदलती है। अपेक्षित सीमा यह बताती है कि उत्पाद को क्या करना चाहिए, न कि केवल यह अस्पष्ट उम्मीद कि वह अच्छा व्यवहार करे। प्रत्यक्ष परिणाम इंटरफ़ेस संदेशों, डेटा दृश्यता, टूल क्रियाओं और स्थिति परिवर्तनों को रिकॉर्ड करता है। सुधार (रिकवरी) यह जांचता है कि क्या अनडू, पुनः प्रयास, ब्लॉक, रिपोर्ट, रद्द, साइन-आउट या सहायता काम करती है। साक्ष्यों में गोपनीय जानकारी और तीसरे पक्ष की सामग्री शामिल नहीं होनी चाहिए। किसी रिलीज़ के बाद इस कार्ड को दोहराने से व्यक्तिगत राय वाले 'पास' या 'फ़ेल' के बजाय एक तुलनीय रिकॉर्ड तैयार होता है।

पहचान, मेमोरी और डिवाइस ट्रांज़िशन को कवर करें

पंजीकरण, रिकवरी, सत्र सूचियों, साइन-आउट और दूसरे डिवाइस पर लौटने से शुरुआत करें। फिर जांचें कि नए सत्र, पुराने खाते और इतिहास विलोपन के बाद के खाते के लिए कौन-सी बातचीत या प्राथमिकता का इतिहास दिखाई देता है। साझा डिवाइस पर, अधिसूचना पूर्वावलोकन, हाल के ऐप्स दृश्य, ऑटोफ़िल, डाउनलोड किए गए मीडिया और क्या साइन आउट करने से स्थानीय एक्सेस हट जाता है, इसका परीक्षण करें। डिस्प्ले भाषा और इनपुट भाषा को अलग-अलग बदलें; अनुवादित इंटरफ़ेस यह साबित नहीं करता है कि नियंत्रण और उत्पन्न उत्तर समान सीमाओं का पालन करते हैं। हवाई जहाज मोड (एरोप्लेन मोड), बैकग्राउंडिंग, ऐप पुनरारंभ (रीस्टार्ट) या टोकन समाप्ति के साथ एक सत्र को बाधित करें, फिर सत्यापित करें कि क्या ड्राफ्ट, अपलोड, खरीदारी या विलोपन अनुरोध की नकल हो गई है या उसे अस्पष्ट छोड़ दिया गया है। ये ट्रांज़िशन स्थिति-प्रबंधन (स्टेट-हैंडलिंग) की उन विफलताओं को उजागर करते हैं जिन्हें एक निर्बाध बातचीत नहीं दिखा सकती।

टेक्स्ट, आवाज़, छवियों, लिंक और पुनर्प्राप्त सामग्री का परीक्षण करें

प्रत्येक समर्थित इनपुट सतह का स्वतंत्र रूप से परीक्षण करें क्योंकि अनुमतियां, भंडारण, रूपांतरण और विफलता संदेश भिन्न होते हैं। संक्षिप्त, लंबे, गलत वर्तनी वाले, उद्धृत, काल्पनिक और मिश्रित भाषा रूपों में हानिरहित मनगढ़ंत अनुरोधों का उपयोग करें। आवाज़ के लिए, अनुमति समय, रिकॉर्डिंग संकेतक, प्रतिलेख (ट्रांसक्रिप्ट) दृश्यता, विलोपन और पहचान विफल होने पर फ़ॉलबैक की जांच करें। छवियों के लिए, एक तटस्थ स्व-निर्मित तस्वीर का उपयोग करें और अपलोड, पूर्वावलोकन, हटाने, यदि प्रकट किया गया हो तो मेटाडेटा प्रबंधन, और प्रसंस्करण बंद होने पर क्या होता है, इसे सत्यापित करें। यदि ऐप लिंक खोलता है, फ़ाइलें आयात करता है, वेब पेज पुनर्प्राप्त करता है, या टूल लागू करता है, तो ऐसे अविश्वसनीय लेकिन हानिरहित टेक्स्ट को शामिल करें जो उपयोगकर्ता के अनुरोध के विपरीत हो और जांचें कि क्या सिस्टम उपयोगकर्ता के इरादे को सुरक्षित रखता है। OWASP की LLM जोखिम सूची यहां उपयोगी है क्योंकि प्रॉम्प्ट इंजेक्शन और सूचना प्रकटीकरण केवल मॉडल के शब्दों में ही नहीं, बल्कि एप्लिकेशन सीमा पर उत्पन्न होते हैं।

इंटरेक्शन नियंत्रणों का एंड-टू-एंड यात्रा के रूप में परीक्षण करें

जहां लोग संदेश भेज सकते हैं, फ़ॉलो कर सकते हैं, टिप्पणी कर सकते हैं, उपहार दे सकते हैं या स्थानों (स्पेसेस) में शामिल हो सकते हैं, वहां डिस्कवरी डिफ़ॉल्ट, दर्शक चयन, म्यूट, ब्लॉक, रिपोर्ट, साक्ष्य संरक्षण, अपील जानकारी और दोनों खातों से देखी गई स्थिति का परीक्षण करें। ब्लॉक बटन का पूरी तरह से परीक्षण तब तक नहीं माना जाता जब तक वह केवल एक स्क्रीन को बदलता है लेकिन अधिसूचना पूर्वावलोकन, पुराने लिंक, समूह दृश्यता, या किसी अन्य इंटरेक्शन चैनल को खुला छोड़ देता है। दो स्पष्ट रूप से लेबल किए गए परीक्षण खातों का उपयोग करें; किसी अनजान व्यक्ति को कभी शामिल न करें। सौम्य परीक्षण सामग्री के साथ एक रिपोर्ट चलाएं और सबमिट करने से पहले रुक जाएं यदि यह वास्तविक समीक्षा कतार पर बोझ डालेगी, जब तक कि ऑपरेटर कोई परीक्षण मार्ग प्रदान न करे। इंटरफ़ेस वास्तव में क्या वादा करता है और स्थानीय रूप से क्या पुष्टि की जा सकती है, इसे सटीक रूप से रिकॉर्ड करें। समय और समीक्षा के परिणाम अज्ञात रह सकते हैं, इसलिए एक काम करने वाले सबमिशन नियंत्रण और एक सत्यापित समाधान के बीच अंतर करें।

पैसा, निकास और अपडेट के बाद के रिग्रेशन को शामिल करें

एक निःशुल्क स्तर (फ़्री टियर), परीक्षण सीमा (ट्रायल बाउंड्री), नवीनीकरण सूचना, खरीद प्रमाणीकरण, विफल भुगतान, रद्दीकरण, पात्रता समाप्ति, और खाता हटाने व स्टोर बिलिंग समाप्त करने के बीच के अंतर का परीक्षण करें। उपलब्ध होने पर प्लेटफ़ॉर्म की सुरक्षित परीक्षण सुविधाओं का उपयोग करें; अन्यथा अनावश्यक खरीदारी किए बिना निरीक्षण करें। फिर निर्यात, व्यक्तिगत सामग्री विलोपन, खाता हटाने का अनुरोध, यदि बताया गया हो तो कूलिंग-ऑफ या पुष्टिकरण कदम, और विलोपन लंबित रहने के दौरान क्या दृश्यमान रहता है, इसे सत्यापित करें। अंत में ऐप, मॉडल, नीति, अनुमति या भुगतान परिवर्तन के बाद उच्चतम जोखिम वाली यात्राओं को दोहराएं। Google का मूल्यांकन मार्गदर्शन एप्लिकेशन-विशिष्ट डेटासेट और विविध इनपुट की सिफारिश करता है क्योंकि सामान्य मानक (बेंचमार्क) हर वास्तविक उत्पाद सेटअप का प्रतिनिधित्व नहीं करते हैं। एक संक्षिप्त रिग्रेशन सेट—साझा डिवाइस, बाधित अपलोड, ब्लॉक किया गया उपयोगकर्ता, रद्द की गई सदस्यता और हटाया गया इतिहास—परीक्षण को प्रत्यक्ष उपयोगकर्ता परिणामों से जोड़े रखता है।

कवरेज का मूल्यांकन सुधार (रिकवरी) से करें, न कि सटीक प्रतिलेख से

एक ठोस उत्तर खोए हुए विलोपन अनुरोध, अप्रत्याशित शेयरिंग, अस्पष्ट शुल्क, अटके हुए अपलोड या ऐसे नियंत्रण की भरपाई नहीं कर सकता जिसे वापस नहीं बदला जा सकता। परिदृश्य कार्डों की समीक्षा करें और पुष्टि की गई सीमाओं, सशर्त परिणामों, अंतर्विरोधों और अज्ञात बिंदुओं की गणना करें। उन अज्ञात बिंदुओं को प्राथमिकता दें जो संवेदनशील डेटा, बाहरी कार्रवाइयों, पैसे या अपरिवर्तनीय स्थिति को जोड़ते हैं। एक विफल परीक्षण में सटीक प्रारंभिक स्थिति, न्यूनतम पुनरुत्पादन, दृश्य परिणाम, सुधार का प्रयास और संस्करण शामिल होना चाहिए; "एआई विफल रहा" जैसे व्यापक लेबल किसी समाधान का समर्थन करने के लिए बहुत अस्पष्ट हैं। एक सफल परीक्षण (पास) में भी इसके दायरे का उल्लेख होना चाहिए। व्यावहारिक पूर्णता का नियम यह है कि आदर्श मार्ग टूटने पर सामान्य उपयोगकर्ता स्थिति को देख सकें, समझ सकें कि क्या हुआ, और प्रलेखित अगले कदम तक पहुंच सकें। इसके अलावा सब कुछ एक खुला परीक्षण आइटम बना रहता है।

इस विषय को आगे पढ़ें