தேடுதல் வேட்டை

Monday, December 18, 2006

டெஸ்டிங் படிச்சா வேலை கிடைக்குமா? - 2

டெஸ்டிங் படிப்பது என்று முடிவெடுத்தாகிவிட்டது...இப்போது குழப்பமே யாரை அணுகுவது ? எப்படி படிப்பது ? இந்த துறையில் உள்ள வேலை வாய்ப்புகள் என்ன என்பதுதான்...ஆங்கில நாளிதழ்களில் புதன்கிழமைகளில் வரும் வேலைவாய்ப்பு பகுதிகளில் டெஸ்டிங் துறையில் ஆட்கள் தேவை என்று சிறிது சிறிதாக விளம்பரங்களும் வர ஆரம்பித்தன...அங்கே இங்கே விசாரித்து டெஸ்டிங் பற்றி ஒரு முழு ஐடியாவும் கிடைத்துவிட்டது...கொஞ்சம் சுருக்கமாக சொல்லப்போனால்...

* மென்பொருள் துறையின் அடிப்படை அறிவை ஆழமாக பெறுதல் வேண்டும். ( Software Engineering Life Cycle)

* டெஸ்டிங் துறையில் மேனுவல் டெஸ்டிங் (Manual Testing), ஆட்டமேஷன் டெஸ்டிங் (Automation Testing) என்று இரு பிரிவுகளில் பணிவாய்ப்பு கிடைக்கும்.

* மேனுவல் டெஸ்டிங் சொந்தமாக நாமே படித்துக்கொள்ளும் அளவில் குறைந்த அளவிலான பாடங்களை கொண்டது. நல்ல புரிதலும், சிறந்த ஆங்கில அறிவும் இருந்தால் எந்த நேர்முக தேர்வையும் அடித்து தூள் கிளப்பி விடலாம்..

* ஆட்டமேஷன் துறையில் சிறந்த பணிவாய்ப்புகள், வெளிநாட்டு வேலைவாய்ப்புகள் கணக்கில்லாமல் காத்திருக்கின்றன..

* டெஸ்டிங் துறையை தேர்ந்தெடுப்பவர்கள் குறைவு, போட்டி அதிகம் இல்லை..

* அதிகபட்ச ப்ரஷர் இல்லாமல் சிறப்பாக பணியாற்றும் வாய்ப்பு..

* டெஸ்டிங் துறையில் இருப்பவர்களுக்கு சம்பளம் குறைவு / வாய்ப்புகள் குறைவு / மதிப்பு இல்லை என்ற தகவல் பொய்யானது..

* ஆட்டமேஷன் டூல்ஸ் (Tools) வைத்திருந்தாலும் சில நிறுவனங்கள் பெரும்பாலும் மேனுவல் டெஸ்டிங்கையே நம்பியிருக்கின்றன...

பல விஷயங்கள் தெளிவாக புரிந்தது..மேனுவல் டெஸ்டிங் சொந்தமாக படித்துக்கொள்ளும் திறமை இருந்தால் படித்துக்கொள்ளலாம்..ஆனால் ஆட்டமேஷன்..கண்டிப்பாக ஏதாவது ஒரு நிறுவனத்தில் படித்தல் நலம் என்று முடிவெடுத்தோம்..ஆனால் கல்வி நிறுவனங்களில் மேனுவல் டெஸ்டிங் ஆரம்பித்து பிறகுதான் ஆட்டமேஷன் சொல்லித்தருவார்கள் என்று தகவல் கிடைத்தது...சரி அதனால் என்ன, மேனுவல் டெஸ்டிங் பற்றிய தகவல்களை நன்பர்களிடமிருந்து பெற்றும், இணையத்திலிருந்து தரவிறக்கியும் நன்றாக புரிதலுடன் தெரிந்துகொண்டால், நிறுவனத்தில் இணைந்து படிக்கும்போது இன்னும் எளிமையாகவும், விரைவாக புரிந்துகொள்ளும்படியும் இருக்குமே என்று முடிவெடுத்தோம்....

அதற்க்கு முன்னால் ஏன் எதற்க்கு இந்த டெஸ்டிங் என்று சற்று விரிவாக பார்க்கலாமா ? நான் ஒரு எளிமையான உதாரணத்தை எடுத்துக்கொள்கிறேன்..வாசகர்களில் டெக்னிக்கல் விஷயங்களை கரைத்து குடித்தவர்கள் இருப்பீர்கள்...கொஞ்சம் மன்னித்துவிடுங்கள்...

நீங்கள் ஒரு மென்பொருளை தயாரிக்கிறீர்கள் என்று வைத்துக்கொள்வோம். உதாரணமாக நோட் பேட் (Notepad). இந்து விண்டோஸ் உபயோகித்த அனைவருக்கும் அறிமுகமான ஒரு மென்பொருள்தான். இதில் நம் தகவல்களை டைப் செய்யலாம். விரும்பிய பெயரில் சேமிக்கலாம். பிறகு திறந்து பார்க்கலாம். இந்த கோப்பை அழிக்கவும் செய்யலாம்...

இதே போல் ஒரு மென்பொருளை தயாரிக்க ஒரு நிறுவனம் விரும்புகிறது. அது தன் பணியாளர்களை வைத்தோ அல்லது வேறு ஒரு நிறுவனம் மூலமோ இந்த மென்பொருளை தயாரிக்க முடிவு செய்கிறது..

இதில் ஒரு சிறிய விஷயம், தனக்கு தேவையான மென்பொருளை அந்த நிறுவனமே தயாரித்தால் அது ப்ராஜக்ட் ( Project). எடுத்துக்காட்டாக, தங்கள் பணியாளர்களின் வருகைப்பதிவேட்டினை மென்பொருளாக தயாரித்தால் அது ப்ராஜக்ட். அல்லது வேறு ஒரு நிறுவனத்துக்கு தயாரித்து கொடுத்தாலும் அது ப்ராஜக்ட் தான். ஆனால் ப்ராடக்ட் (Product) என்பது, பொது உபயோகத்துக்காக தயாரிப்பது. உதாரணமாக மைக்ரோசாப்ட் விண்டோஸ், வேர்ட், எக்ஸல் என்பன ப்ராடக்ட் ஆகும்..இந்த சிறு வித்தியாசம் கண்டிப்பாக அறிந்துகொள்ளவேண்டிய ஒன்று...!!!

முதலில் மென்பொருளை தயாரிக்க அனுமதி அளிக்கும் நிறுவனரின் மின் மடல், அல்லது ஒரு Official Request வரவேண்டும். அப்போது தான் ப்ராஜக்டை ஆரம்பிக்க முடியும் இல்லையா...சரி...அனுமதி கிடைத்துவிட்டது.

நிறுவனத்தின் மானேஜர் என்ன செய்கிறார் இப்போது ? ஒரு SRS எனப்படும் கோப்பை தயாரிக்கிறார்..இது Software requirment specification என்பதின் சுருக்கமாகும்...இந்த கோப்பில், மென்பொருள் எப்படி இருக்க வேண்டும், எந்த கணினிகளில் இயங்க வேண்டும் (விண்டோஸ் கணினியிலா / யூனிக்ஸ் (UNIX) கணினியிலா ), மென்பொருளில் என்ன என்ன Funcionality இருக்க வேண்டும் ? சேமிக்கும் வசதி இருக்கவேண்டுமா ? கோப்பை அழிக்கும் வசதி இருக்க வேண்டுமா ? ஏற்கனவே சேமித்த பெயரை மாற்றும் வசதி (Rename) இருக்க வேண்டுமா ? என்பது போல...

சற்று விரிவாக கூறிவிட்டேன்...இருந்தாலும் இவ்வாறெல்லாம் தயாரித்த மென்பொருளை அப்படியே விற்கிறோம் என்று வைத்துக்கொள்வோம்...

ப்ராஜக்ட் ஆக இருந்தாலும் சரி, ப்ராடக்ட் ஆக இருந்தாலும் சரி...முதன்முதலில் உபயோகிப்பவர் அதனை திறக்கிறார்...திறக்க மறுக்கிறது...அல்லது திறந்த பின், ஒரு செய்தியை டைப் செய்து, சேமிக்கிறார்...சேமிக்க மறுக்கிறது...சூடான மடலோடு நீங்கள் அனுப்பிய மென்பொருள் திரும்ப வருகிறது..இந்த மென்பொருளை தயாரிக்க மூன்று மாதங்கள் ஆனது என்று வைத்துக்கொள்வோம்...உழைப்பெல்லாம் வீண்...மீண்டும் ஒரு மாதம் நேரம் கேட்டு மீண்டும் கணிணி வல்லுனர்கள் இரவு பகலாக உழைக்கிறார்கள்...ஆனால் மீண்டும் விற்ற இடத்தில் சரியாக வேலைசெய்யவில்லை உங்கள் மென்பொருள்...கோபமாகும் அந்த நிறுவன அதிகாரிகள், உங்களுடனான ஆர்டரை கேன்ஸல் செய்வதோடு அல்லாமல், சரியான மென்பொருளை வழங்காததால் உங்களுக்கு உரிய பணத்தை பட்டுவாடா செய்ய மறுக்கிறார்கள்...அவர்கள் நேரத்தை வீணடித்தது காரணமாக உங்கள் மீது வழக்கும் தொடர்கிறார்கள் என்று வைத்துக்கொள்ளுங்கள்...எவ்வளவு பிரச்சினை பாருங்கள்...

இது போன்ற பிரச்சினைகள் ஏற்ப்படாமல் எவ்வாறு தடுப்பது ? அங்கேதான் டெஸ்டிங் முன்னால் வந்து நிற்கிறது...இந்த முன்னுரையை பிரிதொரு நேரத்தில் தொடரலாம்...இப்போது சற்று ப்ராக்டிக்கலுக்கு வருவோம்...

டெஸ்டிங் கல்வி பயிற்றுவிக்கும் ஒரு சிறிய நிறுவனத்தை அணுகியபோது அவர்களின் கோர்ஸ் ப்ளான் இவ்வாறு இருந்தது...

1. சாப்ட்வேர் லைப் சைக்கிள் ( Software life Cycle)
2. மேனுவல் டெஸ்டிங் ( Manual Testing)
3. ஆட்டமேஷன் டெஸ்டிங் டூல்ஸ் (Automation Testing Tools)

சற்று விரிவாக பார்க்கலாமா ?

SDLC என்று சுருக்கமாக மொழியப்படும் இது, அடிப்படை கல்வியாகும். டெஸ்டிங் என்ற ஒரு விஷயம் எங்கே ஆரம்பிக்கிறது, எங்கே முடிகிறது, என்பதினை விரிவாக அறிய இதனை தெரிந்துகொள்வது அவசியமாகும்..

சற்று விரிவாக சொல்லப்போனால் கீழ்க்கண்டவாறு அமையும்..

Analyze -> Design -> coding - > testing

