सिंथेटिक बनाम वास्तविक परीक्षण डेटा: पेशेवरों, विपक्ष, नुकसान

आइए मिठाई के साथ शुरू करें और परीक्षण अभ्यास से उदाहरण दें।

लॉन्च के लिए तैयार एक ऑनलाइन स्टोर की कल्पना करें। कुछ भी नहीं मुसीबत। विपणक ने एक प्रचार रणनीति विकसित की, लेख विशेष इंटरनेट संसाधनों में लिखे गए, और विज्ञापन का भुगतान किया गया। साप्ताहिक रूप से 300 खरीद तक ​​प्रबंधन की उम्मीद है। पहला सप्ताह बीत जाता है, प्रबंधक 53 भुगतान रिकॉर्ड करते हैं। स्टोर प्रबंधन गुस्से में है ...

प्रोजेक्ट मैनेजर कारणों की तलाश में चलता है: प्रयोज्य की कमी? अनुचित यातायात? कुछ और? हमने डेटा एनालिटिक्स सिस्टम को समझना, अध्ययन करना शुरू किया। यह पता चला कि 247 लोग चेकआउट में पहुंचे, और केवल 53 ने भुगतान किया।


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


तो मेल @ mail.ru, @ ya.ru (और इसी तरह के) के खुश मालिक अपने मेल में प्रवेश नहीं कर सके और खरीदारी के बिना साइट छोड़ दिया। मालिकों को 600 हजार से कम रूबल मिले, पूरे विज्ञापन बजट को शून्य में सूखा दिया गया, और ऑनलाइन स्टोर को स्वयं नकारात्मक समीक्षाओं का एक समूह मिला।

क्या आपको लगता है कि यह एक अलग मामला है? फिर यहां ग्राहक के लिए एक और डरावनी कहानी है।

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


पायलट प्रोजेक्ट शहर के 3 कार्यालयों में लागू किया गया था। तीन कार्यालयों में मासिक ऋणों की औसत संख्या 340 थी। परिणाम: संगठन कम से कम 612 हजार रूबल से हार गया। राजस्व।

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

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

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

हम शब्दों में समझेंगे

हर बार जब हम एक परीक्षण लेते हैं, तो हम तय करते हैं कि हम किस परीक्षण डेटा का उपयोग करेंगे। उनके स्रोत हो सकते हैं:

1. परीक्षण बेंच पर उत्पादन डेटाबेस की प्रतियां।
2. तृतीय-पक्ष क्लाइंट सिस्टम का डेटाबेस जो वर्तमान में उपयोग किया जा सकता है।
3. डेटा जनरेटर का परीक्षण करें।
4. परीक्षण डेटा का मैनुअल निर्माण।

पहले 2 स्रोत हमें वास्तविक परीक्षण डेटा प्रदान करते हैं। वे उपयोगकर्ताओं या सिस्टम द्वारा मौजूदा प्रक्रियाओं द्वारा बनाए जाते हैं।


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

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


उदाहरण के लिए, हमें 44 संघीय कानूनों के तहत राज्य और नगरपालिका संगठनों द्वारा खरीद के लिए एक नए इलेक्ट्रॉनिक ट्रेडिंग प्लेटफॉर्म से एक आदेश मिला। यहां, बहुत सख्त सूचना सुरक्षा नियमों का पालन किया जाता है, इसलिए टीम के पास वास्तविक डेटा तक पहुंच नहीं है। परीक्षण के लिए एकमात्र तरीका खरोंच से परीक्षण डेटा का एक पूरा सेट बनाना है। यहां तक ​​कि भौतिक डिजिटल हस्ताक्षर जो केवल परीक्षण के लिए अभिप्रेत हैं।

हमारे व्यवहार में, एक प्रकार का डेटा शायद ही कभी उपयोग किया जाता है, आमतौर पर हम कार्य के आधार पर उनमें से एक संयोजन के साथ काम करते हैं।

विनिर्माण कंपनी के लिए एक ही प्रणाली में सीमाओं और अपवादों की जांच करने के लिए, हमने इसके अतिरिक्त सिंथेटिक डेटा का उपयोग किया। उनकी मदद से, हमने जांच की कि आदेश में से कोई भी उत्पाद नहीं होने पर रिपोर्ट कैसे व्यवहार करती है। एक इलेक्ट्रॉनिक ट्रेडिंग प्लेटफॉर्म पर, हमने सिंथेटिक डेटा को वास्तविक संदर्भ पुस्तकों OKPD2 और OKVED2 के साथ जोड़ा।

सिंथेटिक डेटा क्षमताएं

कुछ स्थितियों में, सिंथेटिक डेटा को आसानी से नहीं छोड़ा जा सकता है! आइए देखें कि वे परीक्षक के शस्त्रागार से किन कार्यों का उपयोग कर सकते हैं:

1. सरलीकरण और मानकीकरण

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

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

लाभ: 6 घंटे 30 मिनट और यह केवल एक परीक्षण पर है।

2. संयोजक और परीक्षण कवरेज

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

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

3. स्वचालन

स्वचालित परीक्षण में, सिंथेटिक डेटा अपरिहार्य है। यहां तक ​​कि डेटा में उल्लेखनीय परिवर्तन से परीक्षण रन के पूरे सेट के संचालन को प्रभावित किया जा सकता है।

बैंकिंग क्षेत्र का एक उदाहरण यहाँ स्पष्ट होगा। यह जांचने के लिए कि क्या एप्लिकेशन उसके द्वारा बनाए गए दस्तावेज़ों में बैंक खाता संख्याओं को सही ढंग से रखता है, हमने 120 व्यक्ति / घंटे ऑटोटैस्ट लिखने में बिताए। डेटाबेस तक कोई पहुंच नहीं थी, क्योंकि खाता संख्या ऑटोटेस्ट में ही इंगित की गई थी। परीक्षणों ने उत्कृष्ट परिणाम दिखाए और हम रिपोर्ट में स्वचालन से 180% + आरओआई तैयार करने के लिए तैयार थे। लेकिन एक सप्ताह बाद डेटाबेस को खाता संख्या में बदलाव के साथ अपडेट किया गया। सभी ऑटोटेस्ट्स, साथ ही साथ हमारे स्वचालन प्रयास सुरक्षित रूप से समाप्त हो गए। ऑटोटेस्ट्स को संशोधित करने के बाद, अंतिम आरओआई 106% तक गिर गया। उसी सफलता के साथ, हम तुरंत अपने हाथों से परीक्षण शुरू कर सकते हैं।

4. प्रबंध क्षमता में सुधार

सिंथेटिक डेटा का उपयोग करना, हम जानते हैं (सबसे खराब स्थिति में, हम मानते हैं) सिस्टम से किस तरह की प्रतिक्रिया की उम्मीद है। यदि कार्यक्षमता में परिवर्तन किए जाते हैं, तो हम समझते हैं कि उसी डेटा की प्रतिक्रिया कैसे बदलेगी। या हम वांछित परिणाम प्राप्त करने के लिए डेटा को समायोजित कर सकते हैं।

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

तो नुकसान क्या हैं?

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

वास्तविक डेटा के साथ काम करने के लाभ

वास्तविक डेटा के साथ काम करने में हमें क्या फायदे मिलते हैं? हमारे अनुभव से 4 सबूत:

1. बड़ी मात्रा में जानकारी के साथ काम करें

सिस्टम का वास्तविक संचालन हमें लाखों ऑपरेशन प्रदान करता है। हजारों उपयोगकर्ताओं या स्वचालित डेटा उत्पादन के एक साथ काम को दोहराएं विशेषज्ञों की किसी भी टीम में सक्षम नहीं होंगे।

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

2. विभिन्न डेटा स्वरूपों का उपयोग करना

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

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

3. उपयोगकर्ता के व्यवहार की अप्रत्याशितता

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

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

4. सिस्टम अपडेट

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

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

वे सुबह 18-00 बजे, 11 बजे तय किए गए। संस्करणों के साथ पूरा न होने और अपूर्णता के कारण, कंपनी के डिवीजनों का काम 2 घंटे के लिए पूरी तरह से जमे हुए था। प्रबंधक वर्तमान अनुबंधों की प्रक्रिया नहीं कर सकते थे और नए पंजीकरण नहीं कर सकते थे।

तब से, हम बिना किसी असफलता के तीन स्टैंडों के साथ काम कर रहे हैं:

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

तो क्या डेटा और कब काम करना है?

हम वास्तविक और सिंथेटिक डेटा के साथ अपने काम की 3 अंतर्दृष्टि साझा करते हैं:

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

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

3. ठोस सिंथेटिक्स के पक्ष में न जाएं, लेकिन वास्तविक डेटा पर ध्यान केंद्रित न करें। त्रुटियों को याद न करने, समय बचाने और अपने काम में अधिकतम परिणाम दिखाने के लिए डेटा का परीक्षण करने के लिए एक संयुक्त दृष्टिकोण का उपयोग करें।

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

आइए चर्चा करते हैं। हमें सिंथेटिक और वास्तविक परीक्षण डेटा के साथ काम करने के अपने मामलों के बारे में टिप्पणियों में बताएं। आइए देखें कि हमारे बीच कौन अधिक है: यथार्थवादी या सिंथेटिक्स? ;)

विक्टोरिया सोकोविकोवा।
गुणवत्ता प्रयोगशाला में परीक्षण विश्लेषक