ඔබගේ SDET වසර පහක ගමනේ, ගෙරින් ෆයිලයක් විවෘත කරලා එය මනුෂ්ය පරීක්ෂකයෙකුගේ පියවර‑පියවර මාර්ගෝපදේශයක් වගේ කියලා හිතෙනවාද? "admin" යුසර් නාමයෙන්, "password123" මුරපදයෙන් ලොග්‑ඉන් වීම, "Submit" බොත්තම ක්ලික් කිරීම, පසුබැසීමේ පණිවුඩය "Welcome" පෙන්වීම – මේ වගේ සරල උදාහරණයක් ඔබේ කණ්ඩායම BDD ලෙස නම් කරයි, කළමනාකරු "ජීවිතමය ලේඛන" කියලා කියයි. නමුත් ඇත්තටම එය මනුෂ්ය මූලික පරීක්ෂණයක් පමණයි.
Gherkin සත්යය – එය ටෙස්ට් ඔට්ටෝමේශන් මෙවලමක් නොවේ. එය කථා රීතියක්. ඔබේ සිනාරිය පද්ධතිය කුමක් කරන්නේද කියා විස්තර කරන්නේ නම්, ඒක සැබෑ BDD වේ. පද්ධතිය කොහොම ක්රියා කරනවාද කියා ලියනවා නම්, එය මනුවල් පරීක්ෂණයක්වෙයි.
කොහොමද මේ ගැටලුව උදාවෙන්නේ? බොහෝ කණ්ඩායම් "සහයෝගිතාව" කියලා බ්ලොග් පෝස්ට් එකක් කියවා BDD ගත කරගන්නා අතර, Cucumber හෝ SpecFlow ස්ථාපනය කර, ෆීචර් ෆයිල් ලියලා, ඒවා Selenium/Playwright කෝඩ් එකට මැප් කරලා ඉවරයි. ඒ පසු, ප්රොඩක්ට් ඔනර් ෆීචර් ෆයිල් කියවන්නේ නැති, ඩෙවලොපර් එක තවමත් කේතය ලියන අතර, QA ඉන්ජිනියර් එක එකම ගොඩක් Gherkin පවත්වාගෙන යනවා. මෙය සහයෝගිතාව නොව, ලේඛන නාට්යයකි.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ තාක්ෂණික සමාජයට මේ වැරදි අවධානයෙන් ඉවත් කිරීම අත්යවශ්යයි. නිවැරදි BDD ක්රමය:
- විකසකයන්ට නිවැරදි අවශ්යතා ඉදිරිපත් කරයි – ඉදිරි කේත ලියීමේදී අර්ථ ගැඹුරින් තේරුම් ගත හැකිය.
- පරීක්ෂකයින්ට UI වෙනස්කම් හේතුවෙන් පරීක්ෂණ බිඳ වැටීමේ අවදානම අඩු කරයි.
- ශ්රී ලංකා ආරම්භක ව්යාපාරවලට වේගවත් CI/CD පයිප්ලයින් ගොඩනැගීමට මාර්ගයක් සපයයි.
- අධ්යාපන ආයතනවලට BDD නවෝත්පාදන පදනමක් ලෙස භාවිතා කර, සිසුන්ට ඉදිරි පරීක්ෂණ-කේත අනුබැඳියාව අත්හදා බැලීමට අවස්ථාව ලැබේ.
අදහස නම්, Gherkin එකේ රූපය අඩු කර, තර්කය පදනම් කර ගැනීමයි. පියවර-පියවර UI ක්රියාකාරකම්වලට පමණක් නොව, "කට්ටලයක් අවලංගුයි" වැනි අර්ථවත් තොරතුරු දක්වන්න. ඒ අනුව, ඔබේ ස්ටෙප් ඩෙෆිනිෂන්ස් ඉතා පළලින් පවතින, පේජ් ඔබ්ජෙක්ට් හෝ සර්විස් ලේයර් වලට ලොජික් එකක් මාරු කර, Gherkin එකේ “කොහොමද” කියලා අඩංගු කරගන්න.
අදම ඔබේ පරීක්ෂණ ක්රමය සවිස්තරාත්මක කර, BDD එකේ සැබෑ අරමුණ අත්විඳින්න. ඒකයි තාක්ෂණික පරීක්ෂණයේ සාර්ථකත්වය.