முதலில் அனஸைஸ் செய்யவேண்டும் ( என்ன - எப்படி என்பதை பின்னால் விரிவாக பார்க்கலாம்), பிறகு டிஸைன். இதில் Low Level Design மற்றும் High Level Design என்று பிரிவுகள் உண்டு ( ப்ளோ சார்ட் மாதிரி இருக்கும் இது. உங்கள் மென்பொருள் பற்றிய விரிவான படவிளக்கம். பிறகு கோடிங். இங்கே நாம் ப்ரொக்ராமிங் எழுதுகிறோம். பிறகு டெஸ்டிங். மென்பொருள் சரியாக வேலை செய்கிறதா என்று பார்க்கும் பணி. தொழில் நிறுவனங்களில் QC (க்வாலிட்டி கண்ட்ரோல்) என்று ஒரு பிரிவு இருக்கும் இல்லையா ? தயாரித்த பொருள் உருப்படியாக உள்ளதா என்று சரிபார்க்கும் குழு ? அதுவே தான் மென்பொருள் நிறுவனங்களில் டெஸ்டிங் டீம்...

சரி நமது நன்பர் டெஸ்டிங் கோர்ஸில் இணைந்தாரா ? அங்கே வகுப்பில் என்ன பயிற்றுவித்தார்கள், டெஸ்டிங் வகைகள் - Types Of Testing சொல்லித்தந்தார்களா ? டெஸ்ட் ப்ளான் (Test Plan), டெஸ்ட் கேஸ் (Test Case) பற்றி விளக்கினார்களா ? டெஸ்டிங் நேர்முகத்தேர்வில் என்ன கேள்விகள் கேட்கப்படும் என்பதை சொல்லித்தந்தார்களா ? என்பதை அடுத்த பதிவில் பார்க்கலாம்...

10 comments:

Anonymous said...

I think SDLC means

Software Developement Life cycle.

i dont know exaclty what D is menaing.

SDLC டெஸ்டிங் மட்டுமே குறிக்காது. அது ஒரு பொதுவான் வார்த்தை என்று நினைக்கிறேன்.

செந்தழல் ரவி said...

நீங்கள் சொல்வது சரி. டெஸ்டிங் படிக்க ஆரம்பிப்பவர்கள் SDLC யில் இருந்து ஆரம்பிப்பதே முறை...காரணம் அவர்கள் கல்லூரி பாடத்தில் தெரியாத்தனமாக வந்திருந்தாலும் அது வேப்பங்காயாக கசந்திருக்கும்...!!!

நிலா said...

//நிறுவனத்தின் மானேஜர் என்ன செய்கிறார் இப்போது ? ஒரு SRS எனப்படும் கோப்பை தயாரிக்கிறார்..இது Software requirment specification என்பதின் சுருக்கமாகும்...இந்த கோப்பில், மென்பொருள் எப்படி இருக்க வேண்டும், எந்த கணினிகளில் இயங்க வேண்டும் (விண்டோஸ் கணினியிலா / யூனிக்ஸ் (UNIX) கணினியிலா ), மென்பொருளில் என்ன என்ன Funcionality இருக்க வேண்டும் ? சேமிக்கும் வசதி இருக்கவேண்டுமா ? கோப்பை அழிக்கும் வசதி இருக்க வேண்டுமா ? ஏற்கனவே சேமித்த பெயரை மாற்றும் வசதி (Rename) இருக்க வேண்டுமா ? என்பது போல...
//



ரவி

இதற்கு முன்பாக Business Requirement Specification எழுதப்பட்டிருக்க வேண்டும். இதுதான் மென்பொருளின் நோக்கம் என்ன, அது என்ன செய்ய வேண்டும், அதில் என்னென்ன வசதிகள் இருக்க வேண்டும் போன்ற விபரங்களைக் கொண்டிருக்கும் - சுருக்கமாக பயனருக்கு என்ன தேவை என்பது இந்தக் கோப்பில் இருக்கும் - i.e this document defines the functionality of the end product. இதனை மென்பொருள் தயாரிப்பவர் தயாரிக்க முடியாது. மென்பொருளின் உரிமையாளர்தான் இதனை எழுத வேண்டும்

இந்தத் தேவைகளை புதிய மென்பொருள் எப்படி பூர்த்தி செய்யப் போகிறது என்ற விபரத்தை SRS கொண்டிருக்கும்.

BRS இல்லாமல் SRS எழுத முயலும் போது பல அனுமானங்களைச் செய்ய வேண்டி வரும். பயனருக்கு என்ன தேவை என்பது தெளிவாக இல்லாததால் தாம் உருவாக்கப் போகும் மென்பொருள் என்னவெல்லாம் செய்யும் என்பதாக அமைந்துவிடும்

மேஜை தேவையான இடத்தில் வெகு தரமான நாற்காலியைக் கொடுப்பது போலாகிவிட வாய்ப்புண்டு :-)

My two cents worth :-)

செந்தழல் ரவி said...

நிறுவனங்கள் பிஸினஸ் ரெக்வயர்மெண்ட் டாக்குமெண்ட் தருகின்றன. அது எஸ்.ஆர்.எஸ் எழுத உபயோகமாக இருக்கும் என்பது உண்மைதான்...

கடந்த ஆண்டு சோனி எரிக்ஸன் நிறுவன தலைவரிடம் இருந்து நான் பணிபுரிந்த ஸாஸ்கன் நிறுவன தலைவருக்கு (திரு.ராஜீவ் மோடி) வந்த மின்னஞ்சல்..

"I want a 3G Phone with MMS / Video Calls / WAP and Many More Applications using EMP Platform,I am plaing to Invest 2 Million"

அவ்வளவுதாங்க...

வேலை முடிந்து ஒரு ஆண்டுக்கு பிறகு Panasonic Z800 மொபைல் போன் இப்போது மார்க்கெட்டில்...

நிலா said...

ரவி

BRS எல்லோரும் தருவதில்லை என்பது உண்மைதான். ஆனால் தரப்படவேண்டும் என்பதுதான் முறை. அப்போதுதான் மென்பொருளில் தரம் இருக்கும். அதனை நாம் இங்கு குறிப்பிடாவிட்டால் புதிதாக டெஸ்டிங் படிப்பவர்கள் அதனைத் தெரிந்துகொள்ளாமல் போய்விடுவார்கள்; வேலை செய்யுமிடத்தில் இதனை வலியுறுத்தாமல் போய்விடுவார்கள்

சோனியின் தலைவரின் மெயிலிலுள்ள //Many More Applications using EMP Platform// என்பதை எப்படி டிசைன் செய்திருக்க முடியும்?

