क्यूए से देव अनुपात

Question

हमारे पास एक जटिल जटिल जावा सिस्टम है जिसमें डेटाबेस और मालिकाना स्विंग फ्रंट-एंड समेत कुछ बैक-एंड टियर शामिल हैं। बैक-एंड एपीआई हैं जिनके लिए बाहरी पार्टियां संलग्न हो सकती हैं जो हमारे सामने वाले अंत की नकल करती हैं। हमारे संगठन के भीतर लगभग 5 सिलो हैं जो इस प्रणाली को साझा करते हैं। कुल मिलाकर लगभग 15 डेवलपर्स इस प्रणाली को बनाए रखते हैं।

क्या हमारे क्यूए टीम का आकार क्या होना चाहिए इस पर अंगूठे का नियम है?

संपादित करें:

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

Answer 1

एक पूर्व परीक्षण टीम के नेतृत्व के रूप में, मैं आपको जितना परीक्षण कर सकता हूं उतना परीक्षण करने का सुझाव दूंगा। ऐसा लगता है कि आपके संगठन में बहुत से लोग आपके सॉफ़्टवेयर पर निर्भर करते हैं। जल्दी परीक्षण और परीक्षण अक्सर।

यह जानना बहुत महत्वपूर्ण है कि परीक्षण हर किसी की ज़िम्मेदारी है। डेवलपर्स को अच्छे यूनिट परीक्षण लिखने की जरूरत है। यूआई डेवलपर्स मैन्युअल रूप से यूआई का परीक्षण करना चाहिए।

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

जेफ

Answer 2

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

यदि यह एक जटिल जटिल प्रणाली है, तो आप हर 5 डेवलपर्स के लिए 2-3 क्यूए इंजीनियरों पर विचार करना चाह सकते हैं। हालांकि, विशेषताएं वास्तव में बहुत ज्यादा नहीं बदलती हैं या कम शामिल नहीं हैं, मुझे लगता है कि आप हर 5 डेवलपर्स (शायद हर 10 डेवलपर्स के लिए) के लिए केवल 1 क्यूए से दूर हो सकते हैं।

Answer 3

नहीं, अंगूठे का कोई नियम नहीं है। प्रत्येक संगठन अलग है, क्योंकि प्रत्येक संगठन के पास आवश्यकताओं, जरूरतों, परियोजनाओं आदि का एक पूरी तरह से अलग सेट होता है। आप केवल अपने संगठन के लिए क्या काम करते हैं यह जानने में सक्षम होंगे।

Answer 4

1 क्यूए से 5 या 6 डेवलपर्स के साथ शुरू करें। फिर यह समझें कि क्यूए को क्या करना है या ऐसा करने के लिए कुछ भी नहीं है, इस पर निर्भर करता है कि आप कितना काम करते हैं।

सच में, यह सिर्फ मेरे अपने अनुभव पर आधारित है क्योंकि इसमें बहुत से कारक शामिल हैं। आपका कोडबेस कितना विकसित या स्थिर है? वो कितना बड़ा है? परीक्षण कितना व्यापक होना चाहिए? किस तरह के परीक्षण और विश्लेषण उपकरण शामिल हैं? मील का पत्थर कितनी बार रिलीज़ होता है? आपके पास किस तरह की विकास प्रक्रिया है? कितना मैन्युअल परीक्षण और कितना स्वचालित परीक्षण?

बहुत सारे प्रश्न हैं। तो बस एक मनमाना संख्या से शुरू करें और वहां से जाओ।

Answer 5

अनुपात देव को एक तर्कसंगत क्यूए केवल विचाराधीन एक आवेदन की जटिलता के सापेक्ष प्राप्त किया जा सकता।

स्पष्ट रूप से, एक uberdeveloper शायद एक जटिल अनुप्रयोग के साथ आ सकता है जहां वर्कफ़्लो की जटिलता के कारण केवल 3 क्यूए पूर्णकालिक कुशलतापूर्वक परीक्षण कर सकते हैं; बदले में, 3 जूनियर देवों के लिए 1 क्यूए हो सकता है जो अपेक्षाकृत सरल इनपुट-आउटपुट रिपोर्ट एप्लिकेशन को एकसाथ पाइप कर सकता है।

तो आपको आवश्यक क्यूए कर्मियों की संख्या आपके पास आवश्यक आवश्यकताओं की संख्या और जटिलता द्वारा निर्धारित की जाएगी, न कि आपके द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर डेवलपर्स की संख्या।

Answer 6

मुझे नहीं पता कि 9 0 साल पहले this article के बाद से उसका दृष्टिकोण बदल गया है, लेकिन जोएल प्रति पूर्णकालिक देवताओं के 1 पूर्णकालिक क्यूए व्यक्ति की सिफारिश करेगा। मैं कहूंगा, एक प्रणाली के साथ जो नियमित रूप से विकसित हो रहा है, नियमित अपडेट के साथ, यह अनुपात बहुत अच्छा है।

फिर, यदि आप सिस्टम को अक्सर बदल नहीं रहे हैं, शायद ही कभी अपडेट हो रहा है, तो आपके साथ शुरू करने के लिए कई देवताओं क्यों होंगे? मैंने खुद को मनाने के लिए हस्तक्षेप किया है कि अधिकांश स्थितियों में 1: 2 सही अनुपात है। :)

Answer 7

प्रति 3 डेवलपर्स के 2 टेस्ट इंजीनियरों एक सभ्य शुरुआत है। यदि कई परीक्षण मामलों में ऐसी चीजें शामिल होती हैं जिन्हें स्वचालित नहीं किया जा सकता है (भौतिक रूप से प्लगिंग/अनप्लगिंग सामग्री, यूआई प्रतिपादन के ओकुलर सत्यापन) प्रति टेस्ट इंजीनियरों में 1 परीक्षक जोड़ें।

Answer 8

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

आपको यह भी पूछने की आवश्यकता है कि आप उन्हें मूल सिस्टम परीक्षण या वॉल्यूम और लोड परीक्षण भी करने की उम्मीद कर रहे हैं। ऐसा लगता है कि आप यूआई परीक्षण और एपीआई परीक्षण के संयोजन को देख रहे हैं।

आपको एक प्रारंभिक बिंदु बताते हुए, यह मानते हुए कि आप एक "सामान्य" प्रकार की प्रणाली की बात कर रहे हैं और हम बुनियादी प्रणाली परीक्षण की बात कर रहे हैं, मैं जिस मेट्रिक के साथ जाऊंगा, वह यह है कि सभी प्रयासों का 33% परीक्षण प्रयास होना चाहिए । सिद्धांत रूप में यह आपको 1 से 2 अनुपात देता है लेकिन मान लें कि आपके डेवलपर यूनिट परीक्षण शायद इसे 1 से 3 तक फैलाते हैं। निश्चित रूप से मैं वर्तमान में 1 से 4 तक चल रहा हूं और यह पर्याप्त नहीं है (मैं इसे जल्द से जल्द सुधार दूंगा व्यापार मुझे करने की अनुमति देता है)।

लेकिन आप यह भी विचार करना चाहते हैं कि आपके सॉफ्टवेयर विकास प्रक्रिया कितनी परिपक्व हैं और आपके विनिर्देश क्या हैं। साथ ही टेस्टर्स की सही संख्या रखने के लिए आपको उन्हें सही परीक्षण करने की आवश्यकता है - अगर उनके पास यह नहीं है तो वे नौकरी करने में सक्षम नहीं होंगे और यह तर्कसंगत रूप से बर्बाद धन है। वहाँ में फेंक

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