मॉड्यूल 2 · Software development lifecycle

क्वालिटी इंजीनियरिंग

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

Quality engineering (QE) काम करने का एक तरीका है जिसमें quality को product और उसकी delivery में design करके बनाया जाता है, बजाय इसके कि आख़िर में एक अलग test team मुख्य रूप से उसे जाँचे। टीम system को test करने में आसान बनाती है, हर बदलाव पर चलने वाली ज़रूरी checks automate करती है, और चलते हुए system को ऐसा बनाती है कि वह दिखाए कि वह क्या कर रहा है। Testing ग़ायब नहीं होती: वह पहले शुरू होती है और release के बाद भी चलती रहती है।

एक उदाहरण: एक टीम food-ordering app में "split the bill" (बिल बाँटना) feature जोड़ती है। Traditional तरीके में testers को तैयार build मिलता है और वे release से कुछ दिन पहले rounding में एक defect पाते हैं। Quality engineering में rounding का नियम refinement में उदाहरणों के साथ acceptance criteria बनता है, उसके unit और API tests हर commit पर चलते हैं, और production में failed split payment एक log event से दिखता है। QE industry में चलने वाला term है जिसे ISTQB Foundation syllabus परिभाषित नहीं करता, इसलिए companies के बीच इसका अर्थ बदलता है।

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

जब quality सिर्फ़ आख़िर में जाँची जाती है, तो feedback देर से आता है: पहले हफ़्ते की गलतफ़हमी चौथे हफ़्ते में पकड़ी जाती है, जब उस पर और काम बन चुका होता है। जो टीमें बार-बार release करती हैं, जैसा DevOps और continuous delivery वाले lessons में देखा, वे हर बार manual test phase का इंतज़ार नहीं कर सकतीं, और कुछ failures सिर्फ़ production में दिखते हैं, जहाँ कोई नज़र न रखे तो users उन्हें सबसे पहले पाते हैं।

एक tester के रूप में आपकी मेहनत scripted checks हाथ से दोबारा चलाने से हटकर risk, test design, testability, automation और production signals पर जाती है। सफलता यह नहीं कि आख़िर में कितने defects मिले, बल्कि यह कि कितने कम बाहर निकलते हैं और जब कोई निकलता है तो टीम कितनी जल्दी सीखती है।

Traditional QA और quality engineering

कई organisations में "QA" एक अलग टीम के रूप में विकसित हुआ जो release से पहले तैयार build टेस्ट करती है; जैसा QA और QC वाले lesson में समझाया गया, इस काम का ज़्यादातर हिस्सा quality control है। Quality engineering यह काम रखती है, पर बदल देती है कि यह कब होता है और कौन शामिल होता है, और quality को performance या security की तरह design में बनी engineering property मानती है। साथ-साथ रखकर देखें:

Traditional QA आख़िर में तैयार build टेस्ट करता है; quality engineering refinement से production तक quality पर काम करती है, पूरी टीम के साथ और हर बदलाव के कुछ मिनट बाद feedback के साथ।

Traditional QA

एक अलग टीम release से पहले तैयार build टेस्ट करती है

  1. 1Development
  2. 2Build सौंपना
  3. 3Testing
  4. 4Defects report करना
  5. 5Release
कब:
Development “पूरा” होने के बाद
कौन:
एक अलग test team
मुख्य output:
Bug reports और test execution reports
Feedback:
Code लिखे जाने के दिनों या हफ़्तों बाद
मार्गदर्शक सवाल:
“क्या हमने defects ढूँढ लिए?”

Quality engineering

पूरी टीम refinement से production तक quality built-in बनाती है

  1. 1Refinement: testability और risk
  2. 2Automated checks के साथ build
  3. 3हर बदलाव पर pipeline
  4. 4Release
  5. 5Production में observe करना

दोहराता है: चरण 1 पर वापस

कब:
Refinement से production तक
कौन:
पूरी टीम, quality engineers सक्षम बनाते और coach करते हैं
मुख्य output:
Pipeline में automated checks, testable designs, production signals, साथ में bug reports
Feedback:
हर बदलाव के कुछ मिनट बाद, और फिर production से
मार्गदर्शक सवाल:
“Defects डालना मुश्किल और पकड़ना तेज़ कैसे बनाएँ?”

