நெறிமுறை #5: பூச்சிவிரட்டலில் புதிய முறைகள் (Pesticide Paradox)
மென்பொருள் உருவாக்கம் என்பது காலத்திற்கேற்ப மாறுகின்ற ஒன்று. ஒரு காலத்தில் இணையத்தளம் வடிவமைப்பே பெரிய விடயமாகப் பார்க்கப்பட்டது. ஆனால், இன்றோ பிஹெச்பி(PHP) முதலிய கட்டற்ற மென்பொருட்கள், வேர்டுபிரஸ், ஜூம்லா போன்ற இணையத்தள வடிவமைப்புக் கட்டுமானங்கள் ஆகியன வந்து விட்டன. இதனால் ஒரு நாள், இரண்டு நாட்களிலேயே இணையத்தளங்கள் வடிவமைக்கப்பட்டு விடுகின்றன.
முன்னர் எல்லாம் இணையத்தளத்தைச் சோதிக்க வேண்டும் என்றால், கணினிகள், மடிக்கணினிகள் ஆகியவற்றில் ஒழுங்காக இயங்குகிறதா என்று பார்த்தால் போதும்! அதற்கேற்ப டெஸ்ட் கேஸ்கள் எழுதி வைத்திருந்தால் போதும். ஆனால் இப்போது அப்படியா? ஓர் இணையத்தளம் கணினியில் ஒழுங்காகத் திறக்கிறதா? மடிக்கணினியில் ஒழுங்காகத் தெரிகிறதா? அலைபேசிகளில் ஒழுங்காகத் தெரிகிறதா? என்று எவ்வளவு சோதனைகள்! இந்தச் சோதனைகள் எல்லாவற்றிற்கும் ஏற்ப எவ்வளவு டெஸ்ட் கேஸ்கள்!
இதைத் தான் பூச்சி விரட்டலில் புதிய முறைகள் என்கிறார்கள். அதாவது, பூச்சிகளுக்கு ஏற்ப, அவை பயிரைத் தாக்காமல் இருக்கும் புதிய முறைகளை வேளாண்மையில் எப்படிக் கண்டுபிடிக்க வேண்டுமோ, அதே போல, மென்பொருளிலும் புதிய பூச்சிகளை(Bugs) விரட்ட, புதிய புதிய டெஸ்ட் கேஸ்களை எழுதி வைத்துக் கொள்ள வேண்டும். பழைய டெஸ்ட் கேஸ்களை மட்டுமே வைத்து சோதித்துக் கொண்டிருக்கக் கூடாது என்பது தான் இந்த நெறிமுறை!
நெறிமுறை #6: சூழலைப் பொருத்து சோதனையை மாற்றுக (Testing is context dependent)
மென்பொருள் சோதனையைப் பொருத்தவரை, ஒரு டெஸ்டர் – பயனரைப் போலச் சிந்திக்க வேண்டும்; செயல்பட வேண்டும். பயனர் என்பவர் துறைக்குத் துறை வேறுபடுபவர். பணப் பரிமாற்றத்திற்கான செயலியைப் பயன்படுத்துபவரையும் வாட்சப் போன்ற சமூக வகை செயலியைப் பயன்படுத்துபவரையும் ஒரே அளவுகோல் கொண்டு அளக்க முடியாது அல்லவா?
வாட்சப் செயலியைப் பயன்படுத்துபவர் ஒவ்வொரு முறை செயலியைப் பயன்படுத்தும் போதும் கடவுச்சொல் கேட்கப்படுவதை விரும்ப மாட்டார். ஆனால், பணப் பரிமாற்றத்திற்கான செயலியைப் பயன்படுத்துபவர் – ஒவ்வொரு முறை பயன்படுத்தும் போதும் கடவுச்சொல் கேட்கப்பட வேண்டும் என்று விரும்புவார் அல்லவா? ஆக, இங்கு நமக்கு இருப்பது இருவேறு வகைச் சூழல்கள்! இந்தச் சூழல் ஒவ்வொன்றையும் ஒவ்வோர் அளவுகோல் கொண்டு சோதிக்க வேண்டும் அல்லவா? இதைத் தான் சூழலுக்கு ஏற்ப சோதனையை மாற்றுக என்று நெறிப்படுத்திச் சொல்கிறார்கள்.
நெறிமுறை #7: பிழை வரா நிலை – சோதனையே பிழை! (Absence of error fallacy)
ஒரு மென்பொருளைச் சோதிக்கத் தொடங்குவதற்கு முன்பு, எந்த வகை தேவைகளைச் சோதிக்கப் போகிறோம் என்பதை நன்கு உணர்ந்து, புரிந்து கொண்டு சோதிக்கத் தொடங்க வேண்டும். வாடிக்கையாளரின் தேவைகளைத் தவறாகப் புரிந்து கொண்டால் – சில நேரங்களில் மென்பொருளில் பிழையே இல்லையே! என்று தோன்றும். அது ஒரு வகை தோற்ற மயக்கம். அதில் மயங்கிவிடக் கூடாது. பிழையே இல்லாத மென்பொருள் என்று ஒன்று உலகத்திலேயே கிடையாது. அப்படி ஒரு மென்பொருளை உருவாக்கவும் முடியாது.
அதே நேரம், தவறான தேவையை மனத்தில் வைத்துக் கொண்டு பிழைகள் கண்டுபிடிப்பதும் கூடாது. நாம் நினைவில் நிறுத்த வேண்டிய உண்மைகள்
1) பிழையே வரவில்லை என்றால் சோதனை முறையை மாற்ற வேண்டும்.
2) அதே நேரம் – நாம் கண்டுபிடிக்கும் பிழைகள் – தேவை சுவட்டு ஆவணத்தின்(BRS Document) அடிப்படையில் மட்டுமே அமைய வேண்டும்.
இதுவரை நாம் பார்த்த ஏழு நெறிமுறைகள் தாம் மென்பொருள் சோதனைக்கு அடிப்படையான நெறிமுறைகள் ஆகும். இன்னும் மென்பொருளை அதன் செயல்திறன்(performance) அடிப்படையில் எப்படிச் சோதிப்பது? என்பன போன்ற கேள்விகளுக்கு அடுத்த பதிவில் விடை தேடுவோம்.
– கி. முத்துராமலிங்கம்(muthu@payilagam.com)