यह संकेत कि QA टीम को भंग करना शायद एक गलत फैसला था

 (davidkcaudill.medium.com)
5 पॉइंट द्वारा GN⁺ 2023-12-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें

QA टीम को हटाना वास्तव में एक खराब फैसला रहा हो सकता है

  • सॉफ़्टवेयर डिप्लॉयमेंट का सबसे धीमा हिस्सा testing है। Continuous deployment के अस्तित्व का कारण ही testing है, इसलिए इसका bottleneck होना एक optimized स्थिति माना जाता है।
  • Optimization की आदतें और व्यवहार ने उद्योग में QA टीम को bottleneck मानकर उसे हटाने की प्रवृत्ति को बढ़ावा दिया। इसके कारण QA भूमिका के प्रति सम्मान घटा और अच्छी गुणवत्ता का सॉफ़्टवेयर तैयार न कर पाने की समस्या पैदा हुई।
  • Developers सॉफ़्टवेयर quality management को ठीक से नहीं समझते। कई organizations को यह तक स्पष्ट नहीं है कि सॉफ़्टवेयर quality की ज़िम्मेदारी किसकी है, और जहाँ QA function बचा हुआ है वहाँ भी उसके लिए सही जगह तय करने में कठिनाई होती है।

सॉफ़्टवेयर प्रैक्टिस में quality को मैनेज करने के लिए क्या करना चाहिए

  • Defect tracking: ऐसा तरीका होना चाहिए जिससे users bugs की जानकारी दे सकें और developers bugs को रिकॉर्ड कर सकें।
  • Triage: Bug triage वह प्रक्रिया है जिसमें bugs का assignment, prioritization, cleanup, classification और deduplication मैनेज किया जाता है।
  • Defect investigation: Bug को reproduce करना bug management का महत्वपूर्ण हिस्सा है, और वास्तविक समस्या को समझने व हल करने के लिए engineering effort की आवश्यकता होती है।
  • Focus: कंपनी में ऐसे लोग होने चाहिए जो quality पर केंद्रित हों, और quality तथा speed के बीच संतुलन के लिए quality की वकालत करने वाला कोई होना चाहिए।
  • End-to-end testing: System ownership से जुड़ी समस्याएँ complex architecture के कारण पैदा होती हैं, और इससे product release से पहले वास्तविक उपयोग testing की कमी हो जाती है।

GN⁺ की राय

  • QA टीम को हटाना लंबे समय में सॉफ़्टवेयर quality पर गंभीर असर डाल सकने वाली एक managerial गलती हो सकती है।
  • सॉफ़्टवेयर development process में quality assurance एक महत्वपूर्ण काम है, और इसे नज़रअंदाज़ करना या कमतर आँकना अंततः असफलता की ओर ले जा सकता है।
  • यह लेख सॉफ़्टवेयर उद्योग में QA के महत्व को फिर से सामने लाता है और quality management के प्रति उचित समझ तथा organization के भीतर भूमिकाओं के सही बँटवारे की ज़रूरत पर रोचक ढंग से ज़ोर देता है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-15
Hacker News राय

  • 1970 के दशक के उत्तरार्ध में IBM में product assurance का काम करते हुए, मैं अपने जिम्मे वाले product (word processing system) के लिए test code लिखता था और hardware setup बनाता था। development team को test cases विस्तार से बताए बिना सिर्फ सामान्य समस्याएँ बताई जाती थीं ताकि वे bugs ठीक करें। इस तरीके से, QA द्वारा पाए गए bugs और development team द्वारा ठीक किए गए bugs के बीच के अंतर से बचे हुए bugs का सांख्यिकीय अनुमान लगाया जा सकता था.

  • जिन संगठनों में QA team नहीं थी, वहाँ sniff test नाम की अवधारणा लाई गई थी। इसमें कंपनी के सभी लोग थोड़े समय के लिए, आमतौर पर 1 घंटे तक, किसी नए feature को गहन रूप से test करते थे। इसका नतीजा अक्सर बहुत सारे bug tickets के रूप में निकलता था। साधारण tests से भी समस्याएँ निकल आना आम बात थी, लेकिन अब यह चौंकाने वाली बात नहीं रही.

  • 15-20 साल पहले जिन दो कंपनियों में मैंने काम किया, उन्होंने world-class QA teams में निवेश किया था, और वे ऐसे bugs ढूँढने में बेहद सक्षम थीं जिनके बारे में developers ने सोचा तक नहीं होता था। QA team के पास यह तय करने का अंतिम अधिकार था कि product ship होगा या नहीं। आज कई कंपनियाँ मानती हैं कि developers द्वारा automated tests लिखना और code coverage पर बहुत समय लगाना बेहतर तरीका है, लेकिन मैंने बहुत से ऐसे products देखे हैं जो फिर भी सही से काम नहीं करते। बात यह नहीं है कि automated tests बुरे हैं, बल्कि यह कि human QA testers को पूरी तरह हटाना समस्या है.

  • किसी संगठन में सबसे अधिक conscientious कर्मचारी अक्सर सबसे अधिक असंतुष्ट भी होते हैं। वे quality समस्याओं को पहचानना और हल करना चाहते हैं, लेकिन उन्हें उसका श्रेय नहीं मिलता, और quality की बात करने पर उन्हें धीमा करने वाले लोगों की तरह देखा जाता है। जब तक 'तेजी से चलो और चीजें तोड़ो' वाले लोगों को लगातार इनाम मिलता रहता है, तब तक वे पीछे छूटी गड़बड़ियों को संभालते हुए नाराज़ रहते हैं, और उन्हें लगता है कि संगठन में care करना उनकी career growth के लिए नुकसानदेह हो सकता है.

  • QA को business और senior management अक्सर 'cost center' के रूप में देखते हैं। एक धारणा यह भी है कि जिन departments को 'cost center' माना जाता है, वहाँ काम करने से बचना चाहिए, क्योंकि reward और recognition हमेशा revenue लाने वालों को मिलता है। QA को कम लोगों के साथ ज्यादा काम करना पड़ता है, failures के लिए दोष दिया जाता है, और जब business को lean बनाना होता है तो layoffs की शुरुआत अक्सर यहीं से होती है.

  • QA engineers के पास बेहतरीन debugging skills होती हैं। वे application के हर पहलू पर काम करते हैं, जैसे pipeline, source code, test directories आदि, और अक्सर software engineers pipeline error messages पढ़े बिना, मूल समस्या को नज़रअंदाज़ करके, समाधान का अनुमान लगाते हुए दिन बिता देते हैं। QA engineers के प्रति उपेक्षा लेख में बढ़ा-चढ़ाकर नहीं कही गई है, और क्योंकि QA organizations में interviews अक्सर engineering organizations जितने सख्त नहीं होते, इसलिए QA engineers को कमतर समझा जाता है.

  • मेरे व्यक्तिगत अनुभव में, मैंने शायद ही कभी ऐसी QA team देखी है जो वास्तव में engineering के लिए tests लिखती हो। ज़्यादातर QA teams 'test plan' को manually चलाती हैं, या कभी-कभार automated browser/device tests के ज़रिए। इन tests की अपनी value है, लेकिन ये 'unit tests' या 'integration tests' जितने मूल्यवान नहीं हैं। इस model में असल QA का काम engineering team ही करती है, जबकि QA team अक्सर ऐसी चीज़ों को bug बताती है जो bug होती ही नहीं, जिससे उनकी उपयोगिता कम हो जाती है.

  • Microsoft में QA teams हटाए जाने के बाद Windows और cloud products में ज्यादा bugs देखे गए.