संभव है कि QA टीम को भंग करना गलत फैसला था

 (davidkcaudill.medium.com)
5 पॉइंट द्वारा GN⁺ 2023-12-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DevOps शैली के optimization से release, deployment, image management और rollback की बाधाएँ घटने के बाद software delivery में सबसे धीमा हिस्सा testing ही बचा
  • industry ने testing से ज़्यादा QA team को bottleneck की तरह देखना शुरू किया, और role से अपेक्षाएँ बढ़ीं लेकिन साथ ही खराब treatment, contract-based hiring, offshoring और hiring cuts जारी रहे
  • QA organization को तोड़ने से अनुभवी QA लोगों का मनोबल टूटा, और developers स्वाभाविक रूप से quality का काम अपने ऊपर नहीं ले सके, जिससे low-quality software की समस्या बढ़ी
  • quality management असल काम है, जिसे नाम देकर और assign करके करना पड़ता है, जैसे defect tracking, triage, investigation, quality advocacy और end-to-end testing
  • अगर quality work को संगठित नहीं किया जाता, तो समस्याएँ ढूँढने और संभालने वाले लोगों को reward नहीं मिलता, जबकि जल्दी बनाने और चीज़ें तोड़ने वालों को बार-बार reward मिलता रहता है

DevOps optimization के बाद बचा bottleneck

  • DevOps practitioners ने Theory Of Constraints लागू करके software delivery pipeline और practices को बहुत aggressively optimize किया
  • manual release management, deployment, image management और production rollback automation के लक्ष्य बन गए
  • product backlog से लेकर customer तक code पहुँचने की प्रक्रिया में low-value activities को हटाने या optimize करने योग्य bottleneck की तरह देखा गया
  • नतीजतन software delivery में सबसे धीमा हिस्सा testing ही बचा
    • testing वही वजह भी है जिसके कारण continuous delivery मौजूद है
    • testing को और तेज़, automated और parallel बनाया जा सकता है
    • अगर किसी practice में सबसे मूल्यवान activity ही bottleneck हो, तो इसका मतलब है कि स्थिति पहले से लगभग optimal है

industry ने QA team को bottleneck माना

  • optimization की आदत testing से आगे बढ़कर QA role पर भी लागू हुई
  • integration testing और end-to-end testing को unit tests में घटाकर parallel करने की कोशिशें हुईं
  • लोगों के स्तर पर, जिनके बारे में माना गया कि वे coding नहीं कर सकते, उन्हें function-level roles की ओर धकेलने जैसी बातें भी हुईं
  • industry ने यह देखना शुरू किया कि bottleneck testing नहीं बल्कि QA team हो सकती है
    • QA role से अपेक्षाएँ बढ़ीं
    • salary घटी या दूसरे roles की तुलना में नहीं बढ़ी
    • role contract-based हुआ और offshore किया गया
    • QA engineers की hiring घटाने के फैसले जारी रहे

QA role के सिमटने से बना दुष्चक्र

  • QA में बचे लोग धीरे-धीरे और भी प्रतिकूल ढाँचे में फँसते गए
    • जो लोग coding में काफ़ी अच्छे थे या treatment से थक चुके थे, वे QA छोड़ गए
    • बाकी लोगों को दूसरे लोग ऐसे देखने लगे जैसे वे “इतने सक्षम नहीं कि इस क्षेत्र से बाहर निकल सकें”
    • नए graduates को QA field recommend करने वाले लोग भी कम हो गए
  • कंपनियों ने “हम यह function अब नहीं रखेंगे, ख़ुद संभालो” वाले तरीके से QA से दूरी बना ली
  • यह प्रक्रिया QA career बनाने वाले लोगों के लिए असम्मानजनक और मनोबल तोड़ने वाली थी
  • QA को भंग करने से low-quality software की समस्या बढ़ी, और कई organizations इस स्थिति में पहुँच गईं कि software quality में किसे क्या करना है, यह किसी को पता नहीं रहा
  • जिन organizations ने QA function बनाए रखा, उन्हें भी पहले से क्षतिग्रस्त field के भीतर उसकी सही जगह ढूँढने में कठिनाई हुई

“testers को निकाल देना” समाधान नहीं था

  • तेज़ software delivery के लिए “एक अजीब-सा secret trick” testers को निकाल देना नहीं था
  • QA field को बिगाड़ देना प्रबंधन की सबसे खराब गलतियों में से एक के क़रीब था
    • यह दशकों में विकसित हुई चीज़ को नष्ट करने वाला फैसला था
    • इसका असर कई साल तक महसूस नहीं हो सकता
    • जब organization समस्या को सच में महसूस करती है, तब meaningful recovery में फिर कई साल लग सकते हैं
  • QA role के भीतर जो हिस्से पहले से टूटे हुए थे, वे अब भी बिना हल के बचे हैं
  • काम का बँटवारा हुआ ही नहीं, और developers अतिरिक्त compensation, recognition या incentive structure के बिना QA work ख़ुशी से नहीं लेते
  • जिन कुछ लोगों ने highly capable QA teams के साथ काम किया है, वे उनके कुछ व्यवहारों की नकल कर सकते हैं, लेकिन नए engineers और managers के लिए यह समझना कठिन है कि क्या गायब है
  • मूल सिद्धांत यह है कि quality assurance भी काम है
    • दूसरी तरह के कामों की तरह, अगर मान लिया जाए कि “कोई न कोई” कर देगा, तो विफलता तय है
    • इसे अदृश्य काम की तरह छोड़ देना भी विफलता की ओर ले जाता है

