एंड-टू-एंड प्रोडक्ट क्वालिटी एश्योरेंस
एंड-टू-एंड क्वालिटी एश्योरेंस उन गतिविधियों का समूह है जो टीम को रिलीज़ से पहले यह प्रमाण देती हैं कि उत्पाद वही करता है जो तय हुआ था, बदलावों के बाद भी करता रहता है, और असली लोड और असली हमलावरों के सामने टिकता है। यह विकास के अंत का कोई चरण नहीं है: यह तब शुरू होता है जब कोई आवश्यकता लिखी जाती है और तब ख़त्म होता है जब रिलीज़ को प्रोडक्शन में मापा जाता है।
यह गाइड पूरी प्रैक्टिस को उसी क्रम में रखती है जिसमें टीम उससे मिलती है — आवश्यकताएँ, टेस्ट डिज़ाइन, टेस्ट के स्तर और प्रकार, टेस्ट डेटा और एनवायरनमेंट, रिलीज़ गेट, और वे कुछ संख्याएँ जिन्हें ट्रैक करना सार्थक है — हर हिस्से के आधार-मानकों और उन टूल्स के साथ जिन्हें आप आज इस्तेमाल कर सकते हैं।
एंड-टू-एंड क्वालिटी एश्योरेंस में क्या-क्या आता है?
टेस्टिंग और क्वालिटी एश्योरेंस एक ही चीज़ नहीं हैं। टेस्टिंग उत्पाद की जाँच करती है ताकि दोष मिलें और यह दिखे कि वह अपनी आवश्यकताएँ पूरी करता है या नहीं; क्वालिटी एश्योरेंस वह व्यापक अनुशासन है जो प्रक्रिया को अच्छा उत्पाद बनाने लायक बनाता है — आवश्यकताएँ कैसे लिखी जाती हैं, बदलावों की समीक्षा कैसे होती है, टेस्ट कैसे डिज़ाइन होते हैं और कब चलते हैं, रिलीज़ को क्या रोकता है। ISTQB फ़ाउंडेशन सिलेबस ठीक यही रेखा खींचता है: टेस्टिंग उत्पाद-केंद्रित है, QA प्रक्रिया-केंद्रित, और दोनों क्वालिटी मैनेजमेंट का हिस्सा हैं।
- 1आवश्यकताएँ और स्वीकृति मानदंडआवश्यकता लिखे जाने पर, कोड से पहले शुरूअस्पष्टता, छूटे केस और टेस्ट-योग्यता की समीक्षा; त्रुटि-पथों के लिए भी मानदंड
- 2टेस्ट डिज़ाइनटेस्ट प्लान जोखिम-क्रम पर चलता है; इक्विवैलेंस पार्टिशनिंग, बाउंड्री वैल्यू, डिसीज़न टेबल, स्टेट ट्रांज़िशन
- 3टेस्ट के स्तर और प्रकारयूनिट, इंटीग्रेशन / API, सिस्टम, एक्सेप्टेंस; फ़ंक्शनल, रिग्रेशन, एक्सप्लोरेटरी, नॉन-फ़ंक्शनल
- 4टेस्ट डेटा और एनवायरनमेंटसिंथेटिक डेटा, रीसेट के लिए बेसलाइन, प्रोडक्शन जैसे एनवायरनमेंट, बाहरी सर्विसों की मॉक
- 5रिलीज़ गेटएग्ज़िट मानदंड: नियोजित टेस्ट चले, कोई ब्लॉकर या क्रिटिकल दोष खुला नहीं, रिग्रेशन सूट हरा, परफ़ॉर्मेंस लक्ष्य पूरेरिलीज़ रोक सकता है
शाखा: ब्लॉकर दोष रिलीज़ रोकता है
- 6ट्रैक करने लायक संख्याएँएस्केप रेट, रिक्वायरमेंट कवरेज, सूट की सेहत: हर रिलीज़ पर समीक्षा
इसके बाद:रिलीज़ के प्रोडक्शन में मापे जाने पर ख़त्म
हिस्से उसी क्रम में जिसमें टीम उनसे मिलती है, जैसा यह गाइड उन्हें रखती है। एंट्री और एग्ज़िट मानदंड हर टेस्ट स्तर के लिए स्प्रिंट से पहले सहमत होते हैं।
गुणवत्ता का भी एक से ज़्यादा आयाम है। ISO/IEC 25010 (2023 संस्करण) उत्पाद गुणवत्ता की नौ विशेषताएँ बताता है — फ़ंक्शनल उपयुक्तता, परफ़ॉर्मेंस दक्षता, कम्पैटिबिलिटी, इंटरैक्शन क्षमता (उपयोगिता), विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता, लचीलापन (पोर्टेबिलिटी) और सेफ़्टी। जो उत्पाद हर फ़ंक्शनल टेस्ट पास कर ले पर सामान्य से दोगुने ट्रैफ़िक पर गिर जाए, या सेशन कुकी लीक कर दे, वह उन विशेषताओं में फ़ेल हुआ है जिन्हें किसी ने टेस्ट ही नहीं किया। एंड-टू-एंड QA का मतलब है हर उत्पाद के लिए यह तय करना कि इनमें से कौन-सी मायने रखती हैं और हर एक को कम से कम एक सोची-समझी टेस्ट गतिविधि देना।
- फ़ंक्शनल उपयुक्तता — क्या यह वैध और अवैध इनपुट पर वही करता है जो आवश्यकताएँ कहती हैं?
- विश्वसनीयता और परफ़ॉर्मेंस दक्षता — क्या यह अपेक्षित और पीक लोड पर काम करता रहता है, और किसी विफलता के बाद उबर जाता है?
- सुरक्षा — क्या यह OWASP द्वारा सूचीबद्ध आम हमलों का प्रतिरोध करता है और व्यक्तिगत डेटा की रक्षा करता है?
- कम्पैटिबिलिटी और उपयोगिता — क्या यह उन ब्राउज़र, डिवाइस, भाषाओं और लिपियों पर काम करता है जो उपयोगकर्ताओं के पास सचमुच हैं, जिसमें अरबी दाएँ-से-बाएँ लेआउट भी शामिल है?
- रखरखाव-योग्यता — क्या टीम इसे सुरक्षित रूप से बदल सकती है, जिसके लिए ही रिग्रेशन सूट होता है?
कोड से पहले शुरू करें: आवश्यकताएँ और स्वीकृति मानदंड
सबसे सस्ता दोष वह है जो एक वाक्य में पकड़ा जाए। जो आवश्यकता कहती है "सिस्टम को जल्दी जवाब देना चाहिए" या "उपयोगकर्ता अपना डेटा एक्सपोर्ट कर सकते हैं", उसे तब तक टेस्ट नहीं किया जा सकता जब तक कोई तय न करे कि जल्दी का मतलब क्या है और कौन-सा डेटा — और अगर विकास से पहले कोई तय नहीं करता, तो डेवलपर अकेले तय करता है। अस्पष्टता, छूटे हुए केस और टेस्ट-योग्यता के लिए आवश्यकताओं की समीक्षा QA की पहली गतिविधि है, और यह एक समीक्षा है, टेस्ट नहीं।
स्वीकृति मानदंड आवश्यकता को जाँचने योग्य कथनों में बदलते हैं। Given/When/Then रूप (एक पूर्व-शर्त, एक क्रिया, एक देखा जा सकने वाला परिणाम) इसलिए काम करता है क्योंकि हर खंड एक टेस्ट स्टेप से मेल खाता है, और क्योंकि नकारात्मक केस लिखना — फ़ाइल खाली हो तो क्या होगा, भुगतान अस्वीकार हो जाए, सेशन समाप्त हो चुका हो — ऐसे फ़ैसले उजागर करता है जो स्टोरी ने कभी लिए ही नहीं।
- हर आवश्यकता से पूछें: क्या दो लोग इसे पढ़कर एक ही टेस्ट डिज़ाइन करेंगे? अगर नहीं, तो यह अस्पष्ट है।
- सफलता-पथ के साथ-साथ त्रुटि-पथों के लिए भी स्वीकृति मानदंड लिखें; ज़्यादातर प्रोडक्शन इंसिडेंट त्रुटि-पथों में ही रहते हैं।
- फ़ीचर्स को जोखिम के अनुसार क्रम दें — विफलता की संभावना गुणा विफलता का प्रभाव — और सूची के शीर्ष को सबसे ज़्यादा टेस्ट प्रयास दें। जोखिम-आधारित टेस्टिंग ही वह तरीक़ा है जिससे सीमित टीम अनंत इनपुट-स्पेस को ईमानदारी से कवर करती है।
आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर आज़माएँ: रिस्क-बेस्ड टेस्ट जनरेटर
टेस्ट के स्तर: यूनिट, इंटीग्रेशन, सिस्टम और एक्सेप्टेंस
ISTQB और ISO/IEC 29119 टेस्टिंग को स्तरों में बाँटते हैं, हर स्तर का अपना उद्देश्य और अपना मालिक है। डेवलपर द्वारा लिखे यूनिट टेस्ट एक फ़ंक्शन या क्लास को अलग से जाँचते हैं। इंटीग्रेशन टेस्ट जाँचते हैं कि कंपोनेंट और सर्विस साथ काम करते हैं — आधुनिक उत्पाद में इसका मतलब ज़्यादातर API लेयर है। सिस्टम टेस्ट जुड़े हुए उत्पाद को उसकी आवश्यकताओं के विरुद्ध जाँचते हैं, और एक्सेप्टेंस टेस्ट उसे व्यवसाय या उपयोगकर्ता की ज़रूरत के विरुद्ध।
ज़्यादातर उत्पादों के लिए API लेयर सबसे अच्छा प्रतिफल देने वाला स्तर है। बिज़नेस नियम वहाँ ब्राउज़र की लागत और अस्थिरता के बिना परखे जाते हैं, अनुरोध और उसका रिस्पॉन्स सटीक और तुलनीय होते हैं, और API कॉन्ट्रैक्ट — एक OpenAPI दस्तावेज़ — ऐसा ऑरेकल है जिसके विरुद्ध टूल हर रिस्पॉन्स जाँच सकता है। जिस उत्पाद का API अच्छी तरह टेस्ट हुआ हो, उसे कहीं कम एंड-टू-एंड UI टेस्ट चाहिए, और बचे हुए UI टेस्ट नियमों के बजाय फ़्लो पर ध्यान दे सकते हैं।
- यूनिट — तेज़, अनेक, हर कमिट पर चलते हैं; डेवलपर के स्वामित्व में।
- इंटीग्रेशन / API — सर्विसों के बीच कॉन्ट्रैक्ट, स्टेटस कोड, एरर बॉडी और डेटा को वैलिडेट करता है; वह लेयर जहाँ रिग्रेशन ऑटोमेशन सबसे ज़्यादा फल देता है।
- सिस्टम / एंड-टू-एंड — असली स्टैक पर असली UI के ज़रिए कुछ गिनी-चुनी पूरी यूज़र यात्राएँ।
- एक्सेप्टेंस — स्वीकृति मानदंड, प्रोडक्ट ओनर के साथ चलाए या दिखाए गए; रिलीज़ का फ़ैसला इसी पर टिका है।
आज़माएँ: API कॉन्ट्रैक्ट वैलिडेटर आज़माएँ: API एंडपॉइंट टेस्टर आज़माएँ: User Story → टेस्ट केस
टेस्ट के प्रकार: फ़ंक्शनल, रिग्रेशन, एक्सप्लोरेटरी और नॉन-फ़ंक्शनल
हर स्तर के भीतर टेस्ट अलग-अलग प्रकार के होते हैं। फ़ंक्शनल टेस्ट स्पेसिफ़िकेशन के विरुद्ध व्यवहार की पुष्टि करते हैं, और क्लासिक डिज़ाइन तकनीकें — इक्विवैलेंस पार्टिशनिंग, बाउंड्री वैल्यू एनालिसिस, डिसीज़न टेबल, स्टेट ट्रांज़िशन — वह तरीक़ा हैं जिससे टेस्टर सबसे कम केस से सबसे ज़्यादा दोष निकालता है। रिग्रेशन टेस्ट बदलाव के बाद मौजूदा जाँचें फिर चलाते हैं ताकि साबित हो कि कुछ टूटा नहीं; ये ऑटोमेशन के स्वाभाविक उम्मीदवार हैं क्योंकि दोहराए जाते हैं और इनका अपेक्षित परिणाम ज्ञात है। एक्सप्लोरेटरी टेस्टिंग कुशल टेस्टर द्वारा एक साथ सीखना, डिज़ाइन करना और चलाना है, और यह वे दोष खोजती है जिनके लिए किसी ने केस लिखा ही नहीं।
नॉन-फ़ंक्शनल टेस्टिंग ISO 25010 की बाक़ी विशेषताओं को कवर करती है: परफ़ॉर्मेंस (लोड, स्ट्रेस, सोक), सुरक्षा (OWASP बेसलाइन), ब्राउज़र और डिवाइस पर कम्पैटिबिलिटी, एक्सेसिबिलिटी और लोकलाइज़ेशन — सऊदी अरब और आस-पास के क्षेत्र को सेवा देने वाले उत्पादों के लिए इसका मतलब है अरबी टेक्स्ट, दाएँ-से-बाएँ लेआउट, हिजरी तारीख़ें और मिश्रित-लिपि इनपुट, जिनमें से किसी को भी केवल-लैटिन टेस्ट सूट नहीं छूता।
- पॉज़िटिव केस साबित करते हैं कि फ़ीचर काम करता है; नेगेटिव और बाउंड्री केस साबित करते हैं कि वह सुरक्षित रूप से फ़ेल होता है। सिर्फ़ पॉज़िटिव केस वाला सूट आधा सूट है।
- रिग्रेशन सेट को ऑटोमेट करें और CI में चलाएँ; हर नए फ़ीचर के आसपास एक्सप्लोरेटरी सेशन पर मानवीय ध्यान लगाएँ।
- परफ़ॉर्मेंस और सुरक्षा को अपनी-अपनी निर्धारित गतिविधि दें — ये फ़ंक्शनल टेस्टिंग के साइड-इफ़ेक्ट के रूप में नहीं होतीं।
आज़माएँ: बाउंड्री वैल्यू एनालिसिस आज़माएँ: नेगेटिव टेस्ट जनरेटर आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र आज़माएँ: सिक्योरिटी हेडर एनालाइज़र
टेस्ट डेटा और एनवायरनमेंट
हर टेस्ट को डेटा चाहिए, और वह डेटा कहाँ से आता है यह तय करता है कि टेस्ट दोहराए जा सकते हैं या नहीं और वे क़ानूनी हैं या नहीं। प्रोडक्शन डेटा को टेस्ट एनवायरनमेंट में कॉपी करना तेज़ रास्ता है और ग़लत भी: यह असली ग्राहकों का व्यक्तिगत डेटा हर उस व्यक्ति के सामने खोल देता है जिसके पास टेस्ट एक्सेस है — जिसे सऊदी व्यक्तिगत डेटा संरक्षण क़ानून ऐसी प्रोसेसिंग मानता है जिसके लिए आधार और सुरक्षा-उपाय चाहिए — और यह टेस्ट को बदलते रिकॉर्ड से बाँध देता है। उसी आकार में जनरेट किया गया सिंथेटिक डेटा — नाम, पते, फ़ोन नंबर, IBAN, तारीख़ें, सही लिपियों में — दोहराने योग्य, सुरक्षित है और उन सीमाओं तक धकेला जा सकता है जहाँ प्रोडक्शन डेटा कभी नहीं पहुँचता।
एनवायरनमेंट को उन बातों में प्रोडक्शन से मेल खाना चाहिए जो टेस्ट को प्रभावित करती हैं: वही वर्ज़न, वही कॉन्फ़िगरेशन, वही थर्ड-पार्टी निर्भरताएँ या उनकी विश्वसनीय मॉक। जिस निर्भरता को आप टेस्ट में नियंत्रित नहीं कर सकते — पेमेंट गेटवे, SMS प्रोवाइडर — उसकी जगह ऐसी मॉक रखना सबसे अच्छा है जो आपके चुने हुए रिस्पॉन्स लौटाए, विफलताओं समेत।
- टेस्ट डेटा जनरेट करें; असली व्यक्तिगत डेटा कभी टेस्ट सिस्टम में कॉपी न करें।
- एक ज्ञात बेसलाइन डेटासेट रखें जिस पर सूट रीसेट हो सके, ताकि फ़ेल होता टेस्ट उत्पाद की ग़लती हो, डेटा की नहीं।
- बाहरी सर्विसों को उनकी सीमा पर मॉक करें और उनकी त्रुटियों और टाइमआउट से अपने निपटने को टेस्ट करें, सिर्फ़ उनके सफल रिस्पॉन्स नहीं।
आज़माएँ: टेस्ट डेटा फ़ैक्टरी आज़माएँ: Mock API रिस्पॉन्स जनरेटर आज़माएँ: अस्थायी ईमेल
रिलीज़ गेट, डिफ़ेक्ट मैनेजमेंट और ट्रैक करने लायक संख्याएँ
क्वालिटी सिस्टम तभी असली है जब कोई चीज़ रिलीज़ रोक सके। एंट्री मानदंड बताते हैं कि टेस्टिंग कब शुरू हो सकती है (बिल्ड डिप्लॉय होता है, स्मोक टेस्ट पास होता है, स्वीकृति मानदंड मौजूद हैं); एग्ज़िट मानदंड बताते हैं कि यह कब रुक सकती है (नियोजित टेस्ट चले, कोई ब्लॉकर या क्रिटिकल दोष खुला नहीं, रिग्रेशन सूट हरा है, परफ़ॉर्मेंस लक्ष्य पूरे हुए)। लिखे, सहमत और लागू किए गए ये मानदंड हर स्प्रिंट के अंत की उस बहस की जगह लेते हैं कि उत्पाद "तैयार" है या नहीं।
दोषों के लिए एक जगह, एक फ़ॉर्मेट और दो अलग-अलग रेटिंग चाहिए: सेवेरिटी (उपयोगकर्ता के लिए कितना बुरा) और प्रायोरिटी (कितनी जल्दी ठीक करना है)। मेट्रिक्स कम हों और फ़ैसलों को दिशा दें: डिफ़ेक्ट एस्केप रेट (प्रोडक्शन में मिले दोष बनाम रिलीज़ से पहले मिले) बताता है कि प्रक्रिया काम कर रही है या नहीं; रिक्वायरमेंट कवरेज (किन स्वीकृति मानदंडों का पास होने वाला टेस्ट है) बताता है कि क्या अनटेस्टेड है; रिग्रेशन सूट की अवधि और अस्थिरता बताती है कि ऑटोमेशन स्वस्थ है या नहीं। कोड की लाइन-कवरेज डेवलपर की मेट्रिक है, गुणवत्ता की नहीं।
- हर टेस्ट स्तर के लिए एंट्री और एग्ज़िट मानदंड, स्प्रिंट से पहले सहमत, बिना अपवाद लागू।
- डिफ़ेक्ट रिपोर्ट का एक फ़ॉर्मेट जिससे डेवलपर बिना सवाल पूछे समस्या दोहरा सके।
- एस्केप रेट, रिक्वायरमेंट कवरेज और सूट की सेहत ट्रैक करें; हर रिलीज़ पर समीक्षा करें, हर तिमाही नहीं।
आज़माएँ: AI बग विवरण जनरेटर आज़माएँ: AI टेस्ट कवरेज एनालाइज़र आज़माएँ: रिग्रेशन सिनेरियो जनरेटर
एंड-टू-एंड QA की न्यूनतम चेकलिस्ट
- हर आवश्यकता के स्वीकृति मानदंड हैं, त्रुटि-पथों समेत, जिनकी समीक्षा विकास शुरू होने से पहले हुई है।
- फ़ीचर्स जोखिम के अनुसार क्रमबद्ध हैं और टेस्ट प्लान उसी क्रम पर चलता है।
- API स्तर पर ऑटोमेटेड रिग्रेशन सूट मौजूद है, हर बदलाव पर CI में चलता है और रिलीज़ से पहले हरा होता है।
- एंड-टू-एंड UI यात्राओं का छोटा सेट ऑटोमेटेड है; नए फ़ीचर्स को टेस्टर का एक्सप्लोरेटरी सेशन मिलता है।
- परफ़ॉर्मेंस लक्ष्य संख्याओं में लिखे हैं (p95 लेटेंसी, लक्ष्य लोड पर एरर रेट) और लॉन्च से पहले मापे जाते हैं।
- OWASP बेसलाइन जाँची गई है: एक्सेस कंट्रोल, इंजेक्शन, सिक्योरिटी हेडर, सेशन हैंडलिंग, ऑथेंटिकेशन।
- अरबी और अन्य लक्षित भाषाएँ असली लिपि, दाएँ-से-बाएँ लेआउट और स्थानीय फ़ॉर्मेट के साथ टेस्ट की गई हैं।
- टेस्ट डेटा सिंथेटिक है; कोई व्यक्तिगत डेटा प्रोडक्शन से बाहर नहीं जाता।
- एंट्री और एग्ज़िट मानदंड लिखे और लागू हैं; ब्लॉकर दोष रिलीज़ रोकता है।
- एस्केप रेट, रिक्वायरमेंट कवरेज और रिग्रेशन सूट की सेहत की हर रिलीज़ पर समीक्षा होती है।
अक्सर पूछे जाने वाले सवाल
क्या क्वालिटी एश्योरेंस और टेस्टिंग एक ही चीज़ हैं?
नहीं। टेस्टिंग उत्पाद की जाँच करती है ताकि दोष मिलें और उसे आवश्यकताओं के विरुद्ध परखा जाए। क्वालिटी एश्योरेंस उसके चारों ओर का प्रक्रिया-अनुशासन है — आवश्यकताएँ, समीक्षाएँ, टेस्ट डिज़ाइन, रिलीज़ मानदंड और मेट्रिक्स कैसे तय हों ताकि उत्पाद बनावट से ही अच्छा हो। टेस्टिंग QA की गतिविधियों में से एक है।
कितनी टेस्टिंग पर्याप्त है?
पर्याप्तता जोखिम और आपके तय किए एग्ज़िट मानदंड से परिभाषित होती है, टेस्ट केस की गिनती से नहीं। विफलता की ऊँची संभावना और बड़े प्रभाव वाले फ़ीचर को बाउंड्री, नेगेटिव, रिग्रेशन और एक्सप्लोरेटरी कवरेज मिलती है; कम जोखिम वाले फ़ीचर के स्वीकृति मानदंड जाँचे जाते हैं। जब एग्ज़िट मानदंड पूरे हों और एस्केप रेट रिलीज़-दर-रिलीज़ कम बना रहे, तो मात्रा सही है।
क्या एंड-टू-एंड क्वालिटी एश्योरेंस पूरी तरह ऑटोमेट हो सकता है?
रिग्रेशन वाला हिस्सा हो सकता है और होना चाहिए: ज्ञात अपेक्षित परिणाम वाली दोहराई जाने वाली जाँचें CI में रखी जानी चाहिए। आवश्यकता समीक्षा, एक्सप्लोरेटरी टेस्टिंग, उपयोगिता का आकलन और रिलीज़ का फ़ैसला लोगों की ज़रूरत रखते हैं। AI टूल अब टेस्ट केस, स्वीकृति मानदंड और बग रिपोर्ट का अच्छा मसौदा बनाते हैं, जिससे टाइपिंग हटती है, सोचना नहीं।
छोटी टीम कहाँ से शुरू करे?
हर स्टोरी पर स्वीकृति मानदंड और API स्तर पर ऑटोमेटेड रिग्रेशन सूट से। ये दो बदलाव ज़्यादातर दोष जल्दी और सस्ते में पकड़ लेते हैं। पहले गंभीर लॉन्च से पहले असली संख्याओं के साथ परफ़ॉर्मेंस और सुरक्षा जाँच जोड़ें, और टीम बढ़ने पर हर फ़ीचर के लिए एक्सप्लोरेटरी सेशन।
यह प्रैक्टिस कौन-से मानक परिभाषित करते हैं?
शब्दावली और टेस्ट प्रक्रिया के लिए ISTQB फ़ाउंडेशन लेवल सिलेबस, टेस्ट दस्तावेज़ीकरण और प्रक्रियाओं के लिए ISO/IEC/IEEE 29119, गुणवत्ता विशेषताओं के लिए ISO/IEC 25010, और सुरक्षा आवश्यकताओं के लिए OWASP ASVS। इस पेज के संदर्भ हर एक से जोड़ते हैं।
संदर्भ
- ISTQB Certified Tester Foundation Level (CTFL) v4.0सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
- ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsसॉफ़्टवेयर टेस्टिंग का अंतरराष्ट्रीय मानक: अवधारणाएँ, प्रक्रियाएँ, दस्तावेज़ीकरण और तकनीकें।
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelउत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
- OWASP Application Security Verification Standard (ASVS)वेब एप्लिकेशन के लिए सत्यापन-योग्य सुरक्षा आवश्यकताओं की चेकलिस्ट, तीन एश्योरेंस स्तरों में।
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
- Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)बग रिपोर्टिंग, टेस्ट डिज़ाइन, ऑटोमेशन और टेस्टिंग प्रबंधन पर व्यावहारिक सबक — कॉन्टेक्स्ट-ड्रिवन स्कूल।
- Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)स्थिरता पैटर्न — टाइमआउट, सर्किट ब्रेकर, बल्कहेड, बैक-प्रेशर — और वे विफलता के तरीके जिन्हें लोड टेस्टिंग खोजने के लिए है।
- Personal Data Protection Law (English translation)व्यक्तिगत डेटा पर सऊदी कानून — टेस्ट वातावरण में असली ग्राहक रिकॉर्ड की प्रतियों के बजाय सिंथेटिक डेटा क्यों इस्तेमाल करना चाहिए।
अभ्यास
Go-live से पहले एक छोटी टीम के QA का आकलन करें
आप अभी-अभी एक charity donation platform (काल्पनिक) से उसके पहले tester के रूप में जुड़े हैं। Web app default रूप से Arabic में है, साथ में English भी, और एक REST API उसे सेवा देता है। Release 2.0 में monthly recurring donation जुड़ रहा है, हर charge की receipt e-mail से। इसका go-live आज से एक हफ़्ते बाद तय है, साल के सबसे व्यस्त campaign से तीन हफ़्ते पहले, और product owner रीम ने आपसे पूछा है: "क्या हम अगले रविवार go-live कर सकते हैं?" नीचे के material में है कि टीम आज कैसे काम करती है (P1–P10), release की तीन requirements (R1–R3), पिछली release के defect आँकड़े, और release candidate की आज की स्थिति।
काग़ज़ पर काम करें, गाइड की न्यूनतम एंड-टू-एंड QA चेकलिस्ट को अपना पैमाना बनाकर, और जवाब वैसे लिखें जैसे आप रीम को भेजेंगे: छोटा, हर बिंदु के कारण के साथ। Material से बाहर के तथ्य न गढ़ें; जहाँ material चुप है, वहाँ सवाल लिखें। Step 4 में percentage calculator काम आएगा, और Arabic test data generator दिखाता है कि P7 में किस तरह का डेटा नहीं है। इसके लिए 25–30 मिनट रखें।
Charity donation platform (काल्पनिक) - web app Arabic (default) और English में, REST API
Team: चार developers; रीम, product owner; और आप, टीम के पहले tester (इसी sprint से)।
Release 2.0 में monthly recurring donation और हर charge की e-mail receipt जुड़ती है।
Planned go-live: रविवार 1 नवंबर 2026। साल का donation campaign, साल के सबसे व्यस्त
हफ़्ते, उसके तीन हफ़्ते बाद शुरू होता है। आज: रविवार 25 अक्टूबर 2026।
रीम का आपसे सवाल: "क्या हम अगले रविवार go-live कर सकते हैं?"
टीम आज कैसे काम करती है
P1 Stories में सिर्फ़ description है। Acceptance criteria development के बाद लिखे
जाते हैं, सिर्फ़ success path के लिए।
P2 कोई risk ranking नहीं: features उसी क्रम में टेस्ट होते हैं जिसमें वे आते हैं।
P3 Unit tests हर commit पर चलते हैं। हर sprint review में "line coverage 72%"
को टीम की quality metric बताया जाता है।
P4 API: 40 requests का एक Postman collection, हर release से पहले हाथ से चलाया
जाता है (लगभग 2 घंटे)। यह CI में नहीं है।
P5 UI: 38 automated browser tests CI में चलते हैं (45 मिनट)। इनमें से 5 कभी-कभी
फ़ेल होते हैं और पास होने तक दोबारा चलाए जाते हैं।
P6 न exploratory sessions, न performance test, न security check।
Speed पर टीम कहती है: "demo में साइट तेज़ थी।"
P7 सभी test accounts में Latin लिपि में लिखे English नाम हैं।
P8 Staging हर हफ़्ते production database की copy से refresh होता है: donors के
नाम, फ़ोन नंबर, e-mail addresses और donation history।
P9 Staging card payments को payment provider के sandbox पर भेजता है; टीम sandbox
से declined card या timeout नहीं लौटवा सकती।
P10 Defects में सिर्फ़ severity है; priority chat में तय होती है। कोई लिखित entry
या exit criteria नहीं: "जब रीम कहे कि तैयार है, तब release करते हैं।"
Release 2.0 की requirements
R1 Donor 10 से 5,000 SAR तक का monthly donation set up कर सकता है। हर महीने
उसी तारीख़ को charge होता है जिस तारीख़ को पहला donation हुआ था।
R2 Campaigns के दौरान donation pages तेज़ बने रहने चाहिए।
R3 हर monthly charge के बाद donor को e-mail से receipt मिलती है।
Release 1.9 (पिछली release)
Release से पहले मिले defects: 18।
Production में पहले 30 दिनों में रिपोर्ट हुए defects: 6।
Release 2.0, build 2.0.0-rc1, staging पर, आज की स्थिति
Acceptance criteria: 20। Passing test वाले: 14। Failing test वाले: 2। बिना test: 4।
API collection (Postman): rc1 पर अभी नहीं चला।
UI suite: तीसरे run में हरा।
Performance: मापा नहीं गया।
खुले defects
D-71 Critical Receipt e-mail न भेजी जा सके तो retry job पूरा step दोहराता है,
और donor का card दूसरी बार charge होता है। एक developer को
staging logs में मिला।
D-74 Major Receipts में donors के Arabic नाम "????" दिखते हैं। Sprint demo में
रीम को production copy से आए अपने donor account से मिला।
D-75 Minor Arabic UI: currency label amount field की ग़लत तरफ़ है।- R1–R3 की समीक्षा गाइड के सवाल से करें: क्या दो testers हर requirement पढ़कर एक ही टेस्ट डिज़ाइन करेंगे? R1 के लिए अपने सवाल और boundary values लिखें; R2 को संख्याओं के साथ दोबारा लिखें; R3 के लिए Given/When/Then में acceptance criteria लिखें, कम से कम दो error paths के साथ।
- गाइड की quality characteristics सूची के पाँचों समूहों में से हर एक के लिए release 2.0 का जोखिम, एक सोची-समझी test activity, और उसका test level बताएँ: unit, integration (API), system या acceptance।
- P1–P10 को न्यूनतम चेकलिस्ट से मिलाएँ: क्या ग़ायब या ग़लत है, और उसकी जगह क्या आएगा? Test data और environments पर ख़ास ध्यान दें।
- Release 1.9 का escape rate और release 2.0 का requirement coverage निकालें। बताएँ कि टीम को किस संख्या को quality metric कहना बंद करना चाहिए, और उसकी जगह क्या रिपोर्ट करना चाहिए।
- Release 2.0 के लिए exit criteria लिखें, उन्हें rc1 की स्थिति पर लागू करें और रीम को जवाब दें: 1 नवंबर को go या no-go, और पहले क्या सच होना चाहिए। अंत में टीम के काम करने के तरीक़े में वे तीन बदलाव लिखें जो आप सबसे पहले करेंगे, क्रम से।
मॉडल उत्तर दिखाएँ
Step 1, R1 और R2। R1 टेस्ट करने लायक दिखती है, इसीलिए इसकी कमियाँ आसानी से छूट जाती हैं। रीम के लिए सवाल: क्या 10 और 5,000 SAR दोनों मान्य हैं, जैसा शब्दों से लगता है, और क्या donor दशमलव वाली राशि (halalas) दे सकता है, जैसे 10.50? जिस महीने में donation की तारीख़ ही न हो, उसमें charge कब होगा — जैसे 31 तारीख़ को शुरू हुआ donation 30 दिन वाले महीने में, या 29, 30 या 31 तारीख़ को शुरू हुआ donation फ़रवरी में? क्या पहला donation set up के समय ही charge होता है? और monthly charge फ़ेल हो तो क्या होता है? पूरे riyal हों और दोनों सिरे मान्य हों, तो 2-value boundary values हैं 9 (rejected), 10 (accepted), 5,000 (accepted) और 5,001 (rejected); halalas मान्य हों तो step 0.01 है, यानी 9.99, 10.00, 5,000.00 और 5,000.01। Charge की तारीख़ के लिए 28, 29, 30 और 31 तारीख़ को donations शुरू करें और उन्हें 30 दिन वाले महीने और फ़रवरी से गुज़रते हुए देखें। R2 गाइड के सवाल पर सीधे फ़ेल होती है: कोई नहीं कह सकता कि "campaign" के दौरान page "तेज़" है या नहीं, इसलिए इसे न pass किया जा सकता है न fail। रीम के लिए सवाल: कौन-से pages और API calls donation pages में गिने जाएँगे, और पिछले campaign के peak पर एक साथ कितने donors donation कर रहे थे? फिर इसे उन संख्याओं के साथ दोबारा लिखें जिन पर रीम सहमत हो और जो पिछले campaign के traffic से ली गई हों, जैसे: "जब 500 donors एक साथ donation पूरा कर रहे हों, तो donation page और donation API का 95th percentile (p95) response time अधिकतम 2 सेकंड हो, और 1% से कम requests फ़ेल हों।" ये संख्याएँ सिर्फ़ उदाहरण हैं; रूप — load, percentile, सीमा, error rate — ही requirement को टेस्ट करने लायक बनाता है।
Step 1, R3। यह सिर्फ़ success path बताती है, जबकि गाइड याद दिलाती है कि ज़्यादातर प्रोडक्शन इंसिडेंट error paths में ही रहते हैं। दो error paths के साथ acceptance criteria: (a) Given एक donor जिसका 100 SAR का active monthly donation है, When monthly charge सफल होता है, Then ठीक एक 100.00 SAR का charge दर्ज होता है, और amount, तारीख़ और reference number वाली एक receipt e-mail donor की भाषा में भेजी जाती है। (b) Given वही donor, When payment provider charge को decline करता है, Then कोई receipt नहीं जाती, donation पर "Payment failed" दर्ज होता है और donor से card update करने को कहा जाता है। (c) Given एक सफल charge, When receipt e-mail भेजी नहीं जा सकती, Then card दोबारा charge नहीं होता और सिर्फ़ e-mail retry होती है। Criterion (c) ही D-71 है: development से पहले लिखा गया होता तो यह refinement में एक सवाल होता, go-live से एक हफ़्ता पहले Critical defect नहीं। कितनी बार retry हो और donation कब रोका जाए, ये रीम के फ़ैसले हैं; आपके criteria उसे ये फ़ैसले लेने पर मजबूर करते हैं। यह सब review है — ISTQB की भाषा में static testing — जो किसी code के चलने से पहले, text पर होती है।
Step 2, quality characteristics। फ़ंक्शनल उपयुक्तता: ग़लत amount, charge की तारीख़ या receipt (R1, R3); boundary value और negative tests, ज़्यादातर API के ज़रिए integration level पर, और charge-date की गणना developers के unit tests में भी। विश्वसनीयता और परफ़ॉर्मेंस दक्षता: ऐसा charge जो फ़ेल हो, timeout हो या दोहराया जाए — वही जोखिम जो D-71 दिखा चुका है — और go-live के तीन हफ़्ते बाद campaign का peak; API level पर failure tests, जिनमें payment provider और e-mail service को mock किया जाए ताकि वे decline, timeout या send failure लौटाएँ, और production जैसे configure किए गए environment पर R2 के लक्ष्यों के विरुद्ध load test — system level की गतिविधि, जिसका plan में अपना समय हो। सुरक्षा: donors का व्यक्तिगत डेटा और उनके payments; staging पर दो test donor accounts के साथ OWASP बेसलाइन — क्या एक donor API request में id बदलकर दूसरे donor का monthly donation देख या cancel कर सकता है (access control), और क्या session handling और security headers सही हैं — API और system levels पर। कम्पैटिबिलिटी और उपयोगिता: Arabic-first उत्पाद, दाएँ-से-बाएँ layout, receipts में Arabic नाम, फ़ोन और मुख्य browsers; Arabic UI में Arabic test data के साथ system tests और एक exploratory session, जो demo से पहले ही D-74 और D-75 पकड़ लेते। रखरखाव-योग्यता: charge या receipt logic में बाद का कोई बदलाव जो recurring donations को चुपचाप तोड़ दे, जबकि API का इकलौता regression check हर release पर एक बार हाथ से चलता है; CI में API collection, regression suite के रूप में, integration (API) level पर, ताकि अगला बदलाव सुरक्षित रूप से हो सके। इन सबके ऊपर acceptance testing है: रीम staging पर R1–R3 के acceptance criteria चलाती है या चलते हुए देखती है, और release का फ़ैसला इसी पर टिका है।
Step 3, practices बनाम चेकलिस्ट। P1: acceptance criteria development के बाद आते हैं और सिर्फ़ success path कवर करते हैं; उन्हें development से पहले लिखें, error paths समेत, और रीम के साथ उनकी समीक्षा करें। P2: release के features को जोखिम के अनुसार क्रम दें, यानी संभावना गुणा प्रभाव — recurring charges और receipts पहले — और test plan को इसी क्रम पर चलाएँ। P3: हर commit पर unit tests अच्छी प्रैक्टिस है; समस्या सिर्फ़ metric में है (step 4)। P4: API collection टीम की सबसे अच्छी regression संपत्ति है, और यह release से पहले एक बार हाथ से चलता है; इसे हर बदलाव पर CI में डालें, status codes और error bodies पर assertions के साथ, और इसके हरे run को release की शर्त बनाएँ। P5: पास होने तक tests दोबारा चलाने से "हरा" बेमानी हो जाता है; पाँचों flaky tests को quarantine करें, उन्हें ठीक करें या हटाएँ, और सिर्फ़ पहले run के हरे नतीजे को गिनें। P6: exploratory, performance और security testing, हर एक को अपनी निर्धारित गतिविधि चाहिए (step 2); इनमें से कोई भी फ़ंक्शनल टेस्टिंग के साइड-इफ़ेक्ट के रूप में नहीं होती। P7: सिर्फ़ Latin test data Arabic defects नहीं पकड़ सकता; diacritics (हरकात) वाले Arabic नाम, लंबे नाम और Arabic-English मिश्रित input जोड़ें। P8 सबसे गंभीर है: असली donors का व्यक्तिगत डेटा ऐसे environment में है जो test access वाले हर व्यक्ति के लिए खुला है — जिसे सऊदी व्यक्तिगत डेटा संरक्षण क़ानून ऐसी processing मानता है जिसके लिए आधार और सुरक्षा-उपाय चाहिए; और staging पर असली e-mail addresses होने से receipt feature का हर test किसी असली donor को e-mail भेज सकता है। साप्ताहिक copy बंद करें, कॉपी हुआ डेटा हटाएँ, और Arabic और English में सिंथेटिक donors जनरेट करें, एक ज्ञात baseline dataset के रूप में जिस पर suite रीसेट हो सके। ध्यान दें कि D-74 सिर्फ़ production से कॉपी हुए रीम के असली account के ज़रिए सामने आया, क्योंकि किसी test account में Arabic नाम नहीं है; सिंथेटिक Arabic test data वही defect किसी का व्यक्तिगत डेटा इस्तेमाल किए बिना पकड़ लेता है। P9: payment provider को उसकी सीमा पर mock करें ताकि test decline, timeout या देर से आया जवाब चुन सके, और असली integration के लिए कुछ sandbox runs रखें। P10: हर defect को severity के साथ priority भी दें, और entry और exit criteria लिखें (step 5)।
Step 4, संख्याएँ। Release 1.9 का escape rate: 6 ÷ (18 + 6) = 6 ÷ 24 = 25%, यानी release के 30 दिन बाद तक ज्ञात हर चार defects में से एक सिर्फ़ production में मिला; इसका पूरक, defect detection percentage (DDP), 75% है। कुछ टीमें escape rate को अनुपात के रूप में लिखती हैं: production के 6 defects बनाम release से पहले मिले 18 (हर तीन पकड़े गए defects पर एक escape हुआ); कोई भी रूप ठीक है, बशर्ते रिपोर्ट बताए कि कौन-सा इस्तेमाल हुआ और वह हर release में वही रहे। Release 2.0 का requirement coverage: 20 में से 14 acceptance criteria का passing test है, यानी 70%। 20 में से 16 (80%) का कोई न कोई test है, लेकिन जिस criterion का test फ़ेल हो रहा है वह अभी कवर नहीं है, और 4 तो टेस्ट ही नहीं हुए। "Line coverage 72%" बताता है कि unit tests ने कौन-सी lines चलाईं, यह नहीं कि कोई requirement काम करती है: गाइड इसे डेवलपर की मेट्रिक कहती है, गुणवत्ता की नहीं। इसे developers के लिए रखें, और उसकी जगह हर release पर तीन संख्याएँ रिपोर्ट करें: escape rate, requirement coverage और regression suite की सेहत — जो आज 45 मिनट का UI run है जिसमें 38 में से 5 tests (लगभग 13%) flaky हैं, और एक API collection जो CI में है ही नहीं।
Step 5, exit criteria और जवाब। Release 2.0 के exit criteria, लिखे हुए और रीम के साथ सहमत: सभी planned tests चल चुके हों; हर acceptance criterion का passing test हो; कोई खुला Blocker या Critical defect न हो; API और UI regression suites पहले run में हरे हों; R2 के performance लक्ष्य production जैसे environment पर पूरे हों; और हर खुला Major defect रीम ने लिखित रूप में स्वीकार किया हो और उसका workaround हो। rc1 पर लागू करने पर इनमें से एक भी पूरा नहीं होता: API collection rc1 पर नहीं चला और 4 criteria का कोई test नहीं; 2 criteria फ़ेल हैं; D-71 खुला Critical defect है; UI suite सिर्फ़ तीसरे run में पास हुआ; performance का न लक्ष्य है न माप; और D-74 खुला Major defect है, न स्वीकृति के साथ न workaround के साथ। इसलिए rc1 के लिए सिफ़ारिश no-go है। रीम को लिखित जवाब दें: "rc1 के साथ नहीं। 1 नवंबर को go-live अब भी संभव है, अगर गुरुवार 29 अक्टूबर तक D-71 और D-74 ठीक होकर confirmation testing पास कर लें, नया release candidate पहले ही run में API collection और UI suite पास करे, 6 खुले criteria के passing tests हों, और load test उन R2 लक्ष्यों को पूरा करे जिन पर आप सहमत हों। D-75 known issue के रूप में जा सकता है।" D-74 Major होते हुए भी must-fix सूची में है: Arabic-first उत्पाद में ज़्यादातर receipts पर ऐसा नाम होगा जिसे कोई पढ़ नहीं सकता। अगले candidate के लिए entry criteria जोड़ें: build staging पर deploy होता है, smoke test पास होता है, और उसकी हर story के acceptance criteria हैं। Release का फ़ैसला रीम का ही रहता है; आपका काम जोखिम को दिखाना और लिखित में रखना है। अगर शर्तें समय पर पूरी न हो सकें, तो campaign से पहले की कोई बाद की go-live तारीख़, campaign के दौरान दोहरे charges से सस्ती पड़ती है।
Step 5, सबसे पहले करने वाले तीन बदलाव, क्रम से। पहला P8, production copies की जगह सिंथेटिक डेटा: यह जितने हफ़्ते चलता रहे, हर हफ़्ते क़ानूनी और privacy जोखिम है, release का चाहे जो हो। दूसरा P4, API collection हर बदलाव पर CI में और exit criteria का हिस्सा: छोटी टीम के लिए गाइड के दो शुरुआती क़दमों में से एक, और वह level जहाँ D-71 का scenario — सफल charge के बाद फ़ेल हुई e-mail — mock की गई e-mail service के साथ टेस्ट हो सकता है। तीसरा P1, development से पहले error paths वाले acceptance criteria: गाइड का दूसरा शुरुआती क़दम, और R3 दिखाती है कि इन्हें बाद में लिखने की क्या क़ीमत है। इसके ठीक बाद, campaign से पहले, performance और security लक्ष्य (P6), और ये तीनों जम जाने पर हर नए feature के लिए एक exploratory session। जोखिम के आधार पर बचाव कर सकें तो दूसरा क्रम भी ठीक है; P8 को बाद के लिए छोड़ना ठीक नहीं।
अपना काम कैसे जाँचें। आपके जवाब में होना चाहिए: हर requirement के लिए कम से कम एक सवाल, और R2 में संख्याएँ; R3 के लिए error path का ऐसा criterion जो D-71 से मेल खाए; step 2 की हर गतिविधि के लिए test level; P8 को सुविधा का मामला नहीं, व्यक्तिगत डेटा की समस्या बताना; 25% (या 6 बनाम 18 का अनुपात, साफ़ लिखकर कि यह अनुपात है) और 70%, उनके formulas के साथ; और rc1 के लिए no-go, उन शर्तों के साथ जो इसे go में बदल दें। R2 के लिए अलग उदाहरण-संख्याएँ, अलग पहला बदलाव या अतिरिक्त exit criteria ठीक हैं, अगर कारण लिखा हो।
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।
QA रोडमैप का हिस्सा
इस topic से पहले
अगले topics
इस गाइड में बताए गए टूल्स
requirements में अस्पष्ट, धुँधले या परस्पर विरोधी कथन पकड़ें और Mutqan AI से स्पष्टीकरण के सवाल पाएँ।
किसी user story से Given/When/Then acceptance criteria और definition-of-done चेकलिस्ट जनरेट करें।
फ़ीचर को संभावना और प्रभाव के आधार पर स्कोर दें, फिर प्राथमिकता वाला risk-based टेस्ट प्लान जनरेट करें।
फ़ीचर के विवरण और फ़ील्ड सूची से संरचित टेस्ट केस (id, शीर्षक, पूर्व-शर्तें, स्टेप, अपेक्षित परिणाम, प्राथमिकता) जनरेट करें।
किसी user story (As a / I want / So that) को टेम्पलेट और heuristics की मदद से संरचित टेस्ट केस में बदलें।
जाँचें कि कोई API रिक्वेस्ट/रिस्पॉन्स जोड़ा अपने OpenAPI कॉन्ट्रैक्ट का पालन करता है या नहीं: path, method, पैरामीटर, बॉडी और रिस्पॉन्स स्कीमा।
तुरंत जाँचें कि कोई API endpoint पहुँच में है या नहीं: स्टेटस, रिस्पॉन्स टाइम, साइज़, content type और TLS।
equivalence class और अपेक्षित परिणामों के साथ पूरा boundary value analysis (2-value और 3-value BVA) करें।
फ़ॉर्म फ़ील्ड और API के लिए negative टेस्ट केस बनाएँ: खाली, null, ग़लत टाइप, बहुत लंबा, injection, अमान्य फ़ॉर्मेट।
किसी endpoint का रिस्पॉन्स टाइम कई सैंपल पर मापें: न्यूनतम, अधिकतम, औसत, माध्यिका और p95।
पेस्ट किए गए हेडर या किसी सार्वजनिक URL से HTTP सुरक्षा हेडर (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/CORP) को ग्रेड दें।
सिंथेटिक टेस्ट डेटा की एक ही जगह पर फ़ैक्टरी: users, customers, companies, पते, संख्याएँ, तारीख़ें और स्ट्रिंग — JSON, CSV, SQL या XML में।
success, list, detail, error और empty केस के लिए पूरे mock API रिस्पॉन्स (स्टेटस, हेडर, JSON बॉडी) बनाएँ।
बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।
मोटे-मोटे नोट्स को पूरी बग रिपोर्ट में बदलें: reproduce करने के स्टेप, अपेक्षित बनाम वास्तविक, environment, गंभीरता और attachments चेकलिस्ट।
Mutqan AI से requirements या किसी user story की तुलना मौजूदा टेस्ट केस से करके अनटेस्टेड हिस्से खोजें।