टेस्टर्स के लिए HTML बेसिक्स

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · शुरुआती

HTML (HyperText Markup Language) web page के content और structure का वर्णन करती है: जैसा आपने "ब्राउज़र कैसे काम करता है" lesson में देखा, server एक HTML document भेजता है और browser उससे वह page बनाता है जो आप देखते हैं। Document elements से बना होता है: <button type="submit">Pay now</button> एक button है जिसका text "Pay now" है और जिसका type attribute बताता है कि यह form submit करता है।

Testers शायद ही HTML लिखते हैं, लेकिन उसे अक्सर पढ़ते हैं। Markup दिखाता है कि कोई control असल में क्या है, कौन-से field names server तक पहुँचते हैं और browser कौन-से rules लागू करता है — ये बातें screenshot में नहीं दिखतीं।

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

दो pages एक जैसे दिख सकते हैं और फिर भी अलग व्यवहार कर सकते हैं। <div> से बना "button" mouse से चल सकता है पर keyboard या screen reader से नहीं (screen reader वह software है जो blind और low-vision users के लिए page को बोलकर पढ़ता है); field से न जुड़ा label उस field को screen reader users के लिए बिना नाम के छोड़ देता है; कोई link staging server पर जा सकता है। ये defects screen पर छिपे रहते हैं और markup में साफ़ दिखते हैं।

HTML testers, developers और automation के बीच साझा भाषा भी है। "Label में for="mail" है लेकिन input का id email है" वाली report, "label पर click करने से कुछ नहीं होता" से जल्दी fix होती है, और आगे चलकर UI automation elements को उनके roles, labels और attributes से ढूँढता है।

Elements, tags और attributes

ज़्यादातर elements में एक start tag, content और end tag होता है: <a href="/pricing">See pricing</a> में "See pricing" वह content है जो start tag और end tag </a> के बीच है। Elements डिब्बों की तरह एक-दूसरे के अंदर रहते हैं, जैसे <ul> list के अंदर <li> items। <input>, <img> और <br> जैसे void elements में न content होता है न end tag।

Attributes start tag के अंदर name="value" जोड़ों के रूप में लिखे जाते हैं। हर page पर तीन बातें मायने रखती हैं:

id एक element का नाम है और page में unique होना चाहिए; labels, #fragment links और कई locators (वे queries जिनसे automated tests किसी element को ढूँढते हैं) इसी की ओर इशारा करते हैं।
required और disabled जैसे boolean attributes मौजूद होते ही चालू होते हैं और सिर्फ़ हटाने पर बंद होते हैं: disabled="false" भी field को disable कर देता है।
HTML में खास अर्थ वाले characters को character references के रूप में लिखा जाता है, जिन्हें आम तौर पर entities कहते हैं: < से < दिखता है और & से &। Screen पर & दिखने का मतलब है कि text दो बार encode हुआ है।

एक button के हिस्से: start tag में element का नाम और उसके attributes हैं, disabled सिर्फ़ मौजूद होने से चालू है, content button का नाम है, और void <input> का कोई end tag नहीं होता।

Content वाला element

<भाग 1:button भाग 2:type="भाग 3:submit" भाग 4:id="pay" भाग 5:disabled>भाग 6:Pay nowभाग 7:</button>

Void element

भाग 8:<input type="email" name="email" required>

Text में character reference

<p>Tom भाग 9:& Jerry</p>

1–5Start tag: element का नाम और उसके attributes, < और > के बीच
1–7Element: start tag, content और end tag

1Element का नामबताता है कि element क्या है: असली button के साथ keyboard और screen reader वाला behaviour आता है, जो div में नहीं होता
2Attribute का नामAttributes सिर्फ़ start tag में लिखे जाते हैं
3Attribute की value= के बाद quotes में; submit से button अपना form submit करता है
4id attributePage में unique; labels, #pay links और locators इसी की ओर इशारा करते हैं
5Boolean attributeमौजूद होते ही चालू, सिर्फ़ हटाने पर बंद: disabled="false" भी button को disable करता है
6ContentUser को दिखने वाला text; button के लिए यही वह नाम भी है जो screen reader बोलता है
7End tagElement को बंद करता है; content start tag और end tag के बीच रहता है
8Void elementStart tag ही पूरा element है: न content, न end tag, जैसे <img> और <br> में। required भी एक boolean attribute है
9Character reference (entity)& दिखाता है, जैसे < से < दिखता है। Screen पर खुद & दिखे तो text दो बार encode हुआ है। Page पर दिखता है:Tom & Jerry

आज़माएँ: HTML एंटिटी डिकोडर

हर page का ढाँचा

हर HTML document का ढाँचा एक जैसा होता है। <!DOCTYPE html> standards mode माँगता है; इसके बिना browsers एक पुराने "quirks" mode में चले जाते हैं जो layout बदल देता है। <html> सब कुछ अपने अंदर रखता है और उसका lang attribute भाषा बताता है; Arabic pages dir="rtl" भी जोड़ते हैं। <head> page का वर्णन करता है और दिखता नहीं; <body> में वह है जो user देखता है।

<title>: tab और search results में दिखता है, और screen reader सबसे पहले इसे बोलता है; हर page का अपना वर्णनात्मक title होना चाहिए (WCAG 2.2 criterion 2.4.2)।
lang: screen readers इससे सही उच्चारण चुनते हैं (criterion 3.1.1)।
<meta charset="utf-8">: encoding न होना या गलत होना Arabic और Hindi text के बिगड़कर दिखने की आम वजह है।
<meta name="robots" content="noindex">: page को search engines से बाहर रखता है; staging पर सही, पर production के public page पर गंभीर defect।
<meta name="viewport"> phone से कहता है कि page को अपनी screen की width पर layout करे; इसके बिना phone सिकुड़ा हुआ desktop layout दिखाता है। <link rel="stylesheet"> और <script src> CSS और JavaScript load करते हैं, इसलिए इनमें गलत path page की styling या behaviour बिगाड़ देता है।

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Track your order | Example Store</title>
  <meta name="description" content="Check where your order is.">
  <link rel="stylesheet" href="/styles.css">
  <script src="/app.js" defer></script>
</head>
<body>
  <header>...logo and menu...</header>
  <main>...the content of this page...</main>
  <footer>...contact and legal links...</footer>
</body>
</html>

Semantic elements: अर्थ, रूप नहीं

Semantic element बताता है कि उसका content क्या है: <header>, <nav>, <main> और <footer> page के regions चिह्नित करते हैं, <h1> से <h6> headings, <ul> एक list, <button> एक action और <a href> एक link। <div> और <span> का कोई अर्थ नहीं; ये layout और styling के डिब्बे हैं।

CSS से <div> को हूबहू button जैसा दिखाया जा सकता है, पर असली <button> अपने व्यवहार के साथ आता है: Tab से उस तक पहुँचा जा सकता है, Enter या Space से चलाया जा सकता है, और screen reader उसे button बोलता है। Clickable <div> को इनमें से कुछ नहीं मिलता, जब तक developer हाथ से न जोड़े। इसी तरह <div> में बड़ा bold text heading जैसा दिखता है, पर screen reader की headings list में नहीं आता।

Click पर कोई काम करने वाली हर चीज़ <button> होनी चाहिए, या अगर वह दूसरे page पर ले जाए तो <a href>।
Images को alt चाहिए: जानकारी देने वाली image के लिए छोटा वर्णन, सजावटी image के लिए alt=""।

Markup में forms और links

<form> अपने fields को action में लिखे address पर, method में लिखे HTTP method से भेजता है: post data को request body में रखता है, जबकि get, जो default है, उसे URL में रखता है, जहाँ वह browser history और server logs में पहुँच जाता है। हर field अपने name और अपनी value के रूप में जाता है; जिस field का name न हो, वह भेजा ही नहीं जाता।

Link एक <a> है जिसमें href हो: पूरा URL, /help जैसा path, #faq जैसा fragment जो id="faq" वाले element तक ले जाता है, या mailto: जैसा scheme। Fields और links के attributes सीधे test ideas देते हैं:

type (email, number, date…) browser की built-in checks और phone पर दिखने वाला keyboard या picker तय करता है।
required, minlength, maxlength, min, max और pattern test करने लायक rules हैं, और इनकी limits से boundary values मिलती हैं। इन्हें कोई भी हटा सकता है, इसलिए server को वही rules जाँचने चाहिए। ध्यान दें कि अकेला minlength खाली field को reject नहीं करता।
<label> field को उसका accessible name, यानी वह नाम जो screen reader उस field के लिए बोलता है, तब देता है जब उसका for field के id के बराबर हो या वह field को अपने अंदर रखे; तब label पर click करने से focus भी field पर जाता है।
Form के अंदर बिना type वाला <button> submit button होता है।
<input type="hidden"> screen पर नहीं दिखता, पर user उसे बदल सकता है, इसलिए server को उसकी value पर भरोसा नहीं करना चाहिए।

आज़माएँ: वैलिडेशन टेस्ट जनरेटर आज़माएँ: URL पार्सर

Worked example: sign-up form का source पढ़ना

Server का भेजा HTML देखने के लिए Windows और Linux पर Chrome, Edge या Firefox में Ctrl+U दबाएँ, या address से पहले view-source: लिखें। Source वह document है जो JavaScript के बदलाव से पहले था; live page DevTools में है, जो आगे के lessons में आएँगे। कुछ लंबी lines में ठुँसा minified source, HTML formatter में paste करने पर पढ़ने लायक बन जाता है। कई single-page applications (SPAs), जो page को JavaScript से बनाती हैं, लगभग खाली <body> भेजती हैं, इसलिए उनका source कम ही बताता है।

यह sign-up form screen पर ठीक दिखता है। इसका source नहीं:

method="get": email और password URL में जाएँगे। Expected: post।
Email वाले <label> में for नहीं है और वह input को अपने अंदर भी नहीं रखता, इसलिए field का कोई accessible name नहीं है।
for="pass" और id="password" मेल नहीं खाते: वही defect।
Email के लिए type="text": phone पर email keyboard नहीं और browser में format check नहीं।
required के बिना minlength="12": खाली password browser check पार कर लेता है। 0, 11 और 12 characters टेस्ट करें और maximum पूछें।
Hidden plan की value free है: जिस test environment को टेस्ट करने की आपको अनुमति है, वहाँ DevTools में इसे बदलकर submit करें। Plan server को तय करना चाहिए, page को नहीं।
<button>Cancel</button> में type नहीं है, इसलिए यह form submit करता है। Expected: type="button"।
"Create account" एक <div> है: Tab से उस तक नहीं पहुँचा जा सकता और screen reader उसे button नहीं बोलता।

<form action="/signup" method="get">
  <label>Email</label>
  <input type="text" id="email" name="email" required>

  <label for="pass">Password</label>
  <input type="password" id="password" name="password" minlength="12">

  <input type="hidden" name="plan" value="free">

  <button>Cancel</button>
  <div class="btn-primary" onclick="createAccount()">Create account</div>
</form>

आज़माएँ: HTML फ़ॉर्मेटर

आम गलतियाँ

Element को उसके रूप से आँकना: button जैसा styled <div> keyboard और screen reader के लिए button नहीं है।
required या maxlength को validation का सबूत मान लेना, बजाय यह टेस्ट करने के कि server वही rules लागू करता है।
Single-page application का सिर्फ़ page source पढ़ना, जिसका content सिर्फ़ live DOM में दिखता है।
Bug report में element, attribute और उसकी value quote करने की बजाय "label काम नहीं करता" लिखना।
<head> को नज़रअंदाज़ करना: गलत <title>, lang या noindex page पर कभी नहीं दिखता, पर screen reader users और search results को नुकसान पहुँचाता है।

QA का नज़रिया

Exploratory testing के दौरान source या DevTools को page के बगल में खुला रखें; अगर कोई control अजीब व्यवहार करे, तो देखें कि वह असल में कौन-सा element है। नई screens के review में असली <button>, <label> और heading elements माँगें, और id या data-testid जैसे स्थिर attributes भी, जिन पर automation भरोसा कर सके।

Bug report में defect दिखाने वाला सबसे छोटा snippet, expected markup और users पर असर ("keyboard users account नहीं बना सकते") quote करें, URL और environment के साथ, क्योंकि staging और production अलग HTML दे सकते हैं। सिर्फ़ उन्हीं systems को टेस्ट करें जिनकी आपको अनुमति है, और खुले comments जैसी findings अपनी team की security process को सौंपें।

अभ्यास

Contact page का source review करें

आपका काम

नीचे एक contact page का source है जो visual review में pass हो गया। Markup में मिलने वाला हर defect या खुला सवाल लिखें, user के लिए वह क्यों मायने रखता है, और expected markup या पूछा जाने वाला सवाल।

सामग्री

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Untitled</title>
  <meta name="robots" content="noindex">
</head>
<body>
  <div class="top-bar">
    <img src="/logo.png">
    <a href="http://staging.example.com/pricing">Pricing</a>
    <a href="#faq">FAQ</a>
    <span class="link" onclick="openHelp()">Help</span>
  </div>
  <div class="big-title">Contact us</div>
  <!-- demo login: demo@example.com / Demo-2026 (remove before release) -->
  <form action="/contact" method="post">
    <label for="msg">Message</label>
    <textarea id="message" name="message" maxlength="500"></textarea>
    <button type="submit">Send</button>
  </form>
  <section id="questions">...</section>
</body>
</html>

चरण

