टिकटों का आकलन करते समय परीक्षक का समय शामिल होना चाहिए?

Question

टिकटों के लिए समय का अनुमान लगाते समय परीक्षकों (क्यूएएस) के लिए लगने वाले समय को टिकट के अनुमान में शामिल किया जाना चाहिए? हमने पहले हमेशा परीक्षकों के समय के बिना अनुमान लगाया है लेकिन हम हमेशा इसमें शामिल होने की बात कर रहे हैं। यह हमारे वर्तमान स्प्रिंट के लिए समझ में आता है, रिलीज से पहले आखिरी, क्योंकि हमें यह जानने की जरूरत है कि जाने के लिए कुल टिकट एक सप्ताह के साथ लगेगा।

मुझे हमेशा समझ में आया कि अनुमान सिर्फ डेवलपर समय के लिए था क्योंकि यह टीमों में सीमित संसाधन हो जाता है। एक सहकर्मी कह रहा है कि जहां भी उन्होंने परीक्षक समय से पहले काम किया है उसे भी शामिल किया गया है।

स्पष्ट होने के लिए, यह एक ऐसी प्रक्रिया के लिए है जहां डेवलपर्स इकाई, एकीकरण और यूआई परीक्षण अच्छे कवरेज के साथ लिख रहे हैं।

Comments

परीक्षक द्वारा खोजे जाने वाले मुद्दों से पुन: व्यवस्थित होने वाले बगफिक्स के समय के बारे में क्या? यह अनुमान लगाने के लिए बहुत कठिन बात है :)।

— फ्रैंक पफर

क्या आपके किए गए काम की परिभाषा का हिस्सा है, या हम एक पूरी टीम / विभाग के बारे में बात कर रहे हैं?

— nvoigt

"टिकट" पर खर्च किए गए समय के विशाल बहुमत के लिए परीक्षक के प्रयास के लिए यह पूरी तरह से संभव है। तो, आईएमओ; हाँ।

— ग्रिम द ओपिनर

@nvoigt परीक्षण हमारे किए की परिभाषा का हिस्सा है।

— TTransmit

Answer 1

मेरी सिफारिश: आप या तो टिकट में परीक्षण का समय शामिल करते हैं, या परीक्षण कार्य का प्रतिनिधित्व करने के लिए टिकट जोड़ते हैं। किसी भी अन्य दृष्टिकोण से आपको आवश्यक वास्तविक कार्य को कम करके आंका जाता है।

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

आपके सहयोगी के रूप में, मैंने एक सफल संगठन नहीं देखा है जो परीक्षण के समय को ध्यान में नहीं रखता है।

आपके स्पष्टीकरण के अनुसार परिशिष्ट: भले ही देव स्वचालित परीक्षण लिखते हैं, विशेष रूप से इकाई परीक्षण (एकीकरण परीक्षण बेहतर करते हैं), वे ठीक से परीक्षण करने के लिए अपर्याप्त हैं।

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

Comments

अड़चन स्थान कंपनी पर निर्भर करता है। खान में, हमारे पास 8 डेवलपर्स हैं जो एक क्यूए संसाधन खिलाते हैं। QA स्पष्ट रूप से अड़चन है

— मार्शल टाइगरस

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

— माई हेड हर्ट्स

@MarshallTigerus: मुझे लगता है कि आम तौर पर ऐसा मामला है कि एन डेवलपर्स के लिए क्यूए प्रदान करने के लिए आवश्यक लोगों के साथ तालमेल करना आसान है (सटीक संख्या उत्पाद पर निर्भर करती है), क्योंकि यह एन डेवलपर्स का समन्वय करना है। तो कुछ अर्थों में क्यूए "को" अड़चन नहीं होना चाहिए, आपको "एक और क्यूए" रखना चाहिए (और एक डेवलपर को वेतन और डेस्क स्पेस उपलब्ध कराने के लिए आग लगाना चाहिए, यहां तक ​​कि चलो उम्मीद करते हैं कि यह उस पर नहीं आए)। बेशक हर चीज हमेशा वैसी नहीं होती जैसी होनी चाहिए।

