is there any start stop boundary qa s role scrum
क्या है QA का रोल इन स्क्रैम: टेस्टर्स के लिए स्क्रैम एक्टिविटीज़
यह आलेख क्यूए के रूप में काम करने के बारे में कुछ प्रक्रियाओं या विधियों या निर्देशों के बारे में सिर्फ एक ट्यूटोरियल नहीं है। बल्कि, यह एक लेख है जिसमें मैं SCRUM में एक वरिष्ठ QA के रूप में काम करने के अपने अनुभव को साझा करना चाहता हूं।
मेरा पिछला सीटीओ हमेशा कहा करता था ‘स्वतंत्रता के साथ जिम्मेदारी आती है’। अगर आपको अपने काम को अपने तरीके से करने की आजादी दी जाती है तो यह आप और केवल आप ही हैं जो आपके काम या कार्यों या गतिविधियों के लिए जिम्मेदार हैं।
यह वही है जो सभी के बारे में है !! जैसे-जैसे हम आगे बढ़ते हैं, मैं आपको स्क्रैम के बारे में एक बुनियादी विचार देता हूं।
आप क्या सीखेंगे:
स्कैम का अवलोकन
Scrum का एक सबसेट है फुर्तीली कार्यप्रणाली और एक हल्का प्रोसेस फ्रेमवर्क है जिसका व्यापक रूप से उपयोग किया जाता है।
स्क्रम हमें ग्राहकों को छोटे मॉड्यूल में उत्पाद देकर खुश रखने में मदद करता है, इससे ग्राहक को यह भी पता रहता है कि उनकी लगातार बदलती आवश्यकताएं गतिविधियों को धीमा कर सकती हैं। रिलीज कम है और इसमें शामिल टीम की क्षमता के अनुसार काम लिया जाता है, इसलिए विफलताओं या दुखी ग्राहकों की संभावना काफी हद तक कम हो जाती है।
दूसरी ओर, आवश्यकताओं को (इस मामले में उपयोगकर्ता कहानियां) को अंतिम रूप दिया जाता है इससे पहले कि स्प्रिंट शुरू होने से बचने के लिए और इस प्रकार यह देरी या विफल स्प्रिंट के परिणामस्वरूप होता है (अपवाद हमेशा होते हैं)।
लेकिन क्यूए के लिए सबसे बड़ी चुनौती यह है कि रिलीज अवधि कम है, स्प्रिंट ज्यादातर 15 दिनों का चक्र है। इसलिए, अधिकतम 4-5 दिनों में (बगैर विकास के समय निकालकर) उत्पाद को बग मुक्त करने के लिए काफी प्रयासों और स्मार्ट सोच की जरूरत होती है।
मैं अपनी टीम का क्यूए हूं:
अरे हां, मैं अपनी टीम का क्यूए हूं और मैं अपनी टीम का एक महत्वपूर्ण खिलाड़ी हूं। क्यों?? क्योंकि ग्राहक, BA, Scrum Master और बाकी सभी लोग गुणवत्ता, लुक और फील और एप्लिकेशन या उत्पाद के प्रदर्शन के बारे में फ़र्ज़ी हैं।
स्प्रैम में, स्प्रिंट की अवधि कम होने के कारण, क्यूए को एक स्मार्ट तरीके से प्रदर्शन करना पड़ता है और इसलिए क्यूए को शुरू से ही शामिल करने की आवश्यकता ‘प्लानिंग’ के लिए बहुत महत्वपूर्ण हो जाती है। ऐसे समय होते हैं जब कोई पीओ पीओ उपलब्ध नहीं होने पर प्रॉक्सी प्रोडक्ट के मालिक की भूमिका निभा सकता है, इस प्रकार बीए को स्वीकृति मानदंड परीक्षण परिदृश्य / मामले बनाने में मदद करता है।
डेवलपर्स कई बार QA से संपर्क करते हैं जब उन्हें कार्यक्षमता या व्यावसायिक नियमों से परेशानी होती है। स्क्रम में, ध्यान केवल एक चिकनी और सफल स्प्रिंट रिलीज पर है और यह, माई वर्क ’या give योर वर्क’ के बारे में नहीं है जब आपकी टीम आपसे सहायता के लिए संपर्क करे।
स्क्रैम टीम बॉन्डिंग में, टीम के सदस्यों के बीच स्वस्थ संबंध एक बहुत ही महत्वपूर्ण भूमिका निभाते हैं और एक क्यूए होने के नाते, आपको उन उपयोगकर्ता कहानियों के बारे में अपनी राय का संचार करते समय बहुत सावधानी बरतनी चाहिए जिनका आप परीक्षण कर रहे हैं। आपका संचार उपयोगकर्ता की कहानी या कार्यक्षमता के बारे में होना चाहिए, न कि उस व्यक्ति के बारे में जो उस पर काम करता है।
स्क्रम में, क्यूए को उन बगों की संख्या के लिए न्याय नहीं किया जाता है और न ही उसकी सराहना की जाती है, बल्कि यह भी पता चलता है कि वह टीम के साथ कैसे बातचीत कर रहा है, टीम की मदद कर रहा है या टीम को मुश्किल समय में भी प्रेरित कर रहा है।
स्प्रिंट कार्यों का परीक्षण करने के अलावा, परीक्षण योजनाएं / परीक्षण मामले / रिलीज दस्तावेज भी अधिक शामिल करने की कोशिश करते हैं क्योंकि स्प्रिंट की रिलीज अवधि कम है और लक्ष्य सभी के लिए समान है 'एक दूसरे की मदद करके काम करने वाले बग-मुक्त उत्पाद को सफलतापूर्वक वितरित करना'।
एक QA स्प्रिंट में की गई लगभग सभी गतिविधियों में शामिल है और तकनीकी रूप से QA गतिविधियों की शुरुआत या रोक के लिए कोई सीमा नहीं है। पारंपरिक झरना मॉडल के विपरीत जहां क्यूए केवल रिलीज के परीक्षण तक सीमित है, यहां क्यूए की बहुत अधिक जिम्मेदारियां हैं। इसलिए, मैं निम्नलिखित गतिविधियों के बारे में और अधिक प्रयास करने का सुझाव दूंगा।
गतिविधियों का पालन किया जाना है
नीचे कुछ गतिविधियां दी गई हैं, जो मैं आपको सुझाव दूंगा कि आप स्क्रैम में क्यूए के रूप में अनुसरण करें।
विंडोज़ के लिए सबसे अच्छा मुफ्त डेटाबेस सॉफ्टवेयर
(1) ड्वेलर:
इसके द्वारा, मेरा मतलब है कि जब उपयोगकर्ता कहानियां और उनकी स्वीकृति मानदंड तैयार होते हैं, तो उनका पूरा अध्ययन करें और निर्भरता, छिपे हुए परिणामों के बारे में गहराई से सोचें और यदि ऐसा करने का कोई बेहतर तरीका है।
इस बारे में बीए और विकास टीम के साथ संवाद और सहयोग करें क्योंकि ऐसा हो सकता है कि उन्होंने भी इस बारे में नहीं सोचा होगा। अपने विचारों और निष्कर्षों को टीम के साथ साझा करें।
यदि आप पाते हैं कि छिपे हुए बाधाएं या नकारात्मक प्रभाव हैं, तो उन्हें स्क्रैम मास्टर और देव लोगों के साथ उठाना उन्हें सोचने और तदनुसार कार्य करने का समय देगा। जब परियोजना बड़े पैमाने पर हो और तब स्क्रेम की यह गतिविधि बहुत महत्वपूर्ण हो जाती है जब टीमों में फैले मॉड्यूल होते हैं।
अब निर्भरता के बारे में अध्ययन करते समय, एक क्यूए के लिए एक प्रभाव बहुत महत्वपूर्ण है और यह विकास टीम को भी इसके बारे में अवगत कराता है। ऐसा करने के लिए, अन्य टीमों के क्यूए के साथ चर्चा करें और उनसे इनपुट लें।
# 2) अनुमानों में शामिल:
सामान्य प्रथा का अनुमानों में एक क्यूए शामिल करना है लेकिन छोटे स्प्रिंट के कारण बहुत बार, क्यूए को कार्यों के परीक्षण के लिए आकलन के लिए नहीं कहा जा सकता है और परीक्षण कार्य के लिए उन्हें 3/4/5 दिनों के लिए छोड़ दिया जा सकता है।
इसे कभी स्वीकार न करें। यदि आपको अपनी आवाज़ उठानी है, लेकिन सुनिश्चित करें कि आप अपना परीक्षण अनुमान प्रदान कर रहे हैं जिसमें आपको हर काम के लिए आवश्यक समय शामिल होना चाहिए।
इसमें अनुसंधान के लिए समय, सेटअप के लिए समय, ऐतिहासिक डेटा एकत्र करने के लिए समय आदि शामिल हो सकते हैं, लेकिन परीक्षण गतिविधियों को करने के लिए आवश्यक समय के बारे में सख्त और विशिष्ट होना चाहिए और इन समय मूल्यों को विकास कार्य समय के साथ उपयोगकर्ता कहानी में जोड़ा गया है। ।
यह बहुत महत्वपूर्ण है क्योंकि यदि आप आवंटित समय में अपना काम करने की कोशिश करते हैं और यदि आप पूरा करने में असमर्थ हैं, तो केवल आप विफलता के लिए जिम्मेदार होंगे। जब QA समय जोड़ा जाता है, तो स्क्रम मास्टर, PO को QA गतिविधियों में शामिल होने और आवश्यक समय की मात्रा के बारे में पता होगा।
# 3) देव क्यूए जोड़ी:
आदर्श रूप से, स्क्रैम में, स्प्रिंट उपयोगकर्ता कहानियां विकास के पूरा होने के बाद परीक्षण के लिए सौंप दी जाती हैं और एक बार देव परीक्षण किया गया है, लेकिन यहां समस्या यह है कि जब तक यह परीक्षण के लिए QA को सौंप दिया जाता है, तब तक मुश्किल से 4-5 दिन ही होता है। डेमो या समीक्षा के लिए बने रहें।
अब, यदि एक QA के रूप में आपको 4 अवरोधक या कार्यात्मक विफलताएं भी पता चलती हैं, तो आपको अपनी रिलीज़ की तारीख को पूरा करने के लिए देर रात या सप्ताहांत पर काम करना होगा, क्योंकि कार्यात्मक परीक्षण, प्रतिगमन आदि किए जाएंगे। यह पारंपरिक झरना मॉडल की तरह लगता है जो सबसे अच्छा तरीका नहीं है, स्क्रैम में सबसे स्मार्ट तरीका है 'दोषों को खोजने के बजाय दोषों को रोकें'।
इसलिए समाधान देव क्यूए पेयरिंग करना है और देव सेटअप पर परीक्षण का एक मूल दौर प्रदर्शन करना है जैसे ही डेवलपर्स परीक्षण के लिए एक औपचारिक रिलीज से पहले ही कहानियों के साथ तैयार हैं।
निम्नलिखित मानदंडों को उपयोगकर्ता कहानियों के लिए देव सेटअप पर बीवीटी करने के लिए ध्यान में रखा जा सकता है:
- प्रत्येक उपयोगकर्ता कहानी के लिए स्वीकृति मानदंड: स्वीकृति मानदंडों के अनुसार उपयोगकर्ता कहानियों की BVT।
- डेवलपर्स में आत्मविश्वास की कमी: कभी-कभी डेवलपर्स कुछ कार्यान्वयन के बारे में आश्वस्त नहीं होते हैं और इसलिए वे ऐसे कार्यान्वयन पर चर्चा करते हैं और उसी देव सेटअप पर उन लोगों के लिए बीवीटी करते हैं।
- निर्भरता / प्रभाव परीक्षण: निर्भरता की BVT या नए कार्यान्वयन के अन्य मॉड्यूल के / पर प्रभाव।
- इकाई का परीक्षण: यूनिट परीक्षणों के डेवलपर के साथ बीवीटी करें जो उन्होंने बनाए हैं, यदि आवश्यक हो तो यूनिट परीक्षणों को जोड़कर या अपडेट करके उनकी मदद करें।
इससे बग्स को कम करने और कम करने में मदद मिलेगी, क्यूए जारी होने से पहले सभी के समय को बचाने के लिए दुर्घटनाग्रस्त या कार्यात्मक बगों का बहुमत पहले से तय है। स्प्रिंट समीक्षा से पहले अपने उपकरणों में उन दोषों को लॉग इन करना याद रखें और उन्हें those बंद ’अवस्था तक ले जाएं।
# 4) व्हाइट बोर्ड पर QA:
मैंने हमेशा अपनी टीम को व्यक्तिगत रूप से व्हाइट स्क्रम बोर्ड पर क्यूए कार्यों को शामिल करने के लिए प्रोत्साहित किया है जिसमें कीड़े भी शामिल हैं। यह स्क्रम मास्टर को बोर्ड को देखकर उपयोगकर्ता की क्यूए स्थिति का पता लगाने में मदद करता है।
नहीं। टू डू सूची में कीड़े, प्रगति सूची में कीड़े, टू डू, इन प्रगति और क्यू सूची में क्यूए गतिविधियों खुद के लिए बोलते हैं। मुझे यह वास्तव में दर्दनाक लगता है जब कोई स्प्रिंट के लिए व्यक्तिगत कहानियों के परीक्षण की स्थिति के बारे में पूछता है क्योंकि मुझे उपकरण संकलित से अपनी स्थिति निकालने और उन्हें दिखाने या ईमेल का मसौदा तैयार करने के लिए अतिरिक्त समय बिताना पड़ता है।
मैं बस व्यक्ति को स्क्रैम बोर्ड को इंगित करना पसंद करता हूं और उन्हें इसे खुद के लिए बनाने देता हूं। क्यूए स्टिकी स्लिप्स के लिए एक उज्ज्वल बकाया रंग पसंद करें।
# 5) प्रलेखन:
यह स्क्रम की कमियों या खामियों में से एक है कि स्प्रिंट के छोटे आकार के कारण प्रलेखन के लिए बहुत समय नहीं है और मैंने कभी भी एक स्क्रम टीम में तकनीकी लेखक नहीं देखा है। स्क्रम मास्टर / बीए उत्पाद जानकारी के बारे में हमेशा दस्तावेजों को अपडेट नहीं कर सकता है और न ही कर सकता है।
समस्या तब आती है जब नए सदस्य शामिल होते हैं या सबसे खराब स्थिति में होते हैं यदि व्यवसाय के नियम, कार्यक्षमताएं बदल जाती हैं और इन पर नज़र कैसे रखें क्योंकि जानकारी के लिए searching Done ’उपयोगकर्ता कहानियों में खोज करना एक बाधा में सुई की तलाश की तरह होगा।
प्रलेखन के लिए जब भी संभव हो, समाधान एक स्प्रिंट में बनाया गया एक अलग कार्य होता है (ज्यादातर सुस्त समय में या जब काम का बोझ बहुत कम होता है) ताकि आप दस्तावेजों की समीक्षा कर सकें और स्क्रम मास्टर या बीए को अपडेट कर सकें।
क्यूए दस्तावेजों को अपडेट करने में मदद करने के लिए सही व्यक्ति है क्योंकि आप एक हैं जो परीक्षण करते हैं, उपयोगकर्ता की कहानियों को सत्यापित करते हैं और कार्यक्षमता को अंदर और बाहर जानते हैं। यदि बीए नहीं है और यदि आपका स्कैम मास्टर अपडेट करने में व्यस्त है, तो इसे स्वयं करें।
# 6) स्प्रिंट समीक्षा / स्प्रिंट डेमो:
अधिकतर ऐसा होता है कि क्यूए वह होता है जो पीओ और स्टेकहोल्डर्स को डेमो देने के लिए चुना जाता है। लेकिन अगर ऐसा करने के लिए अपने स्क्रम मास्टर को राजी न करें। क्यूए डेमो देने के लिए एक सही व्यक्ति है क्योंकि उसने उपयोगकर्ता कहानी को अंदर और बाहर का परीक्षण किया है।
एक क्यूए व्यापार के दृष्टिकोण से डेमो कर सकता है क्योंकि वे कार्यात्मकता, प्रवाह और व्यापार नियमों को जानते हैं। डेमो के लिए अच्छी तरह से तैयार करें और पीओ और स्टेकहोल्डर्स के हर सवाल का जवाब देने की कोशिश करें। यह आपको स्क्रम मास्टर और बीए की अनुपस्थिति में उनके लिए संपर्क का बिंदु बनने में मदद करेगा।
# 7) एक बीए की तरह अधिनियम:
यह एक नियमित कार्य नहीं है और एक क्यूए से भी अपेक्षित नहीं है लेकिन इस भूमिका में प्राप्त करने का प्रयास करें जब एक मौका फेंका जाता है क्योंकि एक क्यूए बीए होने के लिए सबसे अच्छा व्यक्ति है। उदाहरण के लिए, यह सोचने और कल्पना करने की कोशिश करें कि क्या प्रवाह, कार्यक्षमता या व्यावसायिक नियमों को संशोधित किया जा सकता है जिससे ग्राहक को लाभ होगा।
UI में वर्तमान रुझानों के बारे में सोचें और खोजें, एप्लिकेशन को देखें और महसूस करें कि इसे कैसे हराया जा सकता है, अधिक उपयोगकर्ता के अनुकूल बनाया गया है आदि। यदि टीम किसी समस्या पर फंस गई है, तो शामिल हो जाएं और एक सरल और स्मार्ट देने का प्रयास करें। उपाय। यह आपकी भूमिका को बढ़ावा देगा और आपके कैरियर के विकास में योगदान करने वाला कारक होगा।
मौके पीओ के साथ कॉल पर आते हैं जब कुछ समस्याओं पर चर्चा की जाती है या समीक्षा / डेमो में जहां आप सुझाव दे सकते हैं।
निष्कर्ष
Scrum एक बहुत ही अलग कार्यप्रणाली है, जो सामान्य झरना विधि से है, और Scrum Master एक सूत्रधार है। इसलिए उससे यह अपेक्षा न करें कि वह आपके लिए अपनी गतिविधियों को परिभाषित करेगा।
स्क्रम में, क्यूए की भूमिका के लिए कोई शुरुआत और अंत सीमा नहीं है। क्यूए की जरूरत है और शुरुआत से अंत तक हर गतिविधि में शामिल होना चाहिए, प्री-प्लानिंग से सही स्प्रिंट समीक्षा / डेमो तक और सभी गतिविधियों में भाग लेना चाहिए।
इससे उत्पाद या एप्लिकेशन को समझने में मदद मिलेगी (जैसा कि मैंने पहले कहा था) स्क्रेम में काम करते समय कोई उचित दस्तावेज उपलब्ध नहीं है। आपको जिम्मेदार, प्रेरित और सक्रिय होने की उम्मीद है। इसलिए किसी के आने का इंतजार न करें और आपको बताएं कि आपको क्या करना है या कैसे करना है।
आपको खुद से पहल करनी चाहिए, टीम की हरसंभव मदद करनी चाहिए, स्वस्थ संबंध बनाए रखना चाहिए, टीम में चल रही चीजों पर नज़र रखना चाहिए और सबसे महत्वपूर्ण बात यह है कि किसी दिए गए स्प्रिंट में अपने कार्यों के बारे में स्पष्ट होना चाहिए।
यहां, कोई प्रबंधक नहीं हैं जो आपकी निगरानी करेगा या आपकी गतिविधियों पर नज़र रखेगा। अपनी टीम के लिए हमेशा मदद के लिए तैयार रहें और आपको बेहतरीन अवसर मिलेंगे।
नीचे टिप्पणी अनुभाग में इस जानकारीपूर्ण लेख के बारे में अपने विचार / सुझाव व्यक्त करने के लिए स्वतंत्र महसूस करें।
अनुशंसित पाठ
- SCRUM में व्यवसाय विश्लेषकों की भूमिका और इस भूमिका के लिए QA सर्वश्रेष्ठ क्यों है?
- Agile Scrum ऑनलाइन क्विज़: Agile Scrum के अपने ज्ञान का परीक्षण करें
- डिवाइस पर अपना एप्लिकेशन इंस्टॉल करना और ग्रहण से परीक्षण शुरू करना
- कानबन बनाम स्क्रम बनाम एजाइल: अंतर खोजने के लिए एक विस्तृत तुलना
- चंचल समय प्रक्रिया का उपयोग करते हुए कम समय की अवधि में उच्च मूल्य सॉफ़्टवेयर सुविधाओं को कैसे वितरित करें
- एजाइल मेनिफेस्टो: अंडरस्टैंडिंग एज़ाइल वैल्यूज़ एंड प्रिंसिपल्स
- स्क्रम में दोषपूर्ण ट्रेजिंग: यह एक स्क्रम सेटअप में कैसे व्यवस्थित किया जाता है
- सर्वश्रेष्ठ सॉफ्टवेयर परीक्षण उपकरण 2021 (क्यूए टेस्ट स्वचालन उपकरण)