एक अच्छा क्यूए कौन है?

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

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

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

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

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

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

परीक्षण और अधिक

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

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

आप पहले से ही समझते हैं कि इतिहास का अंत नहीं है।

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

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

कोई कट्टरता नहीं

हम आगे भी, बहुत विडंबना से, परीक्षण प्रक्रिया ही एक दाढ़ी वाले किस्से की विशेषता है:

एक बार परीक्षक बार में प्रवेश करता है।
बार में चलता है।
बार में ढोंगी।
नृत्य, बार में प्रवेश करता है।
एक बार में चुपके।
बार में टूट जाता है।
बार में कूदता है।

आदेश:
बियर का एक मग
2 गिलास बीयर
0 ग्लास बीयर
999999999 मग बियर,
एक गिलास में छिपकली
-1 कप बीयर
क्वर्टी बीयर मग।

पहला वास्तविक ग्राहक बार में आता है और पूछता है कि शौचालय कहाँ है। बार आग की लपटों में घिर जाता है, हर कोई मर जाता है।

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

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

वैसे, कुछ उपयोगकर्ता इसे स्वीकृति परीक्षण पर करते हैं, बग को महत्वपूर्ण घोषित करते हैं और काम छोड़ देते हैं। यह काम को बहुत जटिल बनाता है, क्योंकि समस्याओं की सामान्य धारा में, जो सामान्य रूप से समस्या नहीं हो सकती है, वास्तव में महत्वपूर्ण कीड़े खो जाते हैं।

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

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

मेरी जुबान मेरी दुश्मन है

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

यह सब क्या होता है? यहां जवाब और हेजहोग समझने योग्य है, लेकिन उदाहरणों के साथ, निश्चित रूप से, अधिक दिलचस्प है।

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

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

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

व्यक्तिगत स्थान

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

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

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

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

संगठनात्मक क्षण

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

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

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

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

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

निष्कर्ष

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

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