— स्टीव जेसोप

एक और टिकट के लिए +1, यह जानना बहुत आसान बनाता है कि चीजें कहां अटकती हैं।

— मैथ्यू एम।

@SteveJessop बहुत सारी चीजें "होनी चाहिए" :)

— मार्शल टाइगरस

Answer 2

जोर से, हाँ

परीक्षण विकास प्रक्रिया का हिस्सा है। यदि आपकी टीम वास्तव में सॉफ़्टवेयर का परीक्षण करने में समय बिताती है, तो परीक्षण में लगा समय अनुमान का हिस्सा होना चाहिए।

Answer 3

यदि यह चुस्त है, तो मैं परीक्षण कहानी को कुल कहानी बिंदुओं के हिस्से के रूप में शामिल करूंगा। उदाहरण के लिए, देव का प्रयास शायद १ दिन और परीक्षण १ दिन का हो ताकि वह २ अंक की कहानी हो।

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

Answer 4

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

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

मैंने टेस्टर टाइम काम सहित देखा है। मैंने अलग-अलग कहानियों का काम देखा है। मैंने अलग-अलग कार्य देखे हैं, प्रत्येक समूह द्वारा अनुमानित किया गया है कि वे काम कर रहे हैं। वह करें जो आपके लिए मायने रखता है, आखिरकार आपकी सेवा करने के लिए है, इसके विपरीत नहीं।

Answer 5

यह तथ्य कि आप इसका दृढ़ता से उत्तर नहीं दे सकते, आपको पता नहीं है कि आप अनुमान क्यों लिख रहे हैं (या कम से कम आप अपने सहयोगी से असहमत हैं कि आप अनुमान क्यों लिख रहे हैं)। यह एक बड़ी समस्या है कि अनुमानों में परीक्षण शामिल होना चाहिए या नहीं होना चाहिए।

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

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

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

यदि अनुमानों का उद्देश्य भविष्यवाणी और योजना के अलावा कुछ और है, उदाहरण के लिए "क्योंकि हम नासमझ एक खाली अनुष्ठान का पालन करते हैं जो उन्हें शामिल करता है", या "क्योंकि प्रबंधन उन्हें एक छड़ी के रूप में उपयोग करता है ताकि हम से बाहर निकलने के लिए हमें हरा सकें", या "क्योंकि हमें एक निश्चित मूल्य की बोली लगानी है और संख्या एक विशाल सूत्र में चली जाती है" (धन्यवाद जॉन वू), तो यह पता लगाना कठिन हो सकता है कि उन्हें क्या शामिल करना चाहिए ;-)

Answer 6

हमेशा उन सभी कार्यों का अनुमान लगाएं जो वास्तव में किए गए उपयोगकर्ता-कहानी / सुविधा / टिकट बनाने के लिए किए जाने की आवश्यकता है। हम इसे डोनेडोन कहते हैं ।

हम तब कर रहे हैं जब हम उत्पादन के लिए तैयार हैं ।

इसमें कोई भी मैनुअल और खोजपूर्ण परीक्षण शामिल है, लेकिन उपयोगकर्ता-स्वीकृति परीक्षण भी।

एक फुर्तीली टीम को किसी भी समय तैयार काम का एक नया हिस्सा जारी करने में सक्षम होना चाहिए। जैसा:

कार्य सॉफ्टवेयर प्रगति का प्राथमिक उपाय है।

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

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

Answer 7

यहाँ कुछ महत्वपूर्ण है: सभी अनुमान मान्यताओं और बहिष्करणों के साथ होने चाहिए ।

इसमें यह निर्दिष्ट करना शामिल है कि क्या शामिल है: केवल विकास, डिजाइन और विकास, देव और इकाई परीक्षण, स्वीकृति परीक्षण के लिए कवरेज, आधारभूत संरचना का निर्माण आदि।

