എല്ലാ ടെസ്റ്റുകളും പാസായി. എന്നിട്ടും ഉപയോക്താവിന് ഗെയിം കളിക്കാൻ കഴിഞ്ഞില്ല

"API 200 OK നൽകുന്നു!"

എന്റെ ആദ്യത്തെ എഞ്ചിനീയറിംഗ് ജോലിയിൽ വെച്ച് ഞാൻ ഒരു വലിയ പ്രശ്നം കണ്ടു. എന്റെ സീനിയേഴ്സിന് ഡാഷ്‌ബോർഡുകളോട് വലിയ താൽപ്പര്യമായിരുന്നു. അവർക്ക് ഉയർന്ന കോഡ് കവറേജ് (code coverage) ഇഷ്ടമായിരുന്നു. ടെസ്റ്റുകൾ പച്ച നിറത്തിൽ (green) കാണിച്ചാൽ ഉൽപ്പന്നം കൃത്യമായി പ്രവർത്തിക്കുന്നു എന്ന് അവർ കരുതി.

അവർക്ക് തെറ്റിപ്പോയി.

കോഡ് പ്രവർത്തിക്കുന്നു എന്നതും ഒരു മനുഷ്യന് അവർക്ക് ആവശ്യമുള്ളത് ലഭിക്കുന്നു എന്നതും രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളാണ്. ഒരു ബട്ടൺ സക്സസ് കോഡ് (success code) നൽകിയേക്കാം, എന്നാൽ അതേസമയം തന്നെ ഉപയോക്താവിനെ ഒരു തകരാറുള്ള സ്ക്രീനിൽ കുടുക്കി കളയാനും അതിന് സാധിക്കും.

ആപ്പ് പ്രവർത്തിപ്പിക്കാതെ തന്നെ ഇത്തരം UX തടസ്സങ്ങൾ (dead-ends) കണ്ടെത്താനുള്ള ഒരു മാർഗ്ഗം ഞാൻ വികസിപ്പിച്ചെടുത്തു. ഇതിനെ ഞാൻ 'ടു-ഏജന്റ് സ്റ്റാറ്റിക് വാക്ക്‌ത്രൂ' (two-agent static walkthrough) എന്ന് വിളിക്കുന്നു. ഇത് പരസ്പരം സംവദിക്കുന്ന രണ്ട് AI ഏജന്റുകളെ ഉപയോഗിക്കുന്നു.

  • ഏജന്റ് A ഉപയോക്താവാണ്. ഈ ഏജന്റിന് ഒരു പ്രത്യേക ലക്ഷ്യമുണ്ട്. ഇത് വാശിയുള്ളതാണ്. ഒരു തെറ്റ് സംഭവിച്ചാൽ ഉടനെ ഇത് പിന്മാറില്ല. വ്യത്യസ്ത വഴികളിലൂടെ ഇത് ശ്രമിച്ചുകൊണ്ടേയിരിക്കും.
  • ഏജന്റ് B ആപ്പാണ്. ഇതിന് യഥാർത്ഥ സോഴ്സ് കോഡിൽ (source code) റീഡ് ആക്സസ് ഉണ്ട്. ഉപയോക്താവിന്റെ ഓരോ പ്രവൃത്തിയുടെയും കോഡ് പാത്ത് (code path) ഇത് പിന്തുടരുന്നു. കോഡ് കൃത്യമായി എന്താണ് ചെയ്യുന്നത് എന്ന് ഇത് റിപ്പോർട്ട് ചെയ്യുന്നു. ഇത് ഫയലും ലൈൻ നമ്പറും സൂചിപ്പിക്കുന്നു. കോഡിൽ ഇല്ലാത്ത കാര്യങ്ങൾ ഇത് സങ്കൽപ്പിക്കില്ല.

തകരാറുള്ള ഒരു AI മിനി-ഗെയിം ജനറേറ്ററിൽ ഞാൻ ഇത് പരീക്ഷിച്ചു. അവിടെ നടന്നത് ഇതാണ്:

ടേൺ 1: ബട്ടൺ പരാജയപ്പെട്ടു. ഉപയോക്താവ് "Generate" ക്ലിക്ക് ചെയ്തു. പുതിയതിന് പകരം കോഡ് പഴയതും പ്രവർത്തനരഹിതവുമായ ഒരു എൻഡ്പോയിന്റിലേക്ക് (endpoint) റിക്വസ്റ്റ് അയച്ചു. പഴയ API ഇപ്പോഴും പ്രവർത്തിക്കുന്നുണ്ടായിരുന്നതിനാൽ ടെസ്റ്റുകൾ പാസായി.