software quality management के लिए ज़रूरी काम

  • defect tracking

    • ऐसा तरीका होना चाहिए जिससे users bug information भेज सकें और developers bugs दर्ज कर सकें
    • bug एक individual ticket होता है जो बताता है कि क्या गलत हुआ और वह कितना गंभीर है
    • यह fix के काम का विवरण नहीं होता
    • इसमें defect, reproduction steps और impact शामिल होना चाहिए
    • हाल में जिन अधिकांश development teams के साथ काम हुआ, वे ऐसे defects track नहीं कर रही थीं
    • “वैसे भी इसे ठीक नहीं करेंगे”, “यह मेरा काम नहीं है”, “नई features पर reward मिलता है” जैसे कारण low-quality outcomes को सही नहीं ठहरा सकते
    • bug list को manage करना भी काम है

  • triage और prioritization

    • bug triage आने वाले bugs को assign, prioritize, organize, classify और deduplicate करने की प्रक्रिया है
    • high, medium और low severity के consistent standards organization के लिए मददगार होते हैं
    • पहले इसे “bug hygiene” कहा जाता था
    • यह तय करना भी काम है कि कौन-सी team उस bug को लेगी
    • जो organizations अच्छी तरह काम करती हैं, वे बाहरी दबाव या restructuring के दौरान बेहतर प्रतिक्रिया दे पाती हैं
    • layoffs होने पर भी वे quality degradation को क्रमिक ढंग से manage करती हैं
    • reorganization के समय वे कुछ bug categories नई teams को transfer करती हैं
    • बंद की गई features के bugs को bulk में close करती हैं
    • अगर कोई team सचमुच बिना किसी बाहरी तनाव या organizational restructuring के चल रही है, तभी triage process को नज़रअंदाज़ करने की बात मज़ाक जैसी लगती है

  • defect investigation

    • reproduction, bug management का महत्वपूर्ण हिस्सा है
    • किसी के “मैं movie ticket खरीदना चाहता था लेकिन नहीं हुआ” जैसे report को “नाम में non-English characters वाले customers के लिए text encoding issue ने purchase flow तोड़ दिया” जैसी form में बदलना पड़ता है
    • “यह समस्या कितनी बार हुई”, “user impact क्या है” जैसे सवालों के जवाब देने के लिए किसी वास्तविक व्यक्ति को समय देना पड़ता है
    • defect investigation का मतलब bug backlog पर engineering rigor लागू करना है

  • quality पर केंद्रित role

    • company के भीतर ऐसा व्यक्ति होना जो final product की quality पर ध्यान दे, वास्तविक मूल्य रखता है
    • quality सबकी ज़िम्मेदारी हो सकती है, लेकिन साथ ही यह किसी एक की ज़िम्मेदारी भी होनी चाहिए
    • quality और speed के बीच के तनाव में quality की वकालत करने वाला व्यक्ति चाहिए
    • testing tools, test quality और test planning के लिए ऐसा पक्ष होना चाहिए जिसकी स्पष्ट राय हो और जो चीज़ों को जितना संभव हो उतना अच्छा बनाने की कोशिश करे

  • end-to-end testing

    • कई engineering organizations में सबसे बड़े और आम मुद्दों में से एक system ownership है
    • architecture complexity बढ़ाना teams और applications को छोटा रखने के उद्देश्य से किया गया, और यह एक तर्कसंगत strategy हो सकती है
    • लेकिन नतीजे में application के सबसे महत्वपूर्ण हिस्सों में खाली जगहें बन गईं
    • औसत team अब end-to-end स्तर पर product का उपयोग और verification नहीं करती, क्योंकि यह बहुत कठिन है
    • यह सुनिश्चित किया जाना चाहिए कि product release होने से पहले organization के भीतर कोई उसे सच में इस्तेमाल कर रहा हो