यदि आप एक परियोजना प्रबंधक को एक अनुमान दस्तावेज प्रदान कर रहे हैं, तो वे उस दस्तावेज को एक ग्राहक के लिए काम के आदेश या कथन में या (यदि एक आंतरिक परियोजना) पीएमओ के लिए परिवर्तित करने जा रहे हैं । वे ओवरहेड जोड़ने के लिए सूत्र निर्धारित कर सकते हैं (उदाहरण के लिए, कुछ परियोजनाएं QA को कवर करने के लिए X% जोड़ सकती हैं, फिर शासन और परियोजना प्रबंधन को कवर करने के लिए Y% जोड़ सकती हैं) जो अनुबंध द्वारा निर्धारित हैं या अनुभव द्वारा निर्धारित हैं। और आप डबल गिनती नहीं करना चाहते हैं। दूसरी ओर, वे अपने आप नहीं जोड़ सकते हैं।

अभ्यास अलग हैं। जो कोई भी इन नंबरों का उपयोग कर रहा है, उसे यह जानना होगा कि संख्याओं का क्या मतलब है, और आपको इस बारे में स्पष्ट होना चाहिए कि क्या आप परीक्षण के समय सहित हैं या नहीं।

Answer 8

समय को अनुमान में शामिल किया जाना चाहिए लेकिन आपको परीक्षकों के समय का अनुमान नहीं लगाना चाहिए, इसके बजाय परीक्षकों को अपने समय का अनुमान लगाना चाहिए ।

परीक्षण समय को शामिल नहीं करना कुल समय का एक गलत अनुमान है, लेकिन डेवलपर समय और परीक्षक समय विनिमेय नहीं हैं (कम से कम क्योंकि आप संभवतः समानांतर में काम करते हैं, परीक्षकों के पीछे एक पुनरावृत्ति के साथ) इसलिए आपको उन्हें अलग से अनुमान लगाना चाहिए। इसके अलावा, आप अनुमान लगाने की स्थिति में नहीं हैं कि समय परीक्षकों को किसी भी बदलाव का परीक्षण करने की आवश्यकता होगी, केवल टेस्ट क्रू को ही ऐसा करना चाहिए।

Comments

यह देखते हुए कि यह आप ही हैं जो टिकट में भरते हैं, और परीक्षण समय को शामिल किया जाना चाहिए, फिर देवता को परीक्षण के लिए एक 'अतिथि' शामिल करना चाहिए, बाद में परिशोधन के लिए। यह कुछ नियमों के साथ 22 अनुमान ब्लैक होल का कैच बनाना आसान है ... ये छेद कई फॉर्म भरने वाले कार्यों में होते हैं।

— फिलिप ओकले

Answer 9

encapsulation

मैं इसे देखने और भाषा के सॉफ़्टवेयर डेवलपमेंट बिंदु से संपर्क करने जा रहा हूं।

• आप एक बड़ी मशीन में एक छोटे से दलदल हैं।
• आपकी टीम के बाहर से, आपका टिकटिंग सिस्टम आपकी टीम के लिए एक इंटरफ़ेस / एपीआई के रूप में कार्य करता है
• व्यवसायिक उपयोगकर्ता जो टिकटिंग सिस्टम का उपयोग करते हैं, वे डेवलपर नहीं हैं

अच्छे सॉफ्टवेयर डिजाइन से, आपको जितना संभव हो उतना सरल और संक्षिप्त करना चाहिए।

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

1. इसका मूल्य कितना होगा?
2. हो गया क्या?

आपकी टीम की आंतरिक प्रक्रिया के बारे में जानने के लिए व्यवसाय उपयोगकर्ता को अनुमति देना बुरा प्रबंधन है; publicआंतरिक स्थिति तक पहुंच प्रदान करने के लिए।

अपनी टीम की आंतरिक स्थिति की रक्षा करने में विफलता, अपने संसाधनों का प्रबंधन करने और अपने आंतरिक स्थिति के साथ खिलवाड़ करने के लिए अन्य टीमों को आमंत्रित कर रही है।