Bug reports और exploratory testing दोनों में रहते हैं; बदलता यह है कि quality का काम कब होता है और कौन शामिल होता है।

  • कब: development "पूरा" होने के बाद (traditional QA), बनाम refinement से production तक (quality engineering)।
  • कौन: एक अलग test team, बनाम पूरी टीम, जिसमें quality engineers दूसरों को सक्षम बनाते और coach करते हैं।
  • मुख्य output: bug reports और test execution reports, बनाम pipeline में automated checks, testable designs और production signals, साथ में bug reports भी।
  • Feedback: code लिखे जाने के दिनों या हफ़्तों बाद, बनाम हर बदलाव के कुछ मिनट बाद और फिर production से।
  • मार्गदर्शक सवाल: "क्या हमने defects ढूँढ लिए?" बनाम "Defects डालना मुश्किल और पकड़ना तेज़ कैसे बनाएँ?"

Quality को built-in बनाना: testability, automation, observability

ज़्यादातर काम तीन engineering properties उठाती हैं; quality engineering हर feature के लिए तीनों की योजना एक साथ, code लिखे जाने से पहले बनाती है।

  • Testability: ISO/IEC 25010 testability को maintainability के अंतर्गत रखता है: test criteria कितने प्रभावी और कुशल तरीके से तय हो सकते हैं और उनके विरुद्ध tests चलाए जा सकते हैं। पूछें कि क्या आप इसे control कर सकते हैं (API से expired session तक पहुँचना, clock set करना), observe कर सकते हैं (साफ़ responses, log events, stable test ids) और isolate कर सकते हैं (payment provider को test double से बदलना)।
  • Automation: जो checks हर बदलाव पर सही रहने चाहिए, वे pipeline में उस सबसे निचले level पर चलते हैं जो defect पकड़ सके, ताकि regression उसे पैदा करने वाले बदलाव के कुछ मिनट बाद दिख जाए। Test code भी software है: review और flaky tests की policy के बिना कोई उस पर भरोसा नहीं करता।
  • Observability: चलते हुए system के signals से समझना कि वह क्या कर रहा है; आम तौर पर logs, metrics और traces। Monitoring में shift-left और shift-right वाले lesson के चार golden signals पर नज़र रखें: latency, traffic, errors और saturation। अच्छे signals "checkout fail हो गया" को "इस order के लिए payment call timeout हो गई" में बदल देते हैं।

आज़माएँ: Mock API रिस्पॉन्स जनरेटर आज़माएँ: API हेल्थ चेकर

Worked example: delivery slots, शुरू से quality के साथ

