पुस्तक "Google पर परीक्षण कैसे करें" - मुफ्त इलेक्ट्रॉनिक संस्करण

छविहैलो, हब्रोज़िटेली!

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

पुस्तक सॉफ्टवेयर विकास उद्योग के पेशेवरों के लिए अभिप्रेत है: परीक्षण विशेषज्ञ, प्रोग्रामर, प्रबंधक।

अंश। जोखिम में कटौती


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

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

  • , , .
  • -, , .
  • , .
  • .
  • , . , .

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

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

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

दस मिनट में जेम्स व्हिटकेकर प्रिस्क्रिप्शन टेस्ट प्लान


, , . , , — ? , , . Google, , -. , , : «», « » — « » ( ). ’, , - , .

— . -, , — , , ( ), , , . : , ,
?

- , , , . , — . : ?

- , - . . : -.

, : - . - , .

, . : . , , .
-, .

. : « , - ». , , . , , , , .

, , , (Google Docs, App Engine, Talk Video . .), .

, ACC-. , . — , — . , . - — . , , .

’, - . . ,
- .

, . , . 80% . ? , , ? , (, , ) . , , .

. -!


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

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

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

जोखिम वाले सभी क्षेत्रों को जानना परीक्षक की जिम्मेदारी है। उसे किसी भी तरह से जोखिम को कम करने की कोशिश करनी चाहिए जो उसके अधीन है। यहां कुछ सिफारिशें दी गई हैं जो हमें जोखिमों से निपटने में उपयोगी लगती हैं।

  1. लाल रंग में चिह्नित सबसे जोखिम भरी विशेषताओं और विशेषता / घटक जोड़े के लिए, उपयोगकर्ता कहानियों, उपयोग परिदृश्यों या एक परीक्षण गाइड का एक सेट लिखें। Google में, सबसे अधिक जोखिम भरे अवसरों की जिम्मेदारी परीक्षक के पास होती है। वह सहयोगियों के साथ अपने काम का समन्वय कर सकता है, विभिन्न उपकरणों का उपयोग कर सकता है, लेकिन व्यक्तिगत जिम्मेदारी अभी भी उस पर है।
  2. , . , GTA? ? ? . , , .
  3. , / , , . .
  4. — . , . , . , : «!», . , .
  5. , . , , . , « ?» « ?». Google , , .
  6. 6 , , , . ! .




, . , , , .

, , - . - , , , . , , . , , .

, , . -, - — !

— . - . — . Google , . -: Google Documents — , .

, , , . — .

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

क्राउडसोर्सिंग




— . , , - ! , . . ?

, , . , , — , , -. , Chromium, . , , . , .

( ) — . , , . , , ? — .

, , , . , : -1000 , : Chrome, : 1 = 1000 20 = 50 . .

, , , . , , . Chrome, , , ( « Chrome»). . , . « , » , .

- — Google: , , . , . , , , (, uTest). .

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

टेस्टर का काम, टेस्टिंग में डेवलपर के काम के विपरीत, उत्पाद के इनलेट के साथ समाप्त नहीं होता है।

» डाउनलोड epub और पीडीएफ

All Articles