Flaky Tests Are Killing Your CI – Switch From Pass Rates to Failure Trust Metrics

പരാജയങ്ങളെ ആരും വിശ്വസിക്കുന്നില്ലെങ്കിൽ നിങ്ങളുടെ ടെസ്റ്റ് സ്യൂട്ട് (test suite) ഉപയോഗശൂന്യമാണ്. ടീമുകൾ കൂടുതൽ ടെസ്റ്റുകളും, മികച്ച ഡാഷ്‌ബോർഡുകളും, അല്ലെങ്കിൽ പാരലൽ എക്സിക്യൂഷനും (parallel execution) ചേർക്കുന്നുണ്ടെങ്കിലും, ഡെവലപ്പർമാർ ഇപ്പോഴും ആ ചുവന്ന ബോക്സ് (red box) മാറുമെന്ന് പ്രതീക്ഷിച്ചുകൊണ്ട് പൈപ്പ്‌ലൈനുകൾ വീണ്ടും റൺ ചെയ്യുന്നു. ഈ ശീലം ഒരു മൂല്യവത്തായ സൂചനയെ (signal) വെറും ബഹളമായി (noise) മാറ്റുന്നു.

യഥാർത്ഥ പ്രശ്നം വിശ്വാസ്യതയാണ്, കവറേജല്ല

മിക്ക എഞ്ചിനീയറിംഗ് ഗ്രൂപ്പുകളും ടെസ്റ്റുകളുടെ കുറപ്പിനെയോ അപര്യാപ്തമായ ബ്രൗസർ കവറേജിനെയോ ആണ് കുറ്റപ്പെടുത്തുന്നത്. വാസ്തവത്തിൽ, പരാജയങ്ങൾ വെറും ബഹളമായിട്ടാണ് (noise) കണക്കാക്കപ്പെടുന്നത്. ഒരു ഡാഷ്‌ബോർഡിൽ 96% പാസ് റേറ്റ് (pass rate) കാണുന്നത് ആകർഷകമായി തോന്നാം, എന്നാൽ ആ 4% പരാജയങ്ങൾ യഥാർത്ഥ പിഴവുകൾ കണ്ടെത്തിയതാണോ അതോ അവ പുറത്തുവരാൻ പലതവണ റീട്രൈ (retry) ചെയ്യേണ്ടി വന്നതാണോ എന്ന് അത് പറഞ്ഞുതരുന്നില്ല. ഡെവലപ്പർമാർ പരാജയങ്ങളെ അവഗണിക്കുമ്പോൾ, ടെസ്റ്റ് സ്യൂട്ട് തീരുമാനങ്ങളെ സ്വാധീനിക്കാതെ സമയം മാത്രം പാഴാക്കുന്നു.

പാസ് റേറ്റ് (pass rate) എന്തുകൊണ്ട് തെറ്റിദ്ധരിപ്പിക്കാം

പാസ് റേറ്റ് മെട്രിക്സുകൾ എല്ലാ ഫലങ്ങളെയും ഒരു സംഖ്യയിലേക്ക് ചുരുക്കുന്നു, ഇത് രണ്ട് പ്രധാന ചോദ്യങ്ങളെ മറച്ചുവെക്കുന്നു:

• പരാജയങ്ങൾ യഥാർത പിഴവുകൾ വെളിപ്പെടുത്തിയോ? ഒരു ബഗ് (bug) ഒരിക്കലും കണ്ടെത്താത്ത അസ്ഥിരമായ (flaky) ടെസ്റ്റ് യാതൊരു മൂല്യവും നൽകുന്നില്ല.
• എത്ര തവണ റീട്രൈ ചെയ്യേണ്ടി വന്നു? അവസാന പാസ് റേറ്റ് ഉയർന്നതാണെങ്കിൽ പോലും, മൂന്ന് തവണ ഓട്ടോമാറ്റിക് റീട്രൈ ചെയ്ത ശേഷമാണ് ഒരു സ്യൂട്ട് വിജയിക്കുന്നതെങ്കിൽ അത് വിശ്വസനീയമല്ല.

ഒരു ടെസ്റ്റ് സ്യൂട്ട് 99% വിജയം റിപ്പോർട്ട് ചെയ്യുന്നുണ്ടെങ്കിലും ചെക്കൗട്ട് പരാജയങ്ങൾ ആവർത്തിച്ച് വിട്ടുപോകുന്നുണ്ടെങ്കിൽ, അത് 92% വിജയിക്കുന്നതും എന്നാൽ വരുമാനത്തെ ബാധിക്കുന്ന ഓരോ ബഗ്ഗും കണ്ടെത്തുന്നതുമായ ഒരു സ്യൂട്ടിനേക്കാൾ വളരെ മോശമാണ്. ലക്ഷ്യം ഉയർന്ന ശതമാനം നേടുക എന്നതല്ല; മറിച്ച് റിസ്ക് (risk) കൃത്യമായി വിലയിരുത്തുക എന്നതാണ്.

പ്രസക്തമായ മെട്രിക്സുകൾ (Metrics)

