स्क्रैम गाइड क्यों कहता है कोई परीक्षक नहीं?

Question

मैं scrum.org से स्क्रैम गाइड पढ़ रहा हूं और यह कहता है:

विकास टीमों में विशेष डोमेन जैसे परीक्षण या व्यवसाय विश्लेषण के लिए समर्पित उप-टीमें शामिल नहीं हैं।

इसके शाब्दिक अनुवाद में इसका मतलब है कि कोई भी परीक्षक नहीं है जो भ्रमित हो। वे इसे कैसे सुझा सकते हैं?

Comments

इसके शाब्दिक अनुवाद में, इसका मतलब कोई प्रोग्रामर नहीं है। कोई व्यापार विश्लेषक नहीं है। एक उपयुक्त सादृश्य यह है कि हर कोई एक उत्तरजीवी है, जिसका काम सभी को जीवित रहने में मदद करने के लिए आवश्यक सब कुछ करना (और सीखना) है।

— रवांग

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

— zzzzBov

Answer 1

इसका मतलब है कि या तो:

1. डेवलपर्स को विकास टीम में एकीकृत किया जाता है - डेवलपर्स के परीक्षण के साथ-साथ परीक्षण करने में मदद करने के लिए उपकरण का निर्माण।

   या:

2. टीम टेस्ट ड्रिवेन डेवलपमेंट का अभ्यास करती है - यानी वे स्वचालित परीक्षण लिखते हैं जो सिस्टम का उपयोग करते हैं।

या तो इनका मतलब है कि अलग परीक्षण टीम की कोई आवश्यकता नहीं है।

Comments

TDD स्टार्टअप टीमों के लिए एक बेहतर दृष्टिकोण होगा। मैंने दृढ़ता से कहा है कि जब नौसिखिए टीमों में परीक्षक और डेवलपर्स एक साथ काम करते हैं, तो परीक्षण एक मुद्दा बन जाता है। क्यों भाई क्या कहते हो?

— मैक्सवुड

@Maxood: मैं कहूँगा कि TDD निश्चित रूप से मैन्युअल परीक्षण को अतिश्योक्तिपूर्ण नहीं बनाता है। अगर कुछ एक मुद्दा बन जाता है, तो आप इसे हल करते हैं; आप इसे टालना शुरू न करें।

— माइकल बोर्गवर्ड

@MichaelBorgwardt बहुत सच! लेकिन क्या होगा अगर आप अपने परीक्षक को इकाई परीक्षण में व्यस्त पाते हैं जो मुख्य रूप से एक डेवलपर का काम है? मुझे लगता है कि पूर्व विकल्प को केवल तभी प्राप्त किया जाना चाहिए जब यह कोड ऑप्टिमाइजेशन और एप्लिकेशन स्केलेबिलिटी आदि के बारे में आता है, आप क्या कहते हैं?

— मैक्सवुड

@ मोमूड: परीक्षकों को मेरी राय में, यूनिट परीक्षणों को नहीं छूना चाहिए। उन्हें डेवलपर्स के सहयोग से स्वीकृति परीक्षणों पर काम करना चाहिए, और मैनुअल / जीयूआई परीक्षण के लिए जिम्मेदारी लेनी चाहिए। यूनिट परीक्षण एक स्तर पर है जो केवल डेवलपर्स के लिए दिलचस्प है। परीक्षण पिरामिड ( blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid ) में रिस्पनाबिलिटीज , यूनिट-परीक्षण = डेवलपर्स, स्वीकृति परीक्षण = साझा, जीयूआई परीक्षण = परीक्षक भी हैं।

— 18

Answer 2

इसके शाब्दिक अनुवाद में इसका मतलब है कि कोई भी परीक्षक नहीं है जो भ्रमित हो ... वे इसे कैसे सुझा सकते हैं?

हां, यह वही है जो वे सुझाव देते हैं। दूसरे शब्दों में - डेवलपर्स परीक्षक हैं और परीक्षक डेवलपर्स हैं।

विचार कोड स्वामित्व और गुणवत्ता को बढ़ावा देना है ।

इसका मतलब यह नहीं है कि कोड का परीक्षण नहीं किया गया है, लेकिन यह है कि इसे लिखने में शामिल लोग इसे परीक्षण करने में शामिल हैं - जिम्मेदारियों का कोई पृथक्करण नहीं है।

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

Comments

मैं व्यक्ति होने के लिए एक मजबूत वकील हूं एक परीक्षण जो व्यक्ति बी विकसित हुआ। "खुद के कोड ब्लाइंडनेस" के नुकसान से बचने के लिए स्क्रैम के पास क्या सलाह हैं काम, या अवचेतन से कमजोर बिंदुओं से बचें)?

— मार्जन वेनमा

@MarjanVenema - किसी व्यक्ति द्वारा लिखे गए किसी व्यक्ति का परीक्षण किस व्यक्ति द्वारा किया जा सकता है, या किसी भी कोड को लिखे जाने से पहले स्वचालित परीक्षण लिखा जाना चाहिए।

— ऊदबिलाव

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

— वॉरेन पी

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

— जियोर्जियो

क्यूए और विकास दो अलग-अलग कौशल सेट (और वेतनमान) के साथ दो अलग-अलग भूमिकाएं हैं। उत्कृष्ट क्यूए को फोकस और विशेषज्ञता के एक स्तर की आवश्यकता होती है जो किसी डेवलपर और क्यूए के रूप में दोहरी ड्यूटी करने पर बस नहीं होगा।

— 17 का 26

Answer 3