quality work को नज़रअंदाज़ करने पर पैदा होने वाली organizational समस्याएँ

  • “हम agile, lean और dynamic हैं, इसलिए हमें यह सब करने की ज़रूरत नहीं” जैसी प्रतिक्रिया आ सकती है
  • ध्यान से देखने पर, संभव है कि यह काम organization के भीतर पहले से हो रहा हो, लेकिन बहुत खराब तरीके से
  • car, bank या doctor जैसे दूसरे क्षेत्रों में “हम quality assurance नहीं करते” सुनना अच्छा अनुभव नहीं होगा
  • अगर quality activities को पहचाना और संगठित नहीं किया जाता, तो इससे बहुत बुरी स्थिति पैदा होती है
  • सबसे conscientious employees सबसे अधिक कड़वाहट की स्थिति में पहुँच जाते हैं
    • वे quality problems देखते हैं और अक्सर उन्हें ठीक भी करते हैं
    • लेकिन इसके लिए उन्हें recognition नहीं मिलता
    • quality concerns उठाने पर उन्हें speed धीमी करने वाला समझा जाता है
    • वे देखते हैं कि “move fast and break things” वाले लोग बार-बार reward पाते हैं
    • उन्हें लगता है कि वे गुस्से में दूसरों की बनाई अव्यवस्था साफ़ कर रहे हैं
  • ऐसी organizations में care करना ही career disadvantage बन जाता है

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

