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

सॉफ़्टवेयर टेस्टिंग क्यों ज़रूरी है

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

Software लोग बनाते हैं, और लोग गलतियाँ करते हैं। कुछ गलतियाँ requirement, design या code में defect छोड़ जाती हैं, और कुछ defects failure पैदा करते हैं: चलता हुआ system वह करता है जो उसे नहीं करना चाहिए, या वह नहीं करता जो उसे करना चाहिए। Testing इसलिए ज़रूरी है क्योंकि यह इन problems को users से पहले ढूँढती है और team को बताती है कि release से पहले कितना risk बाकी है।

उदाहरण: किसी online shop का update, customer के payment page से cart पर लौटने पर discount code दो बार लगा देता है। कोई शिकायत नहीं करता, लेकिन हर ऐसे order पर shop को नुकसान होता है, जब तक हफ़्तों बाद कोई accounts में इसे पकड़ न ले। "Cart पर वापस" वाले रास्ते का एक test यह failure मिनटों में दिखा देता।

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

Failures की कीमत product को पैसे और भरोसे में चुकानी पड़ती है, और कुछ क्षेत्रों में लोगों की safety या कंपनी की कानूनी स्थिति में भी। Testing वह तरीका है जिससे team release से पहले जान पाती है कि इनमें से किस खतरे का सामना है।

Tester के रूप में आपके हर फ़ैसले के पीछे यही वजह है। आप कभी सब कुछ test नहीं कर सकते, इसलिए वहाँ सबसे ज़्यादा test करते हैं जहाँ failure सबसे ज़्यादा नुकसान करेगा, और report उन शब्दों में करते हैं जिनसे team फ़ैसले लेती है: क्या गलत हो सकता है, किसके लिए और कितनी संभावना है, सिर्फ़ यह नहीं कि कितने tests pass हुए।

एक failure की कीमत क्या हो सकती है

Failure की कीमत सिर्फ़ उसे ठीक करने का समय नहीं, बल्कि वह सब कुछ है जो users, business और team के साथ इसलिए होता है क्योंकि failure उन तक पहुँचा। एक ही defect एक product में मामूली और दूसरे में गंभीर हो सकता है: गलत date format किसी internal report के पाठकों को बस खटकता है, लेकिन दवा के schedule में यह safety की समस्या है।

  • पैसा: खोई हुई sales, refunds और मुआवज़ा, गलत prices या fees, और incident का काम जो planned काम की जगह ले लेता है।
  • प्रतिष्ठा: failures झेलने वाले users छोड़ देते हैं और दूसरों को बताते हैं; payments, health और personal data में भरोसा वापस पाना सबसे कठिन है।
  • Safety: जब software medical devices, vehicles या machines को नियंत्रित करता है, तो failure लोगों को चोट पहुँचा सकता है, इसलिए इन क्षेत्रों में testing ज़्यादा औपचारिक और गहरी होती है।
  • कानूनी और regulatory compliance: contracts outages पर penalty तय कर सकते हैं, और सऊदी अरब के Personal Data Protection Law जैसे कानून personal data के लिए दायित्व तय करते हैं। Testing ख़ुद भी किसी contract, कानून या regulatory standard के तहत ज़रूरी हो सकती है।

Testing risk घटाती है और फ़ैसलों को जानकारी देती है

Risk ऐसी घटना है जो हो सकती है और नुकसान पहुँचाएगी; ISTQB इसे दो factors से बताता है: likelihood (संभावना) और impact (असर)। Testing दो तरह से risk level घटाती है: यह defects ढूँढती है जिन्हें developers फिर ठीक करते हैं, और जब किसी risky हिस्से के tests pass होते हैं, तो team के पास सबूत होता है, सिर्फ़ उम्मीद नहीं, कि वह हिस्सा test की गई परिस्थितियों में काम करता है।

Testing जानकारी भी देती है, और stakeholders को सोच-समझकर फ़ैसले लेने के लिए ज़रूरी जानकारी देना ISTQB का एक test objective है। गुरुवार को release करना है या नहीं, यह तय करने वाले product owner को नीचे जैसी तस्वीर चाहिए। फ़ैसला उनका है; tester इस तस्वीर को सटीक और उसकी सीमाओं के बारे में ईमानदार बनाता है।

  • Tested: checkout, card payment और refunds; 48 tests, 46 pass, 1 fail, 1 नहीं चला।
  • Open: एक major defect; refund e-mail गलत amount दिखाता है, हालाँकि refund ख़ुद सही है।
  • Test नहीं हुआ: iOS पर wallet payments, क्योंकि test device उपलब्ध नहीं था।
  • विकल्प: support को note देकर release करें और e-mail को 4.2.1 में ठीक करें, या एक दिन रुकें।

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

