ऑटोमेटेड सुलभता टेस्टिंग

आपने इस कोर्स में अब तक, डिजिटल सुलभता के निजी, कारोबारी, और कानूनी पहलुओं के बारे में सीखा है. साथ ही, डिजिटल सुलभता के मानकों के मुताबिक होने की बुनियादी बातें भी सीखी हैं. आपने समावेशी डिज़ाइन और कोडिंग से जुड़े खास विषयों के बारे में जाना है. इनमें ARIA बनाम एचटीएमएल का इस्तेमाल कब करना है, कलर कंट्रास्ट को कैसे मेज़र करना है, JavaScript कब ज़रूरी है वगैरह शामिल हैं.

बाकी बचे मॉड्यूल में, हम डिज़ाइन और डेवलपमेंट से हटकर, सुलभता के लिए टेस्टिंग पर फ़ोकस करेंगे. हम तीन चरणों वाली टेस्टिंग प्रोसेस के बारे में बताएंगे. इसमें ऑटोमेटेड, मैन्युअल, और सहायक टेक्नोलॉजी की मदद से टेस्टिंग करने के टूल और तकनीकें शामिल हैं. हम इन सभी टेस्टिंग मॉड्यूल में एक ही डेमो का इस्तेमाल करेंगे, ताकि वेब पेज को सुलभ बनाया जा सके.

ऑटोमेटेड, मैन्युअल, और सहायक टेक्नोलॉजी की मदद से की जाने वाली हर तरह की टेस्टिंग, सुलभता के मामले में बेहतर प्रॉडक्ट बनाने के लिए ज़रूरी है. हमारी टेस्टिंग के लिए, वेब कॉन्टेंट ऐक्सेसबिलिटी गाइडलाइंस (डब्ल्यूसीएजी) 2.1 के लेवल A और AA के मानकों का इस्तेमाल किया जाता है.

ध्यान रखें कि आपका उद्योग, प्रॉडक्ट का टाइप, स्थानीय और देश के कानून और नीतियां या सुलभता के कुल लक्ष्य तय करते हैं कि आपको किन दिशा-निर्देशों का पालन करना है और किन लेवल को पूरा करना है. अगर आपको अपने प्रोजेक्ट के लिए किसी खास मानक की ज़रूरत नहीं है, तो हमारा सुझाव है कि आप डब्ल्यूसीएजी के नए वर्शन का पालन करें. सुलभता ऑडिट, मानकों के मुताबिक होने के टाइप/लेवल, डब्ल्यूसीएजी, और POUR के बारे में सामान्य जानकारी पाने के लिए, "डिजिटल सुलभता को कैसे मेज़र किया जाता है?" लेख देखें.

जैसा कि अब आपको पता है, दिव्यांग लोगों की मदद करने के मामले में, सुलभता के मानकों के मुताबिक होना ही काफ़ी नहीं है. हालांकि, यह एक अच्छी शुरुआत है, क्योंकि इससे आपको एक ऐसी मेट्रिक मिलती है जिसकी मदद से टेस्टिंग की जा सकती है. हमारा सुझाव है कि आप मानकों के मुताबिक होने की टेस्टिंग के अलावा, ये कार्रवाइयां भी करें, ताकि आपको ज़्यादा समावेशी प्रॉडक्ट बनाने में मदद मिल सके:

• दिव्यांग लोगों के साथ यूज़ेबिलिटी टेस्ट करें.
• अपनी टीम में काम करने के लिए, दिव्यांग लोगों को काम पर रखें.
• डिजिटल सुलभता के मामले में विशेषज्ञता रखने वाले किसी व्यक्ति या कंपनी से सलाह लें.

ऑटोमेटेड टेस्टिंग की बुनियादी बातें

ऑटोमेटेड सुलभता टेस्टिंग में, सॉफ़्टवेयर का इस्तेमाल करके आपके डिजिटल प्रॉडक्ट को स्कैन किया जाता है. इससे, पहले से तय किए गए सुलभता के मानकों के मुताबिक न होने से जुड़ी समस्याओं का पता लगाया जाता है.

ऑटोमेटेड सुलभता टेस्ट के फ़ायदे:

• प्रॉडक्ट के लाइफ़साइकल के अलग-अलग चरणों में, टेस्ट को तुरंत दोहराया जा सकता है.
• टेस्ट करने के लिए, बस कुछ ही चरणों की ज़रूरत होती है और नतीजे बहुत तेज़ी से मिलते हैं.
• टेस्ट करने या नतीजों को समझने के लिए, सुलभता के बारे में ज़्यादा जानकारी की ज़रूरत नहीं होती.

ऑटोमेटेड सुलभता टेस्ट के नुकसान:

• ऑटोमेटेड टूल, आपके प्रॉडक्ट में सुलभता से जुड़ी सभी गड़बड़ियों का पता नहीं लगाते
• गलत पॉज़िटिव रिपोर्ट किए जाते हैं (किसी ऐसी समस्या की रिपोर्ट की जाती है जो डब्ल्यूसीएजी का उल्लंघन नहीं है)
• प्रॉडक्ट के अलग-अलग टाइप और भूमिकाओं के लिए, एक से ज़्यादा टूल की ज़रूरत पड़ सकती है

ऑटोमेटेड टेस्टिंग, अपनी वेबसाइट या ऐप्लिकेशन की सुलभता की जांच करने का एक अच्छा तरीका है. हालांकि, सभी जांचों को ऑटोमेट नहीं किया जा सकता. हम मैन्युअल सुलभता टेस्टिंग मॉड्यूल में, उन एलिमेंट की सुलभता की जांच करने के तरीके के बारे में ज़्यादा जानकारी देंगे जिन्हें ऑटोमेट नहीं किया जा सकता.

ऑटोमेटेड टूल के टाइप

ऑनलाइन ऑटोमेटेड सुलभता टेस्टिंग टूल में से एक, सेंटर फ़ॉर ऐप्लाइड स्पेशल टेक्नोलॉजी (CAST) ने 1996 में बनाया था. इसे "द बॉबी रिपोर्ट" कहा जाता है. आज, चुनने के लिए 100 से ज़्यादा ऑटोमेटेड टेस्टिंग टूल उपलब्ध हैं !

ऑटोमेटेड टूल को अलग-अलग तरीके से लागू किया जा सकता है. जैसे, सुलभता के लिए ब्राउज़र एक्सटेंशन, कोड लिंटर, डेस्कटॉप और मोबाइल ऐप्लिकेशन, ऑनलाइन डैशबोर्ड. इसके अलावा, ओपन-सोर्स एपीआई का इस्तेमाल करके, अपना ऑटोमेटेड टूल भी बनाया जा सकता है.

ऑटोमेटेड टूल चुनते समय, कई बातों का ध्यान रखना होता है. जैसे:

• आपको किन मानकों और लेवल के हिसाब से टेस्टिंग करनी है? इसमें डब्ल्यूसीएजी 2.2, डब्ल्यूसीएजी 2.1, अमेरिका का सेक्शन 508, या सुलभता के नियमों की बदली हुई सूची शामिल हो सकती है.
• आपको किस तरह के डिजिटल प्रॉडक्ट की टेस्टिंग करनी है? यह कोई वेबसाइट, वेब ऐप्लिकेशन, खास ऑपरेटिंग सिस्टम के लिए बना ऐप्लिकेशन, पीडीएफ़, किऑस्क या कोई अन्य प्रॉडक्ट हो सकता है.
• आपको सॉफ़्टवेयर डेवलपमेंट लाइफ़साइकल के किस चरण में अपने प्रॉडक्ट की टेस्टिंग करनी है?
• टूल को सेट अप करने और इस्तेमाल करने में कितना समय लगता है? किसी व्यक्ति, टीम या कंपनी के लिए?
• टेस्ट कौन कर रहा है: डिज़ाइनर, डेवलपर, क्वालिटी अश्योरेंस (क्यूए) या कोई और?
• आपको सुलभता की जांच कितनी बार करनी है? रिपोर्ट में कौनसी जानकारी शामिल होनी चाहिए? क्या समस्याओं को सीधे टिकट सिस्टम से लिंक किया जाना चाहिए?
• आपके एनवायरमेंट में कौनसे टूल सबसे बेहतर काम करते हैं? आपकी टीम के लिए?

