පරීක්ෂකයින් සොයා ගැනීම සඳහා හිතාමතා දෝෂ කේතයේ තැබීම

අපි මෙය අපගේ ආයතනයෙන් කරන්නේ නැත, නමුත් මගේ මිතුරෙකු පවසන්නේ ඔහුගේ ව්‍යාපෘති කළමනාකරු සෑම සංවර්ධකයෙකුගෙන්ම ඉල්ලා සිටියේ නිෂ්පාදිතය QA වෙත යාමට පෙර හිතාමතාම දෝෂ එකතු කරන ලෙසයි. එය ක්‍රියාත්මක වන ආකාරය මෙයයි:

1. නිෂ්පාදිතය QA වෙත යාමට පෙර, සංවර්ධන කණ්ඩායම කේතයේ අහඹු ස්ථානවල හිතාමතා දෝෂ කිහිපයක් එකතු කරයි. එම දෝෂයන් අවසාන නිෂ්පාදනය සමඟ නැව්ගත නොකිරීමට ඔවුන් මුල්, ක්‍රියාකාරී කේතය නිසි ලෙස උපස්ථ කරයි.
2. මේ පිළිබඳව පරීක්ෂකයින්ට ද දැනුම් දෙනු ලැබේ. එබැවින් ඔවුන් දැඩි ලෙස පරීක්‍ෂා කරනු ඇත, මන්ද දෝෂ පවතින බව ඔවුන් දන්නා නිසා සහ ඒවා සොයා නොගැනීම අකාර්යක්ෂමතාවයේ සලකුණක් ලෙස සැලකිය හැකි බැවිනි.
3. දෝෂයක් (හිතාමතා හෝ වෙනත් ආකාරයකින්) සොයාගෙන තිබේ නම්, ඒවා නිවැරදි කිරීම සඳහා සංවර්ධන කණ්ඩායමට වාර්තා කරනු ලැබේ. නිෂ්පාදිතය දෙවන මට්ටමේ QA වෙත යාමට පෙර සංවර්ධන කණ්ඩායම කේතයේ අදාළ කොටසක තවත් හිතාමතා දෝෂයක් එක් කරයි. ව්‍යාපෘති කළමණාකරු පවසන්නේ පරීක්ෂකයෙකු සංවර්ධකයෙකු ලෙස සිතිය යුතු අතර ඔහු / ඇය වෙනස්කම් සිදු කළ අංශවල නව දෝෂ අපේක්ෂා කළ යුතු බවයි.

හොඳයි, මෙය සිදු වන්නේ එලෙසයි. ඔවුන් පවසන්නේ මෙම ප්‍රවේශයට පහත සඳහන් වාසි ඇති බවයි.

1. පරීක්ෂකයින් සැමවිටම ඇඟිලි තුඩු මත සිටින අතර ඔවුන් පිස්සු මෙන් පරීක්ෂා කරනු ඇත. සැඟවුණු (නොදැනුවත්ව) දෝෂ සොයා ගැනීමට එය ඔවුන්ට උපකාරී වන අතර එමඟින් සංවර්ධකයින්ට ඒවා නිවැරදි කළ හැකිය.
2. පරීක්ෂකයින් දෝෂ වලින් පෝෂණය වේ. කිසිදු දෝෂයක් සොයා නොගැනීම ඔවුන්ගේ චිත්ත ධෛර්යයට බලපායි. එබැවින් ඔවුන්ට පහසුවෙන් සොයා ගැනීමට හැකි වීම ඔවුන්ගේ චිත්ත ධෛර්යයට උපකාරී වේ.

මෙම හිතාමතා දෝෂ වලින් එකක් අවසාන නිෂ්පාදනය සමඟ නැව්ගත වන අවස්ථාව ඔබ නොසලකා හැරියහොත්, මෙම ප්‍රවේශය අනුගමනය කිරීමට සිතීමට පෙර අප සලකා බැලිය යුතු අනෙක් අඩුපාඩු මොනවාද?

සමහර පැහැදිලි කිරීම්:

1. ඔවුන් ප්‍රභව කේතයෙහි මුල් කේතය නිසි ලෙස උපස්ථ කරයි.
2. පරීක්ෂකයෙකු හිතාමතාම දෝෂය සොයාගත් විට, සංවර්ධන කණ්ඩායම එය නොසලකා හරියි. පරීක්ෂකයා නොදැනුවත්වම (මුල්) දෝෂයක් සොයා ගන්නේ නම්, සංවර්ධන කණ්ඩායම මුලින්ම එය කිසියම් හිතාමතා දෝෂයක් නිසා සිදුවී ඇත්දැයි පරීක්ෂා කරයි. එනම්, සංවර්ධන කණ්ඩායම මුලින්ම එය මුල් ක්‍රියාකාරී කේතය මත ප්‍රතිනිෂ්පාදනය කිරීමට උත්සාහ කරන අතර ඔවුන්ට හැකි නම් එය නිවැරදි කිරීමට උත්සාහ කරයි.
3. QA සහ සංවර්ධන කණ්ඩායම අතර සම්බන්ධතා ගැටළු නොසලකා හරින්න. මම විශේෂයෙන් මෙම ප්රශ්නය ඇසුවා වැඩසටහන් , මත නොව මෙම සේවා ස්ථාන . QA සහ සංවර්ධන කණ්ඩායම අතර හොඳ සම්බන්ධතාවයක් ඇති බව සලකන්න, ඔවුන් වැඩ කරන වේලාවෙන් පසුව එකට සාද කරති. ව්‍යාපෘති කළමණාකරු යනු කණ්ඩායම් දෙකටම (ගොඩ්සෙන්ඩ්) සහයෝගය දැක්වීමට සැමවිටම සූදානම්ව සිටින, මහලු මහත්වරුනි.

මෙය ඇත්තෙන්ම නපුරුයි. එය ඉතා සැක සහිත ප්‍රතිලාභයක් සඳහා විශාල පරිශ්‍රමයක් දරමින් සිටින අතර, පුහුණුව සමහර වැරදි පරිශ්‍රයන් මත පදනම් වී ඇති බව පෙනේ:

• සෑම දිනකම පරීක්ෂාවට ලක්වන බව ඔවුන් දැන සිටියහොත් මිස QA මහන්සි නොවනු ඇත (එය චිත්ත ධෛර්යයට යහපත් නොවේ)

• QA සඳහා සොයා ගැනීමට මෘදුකාංගයේ නොදැනුවත්වම හඳුන්වා දුන් දෝෂ නොමැති බව

• QA හි කාර්යය වන්නේ දෝෂ සොයා ගැනීමයි - එය එසේ නොවේ; එය මෘදුකාංගය නිෂ්පාදන ගුණාත්මක බව සහතික කිරීමයි

• සංවර්ධනය හා QA අතර ඇති මේ ආකාරයේ බුද්ධිමය සටන යම් ආකාරයකින් සමාගමට සෞඛ්‍ය සම්පන්න බව - එසේ නොවේ; සියලුම සේවකයින් එකිනෙකා වෙනුවට සමාගමේ තරඟකරුවන්ට එරෙහිව කටයුතු කළ යුතුය.

එය භයානක අදහසක් වන අතර, ව්‍යාපෘති කළමණාකරු යනු මිනිසුන් සහ අභිප්‍රේරණය ගැන කිසිවක් නොතේරෙන විහිළුවක් / මෝඩයෙකි. එය ව්‍යාපාරයට නරක ය.

"QA හි රැකියාව" පිළිබඳ මගේ විස්තරය පුළුල් කිරීම සඳහා QA අනිවාර්යයෙන්ම දෝෂ සොයා ගත යුතුය - කේතයේ සහ ඔවුන්ගේ පරීක්ෂණ කට්ටලවල - ඔවුන්ගේ කාර්යයන් කිරීමේ පුරාවස්තුවක් ලෙස, නමුත් භූමිකාව නිර්වචනය නොකළ යුතුය "ඔබ සොයා ගත යුතුය දෝෂ. ” එය "ඔබ නව අංගයන් සඳහා යාවත්කාලීනව පරීක්ෂණ කට්ටල යාවත්කාලීනව තබා ගත යුතු අතර පරීක්ෂණයේ ඉහළ ආවරණයක් සහතික කළ යුතුය. මෙය දෝෂ සොයා ගැනීමට හේතු නොවේ නම්, පරීක්ෂණ ක්‍රියා පටිපාටිය නිෂ්පාදිතය සඳහා ප්‍රමාණවත් තරම් නවීන නොවේ.