Testing क्या दिखा सकती है और क्या नहीं

ISTQB syllabus के सात testing principles में पहला यह है कि testing defects की मौजूदगी दिखाती है, उनकी गैरमौजूदगी नहीं। Fail हुआ test, जब आप जाँच लें कि test और उसका environment सही हैं, दिखाता है कि defect मौजूद है; pass हुआ test सिर्फ़ इतना दिखाता है कि इस test ने, इस data और environment में, कोई defect नहीं दिखाया। Testing अनदेखे defects की संभावना घटाती है लेकिन software को सही साबित नहीं कर सकती, और exhaustive testing असंभव है: कुछ text fields वाले एक छोटे form में भी इतने input combinations होते हैं जितने कोई चला नहीं सकता।

Testing quality में योगदान देती है, पर अकेले quality नहीं बनाती: जो defects यह ढूँढती है, वे debugging और fixing से हटाए जाते हैं। और जैसा verification और validation वाले पाठ में देखा, software अपनी specification के हर test में pass होकर भी users की ज़रूरतें पूरी करने से चूक सकता है; ISTQB इसे absence-of-defects fallacy कहता है।

इसलिए "सारे tests pass हुए" का मतलब है कि planned tests को कोई failure नहीं मिला, यह नहीं कि कोई defect बचा नहीं या जो हिस्से test नहीं हुए वे काम करते हैं। अच्छी report बताती है कि क्या test नहीं हुआ और कितना risk बाकी है, जिसे residual risk कहते हैं।

Worked example: एक defect, तीन अलग पलों पर

देर से मिला defect ज़्यादा महँगा पड़ता है क्योंकि उस पर ज़्यादा काम बन चुका होता है: requirement का defect design, code, tests और data में बदल जाता है जो सब उसी के पीछे चलते हैं। ISTQB इसे principle के रूप में कहता है: early testing समय और पैसा बचाती है। कितना ज़्यादा, यह project-दर-project बदलता है, इसलिए इसे किसी तय multiplier से नहीं, ठोस नतीजों से समझाएँ।

Requirement: "Customers 24 घंटे के अंदर order cancel करके पूरा refund पा सकते हैं।" इसमें यह नहीं बताया गया कि 24 घंटे कब से गिने जाएँगे, न यह कि "पूरा" में delivery fee शामिल है या नहीं, और developer मान लेता है कि घंटे order देते ही शुरू होते हैं। इसी मान्यता से लिखे गए tests सब pass होंगे। इस defect को तीन पलों तक देखें:

  • Requirements review में मिला: tester पूछता है "24 घंटे कब से, और क्या delivery fee लौटाई जाएगी?" Product owner जवाब देता है (payment confirmation से; fee सिर्फ़ तब जब order dispatch न हुआ हो) और वाक्य दोबारा लिखा जाता है। कीमत: एक बातचीत और एक edit, क्योंकि defect पर अभी कुछ बना ही नहीं।
  • System testing में मिला, जिसमें testers पूरी, integrated application को test environment में जाँचते हैं: bank transfer से paid और अगले दिन confirm हुए order का test दिखाता है कि उसे confirmation के तुरंत बाद भी cancel नहीं किया जा सकता। कीमत: defect report, code change, confirmation test, regression tests और शायद release में देरी।
  • Production में मिला: transfer से pay करने वाले customers cancel नहीं कर पाते और शिकायत करते हैं, जबकि दूसरों को ऐसे fee refunds मिल जाते हैं जो business ने कभी चाहे ही नहीं थे। कीमत: ऊपर का सब कुछ, साथ में incident, hotfix, manual refunds, orders का data सुधारना और खोया भरोसा।
24 घंटे में cancel करने का एक अस्पष्ट नियम, तीन पलों पर पकड़ा गया: review में कीमत एक बातचीत और एक edit, system testing में rework और दोबारा testing, production में इनके साथ incident, refunds और खोया भरोसा। वैचारिक मॉडल

Requirements review में मिलासबसे पहले

  1. 1Tester पूछता है: 24 घंटे कब से? क्या delivery fee लौटेगी?
  2. 2Product owner जवाब देता है; वाक्य दोबारा लिखा जाता है
