அலகுச்(தனி உருப்படி) சோதனையை உருவாக்குநர் முடித்து, இணைப்புச் சோதனையை டெஸ்டர்கள் முடித்திருக்கிறார்கள். ஒவ்வோர் உருப்படியையும் உருவாக்கி அந்த உருப்படிகளை மற்ற உருப்படிகளுடன் சரிவர இணைந்து இயங்குகின்றனவா என்று இது வரை பார்த்திருக்கிறோம். ஜிமெயில், யாஹூ மெயில் போல, மின்னஞ்சல் சேவை கொடுக்கும் மென்பொருள் ஒன்றை நம்முடைய நிறுவனம் உருவாக்கிக் கொண்டிருக்கிறது என்று வைத்துக் கொள்ளுங்கள். இங்கு,
-
மின்னஞ்சல் நுழைவுப் பக்கம் (லாகின் பக்கம்)
-
உள்பெட்டி (இன்பாக்ஸ்)
-
வெளிப்பெட்டி (சென்ட் ஐடெம்)
-
தொடர்புகள்
என ஒவ்வோர் உருப்படியையும் மற்ற உருப்படிகளுடன் இணைத்துச் சோதிக்க வேண்டும். எடுத்துக்காட்டாக, நுழைவுப்பக்கத்தில் எந்தப் பெயர், கடவுச்சொல் கொடுக்கிறோமோ – அந்தத் தகவலுக்கேற்ற உள்பெட்டியைக் காட்ட வேண்டும். குப்பனின் பெயரையும் கடவுச்சொல்லையும் கொடுத்தால் சுப்பனின் உள்பெட்டியைக் காட்டக் கூடாது. இதைத் தான் இணைப்புச் சோதனையில் சரிபார்க்கிறோம்.
ஆனால் இணைப்புச் சோதனை மட்டுமே முழுமையான சோதனையாகி விடாது அல்லவா? எனவே, மொத்த மென்பொருளையும் ஒரு முறை முழுமையாகச் சோதிக்க வேண்டும். அதைத் தான் முழுமைச் சோதனை என்கிறார்கள். (ஆங்கிலத்தில் இதை ‘ரெக்ரெசன் டெஸ்டிங்‘ Regression Testing என்பார்கள்.)
உருவாக்குநர்கள் அனைவரும் இணைந்து மொத்த மென்பொருளையும் உருவாக்கிய பிறகு, மென்பொருள் முழுமையையும் மொத்தமாகச் சோதிக்க வேண்டும். இந்தச் சோதனை, உண்மையான ஒரு வாடிக்கையாளர் மென்பொருளை எப்படிக் கையாள்வாரோ, அதே அடிப்படையில் இருக்க வேண்டும். அதாவது, மேல் சொன்ன மின்னஞ்சல் நுழைவுப்பக்கத்தை எடுத்துக்காட்டுக்கு எடுத்துக்கொள்ளுங்கள்.
பயனர்கள்,
- முதல் முறையிலேயே சரியான பயனர் பெயர், கடவுச்சொல் கொடுத்து நுழையலாம்
- முதல் முறையில் சரியான பயனர் பெயரையும் தவறான கடவுச்சொல்லையும் கொடுக்கலாம்
- முதல் முறை – தவறான பயனர் பெயரை உள்ளிடலாம்.
- பயனர் பெயர், கடவுச்சொல் – இரண்டையுமே பயனர் தவறாகக் கொடுக்கலாம்.
இப்படியாக ஒவ்வொரு பயனரும் ஒவ்வொரு விதமாகச் செயல்படலாம். ஆனால், பயனர் எப்படிச் செயல்பட்டாலும், அந்தச் செயல்பாட்டிற்குப் பொருத்தமான பதிலை மென்பொருள் கொடுக்க வேண்டும். அதாவது,
- சரியான பயனர் பெயர், கடவுச்சொல்லிற்கு, நுழைவிற்கு அடுத்த இன்பாக்ஸ் பக்கத்தைக் காட்டுவது
- தவறான கடவுச்சொல்லிற்கோ, தவறானபயனர் பெயருக்கோ ‘பயனர் பெயர் / கடவுச்சொல் தவறு‘ எனச் செய்தி காட்டுவது
என்பன போன்ற பொருத்தமான பதில்களை கொடுக்க வேண்டும்.
ஒரு டெஸ்டராக, மேல் சொன்ன எல்லாவகைகளிலும் உருவாக்கப்பட்டுள்ள மென்பொருள் சரியாக இயங்குகிறதா என்பதைச் சோதிக்க வேண்டும். ஐயயோ! எல்லா வகைகளையும் எப்படி நினைவில் வைத்திருப்பது? ஏதாவது ஒரு வகையை மறந்து விட்டால் என்ன செய்வது? என்று கவலைப்படுகிறீர்களா? கவலையே வேண்டாம்! இந்தக் கவலையைப் போக்குவதற்குத் தான் முன்னரே எல்லாவகைகளையும் உள்ளடக்கி டெஸ்ட் கேஸ்களை எழுதி வைத்திருக்கிறோம். (பார்க்க: www.kaniyam.com/software-testing-8-write-test-case/ )
இப்போது நம்முடைய வேலை, அந்த டெஸ்ட் கேஸ்களை ஒவ்வொன்றாக எடுத்து மென்பொருள் மீது செயல்படுத்திப் பார்ப்பது தான்! இப்படிச் செயல்படுத்துவதில் அணியில் யார் யார் எந்தெந்த டெஸ்ட் கேஸ்களைச் செயல்படுத்த வேண்டும் என்பதை டெஸ்டிங் அணித்தலைவர் தீர்மானித்துப் பிரித்துக் கொடுப்பார். இப்படி டெஸ்ட் கேஸ்களைச் செயல்படுத்தி, வரும் முடிவுகளை ‘உண்மையான முடிவு‘ என்பதில் பதிந்து வைக்க வேண்டும். எதிர்பார்க்கும் முடிவுகளும் உண்மையான முடிவுகளும் பொருந்தி வரும் டெஸ்ட் கேஸ்களை தேறிய டெஸ்ட் கேஸ்களாகவும், பொருந்தாத டெஸ்ட் கேஸ்களைத் தோல்வியடைந்த அல்லது தேறாத டெஸ்ட் கேஸ்களாகவும் எடுத்துக் கொள்ளலாம். இப்படித் தேறாத டெஸ்ட் கேஸ்கள் எல்லாம் நமக்கு உணர்த்தும் செய்தி ஒன்று தான் – வாடிக்கையாளர் எதிர்பார்க்கும் முடிவை நம்முடைய உருவாக்குநர்கள் உருவாக்கியிருக்கும் மென்பொருள் கொடுக்கவில்லை என்பது தான்!
இப்படித் தேறாத டெஸ்ட் கேஸ்களை உருவாக்குநர்களிடம் முறைப்படி அவ்வப்போது தெரியப்படுத்தி விட வேண்டும். அப்போது தான், அவர்கள் உடனுக்குடன் உட்கார்ந்து தவறுகளைத் திருத்தி மீண்டும் சோதிப்பதற்கு நம்மிடம் கொடுப்பார்கள்.
-
தேறாத டெஸ்ட் கேஸ்களை உருவாக்குநர்களிடம் கொடுக்க வேண்டும் என்றால், எந்த உருவாக்குநர் மென்பொருளின் எந்தப் பகுதியை உருவாக்கினார் என்பது தெரிய வேண்டுமே! அதைத் தெரிந்து கொள்ள முடியுமா?
-
அப்படித் தெரிந்து கொண்டாலும் ஒருவேளை அந்த உருவாக்குநர் விடுப்பில் இருந்தாலோ, வேறு திட்டப்பணிக்கு மாற்றப்பட்டிருந்தாலோ, வேறு நிறுவனத்திற்குப் போய் விட்டாலோ தேறாத பகுதிகளை எப்படித் தெரிவிப்பது?
-
உருவாக்குநர்களிடம் தெரிவிப்பது என்றால் எப்படி – சொல்வது மூலமா? அல்லது மின்னஞ்சல் அனுப்ப வேண்டுமா? இல்லை மென்பொருளில் உள்ள தவறுகளைத் தெரிவிப்பதற்கென்று தனியாக மென்பொருட்கள் உள்ளனவா?
-
இதையெல்லாம் தெரிந்து கொண்டு உருவாக்குநரிடம் தெரிவிக்கிறோம் என்று வைத்துக் கொள்வோம். அவர் தவற்றைத் திருத்தி யாரிடம் கொடுப்பார்? தவற்றைச் சுட்டிக்காட்டிய டெஸ்டரிமா? ஒருவேளை அந்தக் குறிப்பிட்ட டெஸ்டர் விடுப்பில் இருந்தாலோ, வேறு திட்டப்பணிக்கு மாற்றப்பட்டிருந்தாலோ உருவாக்குநர் யாரிடம் தெரிவிப்பார்?
இப்படிப் பல கேள்விகள் இப்போது எழலாம். இந்தக் கேள்விகளுக்கெல்லாம் விடை தெரிய வேண்டும் என்றால், ‘பிழை வாழ்க்கை வட்டம்‘ என்றால் என்ன என்று தெரிய வேண்டும். அந்த வட்டத்தைச் சுற்றுவோம் அடுத்த பதிவில்!
– முத்து (muthu@payilagam.com)
தொடரின் பிற பகுதிகள் இங்கே www.kaniyam.com/category/software-testing/
