परीक्षण / परीक्षक दक्षता का एक अच्छा उपाय क्या है?

Question

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

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

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

Comments

stevemcconnell.com/ieeesoftware/bp09.htm किसी तरह से उपयोगी हो सकता है।

यह अजीब है। यदि आप gmail.com का परीक्षण करते हैं और आप एक भी दोष खोजने में विफल रहते हैं, तो क्या आपको लगता है कि आप असफल रहे हैं? यदि आप किसी बहुत ही क्षुद्र के लिए एक लाख परीक्षण के मामले लिखते हैं, तो क्या आपको लगता है कि यह आपको सफल बनाता है? दोष रिसाव की तलाश करें जिसका अर्थ है कि दोष जो एसआईटी के दौरान अज्ञात थे और यूएटी के माध्यम से फिसल गए थे। ऐसे अन्य तरीके हैं जिनसे QA समग्र SDLC में मान जोड़ता है।

Answer 1

लिखित परीक्षा की संख्या बेकार है, और पाए जाने वाले कीड़े की एक उच्च संख्या कुशल क्यूए के बजाय खराब विकास का एक उपाय हो सकती है।

स्वचालन उपाय (कोड कवरेज, फीचर कवरेज ...) अच्छा हो सकता है, लेकिन मुझे लगता है कि वे विकास के लिए एक और मदद कर रहे हैं (एक डेवलपर के रूप में, क्या मुझे पता होगा कि मैं गलती से कुछ तोड़ता हूं) ग्राहकों की तुलना में (मैं ऐसा करना चाहता हूं और यह काम नहीं करता है)।

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

उस मीट्रिक के साथ मुख्य समस्या यह है कि किए गए काम के बीच काफी देरी हो सकती है और जब आप सार्थक संख्याएं शुरू करते हैं।

Comments

+1 अंततः ग्राहक संतुष्टि पूरी टीम के लिए मुख्य मीट्रिक है

— jk।

इसके अलावा प्रोग्रामर

— ।stackexchange.com

Answer 2

कुछ मेट्रिक्स हैं जिनका उपयोग मैंने QA के मूल्यांकन के लिए अपनी अंतिम नौकरी में किया था:

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

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

Comments

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

— rwong

कार्यात्मक परीक्षण ब्लैक बॉक्स परीक्षण होना चाहिए , या क्या मैं गलत हूं?

— B:59овиЈ

"बग की संख्या मिली": यह डेवलपर पर लागू एक उपाय होना चाहिए। इसके अलावा, यदि एक परीक्षक के रूप में मैं इस संकेतक से गुजरता हूं, तो मैं जल्द ही एक डेवलपर के साथ दोस्त बन जाऊंगा जो कोड I परीक्षण में बगों को पेश करने को तैयार है।

— मौविसील

Answer 3

QA को दो मुख्य मैट्रिक्स द्वारा मापा जाना चाहिए: मैदान में पाए जाने वाले QA के कितने कीड़े मिलते हैं? उनकी गंभीरता क्या है?

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

हालांकि अंत में, मुझे डर है कि आप एक अनुबंधित कर्मचारियों का उपयोग करके प्राप्त बचत की तुलना में अपने अनुबंधित कर्मचारियों की प्रभावशीलता को मापने के लिए अधिक पैसा खर्च करेंगे ...

Answer 4

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

मुझे जो सबसे अधिक प्रासंगिक लगता है वह है कोड कवरेज। EMMA जैसा एक उपकरण बहुत अच्छा काम करता है क्योंकि वे अपने मैनुअल परीक्षणों के अलावा पूरी तरह से स्वचालित परीक्षण लिखते हैं।

आप जो भी करें, परीक्षण की संख्या पर ध्यान केंद्रित न करें। यह प्रति दिन LOC जितना ही उपयोगी है।

Answer 5

परियोजना निष्पादन के दौरान विकास और परीक्षण चरणों में प्रदर्शन को मापने के कई तरीके। हमने अपनी परियोजनाओं में उपायों का उपयोग किया है। 4 लोकप्रिय कोड मेट्रिक्स (मेनटेनेबिलिटी इंडेक्स, साइक्लोमेट्रिक जटिलता, वंशानुक्रम की गहराई, कक्षा युग्मन) द्वारा मापा गया विकास प्रदर्शन। C # के लिए Microsoft Visual Studio में मिलेगा। टेस्ट कवरेज के लिए एनसीओआर / एनडिपेंडेंट बहुत उपयोगी है। पिछले 4 स्प्रिंट सिस्टम परीक्षण कीड़े द्वारा पिछले 4 स्प्रिंट पर रोलिंग प्रणाली के विकास के दौर से गुजर नहीं परीक्षण कीड़े द्वारा मापा परीक्षण प्रदर्शन। विशेष रूप से जारी / सुविधाओं में दिए गए स्वचालन परीक्षण में से कोई भी नहीं दिया गया।