പാസ് റേറ്റിന് പകരം സ്യൂട്ടിന്റെ ഉപയോഗപ്രദത പ്രതിഫലിപ്പിക്കുന്ന അളവുകോലുകൾ ഉപയോഗിക്കുക:

• Failure recurrence – ഒരേ ടെസ്റ്റ് തുടർച്ചയായ റണ്ണുകളിൽ എത്ര തവണ പരാജയപ്പെടുന്നു.
• Defect detection rate – പരാജയങ്ങളിൽ എത്ര ശതമാനം സ്ഥിരീകരിച്ച ബഗുകളായി മാറുന്നു.
• Time to diagnosis – പരാജയപ്പെട്ട ഒരു ടെസ്റ്റിന്റെ കാരണം എത്ര വേഗത്തിൽ മനസ്സിലാക്കി നടപടിയെടുക്കാൻ കഴിയും.
• Retry dependence – വിജയിക്കാൻ ഓട്ടോമാറ്റിക് റീറൺ (rerun) ആവശ്യമായി വരുന്ന ടെസ്റ്റുകളുടെ ആവൃത്തി.
• Escaped regressions – സ്യൂട്ട് ഉണ്ടായിരുന്നിട്ടും പിഴവുകൾ സംഭവിക്കുന്നത്.

ഈ സൂചനകൾ നിരീക്ഷിക്കുന്നത് ഒരു പരാജയം നിങ്ങൾ നടപടിയെടുക്കേണ്ട ഒരു മുന്നറിയിപ്പാണോ അതോ വെറുമൊരു അസ്ഥിരതയാണോ (flake) എന്ന് മനസ്സിലാക്കാൻ സഹായിക്കും.

മെയിന്റനൻസിന്റെ (maintenance) മറഞ്ഞിരിക്കുന്ന ചിലവ്

എഴുതാൻ പത്ത് മിനിറ്റ് എടുക്കുന്നതും എന്നാൽ മാസത്തിൽ മൂന്ന് മണിക്കൂർ ശരിയാക്കാൻ വേണ്ടി ചിലവാക്കേണ്ടി വരുന്നതുമായ ഒരു ടെസ്റ്റ് മോശം നിക്ഷേപമാണ്. ടെസ്റ്റുകൾ അസ്ഥിരമാകുമ്പോഴോ, നിരന്തരം ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടി വരുമ്പോഴോ, അല്ലെങ്കിൽ ബ്രൈറ്റിൽ ആയ UI സെലക്ടറുകളെ ആശ്രയിക്കുമ്പോഴോ മെയിന്റനൻസ് ചിലവ് വർദ്ധിക്കുന്നു. AI ഉപയോഗിച്ച് ടെസ്റ്റുകൾ നിർമ്മിക്കുമ്പോൾ ഈ ചിലവ് കൂടുതൽ വ്യക്തമാകും. UI മാറുമ്പോഴെല്ലാം നിർമ്മിച്ച ടെസ്റ്റുകൾ തകരാറിലാകുന്നുണ്ടെങ്കിൽ, അവയുടെ നിർമ്മാണ വേഗത കൊണ്ട് വലിയ പ്രയോജനമില്ല.

AI നിർമ്മിച്ച ടെസ്റ്റുകളെ വിലയിരുത്തുമ്പോൾ ഇവ ചോദിക്കുക:

• ടെസ്റ്റ് എത്ര തവണ മാനുവലായി എഡിറ്റ് ചെയ്യേണ്ടി വരുന്നു?
• അത് പരാജയപ്പെട്ടതിന്റെ കാരണം എത്ര വ്യക്തമായി വിശദീകരിക്കുന്നു?
• പരാജയം പരിഹരിക്കാൻ ഒരു മനുഷ്യന് എത്രത്തോളം വിവരങ്ങൾ (context) ആവശ്യമാണ്?

മറുപടികൾ നിരന്തരമായ മനുഷ്യ ഇടപെടൽ ആവശ്യമാണെന്ന് കാണിക്കുന്നുണ്ടെങ്കിൽ, ഓട്ടോമേഷന്റെ ഗുണം ഇല്ലാതാകുന്നു.

ഒബ്സർവബിലിറ്റി (Observability): പരാജയങ്ങളെ പ്രായോഗികമാക്കുക

വിശകലനം ചെയ്യാൻ നാൽപ്പത് മിനിറ്റ് എടുക്കുന്ന 4,000 വരികളുള്ള ഒരു ലോഗ് (log) ഇല്ലാത്തതിനേക്കാൾ ഉപയോഗശൂന്യമാണ്. നല്ല ഒബ്സർവബിലിറ്റി മൂന്ന് ചോദ്യങ്ങൾക്ക് വേഗത്തിൽ ഉത്തരം നൽകാൻ നിങ്ങളെ സഹായിക്കുന്നു:

• ടെസ്റ്റ് എന്താണ് പ്രതീക്ഷിച്ചത്?
• യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിച്ചത്?
• ഇതിന്റെ മൂലകാരണം (root cause) ഒരു പ്രോഡക്റ്റ് ബഗ്ഗാണോ, ഡാറ്റാ പ്രശ്നമാണോ, അതോ ഇൻഫ്രാസ്ട്രക്ചർ പ്രശ്നമാണോ?

