मॉड्यूल 1 · Software और QA की बुनियाद

QA, QC और टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 17 मिनट · शुरुआती

Quality assurance (QA) और quality control (QC) उस quality तक पहुँचने के दो पूरक तरीके हैं जिसका वर्णन software quality वाले lesson में हुआ। QA process-oriented और preventive है: यह टीम के काम करने का तरीका सुधारता है, ताकि कम defects बनें। QC product-oriented और corrective है: यह जाँचता है कि जो बना उसमें कहाँ कमी है, और उन defects को ठीक करवाता है। Testing, QC का एक प्रमुख रूप है।

उदाहरण: लगातार तीन releases में Arabic screens पर buttons के labels कटे हुए निकले। अगली release को टेस्ट करना और हर कटे label की report करना QC है: यह इस product में इन defects को ठीक करता है। टीम की definition of done (वह checklist जो किसी story को पूरा माने जाने से पहले पूरी करनी होती है) में "हर नई screen को संकरे phone पर Arabic में जाँचा गया" जोड़ना QA है: यह हर आने वाली screen में इस defect की संभावना कम करता है।

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

जो टीम मानती है कि "QA" का मतलब "आख़िर में बैठे testers" है, वह एक ही तरह के defects ढूँढती रहती है, क्योंकि उन्हें पैदा करने वाली चीज़ कोई नहीं बदलता। जो टीम processes लिखती है पर product कभी नहीं जाँचती, उसके पास सबूत की जगह documents होते हैं। ISTQB Foundation syllabus v4.0 बताता है कि test results दोनों के काम आते हैं: QC में उनसे defects ठीक किए जाते हैं, और QA में वे feedback देते हैं कि development और test processes कितनी अच्छी तरह चल रहे हैं।

Tester के रूप में यह फ़र्क तय करता है कि जो मिला उसका क्या करें: एक defect report एक defect ठीक करवाती है, जबकि सबूत के साथ दिखाया गया defects का pattern पूरा process बदल सकता है।

Quality assurance: process सुधारें, defects रोकें

ISTQB Foundation syllabus v4.0, QA को एक process-oriented, preventive approach बताता है जो processes को लागू करने और सुधारने पर ध्यान देता है। इसकी धारणा है कि अच्छा process सही तरीके से follow हो तो अच्छा product बनता है। QA development और test, दोनों processes को कवर करता है, और यह project में हर व्यक्ति की ज़िम्मेदारी है, किसी एक department की नहीं। QA की आम activities:

  • Stories और releases के लिए definition of done और entry व exit criteria (किसी काम को शुरू और ख़त्म करने की शर्तें) पर सहमति।
  • User stories, test cases और bug reports के लिए standards और templates।
  • Workflow में ज़रूरी कदम, जैसे हर merge से पहले code review।
  • Production तक पहुँचे defects का root cause analysis, और उसके बाद process में एक ठोस बदलाव।
  • Training, और यह जाँचना कि टीम वही कर रही है जिस पर सहमति हुई थी (process audit)।

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर

Quality control: product जाँचें, defects ठीक करें

वही syllabus QC को एक product-oriented, corrective approach बताता है जो उन activities पर ध्यान देता है जो quality के उचित स्तर तक पहुँचने में मदद करती हैं। Testing, QC का एक प्रमुख रूप है; syllabus इसके दूसरे रूप भी गिनाता है: formal methods (model checking और proof of correctness), simulation और prototyping।

"Product" का मतलब कोई भी work product है, सिर्फ़ तैयार application नहीं। किसी requirements document का review करके उसके defects दर्ज करना उस document का QC है, क्योंकि review, static testing का एक रूप है: software चलाए बिना किसी work product की जाँच, जबकि dynamic testing software चलाती है। Static और dynamic testing अगले lesson में आती हैं। Reviews दोनों तरफ़ हो सकते हैं: एक specification का review QC है; हर specification के लिए review अनिवार्य बनाना QA है।

  • किसी build पर test cases चलाना और failures की report करना।
  • Fix के बाद fail हुए test को दोबारा चलाना, यह पक्का करने के लिए कि defect चला गया।
  • Feature बनने से पहले users को एक clickable prototype आज़माने देना।

आज़माएँ: टेस्ट केस जनरेटर आज़माएँ: Requirements → टेस्ट केस

Worked example: एक बार-बार आने वाला defect, दो जवाब

QA और QC एक-दूसरे की जगह नहीं ले सकते। QA के बिना QC वही defects बार-बार ढूँढता है; QC के बिना QA के पास न यह सबूत होता है कि product अच्छा है, न यह कि process काम कर रहा है।

स्थिति: एक online shop ने तीन versions release किए जिनमें checkout पर discount गलत calculate हुआ, और हर बार customer ने ही सबसे पहले ध्यान दिया। ताज़ा मामला: 10% छूट पाने वाले एक member ने 300.00 SAR की basket पर 50.00 SAR का coupon लगाया। Product owner ने तय किया था कि 10% पहले लगेगा (270.00, फिर coupon के बाद 220.00 SAR), पर checkout ने coupon पहले लगाया (250.00, फिर 225.00 SAR)।

  • QC: tester उसी basket, member account और coupon के साथ 225.00 SAR का total reproduce करता है, expected 220.00 SAR के साथ report करता है, fix के बाद test दोबारा चलाता है और उस case को regression suite में जोड़ता है।
  • QA: retrospective (टीम की नियमित meeting, जिसमें टीम अपने काम करने के तरीके पर बात करती है) पूछता है कि defect बना क्यों और पकड़ा क्यों नहीं गया। Discounts किस क्रम में लगें, यह नियम सिर्फ़ product owner के साथ एक chat thread में था, इसलिए developers और testers दोनों ने अपना-अपना अंदाज़ा लगाया।
  • QA: अब से pricing की हर story अपने नियम हिसाब लगाए गए numbers के साथ acceptance criteria के रूप में लिखती है, जैसे ऊपर वाली 300.00 SAR की basket, और development से पहले एक tester उनका review करता है।
  • QA: अगली releases में टीम देखती है कि pricing defects अब भी production तक पहुँचते हैं या नहीं। अब test results सिर्फ़ product पर नहीं, process पर भी feedback देते हैं।
QA process सुधारता है ताकि कम defects बनें, QC product जाँचकर defects ढूँढता और ठीक करवाता है, और testing, QC का एक प्रमुख रूप है।

क्वालिटी एश्योरेंस (QA)

Process पर केंद्रित, preventive

किसे देखता है:
टीम के काम का तरीका: requirements, reviews, release के नियम
लक्ष्य:
कम defects बनें
कौन-सा सवाल पूछता है:
क्या हमारे काम का तरीका अच्छा product बनाएगा?
Discount वाले उदाहरण में:
Pricing के नियम acceptance criteria बनते हैं, development से पहले review होते हैं
कौन करता है:
Project में हर व्यक्ति
Test results:
Processes कैसे चल रहे हैं, इस पर feedback

क्वालिटी कंट्रोल (QC)

Product पर केंद्रित, corrective

किसे देखता है:
जो बना: कोई भी work product
लक्ष्य:
जो defects बने, वे मिलें और ठीक हों
कौन-सा सवाल पूछता है:
क्या यह product काफ़ी अच्छा है, और क्या ठीक करना है?
Discount वाले उदाहरण में:
225.00 SAR का गलत total report होकर ठीक होता है
कौन करता है:
Testers, developers, reviewers और prototype आज़माने वाले users
Test results:
Defects ठीक करने में इस्तेमाल

टेस्टिंगQC का हिस्सा

QC का एक प्रमुख रूप

किसे देखता है:
Review से work products, और चलता हुआ software
लक्ष्य:
Defects मिलें, quality के सबूत के साथ
कौन-सा सवाल पूछता है:
यह work product या build कहाँ कम पड़ता है?
Discount वाले उदाहरण में:
Fail हुआ test दोबारा चलता है और regression suite में जुड़ता है
कौन करता है:
ज़्यादातर testers; developers और reviewers भी
Test results:
यहीं बनते हैं, दोनों इस्तेमाल करते हैं

Testing का अलग column इसलिए है कि वह QC का एक प्रमुख रूप है, कोई तीसरा approach नहीं।

Job titles में QA, पर मतलब अक्सर testing क्यों

रोज़ की बोलचाल में "QA" का मतलब अक्सर testing होता है: "QA engineer", "इसे QA को भेजो", "QA environment"। ISTQB syllabus बताता है कि लोग अक्सर दोनों शब्दों को एक-दूसरे की जगह इस्तेमाल करते हैं, पर ये एक नहीं हैं। QA कहलाने वाली कई भूमिकाएँ मुख्य रूप से QC का काम हैं: tests design करना और चलाना, checks automate करना और defects report करना।

हर job advert को सुधारने की ज़रूरत नहीं। Title नहीं, duties पढ़ें:

  • "Test cases execute करना", "automated tests लिखना" और "bugs report करना" testing, यानी QC, बताते हैं।
  • "Test process define करना", "quality standards तय करना" और "process audits करना" सख़्त अर्थ में QA बताते हैं।
  • कई testing भूमिकाओं में दोनों होते हैं: ज़्यादातर QC, और साथ में requirements, reviews और releases कैसे चलें, इस पर अपनी आवाज़।

आम गलतियाँ

  • QA को development के आख़िर का phase या टीम मानना, न कि पूरी टीम के काम करने का तरीका।
  • यह उम्मीद करना कि सिर्फ़ ज़्यादा testing से quality बनी रहेगी: testing इस release के defects ढूँढती है, पर जब तक process नहीं बदलता, उसी तरह के defects बनते रहते हैं।
  • हर review को "QA" कहना: एक document का review QC है; review को ज़रूरी कदम बनाना QA है।
  • एक ही तरह के defect को बार-बार report करना, पर pattern की ओर ध्यान न दिलाना।
  • ऐसे processes लिखना जिन्हें न कोई follow करता है न कोई मापता है: जो QA test results नहीं देखता, उसके पास कोई feedback नहीं होता।

QA का नज़रिया

Tester के ज़्यादातर घंटे QC में जाते हैं: tests design करना और चलाना, defects report करना और fixes दोबारा जाँचना। यही काम आपको दिखाता है कि defects कहाँ इकट्ठा होते हैं और कौन-से production तक पहुँचते हैं, और QA को ठीक यही चाहिए।

इसे दिखाई देने लायक बनाएँ। अगर आपके tracker में field हो, तो हर defect के लिए दर्ज करें कि वह शायद कहाँ आया (requirement, design, code, configuration, data)। Numbers के साथ patterns retrospective में लाएँ, एक छोटा बदलाव सुझाएँ — checklist का एक item, acceptance criteria का एक नियम, एक review step — और QA वाला सवाल पूछें: "इसे किस चीज़ ने रोका होता, या पहले पकड़ा होता?" फिर अगली releases में देखें कि बदलाव काम आया या नहीं।

अभ्यास

एक महीने की activities को QA और QC में बाँटें

आपका काम

नीचे एक टीम के एक महीने की आठ activities हैं। टीम sprints में काम करती है, यानी तय अवधि के work cycles, जिनमें से हर एक एक महीने या उससे कम का होता है। हर एक को QA या QC में बाँटें, और बताएँ कि कौन-से QC items testing हैं। फिर list के आख़िर वाले note के लिए एक QC action और दो QA actions सुझाएँ।

सामग्री
1. Build 4.2 पर login के test cases चलाए और दो failures दर्ज किए।
2. तय किया कि कोई story acceptance criteria के बिना sprint में नहीं आएगी।
3. Refund की requirements का review किया और पाँच अस्पष्ट बातें लिखीं।
4. Product owners के लिए acceptance criteria लिखने पर छोटा training session किया।
5. Developer के fix वाले build पर fail हुआ login test दोबारा चलाया।
6. टीम के लिए ज़रूरी fields वाला bug report template बनाया।
7. तीन customers से नए checkout का clickable prototype आज़माने को कहा।
8. Retrospective के बाद तय किया कि हर story अपने API error paths टेस्ट करेगी।

Note: production के पिछले 9 defects में से 6 अलग-अलग time zones में
आधी रात के आसपास की dates से जुड़े थे।
चरण
  1. हर activity से पूछें: क्या यह किसी ख़ास work product को जाँचती है, या टीम के काम करने का तरीका बदलती है?
  2. हर QC item के लिए पूछें कि वह किसी work product का review करता है या software चलाता है (दोनों testing हैं), या prototyping जैसा कोई दूसरा रूप इस्तेमाल करता है।
  3. हर QA action के लिए बताएँ कि टीम कैसे जानेगी कि वह काम आया या नहीं।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

QC और testing: 1 (build की dynamic testing), 3 (review एक static testing है) और 5 (fix की confirmation testing)। QC, पर testing नहीं: 7 (prototyping, जिसे syllabus testing से अलग QC का एक रूप गिनाता है)।

QA: 2 (entry का नियम), 4 (training), 6 (standard template) और 8 (retrospective में तय हुआ process बदलाव)।

Time zone pattern — QC: प्रभावित date logic को हर supported time zone में आधी रात के आसपास टेस्ट करें, failures report करें और fixes दोबारा टेस्ट करें। QA: date store करने या दिखाने वाली हर story अपने acceptance criteria में time zone बताए, और code review checklist में time zone का एक item जुड़े, साथ में storage का एक तय नियम (जैसे UTC)। असर जानने के लिए अगली releases में production के time zone defects की तुलना 9 में से 6 से करें।

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

Testing, QA का हिस्सा है या QC का?

ISTQB की भाषा में testing, quality control का एक रूप है, और एक प्रमुख रूप, क्योंकि यह product को जाँचती है। इसके results quality assurance को भी मिलते हैं, इस सबूत के रूप में कि processes कितने अच्छे चल रहे हैं। रोज़ की बोलचाल में बहुत लोग अब भी testing को "QA" कहते हैं।

क्या एक ही व्यक्ति QA और QC दोनों कर सकता है?

हाँ। ISTQB, QA को project में हर व्यक्ति की ज़िम्मेदारी बताता है। Tester आम तौर पर ज़्यादातर समय QC पर लगाता है और process के सुझावों व retrospectives के ज़रिए QA में योगदान देता है; developer अपना code टेस्ट करते समय QC करता है, और टीम के standards follow करते व सुधारते समय QA में योगदान देता है।

Quality management कहाँ आता है?

Quality management बड़ी छतरी है। ISTQB glossary इसे quality के मामले में किसी संगठन को दिशा देने और नियंत्रित करने की समन्वित activities बताता है, जिनमें quality policy और quality objectives, quality planning, quality control, quality assurance और quality improvement शामिल हैं। QA और QC इसके दो हिस्से हैं।

क्या QA, QC से ज़्यादा ज़रूरी है?

कोई भी दूसरे की जगह नहीं लेता। Prevention से बनने वाले defects कम होते हैं, पर कोई process उन्हें पूरी तरह ख़त्म नहीं करता, इसलिए product को जाँचना ही पड़ता है। और QC के results के बिना QA के पास यह सबूत नहीं होता कि उसके process बदलाव काम आ रहे हैं।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
टूल्स

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

टेस्ट केस जनरेटर

फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।

टेस्ट डिज़ाइन

Requirements → टेस्ट केस

क्रमांकित आवश्यकताओं की सूची को requirement-to-test मैट्रिक्स के साथ ट्रेस करने योग्य टेस्ट केस में बदलें।

टेस्ट डिज़ाइन

और गहराई से

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

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