இதற்கு மேல் உங்கள் நிறுவனத்திலுள்ள பிஸினஸ் அனலிஸ்ட் 'Many More Applications' என்னென்ன என்பதை வரையறுத்திருப்பார்கள். அதாவது இந்த சூழ்நிலையில் மென்பொருளின் உரிமையாளரின் சார்பில் உங்கள் நிறுவனத்தில் ஒருவர் தேவைகளை நிர்ணயித்து உரிமையாளரிடம் அப்ரூவல் வாங்கி இருப்பார்.அதுதான் BRS.

BRS மட்டுமல்ல SRS இல்லாமலும் கூட மென்பொருட்கள் தயாரிக்கப்படுவதுண்டு. ஆனால் இந்த வழிமுறைகள் சரியாக கடைப்பிடிக்கப்படும்போது குறைகள் ஏற்பட வாய்ப்புகள் குறைவு

Sridhar Venkat said...

ரவி அவர்களே,

நல்லதொரு கட்டுரை. software testing இன்னும் பலப் பல முன்னேற்றங்களைப் பார்க்கப் போகின்றது.

SDLC-ல் மொத்தம் ஏழு நிலைகள்.

Feasibility Study -> Requirement Analysis -> Software Design -> Build -> Testing -> Post production எனப்படுதாகும்.

இந்த முறையில் வளரும் மென்பொருள்களை - waterfall methodology என்பார்கள். அதாவது ஒரு தேவையை முன்னிட்டு அதன் பலப் பல நிலைகளை உருவாக்கி, சோதனை செய்து, உபயோகத்திற்கு நிறுவுவதாகும்.

ஆனால் இப்பொழுது பல செயலிகள் இந்த ஏழு நிலைகளை கடந்து வருவதில்லை. வேறு பல methodology-கள் பிரபலமடைந்துவிட்டன. Agile Methodology போன்ற சுழற்சி வகை (iterative development) முறைகளில் testing-கு அதிக முக்கியத்துவம் கொடுக்கின்றோம்.

Software Testing-கு இன்னும் நிறைய முக்கியத்துவமும் முன்னேற்றமும் ஏற்படும் என்றுதான் தோன்றுகிறது.

Anonymous said...

Can you Please explain about Performance Testing?

வடுவூர் குமார் said...

செந்தழல் ரவி
இந்த SDLC ஐ பற்றி ஜான் ஸ்மைலி சி++ மற்றும் .நெட் புத்தகங்களில் படித்திருக்கிறேன்.மிக அருமையாக எழுதியிருப்பார் (எனக்கே புரிகிறமாதிரி ;-)) ).
400~500 பக்கங்களில் உள்ள புத்தகத்தை தவணைமுறையில் படித்து வருகிறேன்.
நல்ல தகவல்கள்.
பலர் பயணடையட்டும்.

நாமக்கல் சிபி said...

//SDLC டெஸ்டிங் மட்டுமே குறிக்காது. அது ஒரு பொதுவான் வார்த்தை என்று நினைக்கிறேன்.
//

உண்மைதான்.
SDLC என்பது ஒரு மென் பொருள் தயாரிப்பின் ஆரம்பம் முதல் கடைசி வரை உள்ள நிலைகளைக் குறிப்பது.

Software Developement Life cy என்பது சரியானதே.

நாமக்கல் சிபி said...

//இந்த முறையில் வளரும் மென்பொருள்களை - waterfall methodology என்பார்கள். அதாவது ஒரு தேவையை முன்னிட்டு அதன் பலப் பல நிலைகளை உருவாக்கி, சோதனை செய்து, உபயோகத்திற்கு நிறுவுவதாகும்//

waterfall methodology என்பது ஒரு SDLC ன் பல்வேறு வழிமுறைகளில் ஒன்றாகும்.

அதாவது SDLC ன் ஒவ்வொரு நிலையாகக் கடந்து செல்வது. இந்த வழியை Defence & Areospace போன்ற தளங்களில் கையாளுகிறார்கள். ஒரு நிலையில் இருக்கும் செயலாக்கங்களை, பக்காவாக முடித்து பலமுறை சோதித்து திருத்தி அடைந்த பிறகே அடுத்த நிலைக்குச் செல்வது waterfall methodology ஆகும். ஒரு நிலையைக் கடந்த பின் மீண்டும் அந்த நிலைக்குச் செல்வதில்லை.