10

कभी-कभी मेरी क्यूए टीम बग की रिपोर्ट करती है, लेकिन न तो मुझे और न ही उन पर कोई विचार है कि उन्हें कैसे पुन: पेश किया जाए। यह बहुत लंबे और निराशाजनक डिबगिंग सत्रों की ओर जाता है जो कभी-कभी परिणाम भी नहीं देते हैं।

मेरा सॉफ्टवेयर मालिकाना हार्डवेयर के साथ बहुत अधिक बंधा हुआ है ताकि कीड़े एक साथ कई दिशाओं से आ सकें।

क्या मुझे "आपके सॉफ़्टवेयर के दुर्घटनाग्रस्त होने पर उससे अधिक की उम्मीद करनी चाहिए जब मैंने एक बटन दबाया है" या क्या मुझे खुद पता लगाना चाहिए कि क्या हुआ?

संपादित करें:

मेरे एक सहकर्मी ने बताया कि हम शायद यहां सभी डेवलपर्स हैं, इसलिए परिणाम थोड़ा पूर्वाग्रह का शिकार हो सकते हैं

testing bug qa reporting

— एरिक
स्रोत

1

यह वास्तव में एक उत्तर नहीं है, लेकिन यह इंगित करने के लायक है कि आपके आवेदन के अंदर (अधिक) लॉगिंग करके आप इस मुद्दे को कुछ हद तक कम कर सकते हैं। शायद आपका टेस्ट बिल्ड एक वर्बोज़ लॉगिंग मोड पर सेट हो सकता है जो आपको डिबगिंग सत्र में आपकी सहायता करने के लिए अस्पष्ट प्रजनन कदम देगा?

— क्रिस फॉलेट

वास्तव में, परीक्षण ऐसा होना चाहिए। QA को QA करना चाहिए।

— मटनज़

1

अपने उत्पाद में तर्क जोड़ने पर विचार करें जो आपको उपयोगकर्ता द्वारा उठाए गए कदमों को वापस करने में मदद करता है, और एक क्यूए-बटन है जो बग रिपोर्टर को आपके उत्पाद से उक्त जानकारी को आसानी से निकालने और बग रिपोर्ट में जोड़ने की अनुमति देता है।

वास्तविक स्थिति के कम से कम स्क्रीनशॉट में त्रुटि को पुन: उत्पन्न करने में अधिकांश समय मदद मिलेगी। (ऊपर लॉगिंग कमेंट देखें)। Usersnap बेहतर बग रिपोर्टिंग और संचार समय को बचाने के लिए एक उपकरण है।

— ग्रेगोर

31

क्यूए को हमेशा कोशिश करनी चाहिए और बग को जितना संभव हो उतना आसान बनाना चाहिए और बग विवरण में उठाए गए कदमों को शामिल करना चाहिए।

हालांकि, अगर वे आसानी से बग को पुन: उत्पन्न नहीं कर सकते हैं, तो उन्हें अभी भी बग डेटाबेस में उपयुक्त शीर्षक / शीर्षकों के साथ दर्ज किया जाना चाहिए और बग का कारण बनने के लिए उन्होंने जो किया उसका पूरा विवरण है। बग विवरण में स्पष्ट रूप से कहा जाना चाहिए कि वे बग को पुन: उत्पन्न नहीं कर सकते हैं (शायद कुछ टिप्पणियों के साथ "पांच बार कोशिश की, यह एक बार हुआ)। इस तरह, यदि कोई अन्य समान बग देखता है, तो वे अपने निष्कर्षों के साथ बग डेटाबेस में जोड़ सकते हैं और साथ ही आपको अधिक से अधिक जानकारी मिल सकती है जो समस्या को ट्रैक करने में आपके समय को बचाने के लिए आगे की पंक्ति के लिए महत्वपूर्ण हो सकती है।

इसके अलावा, आपको जानकारी को फ़िल्टर करने के लिए मिलता है - विभिन्न प्रणालियों में बहुत सारे कीड़े हो सकते हैं जिन्हें आप जानते हैं कि वे सभी (जैसे) कोड के एक क्षेत्र से जुड़े हुए हैं - यदि क्यूए कुछ भी रिपोर्ट नहीं करता है (क्योंकि वे उन्हें पुन: पेश नहीं कर सकते हैं ) तब यह जानकारी आपको नहीं मिलती है।

— PhillC
स्रोत

... a full description of what they did to cause the bug। यह रेपो से कैसे अलग है?

— स्टीवन एवर्स

13

@SnOrfus: परिभाषा के अनुसार, पुनरुपयोग योग्य हैं। यदि आप बग ढूंढते हैं, लेकिन बाद में इसे पुन: पेश नहीं कर सकते हैं, तो यह जानना अभी भी उपयोगी है कि आप उस समय क्या कर रहे थे, जिससे यह पता चल सके कि यह किस कारण से हुआ।

— ब्लूराजा - डैनी पफ्लुगुएफ्ट

3

@SnOrfus: The software crashedबनाम The software crashed editing foowidgetsबनाम

The software crashes when viewing a foowidget and toggling the frobulator 10 times followed by pressing this key sequence (stack trace attached)

। अंतिम विवरण स्पष्ट नहीं हो सकता है, लेकिन पहले के बजाय दूसरा विवरण होना निश्चित रूप से सहायक है।

— डेन्थ 21:12

@ डॅनेथ: काफी फेयर। शायद मैं एक पूर्ण विवरण के शब्दार्थ में बहुत दूर हो रहा हूं ।

— स्टीवन एवर्स

सुनिश्चित करें कि "बंद किया / पुन: पेश नहीं कर सका" आपके दोष ट्रैकर में उपयोग करने के लिए उपलब्ध (वहां और स्वीकार्य) है।

— मटनज़

13

ऐसा लगता है कि आपका क्यूए विभाग बहुत अधिक खोजपूर्ण परीक्षण कर रहा है (यानी उनके पास एक अच्छी परीक्षा योजना नहीं है)।

खोजपूर्ण परीक्षण अच्छा है, और समस्या क्षेत्रों की पहचान करता है, लेकिन वहाँ से उन्हें प्रजनन योग्य परीक्षण मामलों (यानी। एक परीक्षण योजना) को परिभाषित करना चाहिए जो विशिष्ट बगों को प्रकट करेगा।

सही रीप्रो क्यों जरूरी है इसके कई कारण हैं (न सिर्फ अच्छा है, बल्कि आवश्यक है):

आपको इसे वापस करना होगा ताकि आप कारण को डिबग / ट्रैक कर सकें।
क्यूए को एक बार ठीक करने के बाद आपको सत्यापित करने में सक्षम होने की आवश्यकता होगी।
आगे के टेस्ट पास को पिछले बग्स पर रिग्रेशन करने की आवश्यकता होगी।
ज्ञात बग को खारिज किया जा सकता है अगर एक्सपोजर बहुत छोटा है या रिप्रो बहुत अधिक संभावना नहीं है।

तो, स्टीवज़ेट्टी नोटों के रूप में: इसे नो रिप्रो के रूप में बंद करें और काम पर वापस जाएं।

— स्टीवन एवर्स
स्रोत

3

पुन: उत्पन्न करने के चरणों के साथ समस्या यह है कि आम तौर पर क्रैश बग के साथ वे प्रत्याशित या तलाश नहीं किए जाते हैं और वे आमतौर पर एक परीक्षण योजना के बीच में होते हैं। उन्हें इसे पुन: पेश करने की कोशिश करनी चाहिए लेकिन कई बार यह अपूर्ण है। मैन्युअल परीक्षण के लिए एक अच्छा डेस्कटॉप स्क्रीन रिकॉर्डिंग सॉफ्टवेयर परीक्षण के मामलों के दौरान हर कदम और टाइमस्टैम्प पर कब्जा कर सकता है जो दुर्घटना के साथ-साथ किसी भी साधारण गलतियों या प्रतीत होने वाली असंगत विवरणों को कैप्चर कर सकता है जो कि क्यूए व्यक्ति को पुन: उत्पन्न करने के लिए अपने कदमों में चूक हो सकती है। इसके साथ और परीक्षण लॉग में एक डेवलपर के पास अधिक स्पष्ट तस्वीर होनी चाहिए।

— maple_shaft

3

@maple_shaft यह वास्तव में सच है - मैं क्यूए से हर बग की 100% प्रतिलिपि प्रस्तुत करने की उम्मीद नहीं करता हूं। स्क्रीन रिकॉर्डिंग एक दिलचस्प विकल्प है और निश्चित रूप से अधिक विचार को सहन करता है, क्योंकि यह परीक्षक के कंधे पर देखने का अवसर दिए बिना अधिक लचीलापन देता है।

— माइकल के

2

@maple_shaft: मैं सहमत हूं, और MTM में वह अंतर्निहित है। इस मामले में, हालांकि, एरिक ("एक दुर्घटना थी") के बीच एक महत्वपूर्ण अंतर है और सबसे अच्छा मामला परिदृश्य क्या है (ईवेंट लॉग्स + एप्लिकेशन लॉग्स + वीडियो + एक्शन रिकॉर्डिंग + इंटेलीट्रेस + आइटम रिप्रोड)। ब्लू स्क्रीन के होने पर IMO / E QA की नौकरी समाप्त नहीं होती है - और एक रिप्रो पहली चीज है जो उन्हें उत्पादन करने की कोशिश करनी चाहिए, भले ही वह हमेशा संभव न हो।

— स्टीवन एवर्स

@SnOrfus मैं केवल एक क्यूए टीम के साथ काम करने का सपना देख सकता था जो इतनी पेशेवर है। ज्यादातर संगठनों में मैंने काम किया है, वे ऐसे ड्रेगर थे जो सॉफ्टवेयर डेवलपर्स के रूप में कटौती करने के लिए बहुत अक्षम या आलसी थे। सबसे अच्छी बात यह है कि मैंने जिस क्यूए टीम के साथ काम किया है, वह पूरी तरह से ऑफशोर थी, शायद इसलिए कि वे वास्तव में क्यूए परीक्षण करना चाहते हैं।

— maple_shaft

@maple_shaft: जहां मैं काम करता हूं, इससे पहले कि मैं क्यूए से देव में चला गया, हम सबसे पहले से ही कर रहे थे (जब आपके पास 400000 परीक्षण मामले हैं तो वीडियो HDD अंतरिक्ष के बकवास को लेता है)।

— स्टीवन एवर्स

7

यदि बग को लगातार पुन: पेश नहीं किया जा सकता है, तो QA को कभी भी कैसे पता चलेगा कि यह तय किया गया था?

— Kyralessa
स्रोत

हाँ, यह एक और समस्या है जिसका मैंने उल्लेख नहीं किया है लेकिन बहुत अधिक है। मुझे एक बग रिपोर्ट मिलती है, बदलाव करते हैं और फिर बग को बंद करते हैं। QA फिर पास को मंजूरी देता है। कुछ हफ़्ते बाद, समस्या ठीक नहीं हुई। मेरे पास "सॉफ्टवेयर दुर्घटनाग्रस्त" के रूप में बहुत सारे मुद्दे हैं, जो हर संभव बग का एक बड़ा पिघलने वाला बर्तन बन जाता है

— एरिक

6

हां, आपको उनसे ज्यादा उम्मीद करनी चाहिए। उन्हें कहना चाहिए:

1. कार्यक्रम का नया उदाहरण शुरू किया
2. मैंने बटन A दबाया
3. फॉर्म # 1 पर टेस्ट नाम क्षेत्र में "परीक्षण पाठ" दर्ज किया
4. दबाया बटन बी
5. देखा कि इस संदेश के साथ कार्यक्रम दुर्घटनाग्रस्त हो गया (संलग्न स्क्रीनशॉट देखें)।

यदि वे सभी बताते हैं कि "यह दुर्घटनाग्रस्त हो गया", तो वे बहुत अच्छे नहीं हैं। यहां तक कि अगर उपरोक्त कदम 100% प्रतिलिपि प्रस्तुत करने योग्य नहीं हैं, तो इन दुर्घटनाओं का एक बड़ा नमूना कारण को कम करने में मदद कर सकता है, एक बार पैटर्न का पता चलने पर।

— FrustratedWithFormsDesigner
स्रोत

5

मेरी सलाह है कि उन बग्स को पढ़ें और उन्हें एक अच्छा पुराना विचार दें। यदि आप किसी संभावित कारण का पता नहीं लगा सकते हैं, तो अभी के लिए उनके बारे में भूल जाएं।

QA को अपने हर मुद्दे का दस्तावेजीकरण करना चाहिए, भले ही उन्हें पता न हो कि यह कैसे हुआ। मुद्दों को आज़माना और पुन: पेश करना QA का काम है, लेकिन वास्तविक रूप से यह हमेशा संभव नहीं होगा। कभी-कभी इससे कोई लेना-देना नहीं होता कि उन्होंने आखिरी 10 मिनट में क्या किया। एक दिन पहले कुछ अमान्य स्थिति में आ गया, और अंतिम 10 चरणों में से एक के कारण यह स्पष्ट हो गया।

इन "1000 में 1" कीड़े के साथ, क्यूए को उन्हें थोड़ा सा पुन: पेश करने की कोशिश करनी चाहिए। यदि उनके पास सफलता नहीं है, तो उन्हें बग को दस्तावेज करना चाहिए, फिर थोड़ा और प्रयास करें।

जिस कारण से उन्हें बग को बहुत जल्दी प्रवेश करना चाहिए, वह यह है कि प्रोग्रामर कोड को क्यूए से बहुत बेहतर जानता है, और तुरंत समस्या को जान सकता है। यह वह कोड हो सकता है जिसे उन्होंने रिफैक्ट किया था। यह हो सकता है कि यह समारोह वे आधे पर लागू किया तो भूल गए। उनके पास कोई विचार नहीं हो सकता है, लेकिन परीक्षक में कोई भी समझ नहीं है जो कुछ घंटों को बर्बाद करने की कोशिश कर रहा है जो उस व्यक्ति को स्पष्ट करने की कोशिश कर रहा है जो इसे कोडित करता है। परीक्षक हमेशा बग के बाद में अधिक विवरण जोड़ सकता है।

बग में यथासंभव अधिक जानकारी शामिल होनी चाहिए। परीक्षक जो भी मुद्दे के लीड-अप के बारे में याद कर सकता है, उसे दर्दनाक विस्तार से लिखा जाना चाहिए। किसी भी क्रैश लॉग, डेटाबेस स्नैपशॉट या संबंधित स्क्रीनशॉट को भी संलग्न किया जाना चाहिए।

अगर बग कभी पुनरुत्पादित नहीं होता है, तो बहुत अच्छा! यह डेटाबेस में यह चोट नहीं करता है। यदि कार्यक्रम जारी किया जाता है और एक उपयोगकर्ता बाद में एक समान बग रिपोर्ट करता है, तो आप उनके अनुभव की तुलना रिपोर्ट में क्या कर सकते हैं और किसी भी समानता की तलाश कर सकते हैं।

मेरे अनुभव में, परीक्षण योजनाओं का पालन करने से जूसी कीड़े नहीं पाए जाते हैं। कभी-कभी आपको कुछ हफ्तों के लिए चीजों को स्टू करने देना पड़ता है ताकि चंद्रमा और तारों को संरेखित किया जा सके जो एक बुरा बग का कारण बनता है। यदि QA कुछ जासूसी का काम कर सकता है और कुछ संभावित कारणों का पता लगा सकता है, तो उन्हें पीठ पर थपथपाएं। लेकिन कभी-कभी, कौन जानता है कि क्या हुआ?

— डीन
स्रोत

+1 के लिए "यह डेटाबेस में होने पर चोट नहीं करता है"

— PhillC

4

जब तक आप उन्हें ठीक करना नहीं जानते तब तक बहुत सारे कीड़े प्रजनन योग्य नहीं होते हैं। इसका मतलब यह नहीं है कि उन्हें ठीक करने की आवश्यकता नहीं है। मैंने पिछले साल एक बग तय किया था जिसे मैं अभी भी नहीं जानता कि कैसे पुन: पेश किया जाए। यह स्टैक पर एक निश्चित मेमोरी स्थान में बहुत विशिष्ट कचरा डेटा के साथ एक ठीक समयबद्ध ट्रांसमिशन त्रुटि के कुछ विचित्र संयोजन की आवश्यकता है। दुर्भाग्य से, हमारे ग्राहकों में से एक "भाग्यशाली" है जो हर समय उस स्थिति में रहने के लिए पर्याप्त है।

तो, हर तरह से क्यूए को जहां संभव हो, प्रजनन योग्य कदमों को शामिल करने के लिए प्रोत्साहित करें, लेकिन अगर वे नहीं कर सकते हैं तो उन्हें दोष न दें। कभी-कभी यह आपको यह जानने में मदद करेगा कि लॉगिंग कहां जोड़ना है। कभी-कभी यह सब आपको बताता है कि बग का क्या कारण नहीं है, लेकिन बग रिपोर्ट हमेशा उपयोगी होती है।

— कार्ल बेवफेल्ड
स्रोत

2

यदि आपका मतलब है कि क्यूए में बग को पुन: उत्पन्न करने के लिए कदम शामिल हैं यदि वे कर सकते हैं, तो इसका उत्तर हां है। यदि आप मतलब है कि वे केवल वे कीड़े रिकॉर्ड कर सकते हैं जिन्हें वे पुन: पेश करने में सक्षम हैं, तो बिल्कुल नहीं। कीड़े बग हैं, चाहे वे केवल आधी रात को पूर्णिमा पर होते हैं, या हर बार जब आप इसे देखते हैं। कुछ बग गैर-नियतात्मक हैं (क्लासिक उदाहरण असमान रूप से परिवर्तनीय है, जहां उठाया गया मूल्य अर्ध-यादृच्छिक है), इसका मतलब यह नहीं है कि उन्हें दर्ज नहीं किया जाना चाहिए, जांच की जानी चाहिए, और यदि संभव हो तो तय किया जाना चाहिए।

गैर प्रजनन योग्य कीड़े में आम तौर पर कम प्राथमिकता होनी चाहिए, लेकिन उन्हें निश्चित रूप से दर्ज किया जाना चाहिए।

— jmoreno
स्रोत

1

IMO, आपको चाहिए। क्यूए अपना काम नहीं कर रहे हैं यदि वे आपको कोई प्रजनन कदम नहीं दे सकते हैं। अपना समय बर्बाद न करें कुछ ऐसा करने की कोशिश करें जो आप नहीं कर सकते, बस इसे "पुन: पेश न करें" के रूप में बंद करें और आगे बढ़ें।

आपका समय इससे कहीं अधिक मूल्यवान है।

— स्टीव Czetty
स्रोत

1

बग रिपोर्ट में होनी चाहिए:

प्रजनन करने कि प्रक्रिया
वास्तविक व्यवहार
अपेक्षित व्यवहार

उदाहरण के लिए:

मैंने डेटाबेस से सभी आपूर्तिकर्ताओं को हटा दिया (उपयोग करके DELETE * FROM tSuppliers), आपूर्तिकर्ता संवाद खोला, और आपूर्तिकर्ता ड्रॉप-डाउन सूची पर क्लिक किया।
सूची निम्न संदेश निहित: GUPOS ERROR #0000000: SOMETHING WENT WRONG!। जब मैंने संदेश पर क्लिक किया, तो ऐप स्क्रीन से गायब हो गया, और टास्क मैनेजर।
मुझे या तो एक खाली सूची या (अधिमानतः) एक संदेश देखने की उम्मीद थी जैसे "कोई आपूर्तिकर्ता नहीं मिला"। खाली सूची या संदेश पर क्लिक करने का कोई प्रभाव नहीं होना चाहिए। एप्लिकेशन को किसी भी परिस्थिति में चेतावनी के बिना गायब नहीं होना चाहिए।

तो, हाँ - इसमें प्रजनन के चरण शामिल होने चाहिए। तथ्य यह है कि वे इसे शामिल करने की आवश्यकता महसूस नहीं करते हैं यह इंगित करने के लिए प्रतीत होता है कि उन्हें लगता है कि उनका काम "सॉफ़्टवेयर को तोड़ना" है, बजाय दोषों की पहचान करना।

— gkrogers
स्रोत

0

क्यूए दर्ज किए गए चरणों के आधार पर कीड़े को पुन: उत्पन्न करने में सक्षम होना चाहिए। यदि वे कड़ी मेहनत करते हैं, फिर भी पुन: पेश नहीं कर सकते हैं, तो उन्हें अभी भी बग्स में उतने ही विवरण दर्ज करने चाहिए जितने कि उनके पास टाइमस्टैम्प के साथ हैं ताकि डेवलपर्स अधिक जानकारी के लिए एप्लिकेशन और डिबग लॉग पर एक नज़र डाल सकें।

— java_mouse
स्रोत

0

यहां पैसा दांव पर है। किसी भी टीम के सदस्य को खराब-परिभाषित, कम-संभावना-सफलता का कार्य बनाने में सक्षम होना चाहिए जो एक (उम्मीद है) अत्यधिक भुगतान करने वाले डेवलपर को बोझ करता है?

यह पेकिंग ऑर्डर, पदानुक्रम, अहंकार, हमें बनाम उनके बारे में या ऐसा कुछ भी नहीं है। यह केवल उन गतिविधियों में निवेश करने के बारे में है जो उत्पाद में मूल्य जोड़ते हैं।

जब किसी समस्या को नकारात्मक रूप से प्रदर्शित किया जा सकता है और उत्पाद के मूल्य को नकारात्मक रूप से प्रभावित किया जा सकता है, तो इसकी जांच, पुनरुत्पादन और निर्धारण किया जाना चाहिए। शोर को फ़िल्टर करने के लिए अपने उत्पाद दोष पाइपलाइन को ठीक करें।

— bneely
स्रोत

-1

आपकी क्यूए टीम बेकार है

उनके पास जाओ और उन्हें एक दस्तावेज पढ़ने के लिए कहो कि किसी भी पेशेवर परीक्षक को उनके दिमाग के अंदर सही मुद्रित करना है (मैं एक बार परीक्षक था और मेरे दिमाग में अभी भी यह वहीं है): कैसे प्रभावी ढंग से कीड़े की रिपोर्ट करें ।

विशेष रूप से, उन्हें "मुझे स्वयं को दिखाने के तरीके दिखाएं" अनुभाग में इंगित करें :

यह इंटरनेट का युग है। यह दुनिया भर में संचार का युग है। यह वह युग है जिसमें मैं अपने सॉफ़्टवेयर को रूस में किसी को एक बटन के स्पर्श पर भेज सकता हूं, और वह मुझे इसके बारे में आसानी से टिप्पणी भेज सकता है। लेकिन अगर उसे मेरे कार्यक्रम में कोई समस्या है, तो वह मुझे इसके सामने खड़ा नहीं कर सकता, जबकि यह विफल रहता है। जब आप कर सकते हैं तो "मुझे दिखाएं" अच्छा है, लेकिन अक्सर आप ऐसा नहीं कर सकते।

यदि आपको किसी प्रोग्रामर को बग की सूचना देनी है जो व्यक्तिगत रूप से उपस्थित नहीं हो सकता है, तो व्यायाम का उद्देश्य उन्हें समस्या को पुन: उत्पन्न करने में सक्षम बनाना है। आप चाहते हैं कि प्रोग्रामर प्रोग्राम की अपनी कॉपी को चलाएं, इसके लिए वही चीजें करें, और इसे उसी तरह से विफल करें। जब वे अपनी आंखों के सामने हो रही समस्या को देख सकते हैं, तो वे इससे निपट सकते हैं ...

यदि वे आपसे यह कहते हुए चिल्लाना शुरू कर देते हैं कि "कीड़े एक ही समय में कई दिशाओं से आ सकते हैं" , तो उन्हें बताएं कि वे आपके द्वारा सोचे गए पहले से भी अधिक चूसते हैं। उन्हें बताएं कि टेस्टिबिलिटी एक ऐसी विशेषता है जिसका मूल्यांकन उन्हें अन्य प्रोजेक्ट फीचर्स के बीच करना चाहिए और उन्हें इस फीचर को सही बनाने के लिए प्रयास करना चाहिए।

परीक्षण क्षमता में सुधार तब हो सकता है जब कोई पेशेवर परीक्षक इस पर ध्यान केंद्रित करता है कि यह जादू की तरह हो सकता है। मुझे पता चला कि कुछ महीने पहले। हमारी टीम के साथ काम करने वाले क्यूए इंजीनियर ने हमारे आवेदन में कुछ घटकों के विकास के लिए मुझे कई परीक्षण योग्य अनुरोध दिए। चीजों के बारे में उन्होंने मुझसे बहुत कम समझदारी की, लेकिन मैंने उन्हें यह मानकर दिया कि वे एक पेशेवर के रूप में बेहतर जानते हैं। मेरे समाप्त होने के तुरंत बाद, वह एक उपकरण लेकर आया जिसने परिमाण के क्रम से परीक्षण के प्रयासों को कम कर दिया । उन्होंने कहा कि इसका अधिकांश हिस्सा मेरे द्वारा लागू किए गए इन गुप्त अनुरोधों पर आधारित था।

— कुटकी
स्रोत

QA को प्रतिलिपि प्रस्तुत करने योग्य परिदृश्यों को ढूंढना चाहिए?

आपकी क्यूए टीम बेकार है