इसके अलावा, कई अन्य बातों का भी ध्यान रखना होता है. अपने और अपनी टीम के लिए सबसे सही टूल चुनने के बारे में ज़्यादा जानकारी पाने के लिए, डब्ल्यूएआई का "वेब ऐक्सेसबिलिटी इवैल्युएशन टूल चुनना" लेख देखें.

डेमो: ऑटोमेटेड टेस्ट

ऑटोमेटेड सुलभता टेस्टिंग के डेमो के लिए, हम Chrome के Lighthouse का इस्तेमाल करेंगे. Lighthouse एक ओपन-सोर्स और ऑटोमेटेड टूल है. इसे परफ़ॉर्मेंस, एसईओ, और सुलभता जैसे अलग-अलग तरह के ऑडिट करके, वेब पेजों की क्वालिटी को बेहतर बनाने के लिए बनाया गया है.

हमारा डेमो, मेडिकल मिस्ट्रीज़ क्लब नाम के एक काल्पनिक संगठन के लिए बनाई गई वेबसाइट है. डेमो के लिए, इस साइट को जान-बूझकर सुलभ नहीं बनाया गया है. हो सकता है कि आपको सुलभता से जुड़ी कुछ समस्याएं दिखें. साथ ही, हमारे ऑटोमेटेड टेस्ट में कुछ (लेकिन सभी नहीं) समस्याएं पकड़ में आएंगी.

पहला चरण

Chrome ब्राउज़र का इस्तेमाल करके, Lighthouse एक्सटेंशन इंस्टॉल करें.

Lighthouse को अपने टेस्टिंग वर्कफ़्लो में इंटिग्रेट करने के कई तरीके हैं. हम इस डेमो के लिए, Chrome एक्सटेंशन का इस्तेमाल करेंगे.

दूसरा चरण

हमने CodePen में एक डेमो बनाया है. अगले टेस्ट करने के लिए, इसे डीबग मोड में देखें. यह ज़रूरी है, क्योंकि इससे डेमो वेब पेज के चारों ओर मौजूद <iframe> हट जाता है. इससे कुछ टेस्टिंग टूल में समस्या आ सकती है.

CodePen के डीबग मोड के बारे में ज़्यादा जानें .

तीसरा चरण

Chrome DevTools खोलें और Lighthouse टैब पर जाएं. "सुलभता" के अलावा, सभी कैटगरी के विकल्प हटाएं. मोड को डिफ़ॉल्ट पर रखें और उस डिवाइस का टाइप चुनें जिस पर आपको टेस्ट करने हैं.

चौथा चरण

पेज लोड का विश्लेषण करें पर क्लिक करें और Lighthouse को अपने टेस्ट करने के लिए समय दें.

टेस्ट पूरे होने के बाद, Lighthouse एक स्कोर दिखाता है. इससे पता चलता है कि जिस प्रॉडक्ट की टेस्टिंग की जा रही है वह कितना सुलभ है. Lighthouse स्कोर की गिनती, समस्याओं की संख्या, समस्याओं के टाइप, और पता लगाई गई समस्याओं से उपयोगकर्ताओं पर पड़ने वाले असर के आधार पर की जाती है.

Lighthouse की रिपोर्ट में, स्कोर के अलावा, यह भी बताया जाता है कि किन समस्याओं का पता लगाया गया है. साथ ही, उन्हें ठीक करने के बारे में ज़्यादा जानने के लिए, संसाधनों के लिंक भी दिए जाते हैं. रिपोर्ट में, पास किए गए या लागू नहीं होने वाले टेस्ट और मैन्युअल तरीके से जांच करने के लिए, अन्य आइटम की सूची भी शामिल होती है.

पांचवां चरण

अब, ऑटोमेटेड सुलभता से जुड़ी हर समस्या का एक उदाहरण देखें और उससे जुड़े स्टाइल और मार्कअप को ठीक करें.

समस्या 1: ARIA रोल

पहली समस्या में बताया गया है: "ARIA [role] वाले एलिमेंट में बच्चों के लिए खास [role] शामिल करने की ज़रूरत होती है. इन एलिमेंट में बच्चों के लिए कुछ या पूरी जानकारी नहीं है. ARIA की कुछ पैरंट भूमिकाओं में खास चाइल्ड भूमिकाएं होनी चाहिए, ताकि वे तय किए गए सुलभता फ़ंक्शन कर सकें." ARIA रोल के नियमों के बारे में ज़्यादा जानें.

हमारे डेमो में, न्यूज़लेटर की सदस्यता लेने वाले बटन में समस्या है:

<button role="list" type="submit" tabindex="1">Subscribe</button>

आइए, इसे ठीक करते हैं.

इनपुट फ़ील्ड के बगल में मौजूद "सदस्यता लें" बटन पर, गलत ARIA रोल लागू किया गया है. इस मामले में, रोल को पूरी तरह से हटाया जा सकता है.

<button type="submit" tabindex="1">Subscribe</button>

समस्या 2: ARIA हिडन

"[aria-hidden="true"] एलिमेंट में फ़ोकस करने लायक डिसेंडेंट हैं. `[aria-hidden="true"]` एलिमेंट में फ़ोकस करने लायक डिसेंडेंट, स्क्रीन रीडर जैसी सहायक टेक्नोलॉजी का इस्तेमाल करने वालों को उन इंटरैक्टिव एलिमेंट का इस्तेमाल करने से रोकते हैं. aria-hidden नियमों के बारे में ज़्यादा जानें.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

आइए, इसे ठीक करते हैं.

इनपुट फ़ील्ड पर aria-hidden="true" एट्रिब्यूट लागू किया गया था. इस एट्रिब्यूट को जोड़ने से, एलिमेंट (और उसके अंदर मौजूद सभी एलिमेंट) सहायक टेक्नोलॉजी से छिप जाता है.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

इस मामले में, आपको इनपुट से इस एट्रिब्यूट को हटाना चाहिए, ताकि सहायक टेक्नोलॉजी का इस्तेमाल करने वाले लोग फ़ॉर्म फ़ील्ड को ऐक्सेस कर सकें और उसमें जानकारी डाल सकें.

समस्या 3: बटन का नाम

बटन का ऐक्सेस किया जा सकने वाला नाम नहीं है. जब किसी बटन का ऐक्सेस किया जा सकने वाला नाम नहीं होता, तो स्क्रीन रीडर सिर्फ़ "बटन" कहता है. इस वजह से, स्क्रीन रीडर का इस्तेमाल करने वाले लोगों के लिए यह किसी काम का नहीं रहता.

बटन के नाम से जुड़े नियमों के बारे में ज़्यादा जानें.

<button role="list" type="submit" tabindex="1">Subscribe</button>

आइए, इसे ठीक करते हैं.

समस्या 1 में, बटन एलिमेंट से गलत ARIA रोल हटाने पर, "सदस्यता लें" शब्द, ऐक्सेस किया जा सकने वाला बटन का नाम बन जाता है. यह सुविधा, सिमेंटिक एचटीएमएल बटन एलिमेंट में पहले से मौजूद होती है. ज़्यादा मुश्किल स्थितियों के लिए, पैटर्न के अन्य विकल्प भी मौजूद हैं.

<button type="submit" tabindex="1">Subscribe</button>

समस्या 4: इमेज के ऑल्ट एट्रिब्यूट

इमेज एलिमेंट में [alt] एट्रिब्यूट मौजूद नहीं हैं. जानकारी वाले एलिमेंट में, छोटा और ब्यौरे वाला वैकल्पिक टेक्स्ट होना चाहिए. सजावटी एलिमेंट में एक खाली ऑल्ट एट्रिब्यूट का इस्तेमाल किया जा सकता है. इमेज के वैकल्पिक टेक्स्ट से जुड़े नियमों के बारे में ज़्यादा जानें.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

आइए, इसे ठीक करते हैं.

लोगो की इमेज भी एक लिंक है. इसलिए, इमेज मॉड्यूल से आपको पता चलता है कि इसे ऐक्शन वाली इमेज कहा जाता है. साथ ही, इसके लिए इमेज के मकसद के बारे में वैकल्पिक टेक्स्ट की जानकारी ज़रूरी होती है. आम तौर पर, पेज पर पहली इमेज लोगो होती है. इसलिए, यह माना जा सकता है कि एटी का इस्तेमाल करने वाले लोगों को इसकी जानकारी होगी. ऐसे में, हो सकता है कि आपको अपनी इमेज के ब्यौरे में, कॉन्टेक्चुअल जानकारी जोड़ने की ज़रूरत न पड़े.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