1 टिप्पणियां

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

  • अपने करियर की शुरुआत में, 1970 के दशक के आखिर में, मैंने IBM Hursley Park के Product Assurance, यानी QA संगठन में काम किया था। जिस word-processing system की जिम्मेदारी थी, उसे टेस्ट करने के लिए हम code और hardware बनाते थे, और टेस्ट किए जाने वाले system पर test cases चलाते थे
    जो issues मिलते थे, उन्हें हम development team को सिर्फ सामान्य description के रूप में बताते थे, मकसद यह था कि development team test case को pass कराने के बजाय bug ठीक करे। नतीजा यह हुआ कि अगर hyphen वाले शब्दों के line break और backspace deletion में हमें 3 bugs मिलते, तो development team उस area के 4 bugs ठीक कर देती, लेकिन उनमें से हमारे actual मिले bugs सिर्फ 2 ही होते; इस तरह हम statistically अनुमान लगा पाते थे कि actual bugs कितने बचे हैं
    जिन organizations में QA team नहीं थी, वहां हमने sniff test का concept शुरू किया। आम तौर पर यह करीब 1 घंटे का session होता था, जिसमें company या department का कोई भी व्यक्ति नए feature को आजमाकर देखता था। Feature भले ही complete माना जाता हो, boundary conditions लगभग हमेशा टूटी होती थीं। सभी fields में "" डालकर submit करना, सिर्फ keyboard से UI navigate करना, या बड़े font और browser 110% zoom जैसी simple conditions आजमाना—इनसे अक्सर समस्याएं सामने आ जाती थीं, और अब तो यह हैरानी की बात भी नहीं रही

    • हमारी company में इसे bug bash कहते हैं, और मिलने वाले defects की संख्या के लिहाज से भी यह आम तौर पर बहुत productive होता है
      छोटे feature development के दौरान आम तौर पर सिर्फ programmers ही test करते हैं, लेकिन उनका तरीका असली end users के इस्तेमाल के तरीके से अलग हो सकता है, इसलिए यह खास तौर पर उपयोगी है
    • automated tests का source developers से छिपाने की strategy दिलचस्प है। ऐसा लगता है कि इससे वे tests को disable करने या सिर्फ tests के हिसाब से code बनाने के बजाय actual problem solving पर focus कर सकते हैं
    • पुराने Microsoft में इसे bug bash कहा जाता था, और मेरे startup ने भी यह idea अपनाया। पूरी company को दोपहर का समय खाली रखकर participate करने के लिए encourage किया जाता था, और सबसे ज्यादा impact वाले bug या सबसे interesting bug के लिए awards भी दिए जाते थे
    • एक घंटे में 100 bug tickets बनाना असल में किसके लिए useful है, इस पर मुझे शक है। अगर duplicates बहुत हैं, तो 10 अलग-अलग bugs ही यह दिखाने के लिए काफी हैं कि feature गंभीर रूप से खराब है; उसके बाद तो ऐसा लगता है जैसे मलबे को ही बार-बार ठोका जा रहा हो
    • precise QA test cases रखकर developers को सिर्फ vague description देना काफी clever तरीका है। ऐसा तरीका मैंने पहली बार देखा, और यह बात भी impressive है कि इससे बचे हुए bugs की संख्या का अनुमान लगाया जा सकता है

  • 15–20 साल पहले मैंने दो ऐसी companies में काम किया था जिन्होंने top-level QA teams में investment किया था, और वे teams सचमुच अपनी कीमत वसूल कराती थीं। QA ऐसे bugs बहुत अच्छे से ढूंढता था जिनके बारे में developer, problem के बहुत करीब होने के कारण, सोच ही नहीं पाते थे; और product भी world-class बन गया था
    दोनों companies में core बात यह थी कि ऊपर से तय था कि release करना है या नहीं, इसका final authority QA team के पास होगा
    आजकल companies सोचती हैं कि developers automated tests इस्तेमाल करें और code coverage पर जरूरत से ज्यादा ध्यान दें तो बेहतर है, लेकिन मैंने 100% code coverage के बावजूद objectively काम न करने वाले बहुत सारे products देखे हैं। मेरा मतलब यह नहीं कि automated tests खराब हैं; समस्या human QA testers को हटाने में है

    • शानदार QA/QE organizations भी कुछ ऐसी ही थीं। production release को certify करना है या नहीं, यह तय करने वाली chain of command development से अलग थी, और incentive structure भी अलग था
      हाल ही में जिस company में था, उसकी QE team ने tests चलाने के लिए बहुत बड़ी मात्रा में code लिखा था; test और certification के target module से भी ज्यादा lines of code थीं
    • code coverage उन bugs को नहीं पकड़ता जो उस code से पैदा होते हैं जिसे लिखा नहीं गया, लेकिन लिखा जाना चाहिए था। coverage कई metrics में से सिर्फ एक है, और उसे इकलौता criterion मानना मूर्खता है
      फिर भी मैंने एक ऐसी बड़ी software company, जिसे सब जानते हैं, के test manager को यह कहते सुना है कि 100% coverage हासिल हो गया है, इसलिए test team का काम खत्म है
    • सिर्फ यह निर्देश कि QA के पास final decision power है, काफी नहीं है; QA culture भी होना चाहिए
      ऐसी authority होने के बावजूद, जिन companies में QA ज्यादातर कम वेतन वाले contractors होते हैं और सिर्फ वही करते हैं जो कहा जाए, वहां हालात फिर भी खराब थे
    • मैंने developers को ऐसे tests लिखते देखा है जिनमें assertions नहीं थे, या सिर्फ assertTrue(true) था। हमेशा green light, और coverage 100%
      वही लोग अक्सर पूछते थे कि जब वे नया feature बना सकते हैं तो tests क्यों लिखें, और फिर senior QA आकर सब तोड़ देता था। एक बार उसने पाया कि 1 मिनट में F5 को 50 बार दबाने पर backend database requests चलाते-चलाते outOfMemory से crash हो जाता है
    • मुझे meticulous QA लोग सच में बहुत पसंद हैं। एक developer के तौर पर यह उम्मीद करके उन पर जरूरत से ज्यादा निर्भर हो जाना कि वे मेरी छूटी चीजें पकड़ लेंगे, anti-pattern है; लेकिन जब मैं अपना code 1 मिनट चलाने से भी डरता हूं, वे इसका मजा लेते हैं
      वे spec से बहुत आगे जाने वाली boundary conditions खोजने में गर्व महसूस करते हैं, और उनकी value पूरी है। जैसे अच्छा type system changes को लेकर confidence देता है, वैसे ही शानदार QA भी developer को confidence देता है। खासकर games जैसी high-interaction apps में unit tests और integration tests से ही पूरे parameter space को cover करना मुश्किल होता है

  • यह बात कड़वी सच्चाई है कि organization के सबसे conscientious employees ही सबसे ज्यादा bitter हो जाते हैं। वे quality issues देखते हैं, अक्सर खुद ठीक भी करते हैं, लेकिन recognition नहीं मिलता; और quality concerns उठाने पर उन्हें speed धीमी करने वाला माना जाता है
    “move fast and break things” वाले लोग लगातार reward पाते हैं, और care करने वाले लोग उनके बाद की सफाई करते-करते नाराजगी जमा करते जाते हैं। उन्हें care करना ही career के लिए बड़ा नुकसान लगता है, क्योंकि असल में ऐसा ही है
    DBA और infrastructure organizations भी QA जैसी ही स्थिति में हैं, और उम्मीद है कि pendulum जल्द ही वापस आएगा

    • बस जहाज से कूद जाइए और उस company को डूबने दीजिए। उसका जल्दी डूबना बेहतर है, और जब आप खराब companies को जबरन सहारा नहीं देते, तभी अच्छी चीजें संभव होती हैं
    • मेरे हिसाब से pendulum वापस आने का तरीका है: अगर आपने बनाया है, तो आप ही operate करें। अगर on-call pager बजना पसंद नहीं है, तो उसे बजने की नौबत मत आने दीजिए
    • आखिरकार यह customers पर निर्भर है। सवाल यह है कि वे bugs और outages की वजह से छोड़ेंगे, या चमकदार नए features की वजह से टिके रहेंगे
    • QA और testing महत्वपूर्ण हैं, लेकिन पता नहीं profit-only सोच रखने वालों को समझाया जा सकेगा या नहीं। Internet deployment बहुत आसान हो जाने की वजह से “जल्दी release करो और बाद में patch करो” वाला तरीका शायद बना रहेगा
      हिसाब यह है कि जब users bug report कर सकते हैं और internet से updates ले सकते हैं, तो बहुत पैसा और समय क्यों लगाया जाए। Games और software के physical media से download-centric होने के बाद patch करना शायद सस्ता पड़ता है। बेशक इससे भयानक security issues और खराब user experience पैदा होते हैं, लेकिन जब तक ऊपर बैठे लोग profit maximize कर रहे हैं, वे खास परवाह नहीं करते
    • conscientious engineer हमेशा सही हो, ऐसा नहीं है; context और balance जरूरी है। कभी-कभी वे सही होते हैं लेकिन communication style खराब होती है, और कभी-कभी वे बस गलत जगह पर होते हैं
      अगर आप POC SaaS product बना रहे हैं, तो avionics microcontroller जैसी quality की जरूरत नहीं है। हर trade-off के साथ risk और cost आती है, और अच्छे engineer को यह फर्क समझना चाहिए

  • QA टीम की मूल समस्या IT टीम या management organization जैसी ही है। अगर वे अपना काम अच्छी तरह करें, तो ऐसा दिखता है जैसे वे कुछ कर ही नहीं रहे
    इसलिए अक्सर ऐसी स्थिति बनती है जहाँ उन्हें अपने काम को “justify” करना पड़ता है, और यह आमतौर पर metrics पर बहुत ज़्यादा निर्भर होने से आता है। Goodhart के नियम की तरह, यह समझ नहीं होती कि कोई metric किस चीज़ का proxy है और उस काम का असली उद्देश्य क्या है
    खराब QA टीम कुछ कहने लायक दिखने के लिए जरूरत से ज्यादा खामियाँ निकालती है, जबकि अच्छी QA टीम quality verify करने के साथ-साथ कर्मचारियों को higher quality बनाने की training भी देती है
    मुझे लगता है कि workforce में कुल मिलाकर training की कमी है। कुछ समय पहले front page पर आया “95th percentile भी इतना खास नहीं है” वाला लेख (https://news.ycombinator.com/item?id=38560345) भी इसी बारे में था कि चूँकि ज्यादातर practitioners actively training नहीं करते या feedback नहीं लेते, इसलिए किसी भी क्षेत्र में top 5% तक पहुँचना आसान है
    मुझे लगता है कंपनियों को amateur sports team नहीं, बल्कि pro team की तरह लगातार training करनी चाहिए। hiring में भी “क्या यह पहले से top performer है” से ज्यादा “क्या हम इस व्यक्ति को top performer बना सकते हैं” देखना चाहिए। पिछले environment में सफल होने का तथ्य, अगर नया environment काफी अलग हो, तो अपेक्षा से कम मायने रखता है

    • 95th percentile किसी जबरदस्त मेहनत का परिणाम होने के बजाय unnecessary mistakes कम करने का परिणाम हो सकता है, फिर भी इसे बहुत कठिन काम मानने वाला cultural meme व्यापक रूप से फैला है
      software quality से जुड़े हर लेख में engineers की व्यापक उदासीनता को स्वाभाविक मानने वाली comments बहुत मिलती हैं। स्थिति के अनुसार फर्क होता है, लेकिन लोग अपने organization के local optimum के हिसाब से बस साथ बहते हुए initiative छोड़ देने में काफी सहज दिखते हैं। यह पूरी तरह उनकी गलती नहीं है, लेकिन वे निर्दोष भी नहीं हैं
    • DevOps team में “काम को justify करना पड़ता है” वाला pattern लगातार दिखता है। आम तौर पर सबसे ज्यादा paid या senior operations person अपनी अक्षमता या गलतियों से लगी आग बुझाने में काफी समय लगाता है, इसलिए लगता है कि वह कुछ कर रहा है
      repetitive work को automation से खत्म कर दें तो उस व्यक्ति की जगह खत्म हो जाती है, लेकिन सही तरीके से करने पर manager को लगेगा कि वह दिन भर बैठकर कुछ नहीं कर रहा, इसलिए सही काम करने की incentive कम होती है
    • नए developers के साथ काम करते समय double-click, leading space, Android back button जैसे basic tests से भी उन्हें अक्सर अटका सकते हैं। कुछ बार tickets reject होने पर वे ये चीजें सीख जाते हैं और बाद में वही issues बहुत कम आते हैं
      चूँकि evaluation bugs मिलने की संख्या से नहीं होती, इसलिए numbers बढ़ाने के लिए बेवकूफाना bugs जबरन खोजने का दबाव भी नहीं होता
    • “अगर इस तरह train करोगे तो वे ज्यादा पैसे लेकर कहीं और चले जाएँगे” यह बात मैंने लगभग हर company में सुनी है। meaningful training हमेशा uphill battle रही है
      अच्छी training के लिए technical roles में पर्याप्त breadth और अच्छे लोग चाहिए। latest technologies सब जानना जरूरी नहीं, लेकिन nonsense पहचानकर उसे point out कर सकना चाहिए। FAANG भी exception नहीं है

  • इस लेख में भी बात आती है, लेकिन असली मुद्दा यह है कि QA लगभग हमेशा business units और upper management को cost department जैसा दिखता है
    मेरी hypothesis है कि जिन organizations को cost department माना जाता है, वहाँ काम न करना ही बेहतर है। bonus, recognition, respect हमेशा revenue लाने वाली side को मिलते हैं, और cost departments कम लोगों के साथ ज्यादा काम उठाते हैं, failures की जिम्मेदारी लेते हैं, और company downsizing करे तो पहले कटते हैं। IT के साथ भी यही है
    इस vicious cycle की वजह से QA career हमेशा similar skills के साथ developer बनने की तुलना में कठिन ही रहेगा। बेहतरीन लोग थककर जितनी जल्दी हो सके बाहर निकल जाते हैं, और यह structure खुद को reinforce करता है

    • mobile app developer होने पर भी मुझे लगता है कि cost-department-type काम न लेने को लेकर सावधान रहना चाहिए
      accessibility, observability, अच्छी logging, test infrastructure सुधार, CI/CD tuning, reliability, बेहतर linting और analyzer issues—ये सब important हैं, लेकिन reward तब मिलता है जब features जल्दी ship किए जाते हैं
      इस साल मैंने team और app के लिए जरूरी समझकर ऐसे कामों पर बहुत ज्यादा समय लगाया, और year-end performance review को लेकर चिंता है। अब समझ आया कि बाकी लोग ये काम क्यों टालते थे, और अगले साल ज्यादा visible feature launches पर focus करने का सोच रहा हूँ। app के bugs के लिए sorry, लेकिन mortgage चुकाने के लिए job चाहिए
    • cost department जैसा एहसास होने से सहमत हूँ, लेकिन अनुभव में इसमें थोड़ा और nuance है
      कुछ organizations QA/QC से आने वाली value को सच में महत्व देती हैं। software की तुलना में manufacturing में यह ज्यादा साफ दिखा, शायद इसलिए कि software inherently ज्यादा abstract है और waste trace करना मुश्किल है
      सच में अच्छा QA easy route खोजने वाला व्यक्ति नहीं, बल्कि QA के mission में विश्वास करने वाला व्यक्ति होता है। आखिरकार value इस बात से बनती है कि organization और individuals QA spirit को सच में अपनाते हैं या नहीं, और कई जगह यह सिर्फ formal तौर पर होता है
    • frontend platform team में performance improvements, CI design, process engineering करता हूँ, लेकिन bank account में सीधे पैसे लाने वाले features ship करने वालों की तुलना में recognition और promotion पाना काफी कठिन है
      फिर भी कोई बात नहीं। चीजों को बेहतर और मजबूत बनाना मुझे पसंद है और मन को शांति देता है। तोड़ने का काम cynical लोगों पर छोड़ दूँगा
    • जिंदगी भर लगभग cost departments में काम किया है, लेकिन इसे किसी और चीज़ से बदलना नहीं चाहूँगा
      bonus आदि दूसरे groups को जाएँ तो भी ठीक है। technical role में मुझे पर्याप्त अच्छी pay मिल रही है, और उन money-making roles में से कई, भले ही मैं उन्हें सच में अच्छी तरह कर पाता, मुझे बहुत दुखी कर देते
    • इसलिए traditional business के IT department में काम नहीं करता

  • software quality, code maintainability, और अच्छा design तभी महत्वपूर्ण हैं जब आप उस company में लंबे समय तक काम करने की योजना रखते हों
    अगर कुछ साल बाद अगली company में जाने का इरादा है, तो सबसे अच्छा path है visible काम करके जल्दी ऊपर बढ़ना और उस track record का उपयोग करके ज्यादा salary वाली job में जाना। कुछ साल बाद वह project टूट जाए या maintain करने लायक न रहे, तो भी फर्क नहीं पड़ता, क्योंकि तब आप वहाँ होंगे ही नहीं
    startups भी इसी तरह चलते हैं। हर जगह उकेरा हुआ growth mindset यही pattern है। product 5 साल बाद maintain करने लायक न रहे, तब तक हो सकता है वे exit कर चुके हों और cash out कर चुके हों
    मैं ऐसे लोगों को ठीक-ठीक दोष नहीं देता। यह वही practices हैं जो companies खुद इस्तेमाल करती हैं, और लोग बस उन rules के हिसाब से खेलते हैं। मुझे यह पसंद नहीं और सच में नापसंद है, लेकिन समझ आता है
    मजेदार हिस्सा वह है जब managers और executives turnover, company commitment की कमी, और quiet quitting की शिकायत करते हैं। यह वैसा है जैसे वे अपना बनाया ज़हर खुद चख रहे हों

    • startups का यह मानना कि 5 साल बाद product maintain करने लायक नहीं रह सकता, एक rational attitude हो सकता है। क्योंकि ज्यादातर startups 5 साल टिकते ही नहीं और fail हो जाते हैं
      अगर 5 साल बाद वे technical debt के साथ भी survive कर रहे हों, तो कई startups के लिए यह उल्टा अच्छी problem है। आखिर इसका मतलब है कि वे 5 साल टिक गए

  • QA इंजीनियर debugging में भी काफ़ी अच्छे होते हैं। वे pipelines, source और test directories में हाथ डालते हैं, और application development व deployment के लगभग हर पहलू से निपटते हैं।
    जब मैं QA lead था, तो अक्सर ऐसे software engineers देखता था जो pipeline error messages पढ़ने की कोशिश तक नहीं करते थे और रोज़ Slack पर शिकायत करते थे। Pipeline optimization के समय भी वे मूल समस्या को नज़रअंदाज़ करते थे, और उस मूल समस्या से निकले symptoms को ऐसे पेश करते थे मानो वे कोई जादुई, समझ से परे समस्याएँ हों, फिर दिनों तक अनुमान लगाकर उन्हें हल करने की कोशिश करते थे।
    इस लेख में QA इंजीनियरों के प्रति अवमानना कोई अतिशयोक्ति नहीं है। जिन कंपनियों में QA org होते हैं, वहाँ भी अक्सर engineering org जैसी सख़्त interview process नहीं होती, इसलिए QA engineers को कम आंका जाता है।
    QA का सम्मान करने वाले SWE सिर्फ़ वही लोग थे जिन्होंने खुद QA में काम किया था। यह तिरस्कार इतना व्यापक था कि अंततः मैं engineering org में लौट गया, और principal engineer के तौर पर अपनी seniority या manager role का इस्तेमाल कर इसे बदलने की कोशिश की, लेकिन असफल रहा। Engineering अपनी ही अहंकार भरी सोच से आगे नहीं देख सकी और leadership ने भी मदद नहीं की।
    layoff से पहले जिस कंपनी में मैं काम करता था, उसके नए CTO ने कहा कि QA की ज़रूरत automation से खत्म की जा सकती है, लेकिन इसका मतलब क्या है—इसका एक भी उदाहरण नहीं दिया। अच्छा software बनाने के काम के प्रति ऊपर से आने वाले सम्मान का स्तर बस इतना ही था।

  • Microsoft इस समस्या का सबसे साफ़ उदाहरण लगता है। QA team हटाने के बाद Windows और cloud product updates में bugs साफ़ तौर पर बढ़ गए।

    • Revenue तो आता रहा, यानी business के हिसाब से शायद यह सही फैसला था… आह भरनी पड़ती है।
      काम में Microsoft software और services बहुत इस्तेमाल करता हूँ, और चाहता हूँ कि quality गिरने की उन्हें किसी न किसी रूप में कीमत चुकानी पड़े।

  • यह मेरा व्यक्तिगत अनुभव हो सकता है, लेकिन मैंने ऐसी QA team नहीं देखी जो engineering के लिए वास्तव में tests लिखती हो।
    जिन QA teams का मैंने अनुभव किया, वे test plans लिखती थीं और उन्हें manually execute करती थीं, या कभी-कभार automated browser/device tests के जरिए चलाती थीं। ऐसे tests की भी value है, लेकिन मेरे हिसाब से unit tests या integration tests से कम।
    इस model में असल में engineering team ही QA team बन जाती थी, और अलग QA team अक्सर non-bugs को bugs की तरह खोजकर noise पैदा करती थी और जितनी value देती थी उससे ज़्यादा cost पैदा कर देती थी।
    मैं जानना चाहता हूँ कि अच्छी तरह काम करने वाला QA team model कैसा होता है। Manual testing शानदार है, लेकिन मेरे अनुभव में इसकी सीमाएँ हैं। मैं QA लोगों को नीचा दिखाने की कोशिश नहीं कर रहा, बस अपना अनुभव साझा कर रहा हूँ।

    • मैंने QA की value product familiarity में देखी है। अच्छा QA यह किसी से बेहतर जानता है कि product वास्तव में कैसे काम करता है।
      PMs, sales, और अधिकांश dev teams से भी ज़्यादा वह user-facing पूरे system को समग्र रूप से जानता है, और ठीक-ठीक बता सकता है कि कौन सा button दबाने पर क्या होगा। खराब QA सच में noise का स्रोत हो सकता है, लेकिन खराब developers, system administrators और level 1/2 support भी वैसे ही होते हैं।
    • अच्छा QA, software developer के लिए वही भूमिका निभाता है जो अच्छा editor किसी लेखक के लिए निभाता है। वह मेहनत से बनाए गए output को ठंडे दिमाग से देखता है और बेरहमी से critique करता है।
      जब यह आपके साथ हो रहा होता है तो सचमुच चिढ़ होती है, लेकिन final output की quality बहुत बेहतर हो जाती है।
      पुराने समय का QA आम तौर पर tests नहीं लिखता था; वह code को manually test करता था और वे सारी अजीब हरकतें करके देखता था जो आप उम्मीद करते हैं कि users न करें। वह ऐसी समस्याएँ और bugs ढूँढता था जिन्हें tests से सार्वभौमिक रूप से पकड़ना मुश्किल होता है।
      अब QA को users पर डाल दिया जाता है। युवा developers के साथ काम करते हुए महसूस होता है कि QA की अवधारणा ही धीरे-धीरे अनजानी होती जा रही है। Production में bug पहुँच जाए और मैं पूछूँ “local में हाथ से चलाकर देखा तो कैसा था?”, तो अक्सर अजीब नज़रों से देखा जाता है। जैसे type checker pass हो गया तो release क्यों न करें।
      आजकल programmer efficiency को प्रति मिनट PRs की संख्या से मापा जाता है, इसलिए bugs introduce करना समस्या नहीं बल्कि उल्टा अच्छा है। कोई production में उसे ढूँढ लेगा तो कुछ दिन बाद उसे fix करने वाला एक और PR निकाला जा सकता है। अगर QA होता तो यह flow खराब हो जाता।
    • मैं QA हूँ जो engineering के लिए tests लिखता है, और मेरा exact title SDET है। मैं सिर्फ़ test plans ही नहीं, बल्कि test framework, infrastructure और उन test plans की automation भी संभालता हूँ।
      हर कंपनी QA function को अलग तरह से implement करती है। कभी इसे customers पर छोड़ा जाता है, कभी developers, customer support, manual QA या SDET पर। आखिरकार यह इस बात पर निर्भर करता है कि leadership quality को कितना महत्व देती है और QA को कैसे देखती है।
      अगर QA team है, तो मेरे हिसाब से उसकी success की संभावना सबसे ज़्यादा तब होती है जब वह process के शुरुआती चरण में शामिल हो। अच्छी QA team को code लिखे जाने से पहले bugs ढूँढने चाहिए। जितनी देर से वह शामिल होती है, bugs भी उतनी देर से मिलते हैं, और “code complete” व release के बीच वह उतनी ही बुरी तरह squeezed होती है। QA team के पास automation capability होनी चाहिए ताकि manual tests बार-बार दोहराने के बजाय नए test cases पर समय लगाया जा सके।
      यह लेख काफ़ी चुभता है। QA को कभी-कभी second-class citizen की तरह treat किया जाता है, और उन discussions से बाहर रखा जाता है जिनसे काम ठीक से करने के लिए context मिल सकता है। अच्छे लोग जब development या product management में चले जाते हैं तो हालात और खराब होते हैं, और downward spiral सचमुच मौजूद है।
    • QA org चलाने का कोई औपचारिक तरीका नहीं है, इसलिए अक्सर लोगों को hire करने के बाद कहा जाता है, “खुद ही पता कर लो।” फिर बाकी orgs QA की ज़रूरतें नहीं समझते और उन्हें ignore करते हैं।
      आपने अभी जो describe किया है वह leadership problem है, QA की usefulness का problem नहीं।
    • classical model में ज़्यादातर QA orgs बेकार appendage की तरह चलते थे। यह structural भी था, और बड़ी वजह यह थी कि development late होने पर QA को धकेल दिया जाता था।
      QA शुरू में शामिल हुए बिना test infrastructure और test plans बनाने में समय बिताता था, फिर आखिर में उसे code का एक बड़ा ढेर और 48-hour approval schedule दे दिया जाता था, और भारी pressure में sign-off करना पड़ता था।
      लेकिन कभी-कभी ऐसे QA orgs भी मिलते थे जो problem domain को गहराई से समझते थे और development को सचमुच drive करते थे। वे development के साथ शुरुआत से अंत तक कंधे से कंधा मिलाकर चलते थे, और न केवल quality बढ़ाते थे बल्कि सबका समय भी बचाते थे।

  • FoundationDB बनाते समय गुणवत्ता और testing पर लगभग जुनून की हद तक फोकस किया गया था। इसलिए Flow नाम की भाषा तक बनाई गई, ताकि मनमाने आकार के FDB clusters को deterministically simulate किया जा सके, उन पर extreme conditions लागू की जा सकें, फिर system properties के violations दिखाए जा सकें और उस violation को पैदा करने वाली test execution को पूरी तरह reproduce किया जा सके
    हर रात tens of thousands test executions उस स्तर तक पहुंच गई थीं जहां नया code न हो तो मूल रूप से सब green दिखती थीं। जो tests red होती थीं, वे लगभग हमेशा हाल में जोड़े गए code की वजह से होती थीं, इसलिए उन्हें आसानी से identify और fix किया जा सकता था
    इसकी बदौलत team यह जानते हुए develop कर सकती थी कि नए डाले गए bugs जल्दी पकड़ लिए जाएंगे, और इसी ने ऐसी speed दी जिससे release के बाद transaction processing system rewrite जैसे bold projects को भी confidence के साथ लिया जा सका। नतीजतन 10x speed improvement भी मिला
    आखिरकार quality पर focus ही speed में बदला, और दोनों बिल्कुल भी एक-दूसरे के विरोध में नहीं थे। मुझे नहीं लगता कि यह कोई isolated phenomenon है, और इसलिए यह एक नए project तक पहुंचा, लेकिन वह अगली कहानी है