AI சோதனைப் பொறியியல் பொறி
"இந்தக் காலாண்டில் 40% அதிக சோதனைகளைச் செய்து முடித்துவிட்டோம்" என்று யாரோ சொல்வதைக் கேட்டு அனைவரும் தலையசைப்பதைப் பார்த்திருப்பீர்கள்.
டோக்கியோவில் உள்ள ஒரு SaaS நிறுவனத்தில் இது நடப்பதைப் பார்த்தேன். QA தலைவர் பெருமிதம் கொண்டார். நிர்வாகம் மகிழ்ச்சியடைந்தது. பைப்லைன் (pipeline) பச்சை நிறத்தில் இருந்தது.
ஆறு வாரங்களுக்குப் பிறகு, ஒரு கட்டண முறைமை (payment system) 72 மணிநேரம் செயலிழந்தது. யாரும் அதை கவனிக்கவில்லை, ஏனெனில் AI "சரியான தரத்தை" சரிபார்க்கும் சோதனைகளுக்குப் பதிலாக "பிழைகள் இல்லை" என்பதை மட்டுமே சரிபார்க்கும் சோதனைகளை எழுதியிருந்தது.
இதுவே சோதனைப் பார்வையின்மை (Testing Blindness).
உங்கள் குழு பல சோதனைகளை உருவாக்குகிறது, ஆனால் அந்தச் சோதனைகள் உங்களை எப்போது ஏமாற்றுகின்றன என்பதை உங்களால் கண்டறிய முடியாதபோது இது நிகழ்கிறது. AI, சோதனைப் பரப்பளவை (test coverage) சோதனையின் தரமாகத் தவறாகக் கருத வழிவகுக்கிறது.
Qiita-வில் உள்ள சமீபத்திய பதிவு இதே போராட்டத்தைக் காட்டுகிறது. ஆட்டோமேஷன் இல்லாத திட்டங்களைக் கையாள ஒரு பொறியாளர் AI-ஐப் பயன்படுத்தினார். சோதனைகள் விரைவாக வந்தன. அளவீடுகள் (metrics) சிறப்பாகத் தெரிந்தன.
ஆனால் அந்தப் பொறியாளர் Playwright மற்றும் API testing-ஐக் கைமுறையாகக் கற்க வேண்டியிருந்தது. ஏன்? ஏனெனில் AI-ஆல் தொடரியலை (syntax) எழுத முடிந்தது, ஆனால் அமைப்பு எவ்வாறு செயல்படுகிறது என்பதைப் புரிந்துகொள்ள முடியவில்லை.
சோதனைப் பார்வையின்மைக்கு (Testing Blindness) மூன்று முக்கிய அறிகுறிகள் உள்ளன:
• Assertion Atrophy: குறியீடு (code) செயலிழக்கிறதா என்பதை மட்டுமே சோதனைகள் சரிபார்க்கின்றனவே தவிர, அது சரியாகச் செயல்படுகிறதா என்பதைச் சரிபார்க்கவில்லை என்பதால் சோதனைகள் வெற்றி பெறுகின்றன. • Boundary Case Blindness: AI "happy paths"-இல் மட்டுமே கவனம் செலுத்துகிறது. null inputs அல்லது race conditions போன்ற விளிம்பு நிலைச் சூழல்களை (edge cases) அது தவறவிடுகிறது. • Regression Confidence Inflation: சோதனை எண்ணிக்கை இரட்டிப்பாகியிருப்பதால் நீங்கள் பாதுகாப்பாக உணர்கிறீர்கள். உண்மையில், உங்கள் தவறான நம்பிக்கையை நீங்கள் இரட்டிப்பாக்கியுள்ளீர்கள்.
எனது அனுபவத்தில், AI-ஐப் பயன்படுத்தி குழுக்கள் சில மாதங்களிலேயே பூஜ்ஜிய சோதனைகளிலிருந்து 1,200 சோதனைகளுக்குச் செல்கின்றன. அறிக்கைகள் மிகச்சரியாகத் தெரிகின்றன. ஆனால் உண்மையான பிழை கண்டறியும் விகிதம் குறைகிறது.
ஜப்பானில், மேலாண்மை மற்றும் செயல்முறை (kanri) மீதான கவனம் இத்தகைய அதிக எண்களை வெற்றியாக உணரச் செய்யலாம். மேற்கத்திய நாடுகளில், AI எளிதாக்குவதால் குழுக்கள் பெரும்பாலும் சோதனைகளைத் தவிர்க்கின்றன. இரண்டு வழிகளும் உற்பத்தித் தோல்விகளுக்கே (production failures) வழிவகுக்கின்றன.
AI அளவீடுகளை மேம்படுத்துகிறது, ஆனால் பிழைகளைத் திருத்தும் (debug) உங்கள் திறனைப் பாதிக்கிறது.
நீங்கள் QA-வில் AI-ஐப் பயன்படுத்தினால், இந்த விதிகளைப் பின்பற்றுங்கள்:
- வாரந்தோறும் சோதனைகளைத் தணிக்கை செய்யுங்கள்: ஏதேனும் 5 AI சோதனைகளைத் தேர்ந்தெடுங்கள். "இந்தச் சோதனை தவறாக வெற்றி பெற எது காரணமாக இருக்கும்?" என்று கேளுங்கள். உங்களால் விரைவாகப் பதிலளிக்க முடியாவிட்டால், உங்களுக்கு ஒரு பார்வையின்மை (blind spot) உள்ளது என்று அர்த்தம்.
- ஒரு எல்லை ஒதுக்கீட்டை (boundary quota) நிர்ணயியுங்கள்: ஒவ்வொரு 10 AI சோதனைகளுக்கும், 2 விளிம்பு நிலைச் சூழல் (edge case) சோதனைகளைத் தாங்களாகவே கைமுறையாக எழுதுங்கள்.
- '3am சோதனை'-ஐப் பயன்படுத்துங்கள்: அதிகாலை 3 மணிக்கு ஒரு தோல்வி ஏற்பட்டால், இந்தச் சோதனைகள் அதைக் கண்டறியுமா என்று கேளுங்கள். உங்களுக்குத் தெரியவில்லை என்றால், அவை போதுமானதாக இல்லை.
- ஒரு தொகுதியை (module) கைமுறையாக வைத்திருங்கள்: ஒரு முக்கியமான பகுதியைத் தாங்களாகவே சோதித்துப் பாருங்கள். இது உங்கள் பிழைத்திருத்தத் திறனைத் கூர்மையாக வைத்திருக்கும்.
சோதனைகளின் எண்ணிக்கையை அதன் தரமாகத் தவறாகக் கருதாதீர்கள். செயல்திறன் உங்கள் தீர்ப்புத் திறனை (judgment) ஆக்கிரமிக்க விடாதீர்கள். உங்களைக் காப்பாற்றுவது நீங்கள் உண்மையில் புரிந்துகொண்ட சோதனைகளே ஆகும்.
AI-ஐப் பயன்படுத்திய பிறகு உங்கள் குழுவின் சோதனைத் தரம் குறைந்துள்ளதா? உங்கள் அனுபவத்தைப் கீழே பகிருங்கள்.
விருப்பத்தேர்வு கற்றல் சமூகம்: https://t.me/GyaanSetuAi