समस्या 5: लिंक टेक्स्ट

लिंक का समझने लायक नाम नहीं है. समझने लायक, यूनीक, और फ़ोकस करने लायक लिंक टेक्स्ट (और इमेज के लिए इस्तेमाल किया जाने वाला वैकल्पिक टेक्स्ट, जब लिंक के तौर पर इस्तेमाल किया जाए) की मदद से, स्क्रीन रीडर इस्तेमाल करने वालों का नेविगेशन अनुभव बेहतर होता है. लिंक टेक्स्ट के नियमों के बारे में ज़्यादा जानें.

<a href="#!"><svg><path>...</path></svg></a>

आइए, इसे ठीक करते हैं.

पेज पर मौजूद सभी ऐक्शन वाली इमेज में, इस बारे में जानकारी शामिल होनी चाहिए कि लिंक, उपयोगकर्ताओं को कहां ले जाता है. इस समस्या को ठीक करने का एक तरीका यह है कि इमेज के मकसद के बारे में वैकल्पिक टेक्स्ट जोड़ा जाए. जैसा कि आपने उदाहरण में लोगो की इमेज के लिए किया था. <img> टैग का इस्तेमाल करने वाली इमेज के लिए यह तरीका बहुत अच्छा है. हालांकि, <svg> टैग के लिए इस तरीके का इस्तेमाल नहीं किया जा सकता.

सोशल मीडिया के आइकॉन के लिए, <svg> टैग का इस्तेमाल किया जाता है. ऐसे में, एसवीजी को टारगेट करने वाले किसी अन्य वैकल्पिक ब्यौरे के पैटर्न का इस्तेमाल किया जा सकता है. इसके अलावा, <a> और <svg> टैग के बीच जानकारी जोड़ी जा सकती है. फिर इसे उपयोगकर्ताओं से छिपाया जा सकता है. साथ ही, कोई ऐसा ARIA जोड़ा जा सकता है जो काम करता हो या अन्य विकल्पों का इस्तेमाल किया जा सकता है. आपके एनवायरमेंट और कोड की पाबंदियों के हिसाब से, एक तरीका दूसरे से बेहतर हो सकता है.

सबसे आसान पैटर्न विकल्प का इस्तेमाल करें. इसमें सहायक टेक्नोलॉजी की कवरेज सबसे ज़्यादा होती है. इसके लिए, role="img" टैग में <svg> जोड़ें और <title> एलिमेंट शामिल करें.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

समस्या 6: कलर कंट्रास्ट

बैकग्राउंड और फ़ोरग्राउंड रंगों में काफ़ी कंट्रास्ट अनुपात नहीं है. कई लोगों के लिए, कम कंट्रास्ट वाला टेक्स्ट पढ़ना मुश्किल या नामुमकिन होता है. कलर कंट्रास्ट के नियमों के बारे में ज़्यादा जानें.

दो उदाहरण रिपोर्ट किए गए थे.

आइए, इसे ठीक करते हैं.

वेब पेज पर, कलर कंट्रास्ट से जुड़ी कई समस्याएं मिली हैं. कलर और कंट्रास्ट मॉड्यूल में आपने सीखा कि सामान्य साइज़ वाले टेक्स्ट (18 पॉइंट / 24 पिक्सल से कम) के लिए, कलर कंट्रास्ट का अनुपात 4.5:1 होना चाहिए. वहीं, बड़े साइज़ वाले टेक्स्ट (कम से कम 18 पॉइंट / 24 पिक्सल या 14 पॉइंट / 18.5 पिक्सल बोल्ड) और ज़रूरी आइकॉन के लिए, यह अनुपात 3:1 होना चाहिए.