හොඳයි, මම ඉගෙන ගත් දේ මත පදනම්ව:

1. එය පාසලක් හෝ රැකියා සම්මුඛ පරීක්ෂණයක් නොවේ;
2. පරීක්ෂකයින් දරුවන් නොවේ;
3. එය ක්‍රීඩාවක් නොවේ;
4. එය සමාගමේ මුදල් නාස්ති කරයි.

QA දෝෂ සොයා ගැනීමට පමණක් නොව , පද්ධතිය කෙතරම් බුද්ධිමත්ද යන්න, පරිශීලකයාගේ ඉගෙනීමේ වක්‍රය කුමක්ද, භාවිතාව සහ පොදුවේ ප්‍රවේශවීමේ හැකියාව ගැන කරදර විය යුතුය. උදාහරණයක් ලෙස: "පද්ධතිය අවලස්සනද ?", "පරිශීලකයාගේ වර්ණය අන්ධද ? දේවල් රතු සහ කොළද?" ඔවුන් ද පැමිණිලි කළ යුතුය.

පද්ධතියක් QA සමත් වීම සඳහා වන අවම අවශ්‍යතා සාමාන්‍යයෙන් විස්තර කරනුයේ එම සුවිශේෂී ලක්ෂණය සඳහා පරිශීලක කතාවක හෝ PO විසින් පද්ධතිය ඔහුගේ හිසෙහි තබා ගැනීමට කොතරම් ඉන්ද්‍රජාලිකද යන්නයි.

tl; dr

එය දෝෂ පමණක් නොව, පරීක්ෂකයින් මෙම පටු දෘෂ්ටියෙන් වර්ධනය විය යුතුය.

නරක අදහසක්.

පරීක්ෂකයාගේ දෘෂ්ටි කෝණයෙන්: "එබැවින් ඔවුන් දැඩි ලෙස පරීක්‍ෂා කරනු ඇත, මන්ද දෝෂ පවතින බව ඔවුන් දන්නා අතර ඒවා සොයා නොගැනීම ඔවුන්ගේ නොහැකියාව ලෙස සැලකිය හැකිය." මූලික වශයෙන් devs යනු කේතය උගුලට හසු කර ගැනීමයි. ස්වල්ප දෙනෙක් වැඩ කිරීමට කැමති වන්නේ අවසානයේ තේරුමක් නැති (දෝෂ කල්තියා දන්නා නිසා) නමුත් ඒවා තවමත් දැනෙන ආකාරය කෙරෙහි බලපායි. උගුල් අටවා නොගැනීම සම්බන්ධයෙන් පැහැදිලි ද ments ුවම් තිබේ නම්, තවත් බොහෝ දේ. දෝෂ සොයාගැනීමේදී පරීක්ෂකයින් ස rive ල වන බව ඔබ දන්නවාද? එය විෂ සහිත ගැටුම්කාරී පරිසරයක් මෙන් පෙනේ; ඔවුන් පරීක්ෂා කරන කේතය උසස් තත්ත්වයේ නම් QA සතුටු විය යුතුය. දෝෂය මඟින් ඔවුන්ට මුදල් ගෙවනු ලැබුවද ... http://thedailywtf.com/articles/The-Defect-Black-Market

දේව්ගේ දෘෂ්ටි කෝණයෙන්: ඔබ දන්නා දෝෂ සොයා ගැනීමට QAs උනන්දු කරනු ලැබේ. බව හොඳින් හැක වැඩි දොර පිටතට යන්නේ සැබෑ දෝෂ සම්භාවිතාව; QAs අවම වශයෙන් ඔවුන්ගේ කාලය වැය කරන්නේ රෝපණය කිරීමට පහසු වන ආකාරයේ දෝෂයක් සෙවීමට මිස සැබවින්ම සියුම් ඒවා නොවේ. ප්ලස් උගුලක් එය දොරෙන් එළියට ගෙන ඒමට කුඩා අවස්ථාවක් තිබේ.

මෙය අභිප්‍රේරණයට අයහපත් වන්නේ මන්ද සහ සාමාන්‍යයෙන් භයානක පුද්ගලයින් කළමනාකරණය කිරීම සඳහා ඉහත පිළිතුරු සමඟ මම සම්පුර්ණයෙන්ම එකඟ වෙමි. කෙසේ වෙතත්, මෙය සිදු නොකිරීමට හොඳ තාක්ෂණික හේතු තිබිය හැක:

නිෂ්පාදිතය QA වෙත යාමට පෙර, dev කණ්ඩායම කේතයේ අහඹු ස්ථානවල හිතාමතා දෝෂ කිහිපයක් එකතු කරයි. එම දෝෂයන් අවසාන නිෂ්පාදනය සමඟ නැව්ගත නොකිරීමට ඔවුන් මුල්, ක්‍රියාකාරී කේතය නිසි ලෙස උපස්ථ කරයි.

1. පළමු ප්‍රකාශය මත පදනම්ව, ඔබ කිසි විටෙකත් මෙම පාස් දෙක තුළ ඔබ අපේක්ෂිත නිෂ්පාදන කේතය පරීක්ෂා නොකරයි .

2. ගනුදෙනුකරුවෙකු සඳහා වෙනසක් කිරීමට ඉක්මන් වීමට උත්සාහ කරන විට, ඔබ විසින් නිකුත් කරන ලද නිෂ්පාදන කේතයට 'හිතාමතා' දෝෂයක් ඇතුළත් කිරීමේ සම්භාවිතාව ඔබ විශාල ලෙස වැඩි කරනු ඇතැයි මම සිතමි. යම් අවස්ථාවක රතු කම්මුල් කිහිපයක් ඇති විය හැක.

3. මෙය ඔබේ පරීක්ෂකයින් ඔබේ සංවර්ධකයින් මෙන් සිතීමට පුහුණු කරයි යැයි මම සිතමි (එනම් ටොම් මෙහි දෝෂයක් එකතු කරන්නේ කෙසේද) ටොම් ගැන නොසිතූ දෝෂ සොයා ගැනීමට ඇති ඉඩකඩ අඩු කරයි.

සංස්කරණය කරන්න

මෙම පිළිතුර ඔබේ QA ක්‍රියාවලිය පරීක්ෂා කිරීමේ සංකල්පය ගැන පමණක් බව මට පැහැදිලි විය යුතු අතර, ප්‍රශ්නයේ නිරූපණය කර ඇති නිශ්චිත ක්‍රමවේදය මම ආරක්ෂා නොකරමි.

සංස්කරණය අවසන් කරන්න

ඔබේ පරීක්ෂාව / පරීක්ෂා කිරීම ඇත්ත වශයෙන්ම ක්‍රියාත්මක වේදැයි පරීක්ෂා කිරීමට වලංගු හේතුවක් තිබේ. නිෂ්පාදනයෙන් මම ඔබට උදාහරණයක් දෙන්නම්, නමුත් මූලධර්මය සමාන වේ.

යන්ත්‍රයක් හරහා ද්‍රව්‍ය පෝෂණය කිරීමේදී එය සාමාන්‍ය දෙයකි. මෙය "කෙටි සංග්‍රහයක්" ලෙස හැඳින්වෙන අතර මෙය වලක්වා ගැනීම සඳහා අපි "කෙටි ආහාර සංවේදකය" ස්ථාපනය කළ හැකිය (සාමාන්‍යයෙන් ද්‍රව්‍ය මගින් අවහිර කරන ලද කදම්බ හරහා සංවේදකය). මෙම සංවේදකය මඟින් සම්පූර්ණ ආහාර දිගට ළඟා වන විට ද්‍රව්‍යයේ අවසානය හඳුනා ගනී. යන්ත්‍ර චක්‍රයේ එක්තරා අවස්ථාවක දී අපි සංවේදකය අවහිර වී ඇත්දැයි පරීක්ෂා කර බලා පරීක්‍ෂණය අසමත් වුවහොත් යන්ත්‍රය නවත්වන්න.