Defect पर क्या बन चुका:
अभी कुछ नहीं
किसे पता चलता है:
Tester, requirement पर सवाल उठाकर
ठीक करने की कीमत:
एक बातचीत और एक edit

System testing में मिला

  1. 1Test: bank transfer से paid order, अगले दिन confirm
  2. 2Confirmation के तुरंत बाद भी cancel मना हो जाता हैफ़ेल
  3. 3Defect report, code change, confirmation और regression tests
Defect पर क्या बन चुका:
Design, code और tests
किसे पता चलता है:
Tester, एक fail हुए test से
ठीक करने की कीमत:
Rework, दोबारा testing और शायद release में देरी

Production में मिलासबसे देर से

  1. 1Transfer से pay करने वाले cancel नहीं कर पाते; दूसरों को अनचाहे fee refunds मिलते हैं
  2. 2शिकायतें support तक पहुँचती हैं
  3. 3Incident, hotfix, manual refunds, orders का data सुधारना
Defect पर क्या बन चुका:
Design, code, tests और असली orders
किसे पता चलता है:
Customers और support
ठीक करने की कीमत:
यह सब, साथ में incident, manual refunds, data सुधार और खोया भरोसा

कीमत defect पर बने काम के साथ बढ़ती है; कितनी बढ़ती है यह project-दर-project अलग है, इसलिए यहाँ कोई तय multiplier नहीं दिखाया गया।

आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर

आम गलतियाँ

  • यह वादा करना, या दूसरों को यह मानने देना, कि test हुआ software defects से मुक्त है।
  • हर feature को एक जैसी गहराई से test करना, बजाय वहाँ सबसे ज़्यादा test करने के जहाँ failure सबसे महँगा होगा।
  • सिर्फ़ गिनती report करना, जैसे "120 tests pass हुए", बिना यह बताए कि क्या test नहीं हुआ और क्या अब भी open है।
  • Finished build का इंतज़ार करना और requirements review छोड़ देना, जहाँ defects हटाना सबसे सस्ता है।
  • देर से मिले defects की कीमत के लिए कोई तय multiplier तथ्य की तरह बताना, बजाय अपने product के ठोस नतीजों के।
  • Release का gatekeeper बन जाना: testers फ़ैसले को जानकारी देते हैं; फ़ैसला वे stakeholders लेते हैं जिनका risk है।

QA का नज़रिया

असली team में हर नए feature के बारे में refinement के दौरान पूछें: "अगर यह production में fail हुआ तो क्या होगा, और किसके साथ?" यह सवाल product owner, developers और ज़रूरत हो तो support, security या compliance के साथियों से पूछें। जवाब बताते हैं कि कहाँ गहराई से test करना है, कहाँ quick check काफ़ी है, और कौन-से सवाल अभी उठाने हैं जब वे सस्ते हैं।

लिखकर रखें कि आपने क्या test किया, क्या मिला, क्या test नहीं कर पाए और कितना risk बाकी है। जब कोई पूछे "क्या यह ready है?", तो सिर्फ़ हाँ या ना नहीं, यही जानकारी दें। Production incident के बाद पूछें कि defect किस पहले वाले पल पर पकड़ा जा सकता था, और अगली बार वह check जोड़ें।

अभ्यास

तय करें कि release में testing कहाँ सबसे ज़्यादा मायने रखती है

आपका काम

एक shopping app के अगले release में नीचे दिए चार बदलाव हैं, और आपके पास सिर्फ़ दो को गहराई से test करने का समय है। वे दो चुनें, failure की कीमत के आधार पर अपने चुनाव को सही ठहराएँ, और product owner के लिए एक छोटा note लिखें।

सामग्री
Release 3.8 — बदलाव

1. Help page पर "Contact us" button का रंग बदलेगा।
2. नया: customers आगे के payments के लिए card save कर सकते हैं।
3. बदला: VAT अब invoice के total की जगह हर line पर round होगा।
4. नया: हर store page उसके opening hours दिखाएगा।
चरण
  1. हर बदलाव के लिए एक realistic तरीका लिखें जिससे वह production में fail हो सकता है।
  2. बताएँ कि किस पर असर पड़ेगा और कीमत किस तरह की है: पैसा, प्रतिष्ठा, safety, या कानूनी और regulatory।
  3. बदलावों को इस क्रम में रखें कि किसे कितनी testing चाहिए।
  4. तीन या चार lines का note लिखें: किसकी गहरी testing होगी, किसका quick check, और कितना risk बाकी है।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Saved cards, सबसे ज़्यादा risk: बिना सहमति card से पैसा कट सकता है, card किसी दूसरे account को दिख सकता है, या हटाने के बाद भी रखा रह सकता है। Card save करने वाला हर customer प्रभावित होगा, और कीमत पैसे, भरोसे और कानूनी जोखिम में है, क्योंकि personal data कानून से सुरक्षित है और card data पर payment industry के सख़्त नियम लागू होते हैं। Declined cards, card हटाना और एक device पर दो accounts test करें।

