டெஸ்டர்கள் மென்பொருள் சோதனைக்கு ஆயத்தமாகிக் கொண்டிருந்த வேளையில் (அதாவது, டெஸ்டர்கள் டெஸ்ட் கேஸ் எழுதிய போதும் அதற்கு முன்பும்) உருவாக்குநர்கள் (டெவலப்பர்கள்) என்ன செய்து கொண்டு இருந்திருப்பார்கள் என்று உங்களால் ஊகிக்க முடிகிறதா? சரியாகச் சொன்னீர்கள் – மென்பொருளை உருவாக்கிக் கொண்டிருப்பார்கள். அவர்கள் வேலையே அது தானே! ஆனால் மென்பொருளை உருவாக்குவதோடு உருவாக்குநர்களின் வேலை முடிந்து விடுவதில்லை! மென்பொருளை முதல் நிலையில் சோதிப்பதும் அவர்கள் வேலை தான்!
என்ன குழப்புகிறீர்கள்? மென்பொருளை உருவாக்குவதால் ‘உருவாக்குநர்கள் (டெவலப்பர்கள்)’ என்கிறீர்கள். பிறகு, சோதிப்பதும் அவர்கள் தாம் என்று சொல்லிச் சோதிக்கிறீர்களே என்கிறீர்களா? குழப்பம் வேண்டாம்! மென்பொருள் இல்லாமல் வேறு ஏதாவது ஓர் எடுத்துக்காட்டு மூலம் இதைப் பார்ப்போம் – புரிந்து விடும்.
நண்பருக்கு விருந்தும் அம்மாவின் சோதனையும்:
நண்பர் ஒருவரை வீட்டிற்கு விருந்திற்குக் கூப்பிட்டிருக்கிறோம் என்று வைத்துக் கொள்ளுங்கள். நம்முடைய அம்மா விருந்தைச் சமைக்கிறார்கள்; இங்கு, நண்பர் தாம் வாடிக்கையாளர், அம்மா தான் உருவாக்குநர். விருந்தில், சோறு, குழம்பு, கூட்டு, பொரியல், வடை, அப்பளம், பாயாசம் எனப் பல உணவுவகைகளை அம்மா உருவாக்க வேண்டும். இப்போது அம்மா – குழம்பு வைத்து முடித்து விட்டார்கள். குழம்பு நன்றாகக் கொதி வந்து அடுப்பில் இருந்து இறக்கி வைக்கும்போது, அம்மா இரண்டு சொட்டு கரண்டியில் எடுத்துச் சுவைத்துப் பார்ப்பார்கள் அல்லவா – உப்பு, உறைப்பு எல்லாம் சரியாக இருக்கிறதா என்று! இது தான் முதல் நிலை சோதனை! அதாவது உருவாக்குநரே தாம் உருவாக்கியுள்ள பொருள் சரியாக இருக்கிறதா என்று சோதித்துப் பார்ப்பது! இங்கு அம்மா எல்லா வகை உணவையும் சமைத்த பின்னர் தனித்தனியாகச் சோதித்துப் பார்ப்பார்கள்! இப்படி ஒவ்வோர் உருப்படியாகச் சோதிப்பதைத் தான் ‘தனி உருப்படிச் சோதனை‘ என்றோ ‘அலகுச் சோதனை‘ என்றோ சொல்கிறார்கள். ஆங்கிலத்தில் இச்சோதனைக்கு ‘யூனிட் டெஸ்டிங்‘ என்று பெயர்.
இச்சோதனையைச் செய்ய, ஜேயூனிட் (junit.org/ ) போன்ற கட்டற்ற வடிவமைப்பு மென்பொருட்கள் பயன்படுத்தப்படுகின்றன. இப்படியாக, அலகுச் சோதனையை முடித்த பிறகு இணைப்புச் சோதனையைச் செய்வார்கள். அதென்ன இணைப்புச் சோதனை? பார்த்து விடுவோம்!
இரு சக்கர வண்டியும் இணைப்புச் சோதனையும்:
ஒரு பெரிய இருசக்கர வண்டிகள் தயாரிக்கும் நிறுவனம். அந்நிறுவனத்தின் ஒவ்வோரு துறையிலும் ஒவ்வொரு பாகத்தைத் தயாரிக்கிறார்கள். ஒரு துறையில் சக்கரங்கள், ஒரு துறையில் வேகமானி (ஸ்பீடோமீட்டர்), மற்றொரு துறையில் இருக்கைகள் இப்படி! நாம் மேலே பார்த்தது போல, ஒவ்வொரு துறை வல்லுநர்களும் தத்தம் உருவாக்கிய பாகத்தை ‘யூனிட் டெஸ்டிங்‘ செய்வார்கள்.
யூனிட் டெஸ்டிங் என்பது தனித்தனியே ஒவ்வொரு பாகமும் சரியாக இயங்குகிறதா? என்று சோதிப்பதாகும். சில அல்லது பல சமயங்களில் ஒவ்வொரு பாகமும் தனித்தனியே சரியாக இயங்கும்; அவற்றை மற்ற பாகங்களுடன் சேர்க்கும் போது சரிவர இயங்காமல் போகும். அதாவது, சக்கரம் தனியாக எந்தவிதச் சிக்கலும் இல்லாமல் சுழலும்; வேகமானி தனியாக சரியாக இயங்கும். ஆனால் இவை இரண்டையும் இணைக்கும் போது, சக்கரத்தின் வேகத்திற்கேற்ப வேகமானியின் முள் இருக்க வேண்டும். இந்த இணைப்பு சரியாக இருக்கிறதா என்று பார்ப்பது தான் இணைப்புச் சோதனையாகும். இதை ஆங்கிலத்தில் ‘இன்டக்ரேஷன் டெஸ்டிங்‘ (Intergration Testing) என்று சொல்வார்கள்.
- இணைப்புச் சோதனையை யார் செய்வார்கள்?
இணைப்புச் சோதனை மற்ற சோதனைகளைப் போல டெஸ்டர்களால் செய்யப்படும் ஒரு சோதனையாகும்.
- இணைப்புச் சோதனையை ஏன் உருவாக்குநர்களே செய்யக்கூடாது?
நல்ல கேள்வி! பொது நிலையில், உருவாக்குநர்களுக்குத் தத்தம் உருவாக்கிய பாகத்தைப் பற்றிய அறிவும் பட்டறிவும் இருக்குமே தவிர, பிற பாகங்களைப் பற்றி அவர்கள் தெரிந்து வைத்திருப்பார்கள் என்று சொல்வது சரியாக அமையாது. சக்கரத்தை உருவாக்குபவருக்கு வேகமானி பற்றிய அறிவும் பட்டறிவும் இருக்க வேண்டும் என்று எதிர்பார்ப்பது நடைமுறைக்கு ஒத்து வராது. அதே நேரத்தில் டெஸ்டர்களுக்கு இவை இரண்டும் இணைந்து இப்படித்தான் வேலை செய்யும் என்பது பற்றிய தெளிவு ஓரளவு இருக்கும் என்பதால் இணைப்புச் சோதனையை டெஸ்டர்கள் செய்வது தான் சரியாக இருக்கும்.
-
இரு வேறு பாகங்களை இணைக்கும் போது, சில நேரங்களில் ஒரு பாகம் மட்டும் சோதனைக்குத் தயாராகி, மற்றொரு பாகம் தயாராகவில்லை எனில் என்ன செய்வார்கள்? அதாவது, வேகமானி கையில் தயாராக இருக்கிறது, ஆனால் இன்னும் சக்கரம் வந்து சேரவில்லை என்று வைத்துக் கொள்ளுங்கள். அந்த நேரத்தில் இணைப்புச் சோதனையைச் செய்வது எப்படி?
இது போன்ற நேரத்தில் எந்த பாகம் இன்னும் உருவாகவில்லையோ அந்தப் பாகத்தைப் போலவே ஒரு போலி மென்பொருளைத் தற்காலிகமாக உருவாக்குவார்கள். அந்தப் போலி மென்பொருளை வைத்து சோதனையை நடத்துவார்கள். ஓர் எளிய எடுத்துக்காட்டு மூலம் இதை விளக்கலாம்.
நீங்கள் ஒரு மாணவன் கல்லூரியில் எட்டுப் பருவங்களிலும் எடுத்த மதிப்பெண்களைக் கூட்டிச் சொல்வதற்குரிய ஒரு மென்பொருளைச் (மென்பொருள் ‘அ‘) சோதிக்கிறீர்கள் என்று வைத்துக் கொள்வோம். இந்த மென்பொருளுக்கு இன்னொரு மென்பொருள் (‘ஆ‘) அதே மாணவன் ஒவ்வொரு பருவத்திலும் எடுத்த மதிப்பெண்களைக் கூட்டிச் சொல்லும் வேலையைச் செய்கிறது. ஆக, மென்பொருள் ‘ஆ‘ உருவான பிறகு தான் மென்பொருள் ‘அ‘ வை நம்மால் சோதிக்க முடியும்.
ஸ்டப் (‘Stub’)
ஆனால், விதிவசத்தில் மென்பொருள் ‘அ‘ முன்னதாகவே உருவாக்கப்பட்டு விடுகிறது. இப்போது சோதனையைச் செய்ய (அதாவது மென்பொருள் ‘அ‘விற்கு மதிப்பெண்களைக் கொடுக்க) மென்பொருள் ‘ஆ‘ நமக்கு வேண்டும் – ஆனால் கையில் இல்லை. இந்த நிலையில் தான் மென்பொருள் ‘ஆ‘ வைப் போலவே ஒரு தற்காலிகப் போலி மென்பொருளை உருவாக்கிச் சோதனையைச் செய்வார்கள். இந்த இடத்தில் மென்பொருள் ‘ஆ‘வை நம்பித் தான் மென்பொருள் ‘அ‘ இருக்கிறது. மென்பொருள் ‘ஆ‘விற்காக உருவாக்கப்படும் தற்காலிகப் போலி மென்பொருளை ஆங்கிலத்தில் ‘ஸ்டப்‘ (Stub) என்று சொல்வார்கள்.
டிரைவர்(‘Driver’)
மேல் சொன்ன அதே எடுத்துக்காட்டில், மென்பொருள் ‘ஆ‘ ஆயத்த நிலையில் இருந்து மென்பொருள் ‘அ‘ இன்னும் உருவாக்கப்படவில்லை என்று வைத்துக் கொள்ளுங்கள். அப்போது மென்பொருள் ‘அ‘விற்கு மாற்றாகத் தற்காலிகப் போலி மென்பொருள் ஒன்றை உருவாக்குவார்கள். அதை ‘டிரைவர்‘ என்று சொல்வார்கள்.
போலி என்றவுடன் தவறான எண்ணத்தில் பார்த்து விடாதீர்கள். உண்மையான மென்பொருளைப் போலவே இருப்பதால் அதைப் போலி என்கிறோம். அவ்வளவுதான்!
-
சரி, இந்த ‘ஸ்டப்‘, ‘டிரைவர்‘ ஆகியவற்றைத் ‘தற்காலிக‘ மென்பொருள் என்று சொல்கிறீர்களே! ஏன்?
உண்மையான மென்பொருளுக்கு மாற்றாக, அந்தந்த நேரத்தில் சோதனையை(டெஸ்டிங்கை) நடத்திப் பார்க்க வேண்டும் என்பதற்காக உருவாக்கப்படும் ஸ்டப், டிரைவர் ஆகிய போலி மென்பொருட்கள் உண்மையான மென்பொருட்கள் உருவாக்கப்பட்டவுடன் அழிக்கப்பட்டு விடும். அவற்றின் தேவை சோதனையை நடத்திவிட வேண்டும் என்பதற்கான தற்காலிகத் தேவையே! எனவே தான் அவற்றைத் தற்காலிக மென்பொருள் என்று சொல்கிறோம்.
இதுவரை அலகுச் சோதனையைப் பற்றியும், இணைப்புச் சோதனையைப் பற்றியும் ஓரளவு பார்த்து விட்டோம். இனிமேல் தான் முழுமையான சோதனையைப் பார்க்கப் போகிறோம். அடுத்த பதிவில் அதைப் பற்றிப் பேசுவோம்.
– முத்து (muthu@payilagam.com )
தொடரின் பிற பகுதிகள் இங்கே www.kaniyam.com/category/software-testing/
