Google सॉफ्टवेयर का परीक्षण कैसे करता है

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

* इसके अलावा, प्रस्तुति में आसानी के लिए, कथन पहले व्यक्ति में आयोजित किया जाएगा, जैसे कि मैं जेम्स था।

दर्शन

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

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

उत्पादकता

जैसा कि आप समझते हैं, हमारी भूमिका Google को गति देने की है, न कि हर चीज और हर चीज के अनिवार्य परीक्षण में। इंजीनियरों की उत्पादकता बढ़ाने के लिए, हमारे पास विशेष उपकरण हैं। एक सामान्य टूलकिट (आईडीई, कंपाइलर, असेंबली सिस्टम, परीक्षण) है और व्यक्तिगत उत्पादों के लिए विशिष्ट है। हम उत्पाद रिलीज, ट्रेन इंजीनियरों और पाठ्यक्रम परीक्षण पर एक साथ काम करते हैं। परीक्षकों के लिए हमारी तीन भूमिकाएँ हैं: SWE, SET, TE।

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

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

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

रणनीति

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

परीक्षण

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

छोटे परीक्षण:

• लगभग हमेशा स्वचालित
• एक छद्म वातावरण में चल रहा है (नकली / मिटे हुए वातावरण)
• एक फ़ंक्शन या एक मॉड्यूल की जांच करें
• डेटा सत्यापन और अपवाद जाँच पर ध्यान दें
• मिलीसेकंड में चलाएं
• ज्यादातर SWE लिखे

औसत परीक्षण:

• आमतौर पर स्वचालित
• एक छद्म वातावरण में चलाएँ
• कार्यों के बीच बातचीत की जाँच करें
• डेटा इंटरऑपरेबिलिटी के कार्यात्मक मुद्दों पर ध्यान दें
• सेकंड में चलाएं
• SET और SWE लिखे हैं

महान परीक्षण:

• वे या तो स्वचालित या मैनुअल हो सकते हैं।
• वास्तविक परिवेश में प्रदर्शन किया
• अंतिम कार्यक्षमता की जाँच की जाती है।
• घंटों तक किया जा सकता है
• लेखन TE ​​और SET द्वारा किया जाता है

परीक्षणों के बारे में कुछ और शब्द

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

हम कोड पठनीयता का भी परीक्षण करते हैं। हमारी विकास प्रक्रिया के भीतर पठनीयता के लिए c ++, फाइटन, जावा और जावा स्क्रिप्ट में प्रत्येक पंक्ति की जाँच की जाती है।

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

एसीसी - 10 मिनट टेस्ट प्लान

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

• सूचियों के पक्ष में गद्य छोड़ दें
• बिक्री से परेशान न हों
• पानी मत डालो, यह एक निबंध नहीं है
• यदि यह प्रजनन योग्य नहीं है, तो भूल जाओ
• एक प्रवाह बनाएं, एक को दूसरे में प्रवाहित करें
• परीक्षक की मानसिकता को समझें
• आउटपुट का परीक्षण होना चाहिए

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

BITE रिकॉर्ड और प्लेबैक

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

BITE बग फाइलिंग

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

गुणवत्ता के बर्तन

और अंत में, मैं एक और उपयोगिता के बारे में बात करूंगा जिसका उपयोग हम क्रोम ब्राउज़र का परीक्षण करने के लिए करते हैं। जब हमने पहली बार क्रोमियम का परीक्षण शुरू किया, तो हमने बहुत सारे मैनुअल चेक किए। वास्तव में, वे मेरे लिए निरर्थक थे। हमारे लिए यह महत्वपूर्ण था कि हम "इंटरनेट को न तोड़ें"। यह हमारे लिए महत्वपूर्ण था कि क्रोम लोकप्रिय साइटों को सही ढंग से प्रदर्शित करता रहे। हम एक ऐसा ब्राउज़र जारी नहीं करना चाहते थे जो cnn, facebook या अन्य लोकप्रिय सेवाओं को प्रस्तुत नहीं करेगा। बेशक, सैकड़ों लोकप्रिय साइटों को डाउनलोड करने और यह पता लगाने में आसान है कि क्या वे एक ब्राउज़र क्रैश का कारण हैं। सच है, यह वह नहीं है जो हमें चाहिए। वास्तव में, हम 10 हजार सबसे लोकप्रिय साइटों की जांच करना चाहते हैं और यह देखना चाहते हैं कि वे हमारे ब्राउज़र के पुराने संस्करण में कैसे दिखते हैं और अब वे फ़ायरफ़ॉक्स, सफारी और IE में कैसे दिखते हैं। हमारे द्वारा किए गए एप्लिकेशन को क्वालिटी बॉट्स कहा जाता है, जिसके बारे में हमने अपने ब्लॉग में भी बात की है। आवेदन दो काम करता है। DOM की तुलना करता है और पेज पर सभी नियंत्रणों के स्थान की जांच करता है। बेशक, हर दिन विज्ञापन देने वाली साइटें अलग दिखेंगी। हमारे लिए यह महत्वपूर्ण है कि वे लगभग समान हों। यदि ऐसा है, तो हम परीक्षण के पारित होने पर विचार करते हैं।

उपसंहार

जो लोग विवरण में रुचि रखते हैं, वे जेम्स के ट्विटर का अनुसरण कर सकते हैं, अपने प्लसस को गोल कर सकते हैं या एक ब्लॉग पढ़ सकते हैं जहां इस विषय पर लेख नियमित रूप से दिखाई देते हैं।