VAT rounding, ऊँचा risk: कई orders पर totals सही amount या accounting records से एक halala अलग हो सकते हैं। Customers और finance team प्रभावित होंगे, और कीमत पैसे और कानूनी जोखिम में है, क्योंकि tax invoices regulated हैं। एक line और कई lines वाले invoices, और ऐसे amounts test करें जिन पर rounding से नतीजा बदलता है।

Opening hours, कम risk: गलत समय या गलत time zone customers को बंद store तक भेज देता है, जिससे उनका समय बर्बाद होता है और shop की प्रतिष्ठा को कुछ नुकसान होता है। Button का रंग, सबसे कम risk: मुख्य खतरा इतना कम contrast है कि कमज़ोर नज़र वाले users पढ़ न सकें, जिसे एक quick check पकड़ लेता है।

Note: "Saved cards और VAT rounding की गहरी testing होगी; opening hours और button का quick check। बाकी risk: opening hours सिर्फ़ एक time zone में check हुए हैं, और pass हुए tests saved cards में defects की संभावना घटाते हैं, ख़त्म नहीं करते।"

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

अगर testing यह साबित नहीं कर सकती कि कोई defect नहीं है, तो testing क्यों करें?

क्योंकि यह risk घटाती है और अंदाज़ों की जगह सबूत देती है। Release से पहले मिले हर failure को team users तक पहुँचने से पहले ठीक कर सकती है, या कम से कम उस पर फ़ैसला ले सकती है, और test हुआ हर हिस्सा team को बताता है कि कितना risk बाकी है। Testing के बिना team इनमें से कुछ भी जाने बिना release करती है।

क्या production में मिला bug ठीक करना सच में 100 गुना महँगा होता है?

कोई एक संख्या नहीं है। ऐसे multipliers बहुत दोहराए जाते हैं, लेकिन असली अंतर project, defect और team के काम करने के तरीके पर निर्भर करता है। जो सच है, और जिसे ISTQB syllabus एक principle के रूप में कहता है, वह दिशा है: defect जितनी देर से मिले, उस पर उतना ज़्यादा काम बन चुका होता है और उसे ठीक करना उतना महँगा होता है। इसे अपने product के नतीजों से समझाएँ।

Software release के लिए तैयार है, यह कौन तय करता है?

वे stakeholders जिनका risk है: आम तौर पर product owner या business owner, कभी-कभी release board, और regulated क्षेत्रों में वे लोग जिन्हें नियम तय करते हैं। Testers इस फ़ैसले के लिए जानकारी देते हैं (results, open defects, जो हिस्से test नहीं हुए और बाकी risk), और पूछे जाने पर सिफ़ारिश।

क्या ज़्यादा testing का मतलब हमेशा बेहतर quality है?

नहीं। Testing defects ढूँढती है और quality का मूल्यांकन करती है; quality तभी सुधरती है जब defects ठीक हों और उनके कारणों पर काम हो। कम risk वाले हिस्सों में extra tests से ज़्यादा फ़ायदा नहीं होता, जबकि वही समय किसी high-risk हिस्से या early review पर लगाने से गंभीर failures रोके जा सकते हैं।

संदर्भ

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
  • ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022सॉफ़्टवेयर टेस्टिंग का अंतरराष्ट्रीय मानक: अवधारणाएँ, प्रक्रियाएँ, दस्तावेज़ीकरण और तकनीकें।
  • Personal Data Protection Law (English translation)सऊदी डेटा एवं AI प्राधिकरण (SDAIA) · 2023व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।
टूल्स

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

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

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

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

AI Requirement अस्पष्टता डिटेक्टर

requirements में अस्पष्ट, धुँधले या परस्पर विरोधी कथन पकड़ें और Mutqan AI से स्पष्टीकरण के सवाल पाएँ।

आवश्यकता विश्लेषण AI

और गहराई से

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

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