एंड-टू-एंड टेस्टिंग: क्या, क्यों, क्यों

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


आइए बहुत शुरुआत से शुरू करें - दो स्तंभों से जहां यह कुख्यात "एंड-टू-एंड बिजनेस टेस्टिंग" आया, अर्थात् परीक्षण पिरामिड और ISO9000 मानक से।

परीक्षण पिरामिड

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



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



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



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



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



एकमात्र सवाल यह है कि यह कैसे किया जाए? यह किसे करना चाहिए? कैसे एक साथ रखा जाए?

ISO9000

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

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

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

सभी प्रक्रियाओं में है:
• इनपुट्स;
• आउटपुट;
• परिचालन नियंत्रण;
• उपयुक्त माप और निगरानी।
प्रत्येक प्रक्रिया में समर्थन प्रक्रियाएँ होंगी जो अंडरपिन करेंगी और प्रक्रिया को साकार होने में सक्षम बनाएगी

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



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

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

क्या अभ्यास में

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

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



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





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


एक गिलहरी कितने तरीकों से टकरा सकती है?

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



और, अफसोस, अकेले परीक्षण पर्याप्त नहीं है। मेरे अभ्यास से, लगभग सभी साधनों में कुछ घातक दोष होते हैं, और इसलिए, यदि आप किसी व्यवसाय प्रक्रिया में परीक्षण स्वचालन के चरण में आते हैं, तो आप एक ऐसी स्क्रिप्ट के निर्माण के लिए आएंगे जो सही क्रम में परीक्षण खींच लेगा।



परिणामस्वरूप, दो निष्कर्ष किए जा सकते हैं:

1) एंड-टू-एंड परिदृश्यों के लिए, यह बहुत संभावना है कि पहले विकसित परीक्षण व्यवसाय प्रक्रिया श्रृंखला (परिदृश्य) में शामिल प्रत्येक सिस्टम के लिए उपयोग किए जाते हैं



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

2) परीक्षण मॉडल के साथ सिंक्रनाइज़ेशन के लिए व्यावसायिक प्रक्रिया की निगरानी, ​​ट्रेस और अपडेट करने के लिए एक उपकरण की आवश्यकता होती है।



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

निष्कर्ष में

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



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

आपकी कंपनी को इस तरह के आदर्श फिनिशिंग रन की जरूरत है या नहीं, यह केवल आपके लक्ष्यों और जरूरतों के लिए एक मामला है। हमेशा, किसी भी परीक्षण के साथ, आपको इस स्तर पर लापता दोषों से संभावित जोखिमों का मूल्यांकन करना चाहिए, साथ ही अंत-टू-एंड परीक्षण की तैयारी और आचरण की लागत भी। मूल्यांकन करने के लिए कि आपको इससे अधिक क्या खर्च करना होगा और उसके बाद ही कार्य करना होगा। लेकिन व्यावसायिक प्रक्रियाओं पर एंड-टू-एंड परीक्षण के मामले में, यह याद रखना चाहिए कि यह 100% पास्रेट यूनिट परीक्षणों (~ 90-100% कवरेज) के रूप में एक ठोस आधार के बिना कोई मतलब नहीं है, एकीकरण परीक्षणों के बिना (~ 60-80%) कवरेज, 90- 100% उत्तीर्ण), बिना सिस्टम परीक्षण (20-40% कवरेज, 80-100% उत्तीर्ण)। सफलता के लिए मानदंड स्थापित करना (गुणवत्ता द्वार) उत्पाद की गुणवत्ता के लिए एक आवश्यकता से अधिक है, यहां याद रखने वाली मुख्य बात यह है कि ई 2 ई परीक्षणों की मात्रा पिरामिड के ऊपर सिर्फ (1-2% कवरेज, ~ 99% पास) है, जो इसके आधार से बड़ा नहीं होना चाहिए, नहीं एक ही समय में पिछले चरणों से छेद का एक प्लग हो। यह एक पूरक है जिसे एक प्राथमिकता को पिछले चरणों में बंद माना जाता है।

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

PS वर्णित उपकरण, साथ ही साथ प्रथाओं - विशुद्ध रूप से उदाहरण के लिए, लेखक ने खुद को विज्ञापन उत्पादों का लक्ष्य निर्धारित नहीं किया और इस दृष्टिकोण को केवल सही तरीके से परीक्षण करने के लिए अंत तक घोषित किया।