உங்கள் சோதனைத் தொகுப்பின் (test suite) தோல்விகளை யாரும் நம்பவில்லை என்றால், அது பயனற்றது. குழுக்கள் அதிக சோதனைகளையும், விரிவான டேஷ்போர்டுகளையும் அல்லது இணையாகச் செயல்படும் (parallel execution) முறைகளையும் சேர்க்கிறார்கள், இருப்பினும் டெவலப்பர்கள் அந்தச் சிவப்பு நிறப் பெட்டி (red box) மறைந்துவிடுமா என்ற நம்பிக்கையில் மீண்டும் மீண்டும் పైப்லைன்களை (pipelines) இயக்குகிறார்கள். அந்தப் பழக்கம், ஒரு மதிப்புமிக்கத் தகவலைத் தேவையற்ற இரைச்சலாக (noise) மாற்றிவிடுகிறது.
உண்மையான பிரச்சனை நம்பிக்கையே தவிர, கவரேஜ் (coverage) அல்ல
பெரும்பாலான பொறியியல் குழுக்கள் சோதனைகளின் பற்றாக்குறை அல்லது போதுமான பிரவுசர் கவரேஜ் இல்லை என்று குற்றம் சாட்டுகின்றன. உண்மையில், தோல்விகள் வெறும் இரைச்சலாகவே கருதப்படுகின்றன. ஒரு டேஷ்போர்டில் 96% வெற்றி விகிதம் (pass rate) பார்ப்பதற்குத் திகைப்பூட்டலாம், ஆனால் அந்த 4% தோல்விகள் உண்மையான குறைபாடுகளைக் கண்டறிந்ததா அல்லது அவை வெளிப்பட பலமுறை மீண்டும் முயற்சிக்க வேண்டியிருந்ததா என்பதை அது உங்களுக்குச் சொல்லாது. டெவலப்பர்கள் தோல்விகளைப் புறக்கணிக்கும்போது, அந்தச் சோதனைத் தொகுப்பு முடிவுகளைப் பாதிக்காமல் நேரத்தையும் கணினி வளங்களையும் (compute resources) மட்டுமே நுகர்கிறது.
வெற்றி விகிதங்கள் ஏன் தவறாக வழிநடத்தலாம்
வெற்றி விகித அளவீடுகள் அனைத்து முடிவுகளையும் ஒரே எண்ணாகச் சுருக்குகின்றன, இது இரண்டு முக்கியமான கேள்விகளை மறைக்கிறது:
- தோல்விகள் உண்மையான குறைபாடுகளை வெளிப்படுத்தினவா? ஒரு பிழையைக் கண்டறியாத நிலையற்ற சோதனை (flaky test) எந்த மதிப்பையும் சேர்க்காது.
- எத்தனை முறை மீண்டும் முயற்சிக்க வேண்டியிருந்தது? இறுதி வெற்றி விகிதம் அதிகமாக இருந்தாலும், மூன்று முறை தானியங்கி மறுமுயற்சிகளுக்குப் பிறகு வெற்றி பெறும் ஒரு சோதனைத் தொகுப்பு நம்பகமானது அல்ல.
99% வெற்றியைப் புகாரளித்துவிட்டு, செக்அவுட் (checkout) தோல்விகளைத் திரும்பத் திரும்பத் தவறவிடுகின்ற ஒரு சோதனைத் தொகுப்பை விட, 92% வெற்றி பெற்று ஒவ்வொரு வருவாய் பாதிக்கும் பிழையையும் கண்டறிந்துவிடும் ஒரு சோதனைத் தொகுப்பு மிகவும் சிறந்தது. இலக்கு என்பது ஒரு உயர்ந்த சதவீதத்தைப் பெறுவதல்ல; அது இடர்களைப் (risk) பற்றிய சிறந்தத் தீர்ப்பாகும்.
முக்கியமான அளவீடுகள்
வெற்றி விகிதக் கவனத்திற்குப் பதிலாக, சோதனைத் தொகுப்பின் பயனுள்ள தன்மையைப் பிரதிபலிக்கும் அளவீடுகளைப் பயன்படுத்துங்கள்:
- தோல்வியின் மீண்டும் நிகழும் தன்மை (Failure recurrence) – அடுத்தடுத்த ஓட்டுகளில் ஒரே சோதனை எவ்வளவு அடிக்கடி தோல்வியடைகிறது.
- குறைபாட்டைக் கண்டறியும் விகிதம் (Defect detection rate) – தோல்விகளில் எத்தனை உண்மையான பிழைகளாக உறுதி செய்யப்படுகின்றன என்பதன் விகிதம்.
- கண்டறியும் நேரம் (Time to diagnosis) – ஒரு தோல்வியுற்ற சோதனையை எவ்வளவு விரைவாகப் புரிந்துகொண்டு நடவடிக்கை எடுக்க முடிகிறது.
- மறுமுயற்சிச் சார்பு (Retry dependence) – வெற்றி பெறத் தானியங்கி மறுமுயற்சிகள் தேவைப்படும் சோதனைகளின் அதிர்வெண்.
- தப்பிச் சென்ற பின்னடைவுகள் (Escaped regressions) – சோதனைத் தொகுப்பு இருந்தபோதிலும் தப்பிச் செல்லும் குறைபாடுகள்.
இந்தத் தகவல்களைக் கண்காணிப்பதன் மூலம், ஒரு தோல்வி நீங்கள் நடவடிக்கை எடுக்க வேண்டிய எச்சரிக்கையா அல்லது வெறும் நிலையற்ற பிழையா (flake) என்பதை நீங்கள் அறியலாம்.
பராமரிப்பின் மறைமுகச் செலவு
எழுத பத்து நிமிடங்கள் எடுக்கும் ஆனால் சரிசெய்ய மாதம் மூன்று மணிநேரம் எடுக்கும் ஒரு சோதனை, ஒரு மோசமான முதலீடு ஆகும். சோதனைகள் நிலையற்றதாக இருக்கும்போது, தொடர்ச்சியான தரவுப் புதுப்பிப்புகள் தேவைப்படும்போது அல்லது எளிதில் உடையக்கூடிய UI selectors-ஐச் சார்ந்திருக்கும்போது பராமரிப்புச் செலவு அதிகரிக்கிறது. AI மூலம் சோதனைகள் உருவாக்கப்படும்போது இந்தச் செலவு இன்னும் அதிகமாகத் தெரியும். UI மாற마다 உருவாக்கப்பட்ட சோதனைகள் உடைந்து போனால், அவை எவ்வளவு வேகமாக உருவாக்கப்படுகின்றன என்பது முக்கியமல்ல.
AI மூலம் உருவாக்கப்பட்ட சோதனைகளை மதிப்பீடு செய்யும்போது, இதைக் கேளுங்கள்:
- சோதனை எவ்வளவு அடிக்கடி கைமுறைத் திருத்தங்களை (manual editing) எதிர்பார்க்கிறது?
- அது ஏன் தோல்வியடைந்தது என்பதை எவ்வளவு தெளிவாக விளக்குகிறது?
- அந்தத் தோல்வியைச் சரிசெய்ய ஒரு மனிதனுக்கு எவ்வளவு சூழல் அறிவு (context) தேவைப்படுகிறது?
பதில்கள் அடிக்கடி மனிதத் தலையீட்டைச் சுட்டிக்காட்டினால், அந்தத் தானியங்கிச் செயல்பாட்டின் பலன் மறைந்துவிடும்.
கவனிப்புத் திறன் (Observability): தோல்விகளைச் செயல்படுத்தக்கூடியதாக மாற்றுதல்
பகுப்பாய்வு செய்ய நாற்பது நிமிடங்கள் எடுக்கும் 4,000 வரிகள் கொண்ட ஒரு லாக் (log) கோப்பு, லாக் இல்லையென்றே வைத்துக்கொள்ளலாம். சிறந்த கவனிப்புத் திறன் (observability) மூன்று கேள்விகளுக்கு விரைவாகப் பதிலளிக்க உதவும்:
- சோதனை எதை எதிர்பார்த்தது?
- உண்மையில் என்ன நடந்தது?
- மூலக் காரணம் ஒரு தயாரிப்புப் பிழையா, தரவுப் பிரச்சனையா அல்லது உள்கட்டமைப்புப் பிரச்சனையா?
AI ஏஜெண்டுகளைச் சோதிக்க ஆழமான சரிபார்ப்புகள் தேவை
சோதனை செய்யப்படும் அமைப்பு ஒரு AI-இயக்கப்படும் ஏஜெண்டாக இருக்கும்போது, ஒரு வெற்றிபெற்ற சோதனை அதன் உட்புறச் செயல்முறை முறிந்துவிட்டதை மறைக்கக்கூடும். ஒரு ஏஜென்ட் தவறான குறுக்குவழியைப் பயன்படுத்துவதன் மூலமோ, தவறான கருவியைத் தேர்ந்தெடுப்பதன் மூலமோ அல்லது அதன் நினைவகத்தை (memory) சரியாகப் புதுப்பிக்கத் தவறுவதன் மூலமோ சரியான விடையைப் பெறலாம். எனவே, நம்பகமான சோதனை பின்வருவனவற்றை ஆராய வேண்டும்:
- கருவித் தேர்வு தர்க்கம் (Tool selection logic)
- நினைவகப் புதுப்பித்தல் நடத்தை (Memory update behavior)
- பிழைகளுக்குப் பிந்தைய மீட்பு வழிமுறைகள் (Recovery mechanisms)
தோல்விச் சூழல்களில் ஒரு ஏஜென்ட் கணிக்கக்கூடிய வகையில் செயல்படும்போது மட்டுமே அதன் வெளியீட்டை நம்ப முடியும்.
சோதனைப் பராமரிப்பை ஒரு தயாரிப்புப் பணியாகக் கருதுங்கள்
நிலையற்ற சோதனைகளை மற்ற குறியீடுகளைப் போலவே அதே கண்டிப்புடன் கையாளவும்:
- வணிக மதிப்பைப் பெறாத சோதனைகளை நீக்கவும்.
- அடிக்கடி மறுமுயற்சிகள் தேவைப்படும் சோதனைகளை மறுசீரமைக்கவும் (refactor).
- தரவு உடைவதற்கு முன்பே சோதனைத் தரவை முன்கூட்டியே புதுப்பிக்கவும்.
- நிலையற்ற அல்லது அதிக ஆபத்துள்ள பகுதிகளுக்குத் தெளிவான பொறுப்பினை (ownership) ஒப்படைக்கவும்.
அடுத்து கவனிக்க வேண்டியவை
AI மூலம் உருவாக்கப்பட்ட சோதனை கருவிகளைக் கவனியுங்கள்: அவற்றின் மதிப்பு சோதனைகளின் எண்ணிக்கையால் அல்லாமல், கைமுறைத் திருத்தங்களின் குறைப்பால் மற்றும் தெளிவான தோல்வி விளக்கங்களால் தீர்மானிக்கப்படும்.
சுருக்கம்
ஒரு சோதனைத் தொகுப்பு ஒவ்வொரு பயனுள்ள தோல்வி மூலமாகவும் நம்பிக்கையைப் பெறுகிறது. தோல்விகள் பயனுள்ளதாக இருக்காதபோது, அதிக சோதனைகளைச் சேர்ப்பது சிக்கலைத் தீவிரப்படுத்தும். பளபளப்பான வெற்றி சதவீதங்களிலிருந்து, உறுதியான இடர் சார்ந்த அளவீடுகளுக்குக் கவனத்தை மாற்றவும், கவனிப்புத் திறனில் (observability) முதலீடு செய்யவும், மற்றும் சோதனைப் பராமரிப்பை ஒரு முக்கியத் தயாரிப்புப் பணியாகக் கருதவும். இதன் விளைவாக, குழுவை இரைச்சலில் மூழ்கடிக்காமல், முடிவுகளைத் துல்லியமாக வழிநடத்தும் ஒரு மெலிதான மற்றும் நம்பகமான தானியங்கி அடுக்கு கிடைக்கும்.