පරීක්ෂණයම අසමත් විය හැකි ආකාරය ගැන දැන් ඔබ සිතා බැලිය යුතුය. උදාහරණයක් ලෙස, සමහර අපිරිසිදු හෝ වෙනත් සුන්බුන් සංවේදකය අවහිර කළ හැකි අතර එය සෑම විටම "හරි" ලෙස වාර්තා කරනු ඇති අතර යන්ත්‍රය කිසි විටෙකත් නතර නොකරයි. එසේම, සංවේදකයේ ස්වභාවය නම්, කදම්භය පහර දුන් විට ග්‍රාහකය ක්‍රියාත්මක වන බැවින් ඔබ ස්ථාපනය කර ඇති සංවේදක වර්ගය මත පදනම්ව, සංවේදකය අවහිර නොවූ විට විද්‍යුත් වශයෙන් ඔබට “ඔන්” ආදානය ලැබේ . එයින් අදහස් වන්නේ කේබලය කපා හෝ විදුලිය එම සංවේදකයට අහිමි වුවහොත් හෝ ආදානය අසමත් වුවහොත්, ඔබේ වැඩසටහනේ තර්කනය "අක්‍රිය" කියවන අතර එයින් අදහස් වන්නේ "අවහිර" හෝ "හරි" යන්නයි.

පරීක්ෂණයේ මෙම අසාර්ථක ප්‍රකාරයන් හසු කර ගැනීම සඳහා, අපි සාමාන්‍යයෙන් දෙවන චෙක්පතක් ඇතුළු කරන්නේ චක්‍රයේ දෙවන කොටස තුළ සංවේදකය අවහිර කර ඇති බව තහවුරු කර ගැනීම සඳහා ය. මේ ආකාරයෙන් අපි පරීක්‍ෂණය ඇත්ත වශයෙන්ම තවමත් ක්‍රියාත්මකද යන්න පරීක්ෂා කර බලමු (අපට හැකි උපරිමයෙන්).

ඒ හා සමානව QA දෙපාර්තමේන්තුවක් අසමත් විය හැකි බොහෝ ක්‍රම තිබේ. සමහර විට ස්වයංක්‍රීය පරීක්ෂණ ක්‍රියාත්මක නොවූ අතර වාර්තාව පරීක්ෂණ දත්තවල පැරණි පිටපතක් දෙස බලයි. සමහර විට කවුරුහරි ඔවුන්ගේ රාජකාරිය හරියටම කරන්නේ නැහැ. QA දෙපාර්තමේන්තුව පරීක්ෂා කිරීම සාධාරණ දෙයකි.

නිසැකවම පසුබෑම වන්නේ "පරීක්ෂණ දෝෂයක්" මඟින් QA දෙපාර්තමේන්තුව හරහා සහ නිමි භාණ්ඩය බවට පත් කළ හැකි බවයි. නිෂ්පාදන කර්මාන්තයේ සමහර විට "රතු හාවා" ලෙස හැඳින්වෙන නරක කොටසක් ක්‍රියාවලියට ඇතුළු කරන අවස්ථා තිබේ (සාමාන්‍යයෙන් QA හි අයෙකු විසින්) ඔවුන් එම කොටස ක්‍රියාවලිය හරහා ගොස් එය කොපමණ කාලයක් ගතවේදැයි මැන බලයි. කොටස සොයාගෙන එය ඉවත් කරන්න. සාමාන්‍යයෙන් මෙම කොටස දීප්තිමත් රතු (හෝ තැඹිලි) ලෙස පින්තාරු කර ඇති බැවින් එය පහසුවෙන් සොයාගත හැකිය. මෙම පරීක්ෂණය අතරතුර යමෙකු ක්‍රියාවලිය හරහා ගමන් කරන ආකාරය යමෙකු බලා සිටින හෙයින්, එය අවසාන නිෂ්පාදනයට ඇතුළත් වීමේ අවස්ථාව ප්‍රායෝගිකව නැත. ඇත්ත වශයෙන්ම, යමෙකු දන්නා නරක කොටසක් ක්‍රියාවලියට විසි කර “පද්ධතියට එය සොයාගත හැකිදැයි බැලීමට” අපෝක්‍රිප්පාල් කථා ඇත,

අවංකවම, මම මෙම හැසිරීම නිර්දය ලෙස සදාචාර විරෝධී හා ප්‍රායෝගික නොවන ලෙස හඳුන්වන්නෙමි. සේවය අවසන් කිරීම නොවන්නේ නම් බරපතල ලෙස නැවත පුහුණු කිරීම අගමැතිට අවශ්‍ය වේ.

• තත්ත්ව සහතිකය පිළිබඳ සංකල්පය පිළිබඳ මූලික අවබෝධයක් නොමැති බව එයින් පෙන්නුම් කෙරේ . පරීක්ෂකයින් සංවර්ධකයින් ලෙස නොසිතිය යුතුය: ඔවුන් අවසාන පරිශීලකයින් මෙන් සිතිය යුතුය. QA කණ්ඩායම් ඇති වීමට සමස්ත හේතුව වන්නේ සංවර්ධකයින් සහජයෙන්ම කේතයට සමීප වීමයි; QA විසින් කේතයෙන් සෑහෙන දුරක් පවත්වා ගෙන යා යුතු අතර ඔවුන්ට devs අතපසු වූ දේ අල්ලා ගත හැකිය.
• එය QA උත්සාහය නාස්ති කරයි. මෙම දෝෂ සුළුපටු නොවන බව උපකල්පනය කිරීම - ඒවා ඇති විට පහත බලන්න- එයින් අදහස් කරන්නේ QA දැනටමත් නොදන්නා දේ සොයා බැලීමට කාලය හා සම්පත් වැය කරන බවයි.
• එය සංවර්ධක උත්සාහය නාස්ති කරයි. මෙම සුළු නොවන දෝෂ අල්ලා ගැනීමට QA පිරිසට, සංවර්ධකයින් පළමුව ඒවා ලිවිය යුතුය. මේ සඳහා තව දුරටත් උත්සාහ කිරීම අවශ්‍ය වන අතර, එය දෝෂ කේත කිරීම පමණක් නොව, මෘදුකාංග අවශ්‍යතා සහ සැලසුමද සැලකිල්ලට ගනී.
• එමඟින් නිෂ්පාදනය අනවශ්‍ය අවදානමකට ලක් කරයි. වෙනස්කම් නිසි ලෙස ඒකාබද්ධ නොවීමට පෙර එය කාලය පිළිබඳ ප්‍රශ්නයක් පමණි.
• එය ඉහත සඳහන් නොකරන්නේ නම් එය අර්ථ විරහිත ය . දන්නා සියලු දෝෂ සුළුපටු නම්, ඔවුන් ප්‍රමිතියෙන් තොර කම්කරුවන් අල්ලා නොගනී: ඔවුන් අල්ලා ගන්නේ කිසිසේත් වැඩ නොකරන පුද්ගලයින් පමණි. එය කිරීමට වඩා හොඳ ක්‍රම තිබේ.
• එය සේවා පරිසරය විෂ කරයි . ඔබේ QA පරීක්ෂකයින් වෘත්තිකයන්. වෙනත් ආකාරයකින් සැක කිරීමට සැබෑ හේතුවක් ඇති තුරු ඔවුන් වෘත්තීය යැයි විශ්වාස කළ යුතුය . වන විට එහි වේ එසේ සැක කිරීමට හේතුවක් නිසා, ඒ වෙනුවට මෙම මනස ක්රීඩා විධිමත් පරීක්ෂණයක් කිරීමට හැකි විය යුතුය. වෙන ඕනෑම දෙයක් චිත්ත ධෛර්යය නැති කරයි.

බරපතල ලෙස. මෙම විශේෂිත අවස්ථාවෙහිදී අගමැතිවරයාගේ මානසික ආතතිය මනාව තහවුරු වූවක් වුවද, මෙය ව්‍යාපාර කළමණාකරන පරීක්ෂකයින් සිටින අයෙකු නොවේ.

පුද්ගලිකව, මෙම ප්රවේශය ගැන මට අපහසුතාවයක් දැනේ.

මා සැලකිලිමත් වන ප්‍රධානතම දෙය නම් හිතාමතාම දෝෂ ඇතුළත් කිරීමේ ප්‍රායෝගිකත්වයයි . මෙය මට පුරෝකථනය කළ හැකි ඕනෑම ආකාරයකින් කිරීමට අපහසු බව පෙනේ.

