एक आयु बैज को परीक्षण योग्य रनटाइम कवरेज मैप में बदलें

पहले रिकॉर्ड करें कि आयु रेटिंग वास्तव में क्या नियंत्रित करती है

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

मैट्रिक्स की प्रत्येक पंक्ति को समान साक्ष्य फ़ील्ड दें

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

AI आउटपुट को उपयोगकर्ता इनपुट से अलग करें

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

समुदाय, संपर्क और लिंक से बाहर निकलने के मार्गों का मैप तैयार करें

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

छवि और आवाज़ का परीक्षण फ़ाइल प्रकारों के रूप में नहीं, बल्कि प्रक्रियाओं (जर्नी) के रूप में करें

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

विज्ञापनों और खरीदारियों को उसी कवरेज मैप के अंदर रखें

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

प्रत्येक सार्थक बदलाव के बाद डिफ़ॉल्ट का पुनः परीक्षण करें

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

अंतिम दावे को साक्ष्य से अधिक व्यापक न बनाएं

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

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