உருவாக்குநர்கள் (டெவலப்பர்கள்) மென்பொருளை உருவாக்கிக் கொண்டிருக்கும் நேரத்தில் டெஸ்டர்கள் உருவாக்கப்பட்டுக் கொண்டிருக்கும் மென்பொருளை எந்தெந்த வழிகளில் எல்லாம் சோதிக்கலாம் என்பதை எழுதி வைக்கிறார்கள். இதைத்தான் நாம் டெஸ்ட் கேஸ் என்று முந்தைய பதிவில் பார்த்தோம். இந்த டெஸ்ட் கேஸ்களை எழுதுவதற்கு வாடிக்கையாளர் தேவை ஆவணத்தை அடிப்படையாக எடுத்துக் கொள்வார்கள் என்பதையும் பார்த்து விட்டோம்.
உருவாக்குநர்கள் மென்பொருளை உருவாக்கி முடித்ததும் டெஸ்டர்கள் ஏற்கெனவே எழுதி வைத்திருக்கும் டெஸ்ட் கேஸ்களின் துணை கொண்டு சோதிப்பதைத் தொடங்கலாம். ஆனால் அப்படிச் சோதனையைத் தொடங்குவதற்கு முன்னர், டெஸ்ட் கேஸ்கள் முழுமையாக எழுதி முடிக்கப்பட்டு விட்டனவா எனப் பார்க்க வேண்டும் அல்லவா? அதை எப்படிப் பார்ப்பது? இங்குத் தான் டெஸ்ட் கேஸ்களையும் வாடிக்கையாளர் தேவை ஆவணத்தையும் ஒப்பிடும் ‘தேவை சுவட்டு ஆவணம்’ (‘Requirements Traceability Matrix – ரெக்குயர்மென்ட்ஸ் டிரேசபிளிட்டி மேட்ரிக்ஸ்’) தேவைப்படுகிறது.
தேவை சுவட்டு ஆவணம் என்றால் என்ன ?
இதென்ன பெயர் – தேவை சுவட்டு ஆவணம் – ஒன்றுமே புரியும்படி இல்லை என்கிறீர்களா? கவலை வேண்டாம்! விளக்கமாகப் பார்த்து விடலாம். அதைப் பார்ப்பதற்கு முன் பழைய பதிவுகளில் இருந்து உங்களிடம் ஒரு கேள்வி – வாடிக்கையாளருடைய தேவைகள் அனைத்தையும் நாம் எங்கே பார்க்கலாம்? சரியாகச் சொன்னீர்கள் – ‘வாடிக்கையாளர் தேவை ஆவணத்தில்’ இருந்து தான்! இந்த வா. தே. ஆவணத்தையும் டெஸ்டர்கள் எழுதி வைத்திருக்கும் டெஸ்ட் கேஸ்களையும் ஒப்பிட்டு ஓர் ஆவணத்தை உருவாக்கி விட்டால், அந்த ஆவணத்திற்குப் பெயர் தான் தேவை சுவட்டு ஆவணம் ஆகும். இந்தத் தேவை சுவட்டு ஆவணத்தில் எல்லாத் தேவைகளையும் அவற்றிற்கு நேர் எதிராக டெஸ்ட் கேஸ்களையும் பட்டியலிட்டுச் சரிபார்ப்பார்கள்.
எ.கா :
| தேவை | வா.தே.ஆ
1.1 |
வா.தே.ஆ
1.2 |
வா.தே.ஆ
1.3 |
வா.தே.ஆ
2.1 |
வா.தே.ஆ
2.2 |
வா.தே.ஆ
3.1 |
| டெஸ்ட் கேஸ் | ||||||
| 1.1.1 | x | |||||
| 1.1.2 | x | |||||
| 1.1.3 | x | x | ||||
| 1.1.4 | x | x | x | x | ||
| 1.2.1 | x | x | x | |||
| 1.2.2 | x | X | X | X |
தேவை சுவட்டு ஆவணம் – வகைகள் :
1) நேர்நிலை சுவட்டு ஆவணம் :
வாடிக்கையாளர் தேவைகளை டெஸ்ட் கேஸ்களுடன் பொருத்திப் பார்த்து உருவாக்குவது நேர்நிலை சுவட்டு ஆவணம் (‘பார்வர்டு டிரேசபிளிட்டி – Forward Traceability’) எனப்படுகிறது. இங்கு முதன்மை நோக்கம் சரியான திசையில் திட்டப்பணி செல்கிறதா, தேவையான மென்பொருளைச் சரியாக உருவாக்குகிறோமா, அதற்கான டெஸ்ட்கேஸ்கள் இருக்கின்றனவா என்று பார்ப்பதாகும்.
2) எதிர்நிலை சுவட்டு ஆவணம் :
எதிர்நிலையில் டெஸ்ட் கேஸ்களை வைத்துக் கொண்டு வாடிக்கையாளர் தேவைகளைத் திட்டப்பணி (அல்லது மென்பொருள்) நிறைவு செய்கிறதா என்று பார்ப்பது! அதாவது வாடிக்கையாளர் தேவை ஆவணத்தைக் கொண்டு டெஸ்ட் கேஸ்களை எழுதி, அந்த டெஸ்ட் கேஸ்களை மட்டுமே மென்பொருள் கொண்டிருக்கிறதா அல்லது வாடிக்கையாளருக்குத் தேவையில்லாதவற்றையும் சேர்த்து மென்பொருளில் டெவலப்பர்கள் (தெரிந்தோ தெரியாமலோ) வைத்து விட்டார்களா என்று பார்ப்பது தான் எதிர்நிலை சுவட்டு ஆவணம் ஆகும்.
யார் உருவாக்குவார்கள் ?
ஓர் அணியின் தலைவருக்குத் தான் அணி உறுப்பினர்கள் ஒவ்வொருவரும் எத்தனை டெஸ்ட் கேஸ்கள் எழுதியிருக்கிறார்கள் என்பதும் அவை எந்தெந்த உருப்படிகளைச் சோதிக்க உதவும் என்பது முழுமையாகத் தெரியும். எனவே இந்த தேவை சுவட்டு ஆவணத்தை உருவாக்குவதற்குத் தகுதியான ஆள் அணித் தலைவர் தாம்! சில நிறுவனங்களில் அணியில் உள்ள மூத்த உறுப்பினர்களும் ஆவண உருவாக்கத்தில் ஈடுபடுவது உண்டு.
நன்மைகள் :
1) ஒன்று விடாமல் வாடிக்கையாளரின் எல்லாத் தேவைகளையும் சோதிக்கத் தேவையான டெஸ்ட் கேஸ்களை எழுதிவிட்டோமா என்று அறிந்து கொள்ளலாம்.
2) வாடிக்கையாளரின் தேவைகளில் ஏதேனும் குழப்பங்களோ சந்தேகங்களோ இருந்தால் அவற்றைத் தெரிந்து திருத்திக் கொள்ள இந்த ஆவணம் உதவும்.
வேறேன்ன செய்யலாம் :
மென்பொருள் உருவாக்கம் ஒரு பக்கம் போய்க் கொண்டிருக்கிறது. அந்நேரத்தில் தான் டெஸ்டர்கள் இது போல பல ஆவணங்களை உருவாக்கிச் சோதனைக்குத் தங்களை ஆயத்தப்படுத்திக் கொள்வார்கள். ஆவணங்கள் எல்லாம் முடிந்த பிறகு, டெஸ்டிங் செய்யத் தேவைப்படும் சூழலை உருவாக்குவதில் ஈடுபடுவார்கள்.
சோதனைக்கு உகந்த சூழல் :
- நாம் பயர்பாக்ஸ் அலைபேசி ஒன்றைச் சோதிக்கிறோம் என்றால், பயர்பாக்ஸ் அலைபேசி ஒன்றையோ அல்லது பயர்பாக்ஸ் நிறுவப்பட்டுள்ள கணினி ஒன்றையோ ஆயத்தப்படுத்தி வைப்பது
- இணையத்தளம் ஒன்றைச் சோதிக்கிறோம் என்றால் தேவைப்படும் உலாவிகளை (பயர்பாக்ஸ், குரோம்) நிறுவி வைத்துக் கொள்வது
- இதைப் போல தேவைப்படும் பிற மென்பொருட்களை நிறுவிக் கொள்வது
ஆகியவற்றைத் தான் சோதனைக்கு உகந்த சூழலை உருவாக்குவது என்கிறோம்.
ஒருவழியாக, டெஸ்ட் கேஸ் எழுதி, சூழலை உருவாக்கிச் சோதனையைத் தொடங்கும் புள்ளிக்கு வந்து விட்டோம். டெவலப்பர்கள் மென்பொருளைக் கொடுத்த உடன், சோதனையைத் தொடங்கி விடலாம். நம்மிடம் மென்பொருளைக் கொடுத்துச் சோதிக்கச் சொல்வதற்கு முன், டெவலப்பர்களே ஒரு முறை சோதித்துப் பார்ப்பார்கள். ‘டெவலப்பர்கள் மென்பொருளைச் சோதிப்பார்களா? சோதித்துப் பார்ப்பதற்குத் தானே நாம் இருக்கிறோம்! பிறகு அவர்கள் என்ன சோதிப்பார்கள்?’ என்கிறீர்களா? அதைப் பற்றிப் பேசுவோம் – அடுத்த பதிவில்!
– முத்து (muthu@payilagam.com )
தொடரின் பிற பகுதிகள் இங்கே www.kaniyam.com/category/software-testing/