ടേൺ 2: ക്ലിക്ക് ചെയ്യാൻ കഴിയാത്ത ശൂന്യത. ഉപയോക്താവ് റിസൾട്ട് ക്ലിക്ക് ചെയ്യാൻ ശ്രമിച്ചു. കോഡ് ആ ടെക്സ്റ്റ് ഒരു സാധാരണ ബോക്സിനുള്ളിൽ ഇട്ടു, എന്നാൽ അതിൽ ക്ലിക്ക് ഹാൻഡ്‌ലർ (click handler) ഉണ്ടായിരുന്നില്ല. ഒന്നും സംഭവിച്ചില്ല.

ടേൺ 3: വ്യാജമായ സന്തോഷം. ഉപയോക്താവ് പിശക് തിരുത്താൻ ശ്രമിച്ചു. ഒരു ഐഡി (ID) ഇല്ലാത്തതിനാൽ ബാക്കെൻഡ് പരാജയപ്പെട്ടു. സിസ്റ്റം തകരാറിലായെങ്കിലും സ്ക്രീനിൽ പച്ച നിറത്തിലുള്ള സക്സസ് മെസ്സേജ് കാണിച്ചു.

ടേൺ 4: പാതിവഴിയിൽ മുറിഞ്ഞ പ്രതീക്ഷ. ഉപയോക്താവ് കോഡ് നേരിട്ട് കോപ്പി ചെയ്യാൻ ശ്രമിച്ചു. API ടെക്സ്റ്റ് പകുതിയിൽ വെച്ച് മുറിച്ചുമാറ്റി. കോഡ് തകരാറിലായിരുന്നു.

ഉപയോക്താവ് ശ്രമം ഉപേക്ഷിച്ചു.

മിക്ക യൂണിറ്റ് ടെസ്റ്റുകളും ഒരു എൻഡ്പോയിന്റ് 200 നൽകുന്നുണ്ടോ എന്ന് മാത്രമേ പരിശോധിക്കുന്നുള്ളൂ. ഉപയോക്താവ് യഥാർത്ഥത്തിൽ അവരുടെ ലക്ഷ്യത്തിൽ എത്തുന്നുണ്ടോ എന്ന് അവ പരിശോധിക്കുന്നില്ല.

ഇത് എങ്ങനെ ഉപയോഗിക്കാം:

  • യൂസർ ഏജന്റിനെ വാശിയുള്ളതാക്കുക. യഥാർത്ഥ ബഗുകൾ ആദ്യത്തെ തെറ്റിന് പിന്നിൽ ഒളിച്ചിരിക്കുന്നു.
  • ആപ്പ് ഏജന്റിനെ യഥാർത്ഥ കോഡുമായി ബന്ധിപ്പിക്കുക. ഇത് വെറുമൊരു റോൾ-പ്ലേയെ യഥാർത്ഥ ബഗ് റിപ്പോർട്ടാക്കി മാറ്റുന്നു.
  • നിങ്ങളുടെ ടെസ്റ്റുകൾക്ക് ഒരു അനുബന്ധമായി ഇത് ഉപയോഗിക്കുക. നിങ്ങളുടെ ലോജിക് യാഥാർത്ഥ്യവുമായി കൂട്ടിമുട്ടുന്ന ഇടങ്ങളിലെ വിടവുകൾ ഇത് കണ്ടെത്തും.

ഈ രീതി സ്റ്റാറ്റിക് ആണ്, ചിലവ് കുറഞ്ഞതുമാണ്. ഒരു ടെസ്റ്റ് ഫിക്സ്ചർ (test fixture) പോലും എഴുതുന്നതിന് മുമ്പ് തന്നെ ഇത് പ്രവർത്തിപ്പിക്കാം. ഇത് "കോഡ് പ്രവർത്തിക്കുന്നു" എന്നതിനെ "ഉപയോക്താവ് വിജയിക്കുന്നു" എന്നതാക്കി മാറ്റുന്നു.

സ്രോതസ്സ്: https://dev.to/terum/every-test-passed-the-user-still-couldnt-play-the-game-388o

ഓപ്ഷണൽ ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi