उत्पाद रिलीज में तेजी लाने और स्थिर करने के लिए परीक्षण का आयोजन कैसे करें। भाग 2

कार्यों और दोषों के निर्माण और स्वीकृति का प्रारूप

• ऐसा मामला जहां आप त्रुटि को पुन: उत्पन्न कर सकते हैं;
• वास्तविक और अपेक्षित परिणाम;
• डेवलपर्स को ठीक करने के लिए स्पष्ट निर्देशों के साथ बैकएंड और फ्रंटेंड के लिए उपशीर्षक। "बैकएंड: इस एपीआई के लिए, फ्रंटेंड को संबंधित उत्तर दें" + विकल्पों में से एक मैट्रिक्स दिखा रहा है कि प्रत्येक संभावित स्थितियों में क्या उत्तर होना चाहिए। "फ्रंटेंड: इस एपीआई के लिए, पीछे से प्रतिक्रिया के आधार पर, संबंधित त्रुटि पाठ जारी करें" + मैट्रिक्स ऑफ ऑप्शंस।

1. एक कार्यात्मक समस्या का वर्णन, त्रुटि को पुन: पेश करने के लिए एक मामला और इतिहास के लिंक के साथ एक कार्य बनाएं, जिसके सत्यापन के दौरान एक दोष पाया गया था।
2. . : , , API , use case . , , API, , , , , , .

परीक्षण के क्षण

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

बैकएंड की बातचीत के नियम - परीक्षण - फ्रंटेंड कनेक्शन

दोषपूर्ण मरम्मत में तेजी लाएं

परिणाम

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

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