पेज के टाइटल के लिए, टील रंग के टेक्स्ट के लिए, कलर कंट्रास्ट का अनुपात 3:1 होना चाहिए, क्योंकि यह 24 पिक्सल का बड़े साइज़ वाला टेक्स्ट है. हालांकि, टील बटन को 16 पिक्सल बोल्ड का सामान्य साइज़ वाला टेक्स्ट माना जाता है. इसलिए, इनके लिए कलर कंट्रास्ट का अनुपात 4.5:1 होना चाहिए.

इस मामले में, हम ऐसा टील रंग ढूंढ सकते हैं जो 4.5:1 के अनुपात को पूरा करता हो. इसके अलावा, बटन के टेक्स्ट का साइज़ बढ़ाकर 18.5 पिक्सल बोल्ड किया जा सकता है और टील रंग की वैल्यू में थोड़ा बदलाव किया जा सकता है. दोनों ही तरीके, डिज़ाइन के हिसाब से सही हैं.

सफ़ेद बैकग्राउंड पर मौजूद सभी ग्रे टेक्स्ट में भी कलर कंट्रास्ट की समस्या है. हालांकि, पेज पर मौजूद दो सबसे बड़े हेडिंग में यह समस्या नहीं है. इस टेक्स्ट को गहरा करके, 4.5:1 के कलर कंट्रास्ट के अनुपात की ज़रूरी शर्त को पूरा किया जाना चाहिए.

समस्या 7: सूची का स्ट्रक्चर

सूची के आइटम (<li>), <ul> या <ol> पैरंट एलिमेंट में शामिल नहीं हैं. स्क्रीन रीडर के लिए ज़रूरी है कि उनमें पैरेंट <ul> या <ol> में सूची आइटम (<li>) शामिल हों, ताकि उन्हें ठीक तरह से बोला जा सके.

सूची के नियमों के बारे में ज़्यादा जानें.

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

आइए, इसे ठीक करते हैं.

हमने इस डेमो में, अनऑर्डर्ड सूची को दिखाने के लिए, <ul> टैग के बजाय, सीएसएस क्लास का इस्तेमाल किया है. इस कोड को गलत तरीके से लिखने पर, हमने इस टैग में मौजूद सिमेंटिक एचटीएमएल की सुविधाओं को हटा दिया. क्लास को असली <ul> टैग से बदलकर और उससे जुड़े सीएसएस में बदलाव करके, हम सुलभता से जुड़ी इस समस्या को ठीक करते हैं.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

समस्या 8: टैब इंडेक्स

कुछ एलिमेंट की tabindex वैल्यू 0 से ज़्यादा है. शून्य से ज़्यादा की वैल्यू साफ़ तौर पर, नेविगेशन के क्रम को दिखाती है. हालांकि, यह वैल्यू तकनीकी रूप से मान्य है. इसके बावजूद, सहायक टेक्नोलॉजी पर भरोसा करने वाले लोगों को यह वैल्यू अक्सर परेशान करती है. टैब इंडेक्स के नियमों के बारे में ज़्यादा जानें.

<button type="submit" tabindex="1">Subscribe</button>

आइए, इसे ठीक करते हैं.

वेब पेज पर, टैब के क्रम को बदलने की कोई खास वजह न होने पर, टैब इंडेक्स एट्रिब्यूट में पॉज़िटिव इंटिजर की ज़रूरत नहीं होती. टैब के क्रम को बनाए रखने के लिए, हम टैब इंडेक्स को 0 पर सेट कर सकते हैं या एट्रिब्यूट को पूरी तरह से हटा सकते हैं.

<button type="submit">Subscribe</button>

छठा चरण

ऑटोमेटेड सुलभता से जुड़ी सभी समस्याओं को ठीक करने के बाद, डीबग मोड का कोई नया पेज खोलें. Lighthouse की मदद से, सुलभता का ऑडिट फिर से करें. आपका स्कोर, पहली बार के मुकाबले काफ़ी बेहतर होना चाहिए.

CodePen

अगला चरण

बहुत ख़ूब खेले आप. आपने अब तक काफ़ी कुछ सीख लिया है. हालांकि, हमें और भी बहुत कुछ बताना है! इसके बाद, हम मैन्युअल तरीके से की जाने वाली जांचों के बारे में जानेंगे. इनकी जानकारी, मैन्युअल सुलभता टेस्टिंग मॉड्यूल में दी गई है.