2008-10-20 11 views
5

मान लें कि 10 डेवलपर्स ने कुछ एप्लिकेशन विकसित करने के लिए 6 महीने का समय लिया है। प्रोजेक्ट मैनेजर के रूप में परीक्षण के लिए मेरी योजनाओं में मुझे कितना समय बचाया जाना चाहिए?परीक्षण समय की योजना कैसे बनाएं

प्रयास के 6 महीने में यूनिट परीक्षण शामिल है। मैं कार्यात्मक परीक्षण और उपयोगकर्ता स्वीकृति परीक्षण के बारे में विशिष्ट हूं।

क्या विकास समय और परीक्षण समय के बीच कोई अनुपात या संबंध है?

+3

मैं इस प्रश्न को ऑफ-विषय के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह प्रोग्रामिंग के बारे में नहीं है। –

उत्तर

6

यहाँ Alan Page से एक short article है, टेस्ट वास्तुकार माइक्रोसॉफ्ट के इंजीनियरिंग उत्कृष्टता टीम:

बातें परीक्षण आकलन में विचार करने के लिए के कुछ उदाहरण हैं:

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

क्या विकास समय और परीक्षण समय के बीच कोई अनुपात या संबंध है?

नहीं, वास्तव में नहीं है। आपको यह निर्धारित करने के लिए अपने आवेदन की कार्यात्मक आवश्यकताओं को देखना होगा कि यह किस प्रकार की आवश्यकता है और यह कितना समय लगेगा।

+1

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

1

एक अंगूठे के सामान्य नियम है कि परीक्षण के 1/3 के रूप में समय लगेगा विकास के रूप में ठीक से करने के लिए है, लेकिन यह बहुत है कि तुम क्या कर रहे हैं और कैसे व्यापक परीक्षण आप उम्मीद के आधार पर भिन्न हो सकता है।

+1

क्या आप अंगूठे के 1/3 नियम के संदर्भ में साइट कर सकते हैं –

1

मुझे विश्वास नहीं है कि यह एक प्रश्न है जिसे हम आपके लिए उत्तर दे सकते हैं। आप एक उचित अनुमान देने के लिए, हम कई बातें जानने की जरूरत होगी:

अपने परीक्षण लक्ष्य क्या हैं? (कोड कवरेज, दोष पाया/तय, आवश्यकताओं का परीक्षण, आदि)
में आप कितना समय समान परियोजनाओं पर परीक्षण खर्च किया है?
उन परियोजनाओं पर आपको किस गुणवत्ता के मुद्दों का सामना करना पड़ा? (बहुत अधिक दोष की खोज की, स्वीकार्य दोष की गंभीरता/अस्वीकार्य)
आप अभी तक किसी भी परीक्षा की योजना बना किया है?
इकाई परीक्षण कितने दोषों को उजागर किया? क्या अधिक/कम चिंता के क्षेत्र थे? आपने उनको कैसे संबोधित किया?
आप किस तरह का परीक्षण विश्लेषण करेंगे?

ऐसे मीट्रिक्स हैं जिनका उपयोग आप इस तरह के काम के लिए एक अनुमानित अनुमान देने में मदद के लिए कर सकते हैं, लेकिन समस्या यह है कि उन्हें सार्थक अनुमान देने के लिए वास्तव में आपके पर्यावरण के लिए ट्यून करने की आवश्यकता है। एक उपाय के परीक्षण के लिए 2 महीने का सुझाव दे सकता है, लेकिन आप पर एहसास हो सकता है नहीं है कि अपने पर्यावरण दो बार है कि समय की आवश्यकता है जब तक आप 2 महीने के लिए प्रतिबद्ध है और है कि तुम सच की जरूरत पता लगाना 4.

-1

यह सवाल का जवाब देना मुश्किल है। यह शायद इसी तरह की परियोजनाओं में आपके अनुभव पर निर्भर करता है। मैं आपको कुछ परियोजनाओं के लिए कुछ आंकड़े प्रदान कर सकता हूं जिनमें मैंने काम किया है। आप देख सकते हैं कि विकास समय के संदर्भ में परीक्षण समय के लिए फॉर्मूला प्राप्त करना मुश्किल है:

प्रोजेक्ट | जटिलता | विकास का समय | टेस्ट टाइम | # डेवलपर्स | # परीक्षक


ए | 4 | 90 दिन | 60 दिन | 4 | 1

बी | 1 | 60 दिन | 30 दिन | 2 | 1

सी | 5 | 90 दिन | 120 दिन | 4 | 1

डी | 2 | 15 दिन | 7 दिन | 2 | 2

ई | 3 | 120 दिन | 90 दिन | 2 | 2

2

मुझे आशा है कि आप एक प्रोजेक्ट मैनेजर के रूप में, Scrum या कुछ अन्य agile method जैसी पुनरावृत्ति विकास प्रक्रिया का उपयोग करने की योजना बना रहे हैं। मैं विकास में एक चरण के रूप में परीक्षण के बारे में नहीं सोचूंगा जो विकास चरण समाप्त होने के बाद किया जाना चाहिए, लेकिन विकास प्रक्रिया के एक अनिवार्य हिस्से के रूप में।

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

+1

Agile बहुत अच्छा है, लेकिन विकास के अंत में विकास के अंत में किसी भी फैंसी नई सुविधाओं को शुरुआत से उबाऊ पुरानी विशेषताओं को तोड़ने के बाद भी पुनर्जीवन आवश्यक है विकास का और स्वचालित परीक्षण अधिकांश क्षेत्रों में * सबकुछ * नहीं पकड़ सकता है। – tloach

+0

सच है, और पीछे की ओर देखने के बारे में मत भूलना! –

0

मैं पास्कल पैराडीस से स्वीकृत उत्तर से सहमत हूं।

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

संबंधित मुद्दे