ठेस पर क्यूए। मस्त क्यों है?

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

यदि आपको पूर्व-उत्पादन का माहौल है, तो आपको उत्पादों पर क्यूए की आवश्यकता क्यों है

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

प्रॉडक्ट्स की मदद से QA क्या कार्य करता है

1. मंचन और उत्पादन वातावरण के बीच अंतर की समस्या।

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

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

इसके अलावा, तीसरे पक्ष की सेवाओं के साथ एकीकरण करते समय, आपके पास परीक्षण और लड़ाकू वातावरण (एक ही एपीआई) के लिए हमेशा अलग-अलग सेटिंग्स होती हैं। मैं यह नहीं कह रहा हूं कि परीक्षण और मंचन वातावरण व्यर्थ है। यह केवल 100% गारंटी के लिए संभव नहीं है कि एक पर्यावरण पर कुछ परीक्षणों के सफल समापन पर, सेवाएं दूसरे पर नहीं गिरेंगी। उत्पादन के लिए अतिरिक्त परीक्षण इस समस्या को हल करने में मदद कर सकते हैं।



2. मल्टीटास्किंग और लोड का वास्तविक स्तर।

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

3. तैनाती त्रुटियां

परिभाषा से, उत्पादन बुनियादी ढांचे में सेवा कार्यक्रम कोड के नए संस्करण के एक कार्य समूह द्वारा तैनाती है। तदनुसार, तैनाती त्रुटियों को देखने का सबसे अच्छा तरीका तैनाती प्रक्रिया में परीक्षण के माध्यम से ही है।

4. पूर्व-ठिकानों पर निगरानी की कमी

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

5. सिस्टम का उपयोग करने के लिए अंतिम-उपयोगकर्ता परिदृश्यों का विश्लेषण करने की क्षमता

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

6. सॉफ्टवेयर की गुणवत्ता के अधिक विश्वसनीय आँकड़े और मैट्रिक्स बनाए रखने की क्षमता।

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

7. यह हमेशा बेहतर होता है, यदि अंतिम उपयोगकर्ता की तुलना में "अपने" परीक्षक द्वारा ठेस पर ध्यान दिया जाता है।

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



उत्पादन पर उपयोगी क्यूए अभ्यास जो हमारी परियोजना पर प्रभावी ढंग से काम करते हैं

1. यह सुनिश्चित करने के लिए कि वे नए वातावरण में अच्छी तरह से स्थापित और काम कर रहे हैं, वितरित कार्यों की जाँच करना।

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

2. लॉगिंग और ऑडिट।

अच्छा लॉगिंग डेवलपर्स और परीक्षकों को किसी समस्या को नोटिस करने में मदद करता है इससे पहले कि अंतिम उपयोगकर्ता यह अनुमान लगाता है, साथ ही नोटिस स्थानों को भी अनुकूलन की आवश्यकता होती है। क्रियाओं और परिवर्तनों का एक ऑडिट हमें किसी भी समस्या के बिना किसी विशेष व्यवहार के कारणों का हमेशा पता लगाने की अनुमति देता है। उदाहरण के लिए, यदि ऋण नीति का एक घटक ऋण पर निर्णय जारी नहीं कर सकता है, तो विश्लेषण करने के लिए कि ऐसा क्यों हुआ, हम पहले लॉग में जाते हैं। यह आइटम दोनों prodcution और पूर्व उत्पादन वातावरण के लिए लागू होता है।

3. निगरानी और सतर्कता प्रणाली

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

4. प्रतिगमन और स्थिरता की जांच

एक शांत अभ्यास समय-समय पर प्रतिगमन परीक्षणों से गुजरना है ताकि यह सुनिश्चित हो सके कि कहीं भी कुछ भी गलत नहीं हुआ। यह कुछ संकीर्ण और विशिष्ट मामलों में मदद कर सकता है जब निगरानी समस्याओं को नहीं देखती है।

5. रिपोर्टिंग और आंकड़े

किसी भी परीक्षण में, रिपोर्टिंग और आँकड़ों के आँकड़ों के परीक्षण के परिणाम प्रक्रिया को और अधिक पारदर्शी बनाते हैं, सॉफ्टवेयर की गुणवत्ता और दोषों के कारण अधिक दिखाई देते हैं।

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