1 पॉइंट द्वारा kyo3553 7 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

नमस्ते। मैं QAMap बना रहा हूँ, एक local CLI जो PR के बदलाव के context को पढ़कर ज़रूरी QA डिज़ाइन करता है.

प्रोडक्ट टीम में मुझे जो bottleneck महसूस हुआ, वह test code लिखने से ज़्यादा यह था कि हर PR पर फिर से तय करना पड़ता था: “इस बदलाव से वास्तव में क्या साबित होना चाहिए?” शुरुआत में मैंने diff और project structure का विश्लेषण करके Playwright·Maestro और E2E drafts सुझाए, लेकिन व्यवहार में वे अक्सर उन बातों तक सीमित रह गए जो developer पहले से जानते थे, या सिर्फ़ साधारण success screen tests तक.

इसलिए मैंने लक्ष्य बदल दिया। हर domain को पूरी तरह समझने की कोशिश करने के बजाय, commit और diff के आधार पर बदलाव के इरादे और functional flow को व्यवस्थित करता हूँ, और normal·failure·boundary·state transition में से वे QA सुझाता हूँ जो छूटे होने की संभावना सबसे ज़्यादा होती है. जिन निर्णयों पर पूरा भरोसा करना मुश्किल होता है, उनके साथ reasoning और confidence भी दिखाता हूँ.

अंततः लक्ष्य एक ऐसा local QA tool बनाना है जो PR रजिस्टर होते ही प्रभावित features को ढूँढे, ज़रूरी E2E और mock·fixture को तैयार करे, उन्हें सुरक्षित रूप से चलाए, और validation evidence भी छोड़े. अभी यह v0.4.0 पर है, और मैं इसे उस लक्ष्य के करीब लाने के लिए असली repositories में होने वाली गलतियों को एक-एक करके verify करते हुए अपडेट कर रहा हूँ.

यह अभी शुरुआती चरण में है, इसलिए यह गलत interpretation कर सकता है या महत्वपूर्ण scenarios छूट सकते हैं. इस समय मुझे सबसे ज़्यादा ज़रूरत वास्तविक failure cases की है. अगर QAMap अजीब निष्कर्ष निकालता है या ऐसे tests सुझाता है जिन्हें इस्तेमाल नहीं किया जा सकता, तो बेझिझक बताइए.

1 टिप्पणियां

 
jeongjin0 1 시간 전

लोकल में diff-आधारित तरीके से boundary/state transition तक सुझाव देने वाली दिशा अच्छी लगती है। अगर हर scenario के लिए यह और साफ़ दिखे कि आधार किस diff hunk या file से लिया गया है, तो review करते समय false positive को छाँटना आसान होगा।