ඕනෑම කේත වෙනස් කිරීමක් (හිතාමතා හෝ වෙනත් ආකාරයකින්) අතුරු ආබාධ ඇතිවීමේ අවදානමක් ඇත. පරීක්ෂණයේදී මෙම අතුරු ආබාධ හොඳින් අනාවරණය විය හැකි නමුත් මූල හේතුව කුමක්ද යන්න පැහැදිලි නොවිය හැකිය (දෝෂය රෝපණය කළ සංවර්ධකයාට පවා). මා අදහස් කරන්නේ කුමක්දැයි ඔබ දන්නේ නම් එයට "ආරක්ෂිත" බවක් දැනෙන්නේ නැත (මම මෙහි කතා කරන්නේ මගේ බඩවැලෙන්).

එසේම, පරීක්ෂකයා ඇත්ත වශයෙන්ම මුදා හැරීමට නොයන බොහෝ කාලයක් පරීක්ෂා කිරීමේ කේත නාස්ති කරනු ඇත. හිතාමතාම දෝෂ ඉවත් කළ පසු, කෙසේ හෝ සම්පූර්ණ නැවත පරීක්ෂණයක් කළ යුතු බව මගේ මතයයි. පරීක්ෂණයේ සම්පූර්ණ ලක්ෂ්‍යය එයයි. යමක් වෙනස් වේ, ඕනෑම දෙයක් , ඔබ සියල්ල නැවත පරීක්ෂා කරයි . හරි, මම දන්නවා එය කිසි විටෙකත් ප්‍රායෝගිකව සිදු නොවන බව, නමුත් ප්‍රතිගාමී පරීක්ෂාව යනු එයයි.

ඉතින්, සමස්තයක් වශයෙන්, ඒත්තු ගැන්වී නැත.

අනෙක් අතට, අපි පාරිභෝගිකයින්ට QA කණ්ඩායම්වල වැඩ සත්‍යාපනය කිරීමට ඉඩ දෙන අතර එය වඩාත් සුදුසු නොවේ. එය ඉතා ප්‍රබල ප්‍රතිපෝෂණ වළල්ලකි.

දැනටමත් ලබා දී ඇති සියලු හේතුන් සඳහා එය නරක අදහසකි, නමුත් දෝෂ රෝපණය වෙනත් අරමුණක් සඳහා ප්රයෝජනවත් මෙවලමකි. QA ක්‍රියාවලිය කෙතරම් effective ලදායීද යන්න පිළිබඳ දළ මෙට්‍රික් එකක් ලබා ගැනීමට ඔබට එය භාවිතා කළ හැකිය.

එහි සරලම අවස්ථාවේ දී, අපි ඔබට දෝෂ 100 ක් බීජ යැයි කියමු, ඒවා සැබෑ දෝෂවල සම්පූර්ණ කාල පරාසය නියෝජනය කරයි (මම දනිමි, නොහැක්කකි, නමුත් මම සරල කරමි). අත්හදා බැලීම නරක් වීම වළක්වා ගැනීම සඳහා ඔබ මෙය කරන්නේ යැයි ඔබ QA ට නොකියයි . QA ක්‍රියාවලිය අවසානයේදී, බීජ 100 න් 60 ක් (සහ වෙනත් සැබෑ දෝෂ) ඔවුන් සොයා ගත් බව කියමු. දැන් ඔබ දන්නවා QA විසින් දෝෂ වලින් 60% ක් සොයා ගනී.

QA සොයාගත් සැබෑ දෝෂ ගණන ගණනය කිරීමෙන් ඔබට මෙය තවදුරටත් දිගු කළ හැකි අතර ව්‍යාජ දෝෂ අනුපාතය යොදන්න. අපගේ උදාහරණයේ දී, QA සැබෑ දෝෂ 200 ක් සොයා ගත්තේ නම් ඔබට නිගමනය කළ හැක්කේ ඒවායින් 60% ක් පමණක් හමු වූ බැවින් 133 ක් ඉතිරිව ඇති බවයි.

ඇත්ත වශයෙන්ම, මෙය විශාල දෝෂ සහිත පුළුල් තක්සේරුවක් පමණි. යථාර්ථවාදී, නියෝජිත දෝෂ ලිවීම දුෂ්කර ය. ඔබ ලියන දෝෂ QA සොයා ගැනීම පහසු වනු ඇත, මන්ද සංවර්ධකයින් දෝෂ ලිවීමට පුහුණු කර ඇති බැවිනි. ඕෆ්-වන් දෝෂ, යුනිකෝඩ් වැරදි, බෆරය පිටාර ගැලීම සහ යනාදී දෝෂ වර්ගයක් අනුකරණය කිරීම වඩා හොඳ විය හැකිය.

සංවර්ධක ඒකක පරීක්ෂාව, අඛණ්ඩව ඒකාබද්ධ කිරීම සහ ලබා ගත හැකි නම් කැපවූ QA කණ්ඩායමක් ඇතුළත් වන සමස්ත QA ක්‍රියාවලියට මෙය අදාළ කළ යුතුය .

මෙය මෙට්‍රික් එකක් වන අතර කළමනාකරණ අභිප්‍රේරණ මෙවලමක් ලෙස පැහැර නොගත යුතුය.

නරක අදහසක්.

සංවර්ධකයින් බොහෝ විට ගෙන එන තාර්කික, ද්විමය ප්‍රවේශය මෙයයි, නමුත් එය QE සඳහා පහත් කිරීමකි. එය හුදෙක් පෙන්නුම් කරන්නේ විශ්වාසයේ lack නතාවයයි. QEs බොහෝ විට ඔවුන්ගෙන් වැඩි ආදානයකින් තොරව මෙම තත්වයන් තුළ ස්ථානගත වන අතර, එය ඔවුන් එය සමඟ හොඳින් සිටින බව උපකල්පනය කර ඇති අතර වෙනත් ආකාරයකින් යෝජනා කිරීම ඔවුන්ගේ ස්ථානය නොවේ.

මේ ආකාරයේ චින්තනය QEs අතින් පරීක්ෂකයින් වීම පමණක් වන අතර පරීක්ෂණයට ලක්වන සත්‍ය කේතය තේරුම් ගැනීමට පෙළඹවීමක් නොකරයි.

මම ජ්‍යෙෂ් Q QE කෙනෙක් වන අතර මෙය මා සේවය කළ බොහෝ සංවිධානවල හුරුපුරුදු කරුණකි.

මම නරක අදහසක් කියන්නම්.

එකක්: ක්‍රමලේඛකයින් හිතාමතා දෝෂ කේතයට දමා කාලය ගත කිරීමට යන අතර හොඳ අනුවාදය සුරැකීමට යම් උත්සාහයක් දරයි. පරීක්ෂකයින් අනුමාන වශයෙන් රෝපණය කළ දෝෂය සමඟ ඇති සියල්ල ඇතුළුව සෑම දෙයක්ම පරික්ෂා කළ යුතු අතර, ඔවුන් එකක් සොයාගත් විට ඔවුන්ට ආපසු ගොස් එම පරීක්ෂණය නැවත ක්‍රියාත්මක කිරීමට සිදුවනු ඇත්තේ මෙය ඇත්ත වශයෙන්ම දෝෂයක්ද යන්න තහවුරු කර ගැනීම සඳහාය (පරීක්ෂකයා ව්‍යාකූල වී ඇති බව නොවේ) යම් ආකාරයකින්). අවම වශයෙන්, පරීක්ෂකයින් රෝපණය කළ දෝෂ ලිවීමට කාලය ගත කරනු ඇත. එවිට ක්‍රමලේඛකයන්ට තමන් රෝපණය කළ දෝෂය නිවැරදි කිරීමට කාලය ගත කිරීමට සිදුවේ. මෙය හොඳ කේතයක් ලිවීමට සහ සැබෑ දෝෂ ලිවීමට උත්සාහ කළ හැකි විශාල උත්සාහයකි.

දෙක: ක්‍රමලේඛකයින් සහ / හෝ කළමනාකාරිත්වය සිතන්නේ ඔවුන් තම රාජකාරිය නොකරන බවත් ළමයින් ලෙස සැලකිය යුතු බවත් එය පරීක්ෂකයින්ට පැහැදිලි පණිවිඩයක් යවයි. මෙය චිත්ත ධෛර්යයට යහපත් යැයි මට සිතාගත නොහැකිය. ක්‍රමලේඛකයෙකු ලෙස, මට වැඩසටහනක් සඳහා නොපැහැදිලි හෝ පරස්පර විරෝධී පිරිවිතර ලබා දී ඒවා පැහැදිලි කර ගැනීම සඳහා යම් කාලයක් ගත කිරීමට සිදුවුවහොත්, පැය හෝ දින නාස්ති කිරීමෙන් පසු මගේ ලොක්කා මට කීවේ, “අනේ, මම හිතාමතාම පරස්පර ප්‍රකාශ ඉදිරිපත් කළෙමි පිරිවිතර ඔබ ඒවා කියවන බවට වග බලා ගැනීම සඳහා ", මම හිතන්නේ මම ඇත්තටම කෝපයට පත් වනු ඇත. එය නිතිපතා සිදු වූවා නම්, එය මට වෙනත් රැකියාවක් සොයා ගැනීමට ප්‍රමාණවත් වේ.

සැබෑ ජීවිතයේ දී, වඩාත්ම සුළු කේත වෙනස්වීම් හැර අන් සියල්ලටම දෝෂ ඇත. පරීක්ෂකයින් සෑහීමකට පත්වීම පිළිබඳව මට කිසි විටෙකත් ගැටළුවක් නොවීය, මන්ද ඔවුන්ට ලබා දුන් පළමු කෙටුම්පත් කේතය බොහෝ විට 100% පරිපූර්ණ විය. ප්‍රමාණවත් රැකියාවක් නොකරන කම්මැලි පරීක්ෂකයින් සමඟ මට ගනුදෙනු කිරීමට සිදුවිය, නමුත් ක්‍රමලේඛකයින් එතරම් පරිපූර්ණ බැවින් ඔවුන්ට එය නොලැබුණි. මා සමඟ වැඩ කළ හොඳම පරීක්‍ෂක පුද්ගලයා වරක් මට කීවේ නව මෘදුකාංග නිකුතුවක් සඳහා ඔහු දෝෂ 100 ක් සොයා ගැනීම සඳහා පෞද්ගලික ඉලක්කයක් තබා ගත් බවයි. හරි, 100 යථාර්ථවාදී සංඛ්‍යාවක්ද යන්න රඳා පවතින්නේ නිෂ්පාදිතය කොතරම් විශාලද සහ වෙනස්කම් කොතරම් පුළුල්ද යන්න මතය, නමුත් අපගේ නඩුවේදී, ඔහු සෑම විටම පාහේ එම ඉලක්කය සපුරා ගැනීමට සමත් විය. සමහර විට ඔහුට පණිවුඩයක වැරදි අක්ෂර වින්‍යාසයක් "දෝෂයක්" ලෙස හැඳින්වීම වැනි දේවල් දිගු කිරීමට සිදු විය, නමුත් හේයි, එය නිවැරදි කළ යුතුව තිබුණි.

පෝස්ට් ස්ක්‍රිප්ට්: ඔබ මෙය කරන්නේ නම්, ඉක්මනින් හෝ පසුව ක්‍රමලේඛකයින් හිතාමතාම දෝෂයක් රෝපණය කිරීමට යන බව මම ඔට්ටු අල්ලමි, පරීක්ෂකයින්ට එම විශේෂිත එක සොයාගත නොහැකි අතර ක්‍රමලේඛකයන්ට හොඳ කේතය නැවත දැමීමට අමතක වේ. එබැවින් දැන් හිතාමතාම රෝපණය කරන ලද දෝෂයක් පාරිභෝගිකයා වෙත යවනු ලැබේ.

මම හිතන්නේ නැහැ මේක නරක අදහසක් කියලා. වැඩ වඩා හොඳ යැයි මම අනුමාන කරන බොහෝ දේ ඇත:

1. ඔබට හැකි ඕනෑම ආකාරයකින් ගුණාත්මකභාවය සඳහා QA වගවීම කරන්න. නිදසුනක් වශයෙන්, ඔවුන්ගේ වගකීම ද සහාය දැක්වීමෙන්. නැව්ගත කරන ලද නිෂ්පාදනවල ගුණාත්මක බව සහතික කිරීම සඳහා මෙය ඔවුන්ගේ අභිප්‍රේරණය වැඩි කරනු ඇත. ප්‍රමාණවත් නොවීම (දෝෂය, පැහැදිලිවම නැතිවූ ලක්ෂණය, ප්‍රති-බුද්ධිමය හැසිරීම) ඔබම සොයා ගැනීමට සෑම විටම අඩු උත්සාහයක් ගත යුතුය. එම වගකීම සමහරක් සංවර්ධකයින් වෙත පැවරීමෙන් QA හට ඔවුන්ගේ කාර්යය උපරිමයෙන් කිරීමට උදව් කිරීමට ඔවුන්ගේ අභිප්‍රේරණය වැඩි විය හැකිය.

2. තරඟ කළ හැකි QA කණ්ඩායම් කිහිපයක් තබා ගන්න. ඇත්ත වශයෙන්ම ඔබ සංවේදී මෙට්‍රික් එකක් සොයා ගත යුතුය. නිසැකවම ගැටළු ගණන පමණක් නොවේ. යෝජිත වැඩිදියුණු කිරීම්වල අඩුපාඩුවෙහි බරපතලකම හෝ ව්‍යාපාර වටිනාකම (පාර්ශවකරුවන් විසින් තීරණය කරනු ලබන පරිදි) සාධක කිරීම උපකාරී වේ.

QA "ප්‍රමාණවත්ද" යන්න කීමට අපහසුය. QA "සදාකාලිකව වැඩිදියුණු කිරීම" සඳහා මාර්ග සොයා ගැනීම දිගු කාලීනව පහසු සහ සමහර විට ඊටත් වඩා හොඳය.

කෙසේ වෙතත්, ඔබ හිතාමතා දෝෂ හඳුන්වා දෙන්නේ නම් දැනුවත් විය යුතු එක් ප්‍රශ්නයක් තිබේ: “නිවැරදි” කේතය මුලින් ම නිවැරදි බව ඔබ දන්නේ කෙසේද? 2 වන QA පසු ඔබ සොයා නොගත් සියලු හිතාමතා දෝෂ ඉවත් කරයි. ඔබ ඒවා වෙනත් ආකාරයකින් කැඩී ඇති කේතයකින් ප්‍රතිස්ථාපනය නොකරන බව හෝ මීට පෙර ළඟා විය නොහැකි බිඳුණු හැසිරීමට ඔබ ඉඩ නොදෙන බව දැන ගැනීමට ක්‍රමයක් නොමැත (අතිශයෝක්තියෙන් උදාහරණය: හිතාමතා දෝෂයක් නිසා සමහර දෙබස් විවෘත නොවීය, නමුත් දෙබස් කැඩී ඇත - පරීක්ෂකයින්ට එය දැක ගැනීමට නොහැකි වූ නිසා ඔබ සොයා නොගනී).

අනෙක් අය පවසා ඇති පරිදි, සංවර්ධකයින් මෘදුකාංගයේ දෝෂ එකතු කිරීම නොකළ යුතුය, නමුත් එය පරීක්ෂණ ක්‍රියාවලියේ කොටසක් ලෙස මෘදුකාංගයට දෝෂ එකතු කිරීම ඔබේ පරීක්ෂණ කට්ටලයට නීත්‍යානුකූල උපාය මාර්ගයකි .

එය විකෘති පරීක්ෂණ ලෙස හැඳින්වේ . මූලාශ්‍ර කේතයේ (විකෘති ලෙස හැඳින්වෙන) කුඩා වෙනස්කම් නිර්මාණය කිරීම ස්වයංක්‍රීය කිරීම සඳහා මෘදුකාංග භාවිතා කිරීම මෙහි අදහසයි. වෙනස්කම් සැලසුම් කර ඇත්තේ වෙනස් හැසිරීම් නිර්මාණය කිරීම සඳහා ය, උදාහරණයක් ලෙස අපට වෙනස් විය හැකිය

if x < 10:
    print "X is small!"

වෙත

# we flipped the inequality operator
if x > 10:
    print "X is small!"

හොඳ ඒකකය පරීක්ෂණ සහ අපේක්ෂා ලෙස mutant කේතය කැබැල්ලක් තවදුරටත් ක්රියා කරන අතර ඒ හඳුනා යුතු ද mutant මරුට . මුල් කේතය පරීක්ෂණයෙන් සමත් වූ විට සහ සියලුම විකෘති (ක්‍රියාකාරී ලෙස සමාන නොවන) පරීක්ෂණය අසමත් වූ විට, ඔබේ කේතය සහ ඔබේ පරීක්ෂණ ශක්තිමත් බව ඔබ දන්නවා .

මම අදහසට කැමතියි. ජෙනරාල් පැටන් පැවසුවේ, “ඔබ සාමයෙන් දහඩිය දමන තරමට, ඔබ යුද්ධයෙන් ලේ ගැලීම අඩු වේ” යනුවෙනි.

හිතාමතා දෝෂ දැමීම පරීක්ෂකයින්ගේ "කාලය නාස්ති කරයි". නමුත් එමඟින් ඔවුන් වඩාත් වෙහෙස මහන්සි වී වැඩ කරයි, එයින් අදහස් කරන්නේ ඔවුන් නොදැනුවත්වම දෝෂ සොයා ගැනීමේ වඩා හොඳ කාර්යයක් කරනු ඇති බවයි. (තවද ඔබට "මුල් පිටපතෙහි පිටපතක් ඇත, එබැවින් ඔබ කළ දේ සමඟ ජීවත් වීමට අවශ්‍ය නැත.)

හිතාමතාම දෝෂ සොයා ගැනීම දිගු කාලීනව හිතාමතාම ගනුදෙනු කිරීමේ පිරිවැය පිළිබඳ වැඩි ශෝකයක් ඉතිරි කර දෙනු ඇත.

ප්ලස්, ඔබේ පරීක්ෂකයින් කොතරම් හොඳද යන්න පිළිබඳ අදහසක් ඔබට ලබා ගත හැකිය, එයින් සුළු ප්‍රතිලාභයක් නොවේ.

ස්වකීය කුසලතාව මත ත්‍යාගයක් හෝ ද punishment ුවමක් සඳහා පදනමක් නොමැත, නමුත් ඔබ ඉලක්ක කරන හැසිරීමේ ප්‍රති result ලය මත. සමහර විට බලාපොරොත්තු නොවූ ප්රතිවිපාක ද ඇත. QA කණ්ඩායම මන්දගාමී වීමෙන් වළක්වා ගැනීම හෝ සමහර කළමනාකරුට ඔහු යම්කිසි දායකත්වයක් ලබා දෙන බවක් හැඟීම ඇති කිරීම ඔහු ඉලක්කය කරා යන බව නොදැන ය.

ධනාත්මක ප්‍රති come ලය - දෝෂ සොයා ගැනීමට QA කණ්ඩායම වඩා වෙහෙස මහන්සි වී වැඩ කරයි. කවුද දන්නේ, සමහර විට ඔවුන් මෙය දකින්නේ අභියෝගයක් ලෙසයි. එය මිත්‍රශීලී ක්‍රීඩාවකි. නැතහොත් ඔවුන් කරන්නේ ඔවුන් නරඹමින් සිටින නිසාය (Hawthorne Effect?).

Neg ණාත්මක ප්‍රති come ල - ඔවුන් වෙහෙස මහන්සි වී වැඩ නොකරන අතර කෙසේ හෝ දෝෂය සොයා ගනී. QA මෙය සුලු හා විරුද්ධවාදී ලෙස දකී. ඉතින් දැන්, ඔවුන් අධි-දෝෂ සොයා ගැනීමේ ධාවකය වෙත ගොස් සියලු ආකාරයේ නයිට්-පික් කුඩා ගැටළු නැවත ලබා දෙයි. මම තිර රුවක් ගෙන එය පීඩීඑෆ් බවට පරිවර්තනය කර 500% ක් බැලූ විට එම අකුරු නිසි ලෙස ක්‍රියාත්මක නොවේ.

බලපෑමක් නැත - මේ ආකාරයෙන් මට ශබ්ද කිරීමෙන් කිසිදු වෙනසක් සිදු නොවේ, එබැවින් කරදර වන්නේ ඇයි? ඔබ කාලය නාස්ති කිරීම හා මිනිසුන් කෝපයට පත් කිරීමේ අවදානමක් ඇත.

මෙය 90% ක්ම ක්‍රියාත්මක නොවන බවට අප සැමට එකඟ විය හැකිය. එය අනෙක් 10% ට එතරම් යහපත් නොවේ. ඔබම දේවල් පරීක්ෂා කරන්න. හිතාමතා කේත දෝෂ ඇති නිකුතුවක් ගැන ගනුදෙනුකරුවන් වඩාත් තෘප්තිමත්ද? එය වෙනත් අංශවල සේවක චිත්ත ධෛර්යයට හා tivity ලදායිතාවයට බලපාන්නේද? පිරිවැටුම වැඩි කරන්න? ඔයා අපිට කියන්න.

සංවර්ධකයින් විසින්ම පරීක්ෂණ ලිවීමට හා ක්‍රියාත්මක කිරීමට අපේක්ෂා කරන ලෝකයකින් පැමිණීම, ඔබ සඳහන් කරන මෙම “පරීක්ෂණ” “QA” සිලෝව මා බිය ගන්වා ව්‍යාකූල කරයි, එබැවින් මම මෙම දෘෂ්ටිකෝණයෙන් පිළිතුරු දීමට උත්සාහ කරමි. අනෙක් අතට, සුදුසුකම් ලත් QA ඉංජිනේරුවන්, මගේ දෘෂ්ටිකෝණයෙන් (@ ස්පාර්ක්ගේ පිළිතුරෙහි හොඳින් විස්තර කර ඇති පරිදි), මෘදුකාංගය පරිශීලක කතන්දර සම්පුර්ණයෙන්ම තෘප්තිමත් කරන බවටත්, සමස්ත “ගුණාත්මකභාවය” ඇති බවටත් වග බලා ගැනීමේ විශාල ගැටළු කෙරෙහි අවධානය යොමු කළ යුතුය. දෝෂ සඳහා දඩයම් කිරීම වෙනුවට මෘදුකාංගය අදහස් කරන වසම).

මා මෙහි ඇදී ගියේ @ ජේම්ස් මැක්ලියෝඩ් විසින් "අඩුපාඩු එන්නත් කිරීම" පිළිබඳ ප්‍රශ්නයට අදහස් දැක්වීමේදී සඳහන් කර ඇත. ආරක්ෂක සංකල්පය ගැඹුරින් ඉලක්ක කර ගැනීම සඳහා පද්ධතියට දෝෂ එන්නත් කරන්නේ කෙසේදැයි සංවර්ධකයින් සිතීම හොඳ අදහසක් යැයි මම සිතමි. මුළු පද්ධතියම පාලනයකින් තොරව (පැහැදිලි ක්‍රියාකාරී ලොග් වීමකින් තොරව) ගෙන ඒමට, දත්ත දූෂණයක් ඇති කිරීමට හෝ ආරක්ෂක අවදානමක් නිරාවරණය කිරීමට කිසිඳු දෝෂයක් ප්‍රමාණවත් නොවේ.

එක් එක් සංරචකයේ සංවර්ධකයින් හිතාමතාම අඩුපාඩු නිර්මාණය කිරීම, අනෙකුත් සංරචක හැසිරවීම සහ සමස්තයක් ලෙස ඔවුන්ගේ මෘදුකාංග පිළිබඳ වඩාත් විරුද්ධවාදී මානසිකත්වයක් ඇති කිරීම මෘදුකාංගයේ ශක්තිමත් බව වැඩි දියුණු කිරීම සඳහා බොහෝ දේ කළ හැකිය. ක්ෂණික ප්‍රතිලාභය පවා වැදගත් විය හැකිය - එවැනි එක් එක් ආකාරයේ අඩුපාඩුවක් එන්නත් කිරීමේදී (මෙතෙක් පරීක්ෂාවට ලක් නොවූ), සංවර්ධකයා වහාම නව පරීක්ෂණයකින් එය ආවරණය කරනු ඇති අතර එය ධජයකින් සකසනු ඇත. දෝෂය කෙටි කාලයක් සඳහා කේත පදනමේ ජීවත් වීමට ඉඩ දෙන්න, පසුව භාරදීමට පෙර (සහ අඩුපාඩුව ඉවත් කර), පරීක්ෂණ කට්ටලය වඩාත් පුළුල් වන පරිදි නිත්‍ය පරීක්ෂණයක් බවට පත් කිරීමට ඉඩ දෙන්න.

ආශ්‍රිත විකල්පයක් නම්, වෙනත් සංරචක සමඟ කටයුතු කරන්නේ කෙසේද යන්න පරීක්ෂා කිරීම සඳහා විශේෂිත සංරචකවල විශේෂාංග හිතාමතාම අක්‍රිය කිරීමට විශේෂාංග ධජ භාවිතා කිරීමයි. 2012 මැතිවරණය සඳහා ඔබාමා කණ්ඩායම විසින් භාවිතා කළ යුතු මෘදුකාංග යටිතල පහසුකම් පිළිබඳ මෙතරම් පුළුල් පරීක්ෂණයක් විස්තර කෙරෙන “පළමු ප්‍රතිචාරකයින්ගෙන් ඉගෙනීම: ඔබේ පද්ධති වැඩ කළ යුතු විට” යන නිදහස් පොත / ලිපිය කියවීමට මම නිර්දේශ කරමි .

අනෙක් අය දැනටමත් පවසා ඇති පරිදි, දෝෂ සොයා ගැනීම QA හි කාර්යයක් නොවේ. මම තව දුරටත් ගොස් තාක්‍ෂණිකව එය ඔවුන්ගේ කාර්යයක් නොවන බව කියමි. තමන්ගේම කේත දෝෂ රහිතව තබා ගැනීම සඳහා සංවර්ධකයින් වගකිව යුතුය. නව කේත කවදා හෝ සිදු කිරීමට පෙර පරීක්ෂණ කට්ටල ධාවනය කළ යුතු අතර, පරීක්ෂණ කට්ටල අසමත් වුවහොත්, එය කිසි විටෙකත් QA වෙත ප්‍රථමයෙන් ලබා නොදිය යුතුය. හිතාමතාම දෝෂ හඳුන්වාදීම යන්නෙන් ඔබට අනිවාර්යයෙන්ම ඔබේ පරීක්ෂණ කට්ටල සමත් විය නොහැක, එබැවින් ඔබේ කේතය QA වෙත යන්නේ ඇයි?

QA හි කාර්යය වන්නේ එය ක්‍රියාත්මක කරන පරිශීලක කථා වලට එරෙහිව යෙදුම වලංගු කිරීමයි. ඔවුන් ප්‍රවාහය, යූඅයි යනාදිය පරීක්‍ෂා කළ යුතු අතර පරිශීලකයාට කළ හැකි සෑම දෙයක්ම පරිශීලකයාට කළ හැකි බවට සහතික විය යුතුය. මෙය කරන අතරතුර, ඇත්ත වශයෙන්ම, ඔවුන් දෝෂ මත පැටලෙන්නට පුළුවන, නමුත් එය ඔවුන් කරන දේ නොව ඔවුන් කරන දේවල අතුරු ආබාධයකි. QA යන්නෙන් අදහස් කරන්නේ තත්ත්ව සහතිකය මිස දෝෂ රහිත සහතික කිරීම බව මතක තබා ගන්න.

මෙය අවශ්‍ය තරම් පිස්සු නොවේ. එය ඔබේ අභිප්‍රේරණය මත රඳා පවතී. ඔබේ ටෙස්ට් කණ්ඩායම පරාජය කිරීමට ඔබ සැරයටියක් සොයන්නේ නම්, එය පිස්සු වනු ඇත. අනෙක් අතට, මෘදුකාංග සංවර්ධනයේ වඩාත්ම දුෂ්කර දෙය නම් ඔබේ පරීක්ෂණ ප්‍රවේශය කෙතරම් effective ලදායීද යන්න දැන ගැනීමයි.

එබැවින් ඔබ එය නිසියාකාරව ව්‍යුහගත කරන්නේ නම්, ඔබ නැව්ගත කිරීමට යන නිෂ්පාදනයේ පදනම් විරහිත දෝෂ කොපමණ ප්‍රමාණයක් ඇත්දැයි තක්සේරු කිරීමට ඔබට මෙම තාක්ෂණය භාවිතා කළ හැකිය. එබැවින් ඔබ ඔබේ පරීක්ෂණයේදී දෝෂ 100 ක් කෘතිමව බීජ කර ඇති බව සිතන්න, පරීක්ෂකයින් ඒවායින් 50 ක් සොයා ගනී. එවිට ඔබට අනුමාන කළ නොහැකි දෝෂ 50 ක් හමු වූවා නම්, සොයා ගැනීමට 50 ක් ඉතිරිව ඇති බවට යම් සම්භාවිතාවක් ඇති බව ඔබට අනුමාන කළ හැකිය.

ඇත්ත වශයෙන්ම, මෙය බොහෝ ගැටළු වලින් පිරී ඇත. මෙම සංඛ්‍යාලේඛන මත පදනම්ව නැව්ගත කළ යුතුද යන්න ඔබට තීරණය කළ හැකිය, නමුත් සැබෑ ජීවිතයේ දී, ඔබට ඉතා නරක ප්‍රශ්නයක් හෝ සුළු කෝපයක් දහසක් සොයා ගත හැකිය.

තවමත් - දැනුම යනු බලය වන අතර මෙම තාක්ෂණය නොමැතිව ඔබේ කේත පදනමේ ගුණාත්මකභාවය පිළිබඳ ඊටත් වඩා අඩු අදහසක් ඔබට ඇත. ඔබට එය ගෞරවාන්විතව හා නිවැරදි හේතුන් මත ක්‍රියාත්මක කළ හැකි නම්, මම කියන්නේ "ඇයි නැත්තේ?"

වෙන කිසිවෙකු තවම සඳහන් කර නැති එක් දෙයක්: විකෘති පරීක්ෂණ .

ස්වයංක්‍රීය මෙවලමක් ඔබගේ ප්‍රභව කේතය ගෙන හිතාමතාම එයට දෝෂ ඇතුල් කරන්නේ මෙතැනදීය. (උදා: අහඹු ලෙස තෝරාගත් ප්‍රකාශයක් මකා දමන්න, සහ AND එකක් හෝ වෙනත් දෙයකට වෙනස් කරන්න.) ඉන්පසු එය ඔබගේ සම්පූර්ණ පරීක්ෂණ කට්ටලය ක්‍රියාත්මක කරන අතර පරීක්ෂණ සමත් වේදැයි පරීක්ෂා කරයි.

සියලුම පරීක්ෂණ සමත් වුවහොත්, හැකියාවන් දෙකක් තිබේ:

• වෙනස් කළ දෙය කිසිවක් නොකරයි. වෙනත් වචන වලින් කිවහොත්, ඔබට මළ කේතයක් ඇත.
• මෙම වෙනස මඟින් ඔබගේ පරීක්ෂණ කට්ටලය හසු නොවන දෝෂයක් හඳුන්වා දී ඇත. ඔබට තවත් පරීක්ෂණ අවශ්‍යයි.

ඔබගේ යෝජනාව මෙන් නොව, මා ඉහත විස්තර කර ඇති සියල්ල ස්වයංක්‍රීය බව සලකන්න . අර්ථ විරහිත දෝෂ අතින් ඇතුල් කිරීමට ඔබ සංවර්ධකයින්ගේ කාලය නාස්ති නොකරයි. ඔබ දන්නා දෝෂ සොයා ගැනීමට පරීක්ෂකයින්ගේ කාලය නාස්ති නොකරයි. ඔබ භාවිතා කරන එකම දෙය යන්ත්‍ර කාලයයි, එය වඩා ලාභදායී වේ. (එකම පරීක්ෂණය 20,000 වතාවක් යන්ත්‍ර මගින් කම්මැලි නොවේ. මිනිසුන් ටික වේලාවකට පසු රැකබලා ගැනීම නවත්වයි!)

ස්වයංක්‍රීය විකෘති පරීක්ෂාව ඔබ කතා කරන අත්පොතට වඩා බෙහෙවින් යහපත් ප්‍රවේශයක් බව මම යෝජනා කරමි.

දෝෂයන් අතින් ඇතුල් කිරීමට ඔබ සංවර්ධකයෙකුගෙන් ඉල්ලා සිටියහොත්, ඔබට ලැබෙන දෝෂය බොහෝ විට මිනිසුන් විසින් සිදු කළ හැකි අහඹු වැරදි නියෝජනය නොකරන බව සලකන්න . .

එය පොදුවේ නරක අදහසක් වුවද (අනෙක් පිළිතුරු එයට මනාව පැහැදිලි කරයි), පාලක, තාවකාලික ආකාරයකින් නිෂ්පාදන කේතයට හිතාමතාම දෝෂ එන්නත් කිරීම අර්ථවත් කළ හැකි විශේෂ අවස්ථා කිහිපයක් තිබේ.

ඔබ පරීක්ෂණ කේතය නැවත ප්‍රතිනිර්මාණය කරන විට - සහ ඔබ කළ යුත්තේ, පරීක්ෂණ කේතය නිෂ්පාදන කේතය තරම්ම අවධානය යොමු කළ යුතුය - පරීක්ෂණ කේතය තවමත් සොයාගත යුතු දෝෂ සොයාගෙන ඇත්දැයි දැන ගැනීමට ඔබට අවශ්‍ය විය හැකිය.

පරීක්ෂණ තවමත් ක්‍රියාත්මක වේදැයි තහවුරු කර ගැනීම සඳහා ඔබට හිතාමතාම නිෂ්පාදන කේතය බිඳ දැමිය හැකිය.

මෙය කළ හැකි මට්ටම් කිහිපයක් තිබේ:

• කිසියම් ඒකක පරීක්ෂණයක් නැවත ප්‍රතිනිර්මාණය කළ සංවර්ධකයෙකුට නිෂ්පාදන කේතය බිඳ දැමිය හැකිය.
• යම් පිළිගැනීමේ පරීක්ෂණයක් නැවත ප්‍රතිනිර්මාණය කර ඇති පරීක්ෂකයෙකු නිෂ්පාදන කේතය බිඳ දැමිය හැකිය, පිළිගැනීමේ පරීක්ෂණය එය සත්‍යාපනය කළ යුතු දේ තවමත් සත්‍යාපනය කරයි.
• අතුරුමුහුණත ස්ථාවර හා ශක්තිමත් නම් (එනම් ප්‍රොටෝකෝලය මත පදනම් වූ), සමාගමට දන්නා දෝෂ සහිත නිෂ්පාදන සංස්කරණ කට්ටලයක් තබා ගැනීමට සහ පරීක්ෂණය නැවත පරීක්ෂා කිරීම සඳහා ඒවාට එරෙහිව පරීක්ෂණ ක්‍රියාත්මක කිරීමට අවශ්‍ය විය හැකිය.

මේ දේවල් තේරුමක් තිබේද යන්න රඳා පවතී. මම සංවර්ධකයෙක් නම්, දෝෂයක් එන්නත් කිරීමට, ඒකක පරීක්ෂණය පරීක්ෂා කිරීමට, දෝෂය ඉවත් කිරීමට මට විනාඩියක් ගත වේ - එසේ නොවන්නේ මන්ද. නමුත් මගේ සංස්කාරකය, මගේ චක්‍රය සහ අනුවාද පාලන පද්ධතිය එතරම් හොඳ පාලනයක් යටතේ තිබිය යුතුය, එවිට මම වැරදීමකින් / භාරදීමට / පරීක්ෂා කිරීමට / දෝෂය තල්ලු නොකරමි. පරීක්ෂකයා සහ පිළිගැනීමේ පරීක්ෂණය සඳහා ද එයම වේ.

දන්නා දෝෂ සහිත නිෂ්පාදන අනුවාදයන් සහ ප්‍රතිගාමී පරීක්ෂණයන්හි කට්ටල තබා ගැනීම ආයතනයකට තේරුමක් තිබේද යන්න පරීක්ෂණය රඳා පවතී. ඔන්ලයින් සාප්පුවක් සඳහා මම එසේ නොකරමි. මෝටර් රථ කාවැද්දූ, අභ්‍යවකාශය කාවැද්දූ, බැංකු කාඩ්පත් හෝ ගෙවන රූපවාහිනී කාඩ්පත් සඳහා.

මෙය කොතරම් උත්සාහයක් දරන්නේද යන්න නිෂ්පාදන කේතයෙන් පරීක්ෂණ කෙතරම් දුරට විසන්ධි වී ඇත්ද යන්න මත රඳා පවතී. පරීක්ෂණ කේතය නිෂ්පාදන කේතයෙන් වැඩි වන තරමට, මෙය කිරීමට අඩු උත්සාහයක්, පරීක්ෂණ කේතය නිෂ්පාදන කේතය සමඟ වඩා සංයුක්ත වේ, වැඩි උත්සාහයක් දරයි.

හේතුව මෙයයි: ඔබේ පරීක්ෂණ සහ නිෂ්පාදන කේතය සංයුක්ත වන විට, නිෂ්පාදන කේතය වෙනස් කිරීම සඳහා බොහෝ විට පරීක්ෂණ වෙනස් කිරීම අවශ්‍ය වන අතර, එමඟින් පරීක්ෂණ සහ වැරදි නිෂ්පාදන සාම්පල අතර පරායත්තතාවය බිඳ වැටෙනු ඇත. එවිට ඔබට වැරදි නිෂ්පාදන සාම්පල පවත්වා ගැනීමටද සිදුවේ. දුර්ලභ අවස්ථාවන්හිදී පවා එය උත්සාහ කිරීම වටී, සහ සමච්චල් කිරීම මෙන්ම අනුවාද පාලන පද්ධතියක ස්මාර්ට් භාවිතය ද උත්සාහය සැලකිය යුතු ලෙස අඩු කළ හැකි නමුත් එයට වඩා ඉහළ දක්ෂ සංවර්ධකයින් අවශ්‍ය වේ.

නිෂ්පාදන කේතයේ හිතාමතාම දෝෂ එන්නත් කිරීමේ සංකල්පය කඩාකප්පල් කිරීම ලෙසද , එන්නත් කරන ලද දෝෂය කඩාකප්පල්කාරී ලෙසද හැඳින්වේ .

පරීක්‍ෂා කළ යුතු කේතය ගබඩාවෙන් කෙලින්ම ලබා නොගන්නා පරීක්ෂකයෙක් එය වැරදි ය. (1)

දන්නා-වැරදි කේතයක් නිධිය තුළට පරික්ෂා කරන සංවර්ධකයෙකු එය වැරදිය. (2)

එබැවින් මෙම අවස්ථාවෙහිදී, සංවර්ධනය හා පරීක්ෂණ සිදු කළ යුතු ආකාරය පිළිබඳ මූලික පරිශ්‍රයන් උල්ලං ting නය කරමින් එක් හෝ දෙපාර්ශ්වයම නොමැතිව මෙම යෝජනා ක්‍රමය ක්‍රියාත්මක වීමට දැනටමත් ක්‍රමයක් නොමැත.

(1) ඔබ පරීක්‍ෂා කළ අනුවාදය ලේඛනගත කිරීමට අවශ්‍ය නිසා. Git hash හෝ SVN සංශෝධන අංකයකින් ටැග් කර ඇති අනුවාදයක් ඔබට පරීක්ෂා කළ හැකි දෙයකි, "ජෝ මට දුන් කේතය" නොවේ.

(2) ඔබ එසේ නොකරන නිසා, අසමත් වීමක් අපේක්ෂා කරන පරීක්ෂණ රියදුරෙකුට පිටතින් .

මෙය කෙටිම, හැකි “සෝපාන තණතීරුව” සඳහා වන උත්සාහයක් වන අතර එය ඩෙව්ස්, පරීක්ෂකයින් සහ කළමනාකරණය යන දෙකටම ක්ෂණිකව අර්ථවත් කළ යුතුය.

ඔබ QA වෙත යවන සෑම ගොඩනැගීමකටම හිතාමතාම දෝෂ එන්නත් කිරීමට එරෙහිව මම නිර්දේශ කරමි.

ඔබට වරින් වර වසරකට වරක් රහසිගත "QA විගණනයක්" කළ හැකිය. "පරීක්‍ෂා කළ සහ වැඩ කරන" කේත පදනමක් ගන්න, සහ ඔබේ ටෝඩෝ ලැයිස්තුවෙන් හැකි තරම් කුඩා නව විශේෂාංග ගන්න. ඔබ සාමාන්‍යයෙන් කරනවාට වඩා ඒවා “ටිකක් අලස” ලෙස ක්‍රියාත්මක කරන්න. අද්දර සිදුවීම් ගැන සිතන්න, ඒවා ලියා තබන්න, නමුත් ඒවා සැලකිල්ලට ගැනීම සඳහා ඔබේ කේතය නිවැරදි නොකරන්න. එය QA වෙත යවන්න.

ඔබ ලියා ඇති ප්‍රමාණයට වඩා වැඩ නොකරන අද්දර දෝෂ ඔවුන් සොයා ගන්නේ නම්, එය නිසැකවම අධීක්ෂණය අවශ්‍ය වන්නේ ඔබේ QA නොවේ ... ;-)