👆🏻 🧓🏾 🚌 हम अपडेट का परीक्षण क्यों और कैसे कर रहे हैं 🙏🏾 👨🏿‍🤝‍👨🏼 🚅

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

आमतौर पर उपयोगकर्ता किस बात से नाखुश होते हैं?

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

ये सभी समस्याएं मोबाइल एप्लिकेशन और DLP सिस्टम के लिए प्रासंगिक हैं जो हम घर पर परीक्षण कर रहे हैं। इसके अलावा हम किसके साथ काम कर रहे हैं।

हम क्या जारी करते हैं और क्या अद्यतन करने की आवश्यकता है

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

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

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

ये सभी स्थितियां हमारे उत्पाद के कॉन्फ़िगरेशन का पर्याप्त बड़ा सेट देती हैं, जिनमें से प्रत्येक के लिए हमें एक सफल अपडेट की गारंटी देनी चाहिए। इसके माध्यम से एक अद्यतन है, जिसके परिणामस्वरूप:

उपयोगकर्ता डेटा खो नहीं है
पुरानी सुविधाएँ नहीं टूटीं
उपयोग के लिए नई सुविधाएँ उपलब्ध हैं

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

जब संस्करण 3 जारी होता है, तो हमारी अपडेट तालिका के साथ उदाहरण पर विचार करें। संस्करण 1.0.0 के लिए, दो पैच और तीन हॉटफ़िक्स जारी किए गए थे, और संस्करण 2.0.0 के लिए दो हॉटफ़िक्स थे।

1.0.0	2.0.0	3.0.0
1.0.1	2.0.1
1.0.2	2.0.2
1.1.0
1.1.1
1.2.0

कुल मिलाकर, उदाहरण में हमारे पास नौ संस्करण हैं, जिनसे हमें नए संस्करण 3.0.0 में अपग्रेड करना होगा। हमारे उत्पाद के प्रत्येक संस्करण के लिए दो OS और दो डेटाबेस हैं। उन। कुल 27 अद्यतन कॉन्फ़िगरेशन जारी किए गए हैं। और अगर हम अलग-अलग इंस्टॉलेशन विधियों को भी लेते हैं, तो यह संख्या दो से सुरक्षित रूप से गुणा की जा सकती है, परिणामस्वरूप हमें 54 प्राप्त

होते हैं। हमारी प्रत्येक रिलीज में कई गंभीर (उत्पाद प्रभाव के संदर्भ में) विशेषताएं शामिल हैं। सिस्टम को समायोजित करने के तरीके बदल सकते हैं, विश्लेषण प्रणालियों को परिष्कृत किया जाता है, घटनाओं को नए डेटा के साथ पूरक किया जाता है, पर्यावरण परिवर्तन का संस्करण, उदाहरण के लिए, ओएस या डेटाबेस का संस्करण, आदि।

ऐतिहासिक रूप से ...

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

अच्छे उत्पाद ज्ञान के बिना शोध परीक्षण की योजना बनाना एक धन्यवाद का काम है, यह इस तरह के परिणामों से भरा था:

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

मुख्य रूप से परीक्षक के विवेक पर प्रारंभिक तैयारी भी की गई थी, जिसे कार्य मिला और कभी-कभी संस्करण में सभी परिवर्तनों को ध्यान में रखे बिना।

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

नतीजतन, अद्यतन परीक्षण रिपोर्ट से स्पष्ट रूप से समझना असंभव था कि कौन से मूल्यों पर जांच की गई थी, आदि।

फिर भी, कुछ समय के लिए हम अनुसंधान परीक्षण के परिणामों से संतुष्ट थे: उन्नयन के लिए इतने सारे सैन्य दोष नहीं थे, और सैद्धांतिक लाभ के लिए परिवर्तनों के लिए कोई संसाधन नहीं थे।

कुछ गलत हो गया

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

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

;
, ;
, , , , ;
, ;
;
. ? ? ? ?

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

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

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

नए दृष्टिकोण में, हम सिस्टम ऑब्जेक्ट्स पर चेक के संयोजन का उपयोग करते हैं (अपडेट के दौरान अपरिवर्तित और बदलते हुए) + फंक्शनल के स्मोक-चेक (पुराने और नए दोनों या पुराने बदल गए)।

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

चेकों का यह संयोजन हमें निम्नलिखित सिस्टम घटकों का परीक्षण करने का अवसर देगा:

डीबी
वेब (फ्रंटएंड, बैकएंड);
लिनक्स घटक

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

परीक्षण अद्यतन प्रतिगमन में बदल जाता है। कार्यात्मक परीक्षण किया जाता है, न कि सिस्टम ऑब्जेक्ट और उन पर संचालन। हम कार्यात्मक + डेटा सत्यापन के धूम्रपान-परीक्षणों के रूप में परीक्षण मामलों पर अद्यतन का परीक्षण करेंगे।

असंगत रिपोर्टिंग। कवरेज और परिणाम परीक्षण मामलों से लिए जा सकते हैं।

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

नई प्रक्रिया

परिणामस्वरूप, हमने एक प्रभावी प्रक्रिया का निर्माण किया।

हमने परीक्षण को कई चरणों में विभाजित किया है, जिसने और भी अधिक अनियोजित बोनस दिए हैं, जो नीचे वर्णित हैं:

प्रशिक्षण।
- हम सिस्टम में परिवर्तन का विश्लेषण करते हैं, बदलते क्षेत्रों के लिए विश्लेषकों और डेवलपर्स के साथ संयुक्त रूप से तैयार किया गया है।
- विश्लेषण के परिणामों के अनुसार, हम परीक्षण अद्यतनों के लिए तैयार किए गए सिस्टम ऑब्जेक्ट्स की एक सूची संकलित करते हैं।
- प्रत्येक सिस्टम ऑब्जेक्ट के लिए, राज्यों, स्थितियों और मापदंडों का आवश्यक सेट निर्धारित किया जाता है।
- हम उत्पाद के आवश्यक (अपडेटेड) संस्करण के साथ स्टैंड बनाते हैं।
- , .
- ( ).
- smoke- , .
:
- ;
- (, , , );
- , .
- .
- -, .
- .
- , .
- वस्तुओं पर संचालन की जाँच (निर्माण, संपादन, विलोपन)।
- अन्य वस्तुओं के साथ वस्तुओं की बातचीत की जाँच करना (पता लगाना)।

दृष्टिकोण के पेशेवरों और विपक्ष

हमने अपना लक्ष्य प्राप्त कर लिया है, जिसका नाम है:

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

लेकिन एक नई परीक्षण रणनीति के आसपास, हम नए दृष्टिकोण के स्पष्ट शून्य का सामना करने में विफल नहीं हो सके - परीक्षण समय में उल्लेखनीय वृद्धि।

हमने न केवल प्रत्यक्ष परीक्षण पर समय बिताना शुरू किया, जैसा कि शोध परीक्षण के मामले में था। नए समय की लागत मुख्य रूप से परीक्षण की तैयारी के साथ जुड़ी हुई थी, अर्थात्:

विश्लेषण बदलें;
अद्यतन करने के लिए खड़ा होना, भरना, रखरखाव करना;
पुराने टेस्ट किट को अपडेट करना और नए बनाना।

यह शून्य अच्छी तरह से एक "लेकिन" के लिए नहीं, तो नई पद्धति को छोड़ने का निर्णय लेने के लिए निर्णायक बन सकता है।

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

कुल मिलाकर, सुधार के पहले चरण के परिणामों के अनुसार, हमें निम्नलिखित प्राप्त हुए: हमने अधिक समय परीक्षण करना शुरू किया, लेकिन साथ ही साथ हमारे पास एक पारदर्शी प्रक्रिया, परिणामों का स्पष्ट प्रदर्शन और अधिक कवरेज है, जो हमें इसकी अनुमति देता है:

अपने विभाग में उत्पाद अपडेट की जाँच के परिणामस्वरूप अधिक दोषों का पता लगाएं;
कार्यान्वयन इंजीनियरों द्वारा हमारे ग्राहकों को अपडेट करते समय दोषों की संख्या को कम करना;
तकनीकी सहायता से प्राप्त दोषों की संख्या को कम करना।

आगे क्या होगा? - अनुकूलन के बारे में

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

हम दो तरह से गए:

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

मैं प्रत्येक पथ के बारे में कुछ और बात करूंगा।

पहला तरीका: टेस्ट रन के विश्लेषण के आधार पर अनुकूलन।

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

पहली चीज जिस पर हमने ध्यान दिया, वह परीक्षण थे जो डेटाबेस पर और केवल डेटाबेस पर निर्भर थे। हम यह समझने में सक्षम थे कि प्रत्येक बेस पर एक बार क्या चेक किया जाना पर्याप्त है, और फिर उन्हें पूरी तरह से ओएस के साथ हमारे कॉम्बिनेटरिक्स से बाहर करने के लिए।

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

इसके अलावा, पैच और हॉटफ़िक्स जारी करते समय एक ही चेकलिस्ट हमारे लिए बहुत उपयोगी थी, जहां प्रमुख संस्करणों के बीच अपडेट के अलावा, संस्करण के भीतर अपडेट की जांच करना भी महत्वपूर्ण है।

दूसरा तरीका: परीक्षण स्वचालन

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

इस स्तर पर, पैच और हॉटफ़िक्स जारी करते समय अपडेट अपडेट करना लगभग पूरी तरह से स्वचालित है।

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

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

सारांश

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

मुझे नहीं लगता है कि इस स्थिति में हमने एक साइकिल का आविष्कार किया जब हमने अपनी परियोजना और विशेष रूप से हमारे उत्पाद की विशेषताओं के अनुरूप अपनी प्रक्रिया बनाने का मार्ग अपनाया। यदि हम प्रक्रिया को उसके घटक भागों में इकट्ठा करते हैं, तो हम सामान्य रूप से स्वीकृत और व्यापक रूप से उपयोग की जाने वाली तकनीकों को प्राप्त करते हैं।

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

हमने ईमानदारी से यहां सभी पेशेवरों और विपक्षों के साथ-साथ हमारे फैसलों के नुकसान का वर्णन करने की कोशिश की, ताकि कथा विशेष रूप से एक सफलता की कहानी की तरह न लगे "यह बुरा था - यह अच्छा हो गया"।

हमें उम्मीद है कि आप हमारे अनुभव को उपयोगी पाएंगे।

सामग्री लेखक:tryzhova (रियाज़ोवा तात्याना)।

हम अपडेट का परीक्षण क्यों और कैसे कर रहे हैं