नमस्ते!
मैं यह साझा करते हुए रोमांचित हूं कि कैसे मैं सिस्टम क्यूए भूमिका के कार्यान्वयन के माध्यम से हमारे रिलीज प्रवाह को 20% तक सुधारने में कामयाब रहा।
यह देखते हुए कि मेरी कंपनी एक विशिष्ट उत्पाद कंपनी है, टीमों को उत्पाद के आधार पर नहीं बल्कि घटकों के आधार पर विभाजित किया गया है। इसके लिए धन्यवाद, एक ओर, हम ज्ञान के "धारकों" के साथ शक्तिशाली टीमें बनाने में कामयाब रहे। लेकिन दूसरी ओर, इकाइयों के भीतर भूमिकाएँ अपेक्षाकृत अलग-थलग हैं, और कठिन कौशल और विशेषज्ञता के विभिन्न सेट अपनी सीमाएँ लगाते हैं। उदाहरण के लिए, मुझे कभी-कभी किसी परीक्षक को बैकएंड टीम से फ्रंटएंड पर या इसके विपरीत स्थानांतरित करने की आवश्यकता होती है।
इससे यह तथ्य सामने आया कि क्यूए टीमों के भीतर प्रभावी ऑर्केस्ट्रेशन और क्रॉस-टीम इंटरैक्शन के प्रबंधन का सवाल था। निस्संदेह, अंततः रिलीज़ प्रवाह प्रभावित हुआ।
परिवर्तन से पहले प्रवाह जारी करें
परिवर्तनों से पहले, हमारा रिलीज़ प्रवाह इस तरह दिखता था:
- व्यवसाय आवश्यकताएँ विशिष्टता (बीआरएस) एक दस्तावेज़ है जो किसी व्यवसाय के भीतर एक विशिष्ट सुविधा, प्रणाली, उत्पाद या परियोजना के लिए विस्तृत आवश्यकताओं, अपेक्षाओं और विशिष्टताओं की रूपरेखा तैयार करता है। यह व्यावसायिक हितधारकों और विकास या कार्यान्वयन टीमों के बीच एक पुल के रूप में कार्य करता है, जिससे यह स्पष्ट समझ सुनिश्चित होती है कि क्या हासिल किया जाना है और यह समग्र व्यावसायिक लक्ष्यों के साथ कैसे संरेखित होता है। इसमें विस्तृत परिदृश्य शामिल होने चाहिए जो बताते हैं कि उपयोगकर्ता सुविधा के साथ कैसे बातचीत करेंगे। फ़ीचर ओनर (एफओ) को व्यावसायिक आवश्यकताओं को तैयार करने का कर्तव्य सौंपा गया है।
- सॉफ़्टवेयर आवश्यकताएँ विशिष्टता (एसआरएस) एक व्यापक दस्तावेज़ है जो एक सॉफ़्टवेयर सिस्टम से क्या पूरा करने की अपेक्षा की जाती है, इसका विस्तृत विवरण प्रस्तुत करता है। उदाहरण के लिए, कैसे और कौन से कमांड इंटरैक्ट करते हैं, किस प्रोटोकॉल द्वारा, और कौन सा डेटा प्रसारित किया जाएगा। यदि फीचर पर काम करने वाली टीम ग्राफिकल इंटरफ़ेस का उपयोग करती है, तो एसआरएस में विकसित किए जा रहे फीचर के लेआउट शामिल होने चाहिए। फीचर आर्किटेक्ट एसआरएस लिखने के लिए जिम्मेदार है।
- गुणवत्ता कार्य योजना (क्यूएपी) - मामलों का एक सेट जिसे एक सुविधा स्वामी किसी सुविधा को स्वीकार करने से पहले जांचता है। दस्तावेज़ों का वर्णन करने के बाद, हम सुविधा को लागू करने के लिए आगे बढ़ते हैं। जब पहली टीम फीचर के अपने हिस्से का विकास और परीक्षण पूरा कर लेती है, तो इसे दूसरी टीम को स्थानांतरित कर दिया जाता है। दूसरी टीम एकीकरण/विकास/परीक्षण करती है और इसे अगली इकाई को भेजती है। और इसी तरह जब तक फीचर विकास में भाग लेने वाली सभी घटक टीमें इस प्रवाह से नहीं गुजरतीं। एफओ सुविधा को मान्य करता है, और इसे रिलीज़ के लिए भेजा जाता है।
रिलीज़ प्रवाह समस्याएँ
तो, सब कुछ ठीक लगता है - दस्तावेज़, आवेदन, स्वीकृति मामले। हालाँकि, इस प्रक्रिया में हमें निम्नलिखित कठिनाइयों का सामना करना पड़ा:
क्यूए की ओर से समस्याएं:
- आवश्यकताओं का परीक्षण विकास के बाद ही शुरू होता है। डेवलपर्स द्वारा पहले से ही कार्यान्वित किए गए कार्य, उनकी आवश्यकताओं के साथ, क्यूए टीम को सौंप दिए जाते हैं। लेकिन, जैसा कि हम जानते हैं, आवश्यकताओं में त्रुटियाँ हो सकती हैं।
- किसी बग के लिए जिम्मेदार टीम का पता लगाने में काफी समय लगता है क्योंकि यह हमेशा स्पष्ट नहीं होता है कि किन मामलों का परीक्षण अन्य टीमों द्वारा पहले ही किया जा चुका है।
- परीक्षण कलाकृतियों का पुन: उपयोग नहीं। एक सुविधा के परीक्षण के भाग के रूप में, QA टीमें समान परीक्षण डेटा सेट तैयार करती हैं। लेकिन टीमों के अलगाव और संकीर्ण विशेषज्ञता के कारण, वे इस डेटा को एक-दूसरे तक प्रसारित नहीं कर सके।
एफओ की ओर से समस्याएं:
- अनेक विशेषताओं के कारण QAP लिखने में बहुत समय लगता है।
- सुविधा का सत्यापन सभी टीमों द्वारा विकास के बाद होता है। हमारे मामले में, यह कई एकीकरण मुद्दों के कारण रिलीज़ प्रवाह को काफी लंबा कर देता है।
- उत्पाद की जटिलता और टीमों के बीच एकीकरण की मात्रा के कारण परीक्षण वातावरण की तैयारी भी सटीक है। अलग-अलग टीमें एक साथ अपने घटकों का परीक्षण कर रही हैं, जिससे डेटा को मैश करने, बदलने या हटाने का जोखिम बढ़ रहा है।
अद्यतन रिलीज़ प्रवाह में सिस्टम QA
क्यूए टीमों के बीच प्रभावी क्रॉस-टीम इंटरैक्शन को सुविधाजनक बनाने और रिलीज़ प्रवाह को कम करने के लिए, हमने सिस्टम क्यूए की भूमिका पेश की।
इससे एफओ के साथ स्वीकृति मामलों को लिखने के रूप में कार्यभार को कम करने और परीक्षण परिदृश्यों के लेखन में तेजी लाने में मदद मिली, अगली टीम को पास करने से पहले फीचर घटक का मध्यवर्ती परीक्षण शुरू किया गया, और परीक्षण की तैयारी के समय लेने वाले काम को भी स्थानांतरित किया गया। एकीकरण और परीक्षण डेटा के लिए टीमों की सभी बारीकियों और आवश्यकताओं को ध्यान में रखते हुए, सिस्टम क्यूए के लिए पर्यावरण।
सिस्टम क्यूए प्रत्येक सुविधा और संपूर्ण उत्पाद के लिए तकनीकी और व्यावसायिक आवश्यकताओं के बीच एक कड़ी बन गया है।
सिस्टम क्यूए के लिए ऑनबोर्डिंग
संपूर्ण रिलीज़ चक्र को समझने के लिए, सिस्टम QAs को यह समझने की आवश्यकता है कि प्रत्येक टीम में एक विशिष्ट रिलीज़ चक्र कैसे काम करता है। ऑनबोर्डिंग आम तौर पर लगभग तीन महीने तक चलती है क्योंकि सिस्टम क्यूए प्रत्येक टीम में उनके विशिष्ट रिलीज़ चक्रों को समझने में 2-3 सप्ताह बिताता है।
नई प्रक्रिया के परिणाम
अब हम फीचर मालिकों और आर्किटेक्ट्स से बीआरएस/एसआरएस आवश्यकताओं का परीक्षण कर रहे हैं। शुरुआती बग का पता लगाने से व्यवसाय की लागत में बचत होती है।
हमने एक क्रॉस-टीम क्यूए स्पेस स्थापित किया है, जहां परीक्षण कलाकृतियां प्रत्येक सुविधा से जुड़ी होती हैं - व्यावसायिक आवश्यकताएं, तकनीकी आवश्यकताएं, स्वीकृति मामले, अन्य टीमों के मामले, परीक्षण डेटा। इससे सभी क्यूए टीमों को एक ही संदर्भ में रहने और डेटा का प्रभावी ढंग से पुन: उपयोग करने में काफी मदद मिली।
बग के स्थानीयकरण की प्रक्रिया में तेजी आई क्योंकि सिस्टम क्यूए में सभी टीमों के परीक्षण मामलों के सेट हैं।
चूंकि सिस्टम क्यूए प्रत्येक टीम के लिए स्वीकृति मामले लिख रहा है, यह परीक्षण गुणवत्ता में तेजी लाने और सुधार करने के लिए एक उत्कृष्ट संकेत है।
चूंकि प्रत्येक आदेश के बाद स्वीकृति मामलों द्वारा सुविधा को मान्य किया जाता है, इसलिए एकीकरण प्रक्रिया दर्द रहित हो गई है।
एफओ से लोड का एक महत्वपूर्ण हिस्सा हटाने के बाद, सुविधाओं की स्वीकृति और परीक्षण डेटा के साथ एकीकरण स्टैंड की तैयारी में तेजी आई है।
कुल मिलाकर, रिलीज प्रवाह में 15-20% की तेजी आई और एकीकरण बग की संख्या लगभग आधी हो गई क्योंकि अब हम उन्हें बीआरएस और एसआरएस आवश्यकताओं को लिखने के चरण में और फीचर विकास के ढांचे के भीतर टीम एकीकरण के दौरान पकड़ते हैं।
सुखद और उत्पादक परीक्षण!
