नमस्कार। मेरा नाम ओल्गा मिखालचुक है, मैं आईडी फाइनेंस फिनटेक कंपनी में क्यूए इंजीनियर (क्वालिटी एश्योरेंस इंजीनियर या टेस्टर) हूं। इस पोस्ट में मैं आपको बताऊंगा कि QA क्या करता है और क्रेडिट अनुमानों में बग्स की तलाश कैसे करें और उन्हें ठीक करें, जब तक कि वे आपकी कंपनी में बड़े नुकसान का कारण नहीं बन जाते।
मेरे काम के बारे में थोड़ा: क्यूए या परीक्षक
आईडी फाइनेंस एक फिनटेक कंपनी है, जिसके प्रोजेक्ट सात देशों में प्रस्तुत किए जाते हैं। मैं
मनी मैन (ऑनलाइन उधार सेवा) के उत्पाद ब्राजील के लिए काम करता हूं।
इसके साथ शुरू करने के लिए, मैं "गुणवत्ता आश्वासन इंजीनियर" और "परीक्षक" शब्दों के साथ थोड़ा परिभाषित करना चाहूंगा, हालांकि यह एक अलग लेख के लिए एक विषय है। इन अवधारणाओं का एक भी विचार नहीं है। ज्यादातर मामलों में, परीक्षणकर्ताओं को विशेषज्ञ कहा जाता है जो विकास के बाद सिस्टम के सही संचालन को सत्यापित करते हैं और अंत उपयोगकर्ताओं को कार्यक्षमता प्रदान करने से पहले। और QA का मतलब उत्पाद की गुणवत्ता सुनिश्चित करने के लिए अधिक वैश्विक और गहन कार्य है। इसमें उन दोषों के कारणों का अध्ययन शामिल है जो उनकी रोकथाम, उनकी रिहाई के बाद के रखरखाव, निरंतर प्रक्रिया में सुधार और बहुत कुछ है।
वास्तव में, मेरा काम कुछ इस तरह दिखता है: हम उन कार्यों का विश्लेषण और जांच करते हैं जिन्हें प्रोग्रामर द्वारा संकलित और विकसित अन्य विभाग करते हैं, बग दर्ज करते हैं और उनका विश्लेषण करते हैं, परीक्षण प्रलेखन और रिपोर्ट लिखते हैं, उत्पादन की स्थिति की निगरानी करते हैं, डेमो का संचालन करते हैं, आदि हमारे पास उत्पादन की अवधारणा भी है। क्यूए। हमारे विभाग के लोगों को भी विकास प्रक्रिया के बारे में एक विचार होना चाहिए: हर दिन हम डेटाबेस और सिस्टम लॉगिंग स्तर पर जाते हैं, कोड और कंसोल को देखते हैं, और सिस्टम के लोड और स्थिति की निगरानी के लिए सिस्टम का उपयोग करते हैं। हमें व्यवसाय की बारीकियों को समझना चाहिए: इसमें अन्य विभागों के साथ कार्यों और संचार का विश्लेषण शामिल है। अन्य विभागों के काम की विशेषताओं को जानना चाहिए। उदाहरण: आप यह कैसे परख सकते हैं कि जब आपको यह समझ में नहीं आता है तो क्रेडिट एप्रूवल सही ढंग से किया जाता है? यही कारण है कि मैं अपनी स्थिति क्यूए, यानी एक गुणवत्ता आश्वासन विशेषज्ञ को जारी रखूंगा, हालांकि मुझे परीक्षक कहा जाता है तो मैं नाराज नहीं होऊंगा।
क्रेडिट लागत परीक्षण
हमारी कंपनी में, क्रेडिट गणना मापदंडों और क्रेडिट के संकेतकों के सभी गणनाओं को बुलाती है। यह भुगतानों की एक अनुसूची है, मूलधन और ब्याज की राशि, देरी के मामले में जुर्माना, कर्तव्यों, करों, आदि के मामले में विभिन्न डेटाबेस तालिकाओं में 100 से अधिक संकेतकों का कुल। बुनियादी सेवाओं के अलावा, अतिरिक्त हैं: विस्तार, पुनर्गठन, नवीकरण। छूट, बोनस, उपयोगकर्ता को उपलब्ध विभिन्न क्रेडिट उत्पाद और अन्य सुविधाओं का एक समूह भी है।
क्रेडिट गणना सबसे कठिन क्षेत्रों में से एक है जो मुझे कंपनी में अपने काम के दौरान सामना करना पड़ा। मेरी राय में, केवल एक क्रेडिट पॉलिसी जटिलता में एक स्तर पर है (नियमों और एल्गोरिदम का एक सेट जिसके अनुसार ऋण देने की संभावना के बारे में एक निर्णय किया जाता है, और हम इस उपयोगकर्ता को कौन सा ऋण दे सकते हैं)।
क्रेडिट अनुमानों का परीक्षण करने की विशेषताएं
- परीक्षण प्रक्रिया के लिए अग्रिम रूप से तैयार करें, आदर्श रूप से - विकास से पहले। आवश्यकताओं का विश्लेषण करें, परीक्षण प्रलेखन तैयार करें।
- हम अधिक बुनियादी जांचों से अधिक जटिल और संयुक्त लोगों के पास जाते हैं: पहले हम एक ऋण जारी करने, समय पर भुगतान, राशि की राशि आदि की जांच करते हैं, फिर थोड़ी अधिक जटिल जांच, जैसे कि जल्दी चुकौती, देरी, ओवरपेमेंट और फिर विभिन्न मामलों का संयोजन।
- हम प्रारंभिक सेटिंग्स और अनुबंध की जांच करते हैं जो उधारकर्ता संकेत देता है।
- अतिरिक्त सेवाओं (नवीकरण, छूट, आदि) के बारे में मत भूलना
- उत्पादन का माहौल - परीक्षण मामलों का एक भंडार। "संदर्भ" मामलों को लेना और उनके साथ लागत की तुलना करना एक अच्छा विचार है।
- मौजूदा ग्राहकों की लागत में परिवर्तन के प्रभाव की अनुमति नहीं दी जा सकती है।
- किसी भी बदलाव के बाद आपको रिग्रेशन के बारे में हमेशा याद रखना चाहिए।
- हम विचार करते हैं कि क्या अन्य तृतीय-पक्ष कार्य क्रेडिट अनुमानों को प्रभावित कर सकते हैं।
विशिष्ट मामले: कैसे कीड़े राजस्व में हजारों डॉलर को प्रभावित कर सकते हैं और हम उनके साथ कैसे लड़ेमैंने अनुमानों के साथ काम करना शुरू किया जब वे पहले से ही लगभग दो साल तक रिहा थे, इसलिए मुझे इस प्रक्रिया की उत्पत्ति के कई आकर्षण नहीं पता थे। फिर भी, मुझे उनके स्थिरीकरण और फिक्सिंग कीड़ों का सामना करना पड़ा। मैं आपको उन मामलों के बारे में बताऊंगा जो मुझे याद हैं:
लागत में तितली प्रभावयदि आप "तितली प्रभाव" की परिभाषा को देखते हैं, तो आप देख सकते हैं: "तितली प्रभाव कुछ अराजक प्रणालियों की संपत्ति को दर्शाते हुए एक शब्द है: सिस्टम पर एक मामूली प्रभाव बड़े पैमाने पर और अप्रत्याशित परिणाम हो सकता है, जिसमें पूरी तरह से अलग जगह भी शामिल है।" मुझे लगता है कि यह परिभाषा पूरी तरह से क्रेडिट अनुमानों में स्थिति का वर्णन करती है।
एक उदाहरण के रूप में, एक बार जब हमने एक मामूली बग तय किया था: कुछ क्षेत्रों की गोलाई में थोड़ी सी अशुद्धि थी। सभी ऋणों की पुनरावृत्ति करने के बाद (परीक्षण के माहौल पर अच्छा), यह पता चला कि लगभग एक हजार ऋण देर से थे, हालांकि उन्हें वास्तव में नहीं होना चाहिए! तो उस तुच्छ बग को ठीक कर दिया, क्योंकि क्रेडिट गणना में सभी पैरामीटर दृढ़ता से परस्पर जुड़े हुए हैं और एक-दूसरे को प्रभावित करते हैं, कभी-कभी अप्रत्याशित स्थानों पर। भगवान का शुक्र है, यह जल्दी से देखा गया, मरम्मत की गई, इसे उपयोगकर्ताओं को समाप्त करने की अनुमति नहीं दी गई। तथ्य यह है कि हम क्रेडिट ब्यूरो को देरी के बारे में जानकारी भेजते हैं। हम सैकड़ों ग्राहक क्रेडिट इतिहास और हमारी प्रतिष्ठा को खराब कर सकते हैं। और, ज़ाहिर है, इस तरह के बग से हजारों डॉलर का नुकसान होगा।
100% बग्स को ठीक नहीं कर सकतेजैसा कि मैंने पहले पैराग्राफ में लिखा था, गणना में सभी पैरामीटर एक-दूसरे को बहुत प्रभावित करते हैं। इस वजह से, एक स्थान पर सुधार के दौरान, बहुत बार दूसरे में कुछ टूट जाता है। जब हम बड़ी संख्या में संचित कीड़े को ठीक करने का सामना कर रहे थे, तो निश्चित रूप से, व्यवसाय विभाग बिल्कुल सभी त्रुटियों को ठीक करना चाहता था। लेकिन यह पता चला कि कुछ महत्वहीन बग को ठीक करने के प्रयास में, अधिक से अधिक त्रुटियां बढ़ीं, जैसे स्नोबॉल। जैसा कि वे कहते हैं, आदर्श अच्छे का दुश्मन है। इसलिए, उस समय हमारा मुख्य कार्य सिस्टम को सबसे स्थिर स्थिति में लाना था, जिसमें व्यापार पर कीड़े का न्यूनतम प्रभाव था, न कि 100% दोषों को ठीक करना। यह दृष्टिकोण अधिक से अधिक बग्स के अंतहीन सुधार की तुलना में बहुत अधिक उत्पादक निकला जो एक-दूसरे से स्पॉन करते हैं।
Nontrivial कॉम्बिनेशन पर ध्यान देंऋण देने और उपयोग करने के तरीकों के गैर-तुच्छ संयोजन के साथ अधिकांश कीड़े ठीक होते हैं, जब कोड की शाखाएं एक दूसरे में भ्रमित हो जाती हैं। उदाहरण के लिए: उपयोगकर्ता पहले किस्त का अग्रिम भुगतान करता है, दूसरा 5 चरणों में भुगतान करता है, तीसरे में विस्तार लेता है, और फिर कई हफ्तों तक देरी करता है ... दुर्भाग्य से, अक्सर ऐसे मामलों में कीड़े पहले से ही ठेस पर होते हैं। निष्कर्ष: हम मामलों के संयोजन पर ध्यान देते हैं और अंतिम खंड के छठे बिंदु के बारे में याद करते हैं (ठेस। बुधवार - परीक्षण का एक भंडार)।
मौजूदा ग्राहकों को मत छुओ!मौजूदा ग्राहकों को प्रभावित करने के लिए ऋण की राशि, अवधि या शर्तों में किसी भी बदलाव की अनुमति देना असंभव है, जिन्होंने इसे कुछ शर्तों पर लिया था। यदि ऐसा होता है, तो यह सहायता विभाग और पूरी कंपनी के लिए बहुत परेशानी लाएगा।
ऋण विभागों की तुलनायह जांचने का एक बहुत प्रभावी तरीका है कि यदि कोई परिवर्तन किए गए हैं तो क्रेडिट अनुमान सही ढंग से काम करता है, तो परिवर्तनों से पहले और बाद में ऋण पोर्टफोलियो की तुलना करना है। इसका मतलब है कि हमारे पास सशर्त रूप से सही ऋण आधार है, अनुमान के साथ जो व्यवसाय की अपेक्षाओं को पूरा करता है। और हम इस डेटाबेस में नई क्रेडिट गणना लागू करते हैं, और फिर विशेष उपकरणों और डेटा विश्लेषण का उपयोग करके हम ऋण के इस ढेर के कुछ सामान्य संकेतकों की तुलना करते हैं। उदाहरण के लिए, सभी ऋणों पर परिवर्तन या ब्याज की राशि से पहले और बाद में अतिदेय ऋणों की संख्या। यह विधि परीक्षण और समस्या निवारण दोनों में बहुत सहायक है।
निष्कर्ष
क्रेडिट गणना एक गंभीर और कठिन विषय है, लेकिन बहुत ही रोचक और पहेली से भरा है। इसके साथ काम करते समय, आपको थोड़ा डेटा विश्लेषक, और फाइनेंसर, और गणितज्ञ होने की आवश्यकता है। लेकिन यहां तक कि इस तरह के एक खतरनाक जानवर को वश में किया जा सकता है यदि आप इसके लिए एक दृष्टिकोण पाते हैं
और सरल बिंदु इसमें मदद करेंगे:
- सावधानीपूर्वक तैयारी: गुणवत्ता की आवश्यकताएं, व्यवसाय और क्यूए प्रलेखन, विचारशील परीक्षण डिजाइन;
- प्रतिगमन ("तितली प्रभाव" याद रखें);
- परीक्षण मामलों और बेंचमार्क का एक अनिवार्य स्रोत के रूप में उत्पादन का माहौल।