टेस्टर्स के लिए ब्राउज़र DevTools

यह क्यों ज़रूरी है

Screen पर आप failure देखते हैं; उसके पीछे का defect page के code, server या data में होता है। "Save काम नहीं करता" वाली report से developer को शून्य से शुरू करना पड़ता है। "Save PATCH /api/v1/profile भेजता है, server 422 लौटाता है और page फिर भी success दिखाता है" पहले से बता देता है कि server ने input reject किया और page ने उस rejection को ignore किया।

DevTools वे failures भी दिखाता है जिन्हें interface छिपा देता है: कुछ न करने वाले button के पीछे script error, चुपचाप fail होती request, logout के बाद भी बची session cookie। हर panel किस सवाल का जवाब देता है, यह जानना अंदाज़े को सबूत में बदल देता है।

हर panel, एक सवाल

ज़्यादातर testing काम छह panels से हो जाता है। यह lesson Chrome के नाम इस्तेमाल करता है; Edge के DevTools उसी Chromium code से बने हैं, इसलिए नाम और layout लगभग हर जगह मेल खाते हैं। Firefox और Safari में भी यही tools हैं, कुछ दूसरे नामों से: Firefox में Elements की जगह Inspector, और दोनों में Application की जगह Storage और device toolbar की जगह Responsive Design Mode। वह panel खोलें जिसका सवाल आपके सामने के symptom से मेल खाता हो।

• Elements: page पर अभी क्या है, और वह ऐसा क्यों दिखता है?
• Console: क्या page का code fail हुआ, और उसने क्या कहा?
• Network: browser ने क्या भेजा, जवाब में क्या आया, और कितना समय लगा?
• Application: यह site मेरे browser में क्या store करती है?
• Performance: load या click के दौरान समय कहाँ जाता है?
• Device toolbar: phone के साइज़ वाली screen और touch पर layout कैसे बदलता है?

Elements और Console: page और उसका code

Elements panel live DOM दिखाता है, जैसा DOM वाले lesson में देखा। कोई node चुनें तो Styles pane उस पर लागू हर CSS rule दिखाता है, और override हुई declarations कटी हुई दिखती हैं: इसी से पता चलता है कि button grey क्यों है या label क्यों कट रहा है। Accessibility pane उसका computed role और accessible name दिखाता है, यानी वह नाम जो screen reader बोलता है।

किसी समस्या की जाँच के लिए आप text और styles वहीं edit कर सकते हैं, जैसे label में एक लंबा Arabic शब्द paste करके देखें कि वह बाहर निकलता है या नहीं। ये edits सिर्फ़ आपके tab में रहते हैं और reload पर मिट जाते हैं: ये defect की संभावित जगह दिखाते हैं, यह साबित नहीं करते कि product काम करता है।

Console JavaScript errors और warnings, fail हुए resource loads और security messages दिखाता है; ज़्यादातर messages उस file और line, या उस URL से जुड़े होते हैं जहाँ से वे आए। आप page से सवाल पूछने के लिए expressions भी type कर सकते हैं, जैसे नीचे। जो code आप नहीं समझते उसे कभी paste न करें: वह आपके logged-in session के साथ चलता है। एक सीमा: Chrome navigator.userAgent को major version और उसके बाद .0.0.0 तथा एक fixed OS version तक घटा देता है, इसलिए browser का exact version उसके About page से लें।

$0                            // the element selected in Elements
$0.disabled                   // is that button disabled right now?
$$('img:not([alt])').length   // images without an alt attribute
navigator.userAgent           // browser and OS; Chrome gives the major version only

आज़माएँ: User-Agent पार्सर

Network: क्या भेजा गया और क्या लौटा

Network panel DevTools खुले रहने तक हर request record करता है, उसके status code, type, initiator, size और time के साथ। किसी request पर click करें तो उसके headers, page का भेजा payload, response और timing दिखते हैं।

एक request बता देती है कि किस तरफ़ शक करना है। Request में गलत data: page देखें। Request सही, response गलत: server देखें। दोनों सही पर screen गलत: देखें कि page response को कैसे handle करता है। जिस request को जवाब नहीं मिला, उसमें status code की जगह (failed) दिखता है।

समस्या reproduce करने से पहले panel खोलें; पहले की requests उसमें नहीं दिखतीं। फिर इनका इस्तेमाल करें:

• Preserve log, ताकि page navigate होने पर भी list बनी रहे, जैसे form submit होने के बाद।
• Disable cache, ताकि DevTools खुले रहने तक requests browser का HTTP cache छोड़ दें। Cookies, stored data और कोई भी service worker बने रहते हैं, इसलिए पहली बार आने वाले visitor का view देखने के लिए private window इस्तेमाल करें।
• Throttling, धीमे connection या offline होने को simulate करके loading और error states देखने के लिए।
• Fetch/XHR filter, static files छिपाकर सिर्फ़ data ले जाने वाली calls रखने के लिए।
• Copy as cURL, जो request को curl के command में बदल देता है (curl HTTP requests भेजने वाला command-line program है), ताकि developer ठीक वही request दोबारा भेज सके। Command में आपकी cookies और Authorization header होते हैं: share करने से पहले इन्हें हटा दें।
• Export HAR, ताकि list की सारी requests bug report के लिए एक file में save हो जाएँ। Chrome default रूप से Cookie, Set-Cookie और Authorization headers छोड़ देता है, लेकिन request और response bodies में अब भी personal data हो सकता है।

आज़माएँ: cURL पार्सर आज़माएँ: HTTP हेडर पार्सर आज़माएँ: JSON फ़ॉर्मेटर

Application, Performance और device toolbar

Application panel दिखाता है कि site आपके browser में क्या रखती है: cookies अपने attributes (HttpOnly, Secure, SameSite, expiry; इन्हें cookies और web storage वाला lesson समझाता है) के साथ, local storage और session storage, IndexedDB और service workers। आप entries edit या delete कर सकते हैं, या site data clear करके नए सिरे से शुरू कर सकते हैं। एक आम check: logout के बाद क्या session cookie, यानी वह cookie जो आपको logged in रखती है, हट गई?

Performance panel किसी load या interaction को record करके दिखाता है कि browser का main thread क्या कर रहा था। Long tasks, यानी 50 ms से लंबे tasks, लाल रंग में marked होते हैं और layout shifts का अपना track होता है, जिससे देर से जवाब देने वाला click या उछलता content समझ आता है। आपके laptop के नतीजे lab measurements हैं, आपके users का अनुभव नहीं।

Device toolbar phone या tablet का viewport, उसका pixel ratio, touch events और device preset चुनने पर उसका user agent emulate करता है। यह layout का तेज़ पहला check है, लेकिन engine, CPU और fonts आपके desktop browser के ही रहते हैं; ज़रूरी नतीजे real device पर confirm करें। Responsive testing वाला lesson इसकी सीमाएँ "Device toolbar क्या बता सकता है और क्या नहीं" section में विस्तार से समझाता है।

आज़माएँ: कुकी एनालाइज़र

Worked example: "Profile saved", पर कुछ save नहीं हुआ

Staging पर एक tester phone number बदलकर +966 50 123 4567 करती है, Save पर click करती है और "Profile saved" देखती है; reload के बाद पुराना number लौट आता है। "Save काम नहीं करता" लिखने की बजाय वह Preserve log चालू करती है, Fetch/XHR filter चुनती है और steps दोहराती है:

• PATCH request (किसी resource का एक हिस्सा बदलने वाला HTTP method) नया number लेकर गई: form ने input सही collect किया।
• Server ने 422 (RFC 9110 में Unprocessable Content) लौटाया, यानी data reject किया: कुछ save नहीं हुआ, जैसा reload के बाद वाला GET पक्का करता है।
• फिर भी page ने success दिखाया, यानी वह response status check नहीं करता; JavaScript basics वाले lesson की तरह, 4xx जवाब से fetch() fail नहीं होता। यह page का defect है।
• क्या phone number में spaces allowed हैं? Requirement तय करेगी कि server के validation में दूसरा defect है या नहीं।
• Report page का defect बताती है, phone format का सवाल उठाती है और screenshot, request और response attach करती है, session cookie के बिना।

Console   (no errors)

Network   Fetch/XHR, Preserve log on
  PATCH  https://staging.example.com/api/v1/profile
  Status:    422
  Payload:   {"phone":"+966 50 123 4567"}
  Response:  {"field":"phone","message":"Invalid phone format"}

  GET    https://staging.example.com/api/v1/profile    (after reload)
  Status:    200
  Response:  {"name":"Sara","phone":"+966501112233"}

आज़माएँ: HTTP स्टेटस कोड लुकअप

अक्सर पूछे जाने वाले सवाल

संदर्भ

• What are browser developer tools? — MDNMDN Web Docs (Mozilla)ब्राउज़र में बने developer tools का परिचय — inspector, JavaScript console और debugger — टेस्ट करते समय पेज की जाँच के लिए।
• RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
• Using HTTP cookies — MDNMDN Web Docs (Mozilla)कुकी की अवधि, स्कोप, Secure/HttpOnly/SameSite एट्रिब्यूट और उनके सुरक्षा निहितार्थ।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।