AI ടെസ്റ്റിംഗ് കെണി
"ഈ പാദത്തിൽ ഞങ്ങൾ 40% കൂടുതൽ ടെസ്റ്റുകൾ പൂർത്തിയാക്കി" എന്ന് ആരെങ്കിലും പറയുന്നത് നിങ്ങൾ കേൾക്കുന്നു, എല്ലാവരും അത് ശരിവെച്ച് തലയാട്ടുന്നു.
ടോക്കിയോയിലെ ഒരു SaaS കമ്പനിയിൽ ഇത് സംഭവിക്കുന്നത് ഞാൻ കണ്ടിട്ടുണ്ട്. QA ലീഡ് അഭിമാനത്തിലായിരുന്നു. മാനേജ്മെന്റ് സന്തോഷവാനായിരുന്നു. പൈപ്പ്ലൈൻ പച്ച നിറത്തിലായിരുന്നു (green).
ആറ് ആഴ്ചകൾക്ക് ശേഷം, ഒരു പേയ്മെന്റ് സിസ്റ്റം 72 മണിക്കൂർ നേരത്തേക്ക് തകരാറിലായി. ആരും അത് ശ്രദ്ധിച്ചില്ല, കാരണം AI എഴുതിയ ടെസ്റ്റുകൾ "ശരിയായ ഡാറ്റ" പരിശോധിക്കുന്നതിന് പകരം "എററുകൾ ഇല്ലെന്ന്" മാത്രം പരിശോധിക്കുന്നവയായിരുന്നു.
ഇതാണ് Testing Blindness.
നിങ്ങളുടെ ടീം ധാരാളം ടെസ്റ്റുകൾ നിർമ്മിക്കുന്നുണ്ടെങ്കിലും, ആ ടെസ്റ്റുകൾ നിങ്ങളെ തെറ്റിദ്ധരിപ്പിക്കുന്നുണ്ടോ എന്ന് തിരിച്ചറിയാൻ കഴിയാത്ത അവസ്ഥയാണിത്. ടെസ്റ്റ് കവറേജിനെ (test coverage) ടെസ്റ്റ് ക്വാളിറ്റിയായി (test quality) തെറ്റിദ്ധരിക്കാൻ AI കാരണമാകുന്നു.
Qiita-യിലെ ഒരു സമീപകാല പോസ്റ്റ് ഈ പോരാട്ടം വ്യക്തമാക്കുന്നു. ഓട്ടോമേഷൻ ഇല്ലാത്ത പ്രോജക്റ്റുകൾ കൈകാര്യം ചെയ്യാൻ ഒരു എഞ്ചിനീയർ AI ഉപയോഗിച്ചു. ടെസ്റ്റുകൾ വേഗത്തിൽ വന്നു. മെട്രിക്സ് (metrics) മികച്ചതായി തോന്നി.
എന്നാൽ ആ എഞ്ചിനീയർക്ക് Playwright-ഉം API ടെസ്റ്റിംഗും നേരിട്ട് പഠിക്കേണ്ടി വന്നു. എന്തുകൊണ്ട്? കാരണം AI-ക്ക് സിന്റാക്സ് (syntax) എഴുതാൻ കഴിഞ്ഞു, പക്ഷേ സിസ്റ്റം എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് അതിന് മനസ്സിലായില്ല.
Testing Blindness-ന് പ്രധാനമായും മൂന്ന് ലക്ഷണങ്ങളുണ്ട്:
• Assertion Atrophy: കോഡ് ക്രാഷ് ആകുന്നുണ്ടോ എന്ന് മാത്രമാണ് ടെസ്റ്റുകൾ പരിശോധിക്കുന്നത്, അത് ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടോ എന്നല്ല. അതിനാൽ ടെസ്റ്റുകൾ പാസ് ആകുന്നു. • Boundary Case Blindness: AI "ഹാപ്പി പാത്തുകളിൽ" (happy paths) മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു. null ഇൻപുട്ടുകൾ അല്ലെങ്കിൽ race conditions പോലുള്ള എഡ്ജ് കേസുകൾ (edge cases) അത് വിട്ടുപോകുന്നു. • Regression Confidence Inflation: ടെസ്റ്റുകളുടെ എണ്ണം ഇരട്ടിയായതുകൊണ്ട് നിങ്ങൾക്ക് സുരക്ഷിതത്വം തോന്നുന്നു. എന്നാൽ യഥാർത്ഥത്തിൽ, നിങ്ങളുടെ തെറ്റായ ആത്മവിശ്വാസം നിങ്ങൾ ഇരട്ടിയാക്കുക മാത്രമാണ് ചെയ്യുന്നത്.
എന്റെ അനുഭവത്തിൽ, AI ഉപയോഗിച്ച് മാസങ്ങൾക്കുള്ളിൽ ടീമുകൾ പൂജ്യത്തിൽ നിന്ന് 1,200 ടെസ്റ്റുകളിലേക്ക് വളരുന്നു. റിപ്പോർട്ടുകൾ തികച്ചും കൃത്യമായി തോന്നും. എന്നാൽ യഥാർത്ഥ ബഗ്ഗുകൾ കണ്ടെത്തുന്ന നിരക്ക് കുറയുന്നു.
ജപ്പാനിൽ, മാനേജ്മെന്റിനും പ്രോസസിനും (kanri) നൽകുന്ന പ്രാധാന്യം ഇത്തരം ഉയർന്ന കണക്കുകളെ വിജയമായി തോന്നിപ്പിക്കാം. പാശ്ചാത്യ രാജ്യങ്ങളിൽ, AI കാര്യങ്ങൾ എളുപ്പമാക്കുന്നത് കൊണ്ട് ടീമുകൾ പലപ്പോഴും ടെസ്റ്റുകൾ ഒഴിവാക്കുന്നു. രണ്ട് രീതികളും പ്രൊഡക്ഷൻ പരാജയങ്ങളിലേക്ക് (production failures) നയിക്കുന്നു.
AI മെട്രിക്സുകൾ മെച്ചപ്പെടുത്തുന്നുണ്ടെങ്കിലും, ബഗ്ഗുകൾ കണ്ടെത്തുന്ന (debug) നിങ്ങളുടെ കഴിവിനെ അത് തളർത്തുന്നു.
നിങ്ങൾ QA-യിൽ AI ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, ഈ നിയമങ്ങൾ പാലിക്കുക:
- ടെസ്റ്റുകൾ ആഴ്ചതോറും ഓഡിറ്റ് ചെയ്യുക: ഏതെങ്കിലും 5 AI ടെസ്റ്റുകൾ തിരഞ്ഞെടുക്കുക. "എന്താണ് ഈ ടെസ്റ്റ് തെറ്റായി പാസ് ആകാൻ കാരണമാകുന്നത്?" എന്ന് സ്വയം ചോദിക്കുക. നിങ്ങൾക്ക് വേഗത്തിൽ ഉത്തരം നൽകാൻ കഴിയുന്നില്ലെങ്കിൽ, അവിടെ നിങ്ങൾക്ക് ഒരു അറിവില്ലായ്മ (blind spot) ഉണ്ട്.
- ഒരു പരിധി നിശ്ചയിക്കുക: ഓരോ 10 AI ടെസ്റ്റുകൾക്കും പകരം 2 എഡ്ജ് കേസ് ടെസ്റ്റുകൾ നേരിട്ട് (manually) എഴുതുക.
- 3am ടെസ്റ്റ് ഉപയോഗിക്കുക: പുലർച്ചെ 3 മണിക്ക് ഒരു പരാജയം സംഭവിച്ചാൽ ഈ ടെസ്റ്റുകൾ അത് കണ്ടെത്തും എന്ന് ഉറപ്പാണോ? നിങ്ങൾക്ക് ഉറപ്പില്ലെങ്കിൽ, അവ മതിയായതല്ല.
- ഒരു മോഡ്യൂൾ മാനുവൽ ആയി സൂക്ഷിക്കുക: ഒരു പ്രധാന ഭാഗം നേരിട്ട് ടെസ്റ്റ് ചെയ്യുക. ഇത് നിങ്ങളുടെ ഡീബഗ്ഗിംഗ് (debugging) കഴിവുകൾ കൂർപ്പിച്ചു നിർത്തും.
ടെസ്റ്റുകളുടെ എണ്ണത്തെ അവയുടെ ഗുണനിലവാരമായി തെറ്റിദ്ധരിക്കരുത്. കാര്യക്ഷമത (efficiency) നിങ്ങളുടെ വിവേചനബുദ്ധിയെ (judgment) ഇല്ലാതാക്കാൻ അനുവദിക്കരുത്. നിങ്ങൾക്ക് ശരിക്കും മനസ്സിലായ ടെസ്റ്റുകൾ മാത്രമാണ് നിങ്ങളെ രക്ഷിക്കുന്നത്.
AI ഉപയോഗിക്കാൻ തുടങ്ങിയ ശേഷം നിങ്ങളുടെ ടീമിലെ ടെസ്റ്റിംഗ് ഗുണനിലവാരത്തിൽ കുറവ് കണ്ടോ? നിങ്ങളുടെ അനുഭവം താഴെ പങ്കുവെക്കുക.
ഓപ്ഷണൽ ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi