Thursday, June 28, 2012

එක වසරට ළමුන් ඇතුලත් කිරිමේ නව ක්‍රමයක්

මේ දවස් වල ප්‍රසිද්ධ මාතෘකාවක් තමයි එක වසරට ළමයි ඇතුලත් කරන එක. මාර කට්ටක් තමයි තියෙන්නේ.(මමත් දන්නේ අපේ නංගිව ඉස්කොලෙකට දාන්න සහභාගි උන හින්දා  ). මේ දවස් වල ඉතින් අම්මලා තාත්තලාට ඉතින් නින්දක් නැ. මොකද කොහොමහරි පොඩි එකාව හොද ඉස්කොලෙකට දාගන්න එපැයි ඉතින්. ඉතින් ඉස්කොලේ ලගින් ගෙවල් හොයන්න(මෙකනම් ඉතින් ලමයා හම්බවුන ගමන් කොරන්න එපැයි ), ග්‍රාමසේවක මහත්වරු පස්සේ යන්න වැඩගොඩායි. එවා කොරා විතරක්යැ, ඉන්ටවිව් දවස් වලට ඉස්කොලවල් ගානේ යන්නත් එපායැ ඉතින්. දවස් කියක් ඉතින් නිකරුනේ නාස්ති වෙනවද මෙහෙම නිකන්. ඉතින් ඔන්න ඔය ප්‍රශ්නයට විසදුමක් තමයි මෙ යොජනා කරන්නේ. කොහොමද කියලා බලන්නකො ඉතින්. ඇත්තම කිව්වොත් 100% මටම හිතුනු දෙයක් නම් නෙවෙයි. දවසක් ලෙක්චර් එකක ඉන්නකොට අපේ ලෙක්චර කෙනෙක් දිපු අදහසක් තමයි පස්සේ මම හොයලා බලලා මේ විදියට ගෙනැල්ලා තියෙන්නේ.


ඔය දක්වලා තියෙන්නේ දැන් තියන විදිය. ඉල්ලුම් කරද්දි පුරවන්න ඔන මොන ගණයෙන්ද(Category) ඉල්ලුම් කරන්නේ කියලා.පහල දක්වලා තියෙන්නේ එහෙම වෙන්කල ගණයන් කිහිපයක්.
  1. පදිංචිය
  2. ආදි ශිෂ්‍ය භාවය
  3. සහෝදර සහෝදරියන් ඉගනුම ලැබිම.....
 ඔය උඩින් පෙන්නලා තියන පින්තුරේ තියෙන්නේ එක ලමයෙක් පාසල් දෙකකට ඇප්ලිකේශන් දාපු අවස්ථාවක්. A කියන පාසලට පදිංචියයි ආදි ශිෂ්‍ය භාවයයි අනුව ඉල්ලුම් කරලා තියනවා. B කියන පාසලට ඒ දෙකට අමතරව සහෝදර සහෝදරියන් ගණයෙනුත් ඉල්ලුම් කරලා තියනවා.ඉතින් මෙතනදි එම අදාල ලමයා වෙනුවෙන් ඇප්ලිකේශන් 5ක් දාන්න ඔන. එක එකට වෙන වෙනම. ඉන්ටෙව් යන්න ගියොත් අවම වශයෙන් දෙකක් තියනවා. ඉතින් දවස් දෙකක් අම්මටයි තාත්තටයි නිවාඩු දාන්න වෙනවා.ඒ වගේද රස්තියාදුව, වියදම. ළමයටත් ඉතින් බුදුසරණයි. ඇයි ගමන් මහන්සියනේ පොඩි එකාට. ඔය තියෙන්නේ දැන් තියන විදියේ තියන අවාසි දෙක තුනක්.

ඉන්ටවිව් දෙක තුනක් තියන එක වෙනුවට එක ඉන්ටවිව් එකක් තිබුනොත් කොහොමද? අර කිව්ව අවාසි ටික මගහරව ගන්න පුලුවන්. මම යෝජනා කරන ක්‍රමයේ තියෙන්නේ එක ඉන්ටවිව් එකයි. ඒක මොකක් හරි පොදු විදියකට ඒ කියන්නේ ඉස්කොලෙන් ඉස්කොලේට ඉන්ටවිව් නැතුව දිස්ත්‍රික්කයේ පාසල් කිහිපයක විතරක් ඉන්ටවිව් තියලා තනි ඉන්ටවිව් එකකින් ළමයෙකුට පාසලක් ලබාදිමේ ක්‍රමයක්.මෙතනදි අදාල දිස්ත්‍රික්කය නියොජනය වෙන විදියට සම්මුක පරික්ශනය සිදුකරන කණ්ඩායම තොරා ගන්න පුලුවන්. මෙතනදි සහාභාගි වෙන්නේ තනි පාසලක ගුරුවරු නොවන නිසා සිදුවෙන්න පුලුවන් වැරදි( ඉන්ටවිව් කරන පුද්ගලයන්ගෙ දැනහැදුනුම් කම් මත සිදුවන අකර්මන්‍යතා )අවම කරන්න පුලුවන්. වර්ථමානයේ සිදු කෙරෙන ක්‍රියාවලියේ මෙවැනි වැරදි සිදුවිමේ සම්භාවිතාව වැඩියි. තව තියන වාසියක් තමයි රජයට ඒ සදහා වැයවන මුදල් අඩුකරගන්නත් පුලුවන් විම. මොකද සාපේක්ෂව ගත්තාම මේ කියන ක්‍රමයේදි අවශ්‍ය කරන ගුරුසම්පත් ප්‍රමාණය අඩුයි. මිට අමතරව අර ඉස්සෙල්ලා කිව්ව අවාසිත් අයින් කර ගන්න පුලුවන්. ඔන්න ඕක තමයි මගේ හිතට ආපු විසදුම. මේක හරියටම වෙන්නේ කොහොමද කියලා තව පොස්ට් එකකින් ලියන්නම්. අදට ඉවරයි.


Sunday, June 3, 2012

QA Engineer කෙනෙක්ගේ Career path එක.

ඉස්සෙල්ලා පොස්ට් වලින් තෙරෙන්න අතිනේ QA Engineer කෙනෙක් උනොත් කරන්න තියන වැඩ මොනවද කියලා. මෙ පොස්ට් එකෙන් බලාපොරොත්තු වෙන්නේ QA Engineer කෙනෙක්ගේ එක මොනවගේද කියලා කියන්න. පහළ තියන පින්තුරේ එක දක්වලා තියනවා.


ඉස්සෙල්ලාම පටන් ගන්න වෙන්නේ Trainee QA කෙනෙක් විදියට තමයි. Trainee QA කෙනෙක්ට ඉතින් ලොකු ලොකු responsibilities නම් ඉතින් දෙන්නේ නැ. නැ කිව්වට ඉතින් එක company එක මත depend වෙනවා. මුලින්ම ඉතින් ඒ company එකේ products ගැන අධ්‍යනයක් කරන්න දෙනවා. එකෙන් පුළුවන් overall idea එකක් ගන්න company products ගැන. මෙක ඉතින් සාමාන්‍යයෙන් අළුතෙන් company එකට එන ඕනැම කෙනෙක්ට ලැබෙන එකක්. ඉතින් ඉට පස්සේ QA engineer කෙනෙක් යටතේ ඉදන් වැඩ කරන්න තමයි වෙන්නේ. ගොඩාක් වෙලාවට system එකේ usability test කරන්න, පොඩි පොඩි function test කරන්න, bug report කරන්නවගේ වැඩ තමයි සෙට් වෙන්නේ. 

Thursday, May 31, 2012

Testing Methods



සාමාන්‍යයෙන් ගත්තාම Testing ප්‍රධාන වශයෙන් දෙයාකාරයක් තියනවා. එකක් තමයි Inputs දාලා Output එක පරික්ෂා කරන එක. එකට කියන්නේ Black box testing කියලා. අනික තමා White box testing / Glass box testing. මෙතනදි Code statement, Structure  එකින් එක පරික්ෂා කිරිමක් සිදුවෙනවා. ඉතින් ඔන්න ඔයවිදියට testing ක්‍රම රාශියක් තියනවා සාමාන්‍යයෙන් use කරන. එවයින් තොරාගත් කිහිපයක් සරළව හා කෙටියෙන් පහළින් විස්තර කරලා තියනවා.

Saturday, May 26, 2012

QA Engineer කෙනෙක්ගේ Work flow එක.

අද කතා කරන්න බලාපොරොත්තු වෙන්නේ QA Engineer කෙනෙක්ගෙ Career path එක ගැන. ඒක ගැන කතා කරන්න ඉස්සෙල්ලා එයාගේ Work floor එක ගැන ලිව්වොත් හොදයි කියලා හිතුනා.

මුලින්ම කරන්නේ System එක අරගෙන එකේ Test plan එක හදා ගන්න එක. එක එක Requirement test කරන දවස් දළ වශයෙන් සටහන් කරගන්න එක තමයි සරළව කිව්වොත් ඔතනදි කරන්නේ. මෙක හදන්න QA engineers ලට අමතරව Team එකේ PM, Tech lead, Developers ලා කට්ටියම සහභාගි වෙනවා. මෙතනදි හදලා නැති කොටස් තියනවානම් එවාට අවසාන දිනයක්(Deadline) ලබාදිමත් සිදුකරනවා. මෙහෙම Test plan එක හදාගෙන ඉවර වෙලා ඉළගට කරන්නේ Test Cases හදන එක. Test Cases එකක් කියන්නේ එක Requirement එකක් test කරන අකාරය සටහන් කල ලියවිල්ලක් (Document එකක්). මෙතනදි අදාළ Function එක නිවරදි දත්ත දුන් විට වැඩකරනවාද වැරදි දත්ත දුන් විට වැඩනොකරනවාද කියා ද Test කලයුතු වෙනවා. පහළ තියන පින්තුරේ Testing Process එක සරළව දක්වලා තියනවා.