ढाँचा जाँचें: lang, <title> और <meta> elements।
हर href जाँचें और देखें कि उसका target मौजूद है या नहीं।
Headings, images और हर clickable चीज़ जाँचें।
Form जाँचें, फिर comments।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

ढाँचा: <html> में lang नहीं है (criterion 3.1.1); <title>Untitled</title> page का वर्णन नहीं करता (criterion 2.4.2); <meta name="viewport"> नहीं है, इसलिए phone सिकुड़ा हुआ desktop layout दिखाता है; noindex public page को search results से बाहर रखता है, इसलिए पूछें कि क्या यह staging से बचा रह गया है।

Links: Pricing http://staging.example.com पर जाता है — गलत environment और HTTPS भी नहीं। #faq किसी id से मेल नहीं खाता (section का id="questions" है), इसलिए link कुछ नहीं करता। Help एक <span> है: Tab से नहीं पहुँचता, link के रूप में नहीं बोला जाता और नए tab में नहीं खुल सकता।

Semantics: logo वाले <img> में alt नहीं है; "Contact us" <h1> की जगह styled <div> है; top bar एक <div> है, <nav> वाला <header> नहीं।

Form और comment: for="msg" और id="message" मेल नहीं खाते, इसलिए textarea का कोई accessible name नहीं है। Message field में required नहीं है: पूछें कि क्या खाली message भेजा जा सकता है। maxlength="500" से 500 और 501 characters पर boundary tests मिलते हैं; browser 500 के बाद typing रोक देता है, इसलिए 501 server को टेस्ट करता है: क्या server भी यह limit लागू करता है? Comment source खोलने वाले हर व्यक्ति को एक login दिखा देता है: इसे security defect के रूप में report करें।

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

क्या tester बनने के लिए HTML लिखना सीखना ज़रूरी है?

नहीं। आपको इसे पढ़ना आना चाहिए: elements और attributes पहचानना, जिस field, link या heading को टेस्ट कर रहे हैं उसे ढूँढना, और bug report में उसे quote करना। छोटे pages लिखना सीखने में मदद करता है, पर रोज़ काम आने वाला skill पढ़ना है।

Page source और DevTools के Elements panel में क्या फ़र्क है?

Page source वह HTML document है जो server ने भेजा। Elements panel live DOM दिखाता है: browser के parse करने और JavaScript के बदलने के बाद का page। Simple pages पर दोनों मेल खाते हैं और single-page applications में बहुत अलग होते हैं; DOM और DevTools पर आगे के lessons live view को cover करते हैं।

क्या invalid HTML हमेशा defect है?

हमेशा नहीं। Browsers कई गलतियाँ, जैसे missing end tag, खुद सुधार लेते हैं, इसलिए page फिर भी चल सकता है। Markup की समस्याएँ उनके असर से report करें: label तोड़ने वाला duplicate id, content निगल लेने वाला बिना बंद element, या missing alt। HTML validator इन्हें ढूँढने में काम आता है, पर severity users पर असर से तय होती है।

संदर्भ

HTML Living StandardWHATWGHTML भाषा, नामित कैरेक्टर रेफ़रेंस (एंटिटी) और ब्राउज़रों के पार्सिंग नियमों सहित।
Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
HTML: HyperText Markup Language — MDNMDN Web Docs (Mozilla)HTML elements और attributes पर MDN का reference और गाइड — वह सिमैंटिक संरचना जिससे पेज बनता है और जिस पर टेस्ट व सहायक तकनीक निर्भर करते हैं।
Client-side form validation — MDNMDN Web Docs (Mozilla)ब्राउज़र में built-in और स्क्रिप्ट से होने वाला form validation, और क्यों यह उपयोगकर्ता की मदद करता है पर server पर validation की जगह कभी नहीं लेता।

टेस्टर्स के लिए HTML बेसिक्स

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

Elements, tags और attributes

हर page का ढाँचा

Semantic elements: अर्थ, रूप नहीं

Markup में forms और links

Worked example: sign-up form का source पढ़ना

आम गलतियाँ

QA का नज़रिया

अभ्यास

Contact page का source review करें

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

संदर्भ

Mutqan tools से अभ्यास करें

HTML फ़ॉर्मेटर

HTML एंटिटी डिकोडर

URL पार्सर

वैलिडेशन टेस्ट जनरेटर

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

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

Elements, tags और attributes

हर page का ढाँचा

Semantic elements: अर्थ, रूप नहीं

Markup में forms और links

Worked example: sign-up form का source पढ़ना

आम गलतियाँ

QA का नज़रिया

अभ्यास

Contact page का source review करें

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

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics