परीक्षकों के बिना जीवन: मिथक या वास्तविकता?

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

और वास्तव में समस्या क्या है?

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

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

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

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

ऐसा क्यों हो रहा है

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

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

परियोजना पर परीक्षक की भूमिका

तो एक परियोजना पर एक परीक्षक की भूमिका कौन निभानी चाहिए? सबसे पहले, यह समझना महत्वपूर्ण है कि यह एक भूमिका है, विशिष्ट व्यक्ति नहीं। और यह भूमिका टीम के सदस्यों के बीच वितरित की जानी चाहिए। तो, कौन जिम्मेदार होगा:

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

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

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

निष्कर्ष

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

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

यूपीडी: लेख में मैं उन परियोजनाओं के बारे में बात नहीं कर रहा हूं जहां त्रुटि की लागत बहुत अधिक है, परमाणु ऊर्जा संयंत्रों के लिए विकास (बैंकिंग प्रणाली का मूल, रोवर के लिए सॉफ्टवेयर)। यहां गुणवत्ता विभाग होना चाहिए, यदि इसकी लागत त्रुटि की लागत से अधिक नहीं है। लेकिन यहां तक ​​कि यह बहुत अधिक महत्वपूर्ण है कि डेवलपर्स पर बचत न करें और परीक्षकों के एक समूह को काम पर रखने के बजाय गुणवत्ता देखभाल की संस्कृति विकसित करें और इसे नियंत्रित करने का प्रयास करें।