Story वही delivery-slot story है जो shift-left और shift-right वाले lesson की exercise में थी: customers checkout पर दो घंटे का delivery slot चुनते हैं; slot शुरू होने से 3 घंटे पहले तक book हो सकता है और उसमें अधिकतम 20 orders आ सकते हैं। Refinement में quality engineer, एक developer और product owner तीनों properties पर बात करते हैं:

  • Testability: service समय एक ऐसी clock से पढ़ती है जिसे tests set कर सकें; एक test-only endpoint किसी slot को 19 bookings से भर देता है; slot picker को stable test ids मिलते हैं।
  • Automation: start से 3:00:01, 3:00:00 और 2:59:59 पहले cut-off के unit tests (तय हुआ: ठीक 3:00:00 पर slot बंद); 20वीं booking (accept) और 21वीं (SLOT_FULL के साथ reject) के API tests; happy path के लिए एक UI test।
  • Observability: हर reject हुई booking अपने reason के साथ एक structured event log करती है; dashboard reason के हिसाब से rejections दिखाता है; काम के घंटों में bookings शून्य पर गिरें तो alert आता है।
  • Manual रहता है: दो customers का एक ही पल में आख़िरी जगह लेना explore करना, और Arabic में slot times।
  • Release के बाद dashboard उन slots के लिए SLOT_FULL rejections दिखाता है जिनमें अभी जगह दिख रही है। नीचे वाले log event में slot id और order id हैं, इसलिए tester एक घंटे में case reproduce कर लेता है: cancelled orders अब भी गिने जा रहे थे।
{
  "time": "2026-10-01T18:42:07Z",
  "level": "warn",
  "event": "slot_booking_rejected",
  "reason": "SLOT_FULL",
  "slot_id": "SLOT-7781",
  "booked_count": 20,
  "capacity": 20,
  "order_id": "ORD-58213",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

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

Quality engineer क्या करता है

Titles अलग-अलग होते हैं — quality engineer, QA engineer, SDET — लेकिन quality engineer पहले एक tester है: risk analysis, test design और exploratory testing केंद्र में रहते हैं। ISTQB Foundation syllabus whole-team approach बताता है, जिसमें ज़रूरी knowledge और skills वाला कोई भी व्यक्ति कोई भी काम कर सकता है और quality के लिए हर कोई ज़िम्मेदार है; quality engineer इसे व्यावहारिक बनाता है।

इसका मतलब अकेले सारे tests लिखना नहीं है; ऐसा करने से bottleneck बस एक desk पर आ जाता है। आम हफ़्ते में शामिल है:

  • Refinement में testability, risk और "हमें कैसे पता चलेगा?" वाले सवाल पूछना।
  • योजना बनाना कि कौन-से checks unit, API और UI level पर चलें, और exploration के लिए क्या छोड़ा जाए।
  • Automated tests लिखना और review करना, और developers को बेहतर tests लिखने में मदद करना।
  • Pipeline को भरोसेमंद रखना: अर्थपूर्ण quality gates, और कोई अनदेखा flaky test नहीं।
  • Developers और operations के साथ तय करना कि release के बाद कौन-से signals देखने हैं।
  • Exploratory testing, सबूत के साथ defect reports, और escaped defects से सीखना।

आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

आम गलतियाँ

  • QA team का नाम QE कर देना, जबकि testing अब भी सिर्फ़ आख़िर में होती है।
  • Quality engineering को automation समझ लेना: पुराने manual tests को UI के ज़रिए script करना और exploratory testing छोड़ देना।
  • सारे tests quality engineer से लिखवाना, जिससे developers quality की ownership छोड़ देते हैं।
  • Testability की ज़रूरतें refinement में उठाने की बजाय तब उठाना जब automation अटक जाए।
  • बिना तय production signals के release करना, जिससे टीम के देखने से पहले users failure report कर देते हैं।
  • सफलता को tests की संख्या या coverage percentage से आँकना, बजाय escaped defects और उन्हें पकड़ने में लगे समय के।

QA का नज़रिया

अपने अगले refinement से शुरुआत करें। हर story के लिए पूछें: हमें कैसे पता चलेगा कि यह काम करती है (कौन-से checks, किस level पर)? हम इसे कैसे टेस्ट करें (state, data, समय)? हमें कैसे पता चलेगा कि production में यह अब भी काम करती है (कौन-सा signal, कौन-सा alert)? जवाब acceptance criteria में लिखें।

Developers के साथ testability पर, product owner के साथ risk पर, और operations या SRE के साथ signals और alerts पर काम करें। हर escaped defect के बाद पूछें कि तीनों में से क्या चूका: वह testable नहीं था, check नहीं हुआ, या दिखाई नहीं दिया? जवाब retrospective में ले जाएँ; यही उसी काम का quality assurance वाला पहलू है।

अभ्यास

Password reset story के लिए quality engineering plan लिखें

आपका काम

नीचे दी गई story पढ़ें और चार हिस्सों में plan लिखें: इसे testable बनाने के लिए क्या बनाना होगा, कौन-से automated checks किस level पर चलेंगे, कौन-से signals दिखाएँगे कि production में यह काम कर रही है, और क्या manual रहेगा। आख़िर में product owner के लिए अपने सवाल लिखें।

सामग्री
Story: एक customer के रूप में, मैं e-mail से अपना password reset करना चाहता हूँ
       ताकि मैं फिर से sign in कर सकूँ।

AC1  Reset link 30 मिनट तक valid है।
AC2  एक link सिर्फ़ एक बार इस्तेमाल हो सकता है।
AC3  एक account के लिए एक घंटे में 5 reset requests के बाद, आगे की requests
     घंटा पूरा होने तक refuse होती हैं।
AC4  E-mail address registered हो या न हो, page एक ही message दिखाता है।
चरण
  1. हर acceptance criterion के लिए लिखें कि आपको क्या control, observe या isolate करना होगा।
  2. हर check को उस सबसे निचले level पर रखें जो defect पकड़ सके: unit, API या UI।
  3. Log events, एक metric और एक alert के नाम लिखें, और यह भी कि क्या कभी log नहीं होना चाहिए।
  4. लिखें कि किसके लिए अब भी एक व्यक्ति चाहिए, और खुले सवाल क्या हैं।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Testability: एक clock जिसे tests set कर सकें, ताकि 30 मिनट इंतज़ार किए बिना expiry जाँची जा सके; link पढ़ने के लिए test inbox या fake e-mail service; tests के बीच rate-limit counter reset करने का तरीका; stable test ids।

Automation: 30 मिनट से ठीक पहले, ठीक 30 पर और ठीक बाद expiry के unit tests, single use के, और 5वीं व 6ठी request के; API tests कि registered और unregistered addresses को एक ही response मिले और इस्तेमाल हो चुका link refuse हो; पूरी journey का एक UI test।

Observability: reset requested, e-mail sent, reset completed और reason (expired, used, rate limited) के साथ reset rejected के events; completed बनाम requested resets का एक metric; ऐसा alert जो तब आए जब requests आ रही हों पर एक घंटे तक कोई reset e-mail न जाए। Token, link या नया password कभी log न करें।

Manual: Arabic में और phone पर e-mail, और link को दूसरे device पर खोलना। सवाल: क्या ठीक 30:00 पर link valid है? क्या नया link पुराने links रद्द करता है? AC3 का घंटा पहली request से गिना जाता है या घड़ी के घंटे की शुरुआत से? क्या AC3 का refusal बता देता है कि account मौजूद है, जिसकी AC4 मनाही करता है?

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

क्या quality engineering और test automation एक ही हैं?

नहीं। Automation इसके तीन स्तंभों में से एक है, testability और observability के साथ, और यह testing की बुनियाद पर टिका है: risk analysis, test design और exploratory testing। जो टीम अपनी पुरानी end-of-cycle scripts automate कर ले पर टेस्ट अब भी सिर्फ़ आख़िर में करे, उसके पास automation है, quality engineering नहीं।

क्या quality engineer बनने के लिए coding आनी चाहिए?

ज़्यादातर quality engineer roles में उम्मीद होती है कि आप test code पढ़ और लिख सकें और pipelines, logs और APIs के साथ काम कर सकें। पहले testing की बुनियाद सीखें, क्योंकि कमज़ोर test design को automate करने से वह बस तेज़ी से दोहराया जाता है; फिर code धीरे-धीरे जोड़ें, API checks और logs पढ़ने से शुरू करके।

क्या quality engineering manual और exploratory testing की जगह ले लेती है?

नहीं। Automated checks उसकी पुष्टि करते हैं जिसका किसी ने पहले से अनुमान लगाया था; exploratory testing वह ढूँढती है जिसका किसी ने अनुमान नहीं लगाया। ISTQB Foundation syllabus DevOps के बारे में यही बात कहता है: बहुत ज़्यादा automated testing के बावजूद manual testing, ख़ासकर user के नज़रिए से, अब भी ज़रूरी है।

क्या quality engineer और SDET एक ही हैं?

ये titles overlap करते हैं और companies के बीच इनका अर्थ बदलता है। SDET (software development engineer in test) आम तौर पर test code और tools बनाने पर ज़ोर देता है; quality engineer आम तौर पर testability, automation, observability और process के व्यापक काम को कवर करता है। Title की बजाय job description की duties पढ़ें।

संदर्भ

टूल्स

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

रिस्क-बेस्ड टेस्ट जनरेटर

फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।

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

API हेल्थ चेकर

एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।

API टेस्टिंग

रिग्रेशन सिनेरियो जनरेटर

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

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

और गहराई से

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

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