AI ഏജന്റുകളെ ടെസ്റ്റ് ചെയ്യാൻ ആഴത്തിലുള്ള പരിശോധനകൾ ആവശ്യമാണ്

ടെസ്റ്റ് ചെയ്യുന്ന സിസ്റ്റം ഒരു AI-ഡ്രൈവൻ ഏജന്റ് ആണെങ്കിൽ, ഒരു പാസ് ടെസ്റ്റ് പരാജയപ്പെട്ട ഒരു ആന്തരിക പ്രക്രിയയെ മറച്ചുവെച്ചേക്കാം. ഒരു ഏജന്റ് തെറ്റായ ഒരു ഷോർട്ട്കട്ട് ഉപയോഗിച്ചോ, തെറ്റായ ടൂൾ തിരഞ്ഞെടുത്തോ, അല്ലെങ്കിൽ അതിന്റെ മെമ്മറി ശരിയായി അപ്‌ഡേറ്റ് ചെയ്യാത്തതിലൂടെയോ ശരിയായ ഉത്തരം നൽകിയേക്കാം. അതിനാൽ വിശ്വസനീയമായ ടെസ്റ്റിംഗിന് ഇവ പരിശോധിക്കണം:

• Tool selection logic
• Memory update behavior
• Recovery mechanisms after errors

പരാജയ സാഹചര്യങ്ങളിൽ ഒരു ഏജന്റ് പ്രവചിക്കാവുന്ന രീതിയിൽ (predictably) പെരുമാറുമ്പോൾ മാത്രമേ അതിന്റെ ഔട്ട്‌പുട്ട് വിശ്വസിക്കാൻ കഴിയൂ.

ടെസ്റ്റ് മെയിന്റനൻസ് ഒരു പ്രോഡക്റ്റ് ജോലിയായി കാണുക

അസ്ഥിരമായ ടെസ്റ്റുകളെ മറ്റ് കോഡുകളെപ്പോലെ തന്നെ കൃത്യതയോടെ കൈകാര്യം ചെയ്യുക:

• ബിസിനസ് മൂല്യം ഇല്ലാത്ത ടെസ്റ്റുകൾ ഒഴിവാക്കുക.
• നിരന്തരം റീട്രൈ ചെയ്യേണ്ടി വരുന്ന ടെസ്റ്റുകൾ റിവ്യൂ ചെയ്യുകയും റീഫാക്ടർ (refactor) ചെയ്യുകയും ചെയ്യുക.
• ടെസ്റ്റ് ഡാറ്റ തകരുന്നതിന് മുമ്പ് തന്നെ അത് പ്രോആക്റ്റീവ് ആയി അപ്‌ഡേറ്റ് ചെയ്യുക.
• അസ്ഥിരമായതോ ഉയർന്ന റിസ്കുള്ളതോ ആയ മേഖലകൾക്കായി വ്യക്തമായ ഉത്തരവാദിത്തം നിശ്ചയിക്കുക.

ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

AI നിർമ്മിച്ച ടെസ്റ്റ് ടൂളുകളെ ശ്രദ്ധിക്കുക: അവയുടെ മൂല്യം അളക്കേണ്ടത് ടെസ്റ്റുകളുടെ എണ്ണം കൊണ്ടല്ല, മറിച്ച് മാനുവൽ എഡിറ്റിംഗിലെ കുറവ് കൊണ്ടും പരാജയങ്ങൾ വ്യക്തമായി വിശദീകരിക്കുന്നതിനാലുമാണ്.

ചുരുക്കം (Takeaway)

ഓരോ ഉപയോഗപ്രദമായ പരാജയത്തിലൂടെയും ഒരു ടെസ്റ്റ് സ്യൂട്ട് വിശ്വാസ്യത നേടുന്നു. പരാജയങ്ങൾ ഉപയോഗപ്രദമല്ലാതാകുമ്പോൾ, കൂടുതൽ ടെസ്റ്റുകൾ ചേർക്കുന്നത് പ്രശ്നം വർദ്ധിപ്പിക്കുകയേ ഉള്ളൂ. തിളക്കമുള്ള പാസ് ശതമാനങ്ങളിൽ നിന്ന് റിസ്ക് അടിസ്ഥാനമാക്കിയുള്ള മെട്രിക്സുകളിലേക്ക് ശ്രദ്ധ മാറ്റുക, ഒബ്സർവബിലിറ്റിയിൽ നിക്ഷേപിക്കുക, ടെസ്റ്റ് പരിപാലനം ഒരു പ്രധാന പ്രോഡക്റ്റ് പ്രവർത്തനമായി കാണുക. ഇതിന്റെ ഫലമായി, ടീമിനെ ബഹളങ്ങളിൽ മുക്കിക്കളയുന്നതിന് പകരം തീരുമാനങ്ങളെ ശരിയായി നയിക്കുന്ന കൂടുതൽ കാര്യക്ഷമവും വിശ്വസനീയവുമായ ഒരു ഓട്ടോമേഷൻ ലെയർ നിങ്ങൾക്ക് ലഭിക്കും.