इसका मूलभूत हिस्सा यह है कि कोडर की जिम्मेदारी कोड बनाने की है जो काम करता है और आवश्यकता को पूरा करता है। इसके लिए एक विशेष मानसिकता की आवश्यकता होती है - "जो कोड मैं लिख रहा हूं वह वही करता है जो इसे करना चाहिए।"

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

परीक्षक की जिम्मेदारी बग और स्थानों को ढूंढना है जहां कार्यक्षमता आवश्यक कार्यक्षमता से हटती है। इसके लिए "कोड टूट गया है और मुझे पता चलेगा कि मानसिकता कैसे है।"

इसी तरह, एक व्यवसाय विश्लेषक उन आवश्यकताओं की पहचान करने की कोशिश कर रहा है जो ग्राहक वास्तव में पूछ रहे हैं। इसके लिए "एप्लिकेशन को इस तरह से काम नहीं करने की मानसिकता की आवश्यकता होती है, लेकिन इसे होना चाहिए।"

उन अन्य क्षमताओं में से किसी में काम करने के लिए एक कोडर के लिए, एक उचित संभावना है कि मानसिकता संघर्ष करेगी और कोडर उप-प्रदर्शन करेगा:

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

यह कहना नहीं है कि हर कोडर इन समस्याओं के लिए अतिसंवेदनशील है (मुझे कुछ बहुत ही गिफ्टेड कोडर / क्यूए प्रकार मिले हैं ... हालांकि कोड के लिए नहीं जो उन्होंने लिखा था)।

यह विकास टीम तक फैली हुई है। एक विकास टीम के लिए उन जिम्मेदारियों की जिम्मेदारियों और संबद्ध मानसिकता को मिलाकर अंतिम उत्पाद (कोड) से समझौता होता है।

Answer 4

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

Comments

"ग्राहक परीक्षण में भी शामिल हो सकता है" - हां, बिल्कुल सही है, अन्यथा आपके पास एक झरना परियोजना है जहां काम किया गया है "हम परियोजना के अंत तक पहुंच गए हैं"। वह फुर्तीली नहीं है।

— रॉबिन ग्रीन

Answer 5

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

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

Answer 6

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

इसके अलावा, स्क्रम गाइड में भूमिकाओं के बारे में बहुत सीमित बात है। वास्तव में, वे विकास टीम के बारे में बात करते हैं। उनका मतलब है कि आप एक मजबूत क्रॉस-फंक्शनल टीम चाहते हैं। इसका मतलब यह है कि आपकी परियोजनाओं की आवश्यकता पर निर्भर करते हुए, आपको कई प्रकार के कौशल चाहिए, जैसे कि UX, BA, QA / Tester, Ops, Coder, इत्यादि, लेकिन क्या यह एक या कई व्यक्ति हैं जो इन्हें कवर करते हैं, वास्तव में कोई फर्क नहीं पड़ता।

मैं जिन टीमों के साथ काम करता हूं, निश्चित रूप से एक भूमिका के रूप में क्यूए है, जैसा कि हमारे पास देवता लोग हैं। लेकिन वे सभी इन क्षेत्रों में विशेषज्ञता के साथ देवता भी हैं। चाल वास्तव में सिलोस में नहीं गिरना और अलगाव में काम करना है।

Answer 7

यह जरूरी नहीं कि कोई परीक्षक न हों। यह मामला हो सकता है कि एक स्क्रम टीम में समर्पित परीक्षक हैं या नहीं।

मेरे लिए, स्क्रैम के बारे में इस कथन का मतलब यह है कि आपको एक ही टीम के रूप में पूरी डिलीवरी पाइपलाइन के बारे में सोचना चाहिए। एक ही टीम का हिस्सा होने से कुछ बातें पता चलती हैं:

1. एक कहानी / बग / कार्य पर एक ही अनुमान है। देव अनुमान और परीक्षण अनुमान नहीं है।
2. टीम किसी कहानी का अनुमान नहीं लगाती है और बिना परीक्षक के लिए प्रतिबद्ध है।
3. यदि कुछ गलत हो जाता है, तो यह डेवलपर की गलती से अधिक परीक्षक की गलती नहीं है। यह टीम की गलती है ।
4. टीम को कभी भी, परीक्षक के लिए उधार लेने, अनुरोध करने या पूछने की आवश्यकता नहीं होती है।
5. परीक्षण किया की परिभाषा का हिस्सा है। अधूरा काम अधूरा काम है।
6. डेवलपर्स को परीक्षणशीलता पर विचार करना चाहिए क्योंकि वे अपना कोड डिज़ाइन करते हैं।

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

संभावित संकेत आप वास्तव में परीक्षकों को डिलीवरी टीम के हिस्से के रूप में नहीं मान सकते हैं, भले ही आपको लगता है कि आप करते हैं:

1. परीक्षकों के पास एक "क्यूए स्टैंडअप" (हाँ, मैंने इसे देखा है)।
2. परीक्षकों के पास एक अलग प्रबंधन संरचना है।
3. आपके पास क्यूए लीड है।
4. आप एंड-टू-एंड परीक्षणों पर बहुत भरोसा करते हैं।
5. टेस्ट में निम्नलिखित स्प्रिंट लिखा जाता है।
6. स्प्रिंट के अंतिम दिन अधिकांश परीक्षण होते हैं।

ये व्यक्तिपरक हैं और जरूरी नहीं कि गलत हों। वे लाल झंडे हैं, हालांकि, मेरी राय में।

इस सभी ने कहा, किसी भी व्यक्ति के बिना एक स्क्रैम टीम होना पूरी तरह से संभव है, जिसके पास परीक्षक की निर्दिष्ट भूमिका है। वह भी अच्छा काम कर सकता है। खासकर यदि आप परीक्षण को स्वचालित करते हैं। TDD भी मदद करता है।