App ကို launch မလုပ်မီ စမ်းသပ်နည်း: လက်တွေ့ launch မတိုင်မီ အစီအစဉ်

Launch မတိုင်မီ app ကို စမ်းသပ်ရန်အတွက် အသုံးပြုသူ လုပ်ဆောင်နိုင်ရမည့် ခရီးစဉ် အနည်းငယ်ကို စာရင်းပြုစုပါ၊ ထို့နောက် အသစ်ဝင်သော အသုံးပြုသူအဖြစ် laptop နှင့် ဖုန်းတစ်ခုစီတွင် တစ်ကြိမ်စီ လုပ်ပါ၊ ထို့နောက် ပျက်စီးနိုင်သော နည်းလမ်းများ — ဒေတာ ဗလာ၊ မှားယွင်းသော input၊ ဒုတိယ account၊ နှေးသော ချိတ်ဆက်မှု — ကို စမ်းပါ။ ငွေနှင့် ပုဂ္ဂိုလ်ရေးဒေတာ ပါဝင်သည့် အရာများကို အထူးဂရုပြုပြီး ထုတ်ဝေပြီးနောက် live URL ပေါ်တွင် အဓိက ခရီးစဉ်များကို ပြန်လုပ်ပါ။ နောက်ဆုံးတွင် app ကို ဘယ်တော့မှ မမြင်ဖူးသူ တစ်ဦးက စမ်းသပ်နေချိန် ကြည့်ပါ။

ဤအလုပ်အတွက် QA အဖွဲ့ သို့မဟုတ် testing framework မလိုပါ။ စာရင်းတစ်ခု၊ နာရီတစ် နှစ်နာရီ၊ နှင့် စာရင်းကို တကယ် နှိပ်ကြည့်မည့် စိတ်ဓာတ်လိုအပ်ပါသည်။

အဆင့် ၁: အရေးကြီးသော ခရီးစဉ်များကို ရေးမှတ်ပါ

ခရီးစဉ် (journey) ဆိုသည်မှာ အသုံးပြုသူ လာရောက်လုပ်ဆောင်လိုသော အစမှ အဆုံးထိ လုပ်ငန်းတစ်ခု ဖြစ်သည်။ App အများစုတွင် အရေးကြီးသော ခရီးစဉ် သုံးမှ ခြောက်ခု ရှိသည်။ Booking app အတွက် ဥပမာ:

1. Sign up လုပ်ပြီး account ကို အတည်ပြုပါ
2. Class တစ်ခု ရှာပြီး book လုပ်ပါ
3. Booking ကို ပယ်ဖျက်ပါ
4. Class pass ကို ငွေပေးပါ
5. Staff: ယနေ့ booking များကို ကြည့်ပါ

User story ရေးထားလျှင် ၎င်းတို့၏ acceptance criteria သည် သင့် test case များ ဖြစ်ပြီးသားဖြစ်သည်။ မရေးထားလျှင် ခရီးစဉ်တစ်ခုလျှင် စာကြောင်းတစ်ကြောင်းဖြင့် "အောင်မြင်ခြင်း" ဆိုသည်မှာ ဘာလဲ ရေးပါ။

အရေးကြီးမှုအလိုက် စီပါ။ ငွေရှာပေးသော သို့မဟုတ် အသုံးပြုသူ အားလုံး ရောက်ရှိသော ခရီးစဉ် (sign-up၊ login၊ အဓိက လုပ်ဆောင်ချက်) ကို ဦးစွာ နှင့် အများဆုံး စမ်းပါ။

အဓိက ခရီးစဉ် (happy path) ကို အသစ်ဝင်သူအဖြစ် စမ်းပါ

"Happy path" ဆိုသည်မှာ ခရီးစဉ်သည် ရည်ရွယ်ထားသည့်အတိုင်း ပြေပြစ်စွာ သွားခြင်း ဖြစ်သည်။ စိမ်းလန်းသူတစ်ဦးက ကြုံရမည့်အတိုင်း စမ်းပါ:

• Private browser window ကို သုံးပါ၊ log in မဝင်ထားဘဲ သိမ်းထားသော ဒေတာ မရှိစေရန်။
• Email ဖြင့် စစ်ဆေးနိုင်သော account အသစ် ကို သုံးပါ။
• ပင်မစာမျက်နှာ သို့မဟုတ် link မှ စပါ၊ တည်ဆောက်စဉ် မှတ်ထားသော စာမျက်နှာမှ မဟုတ်ပါ။

အသစ်ဝင်သော အသုံးပြုသူတွင် ဒေတာ မရှိပါ။ Bug အများအပြားသည် list ဗလာဖြစ်သည့်အခါ၊ profile တွင် ဓာတ်ပုံ မရှိသည့်အခါ၊ သို့မဟုတ် ဘာမျှ မဝယ်ရသေးသည့်အခါမှသာ ပေါ်လာသည်။ သင့် admin account ဖြစ်ပြီး စမ်းသပ်ဒေတာ အပြည့်ရှိသည်ဆိုလျှင် ၎င်းတို့ကို ဖုံးကွယ်ထားမည်။

ဖျက်ပစ်ရန် ကြိုးစားပါ

ယခု ခရီးစဉ်တိုင်းကို ထပ်လုပ်ပြီး ရည်ရွယ်ချက်ရှိရှိ မှားသော အရာကို လုပ်ပါ။

Refresh ကို အထူးမှတ်သားသင့်သည်: app ကို နှိပ်ကြည့်ရာတွင် အလုပ်လုပ်သော်လည်း နက်ရှိုင်းသော စာမျက်နှာပေါ်တွင် refresh လုပ်လျှင် 404 ပေါ်လာပါက deploy ပြီးနောက် 404 error များကို ပြင်နည်း ကို ကြည့်ပါ။

အကောင့်နှစ်ခုဖြင့် ခွင့်ပြုချက်များကို စမ်းပါ

အကောင့်ပါသော app အတွက် ဤစမ်းသပ်မှုသည် အရေးအကြီးဆုံး ဖြစ်ပြီး မကြာခဏ ကျော်သွားတတ်သည်။

သုံးစွဲသူ ပုံမှန် နှစ်ဦး A နှင့် B၊ (app တွင် ရှိလျှင်) admin တစ်ဦး ဖန်တီးပါ။

• A အနေဖြင့် record တစ်ခု ဖန်တီးပါ။ B အဖြစ် log in ဝင်ပါ။ B က မြင်နိုင်၊ ပြင်နိုင်၊ ဖျက်နိုင်သလား။ ဒီဇိုင်းအရ ရည်ရွယ်မထားလျှင် မရသင့်ပါ။
• A ၏ record တစ်ခု၏ URL ကို ကူးပါ။ B အဖြစ် log in ဝင်ပြီး URL ကို တိုက်ရိုက် ဖွင့်ပါ။
• ပုံမှန်အသုံးပြုသူအနေဖြင့် admin စာမျက်နှာများ၏ URL ကို ရိုက်ပြီး ဖွင့်ကြည့်ပါ။
• လုံးဝ log out ထွက်ပြီး တူညီသော URL များကို စမ်းပါ။

ဤနေရာတွင် ပြဿနာတွေ့လျှင် ပြင်ပြီးမှသာ launch လုပ်ပါ။ စစ်ဆေးမှုသည် ခလုတ်ကို ဖျောက်ခြင်းဖြင့်သာ မဟုတ်ဘဲ server ပေါ်တွင် ဖြစ်ရမည်။ AI-built app များအတွက် လုံခြုံရေး စစ်ဆေးစာရင်း တွင် ပိုနက်ရှိုင်းစွာ ရှိသည်။

အစစ်အမှန် ဖုန်းများပေါ်တွင် စမ်းပါ

Browser ပြတင်းပေါက် သေးငယ်သည့်အရာမျှသာ မဟုတ်ဘဲ အမှန်တကယ် ဖုန်းတစ်လုံးပေါ်တွင် app ကို ဖွင့်ပါ။

• Zoom မလုပ်ဘဲ ခလုတ်အားလုံးကို နှိပ်နိုင်ပါသလား။
• ရိုက်နေသော field ကို keyboard က ဖုံးထားပါသလား။
• Table နှင့် ကျယ်သော content များသည် scroll သို့မဟုတ် wrap ဖြစ်ပြီး စာမျက်နှာ ဘေးသို့ မတွန်းပါသလား။
• Pinch မလုပ်ဘဲ စာသား ဖတ်ရလွယ်ပါသလား။

အနည်းဆုံး iPhone (Safari) တစ်လုံးနှင့် Android ဖုန်း (Chrome) တစ်လုံး ရနိုင်လျှင် စမ်းပါ။ Safari တွင် ရက်စွဲ၊ video နှင့် fixed-position element များနှင့် ဆိုင်သော ထူးခြားချက်များ ရှိသည်။

ငွေနှင့် email ကို အစမှ အဆုံးထိ စမ်းပါ

ကတ်ငွေ ယူသော သို့မဟုတ် email ပို့သော အရာအားလုံးသည် အပြည့်အဝ အလုပ်လုပ်ပုံ လိုအပ်သည်။

ငွေပေးချေမှု။ ငွေပေးချေသူ၏ test mode နှင့် test ကတ်နံပါတ်များကို သုံးပါ။ အောင်မြင်သော ငွေပေးချေမှု၊ ပယ်ချခံရသော ကတ်နှင့် ပယ်ဖျက်ထားသော checkout တို့ကို စစ်ပါ။ ငွေပေးပြီးနောက် order သို့မဟုတ် subscription သည် provider ၏ dashboard တွင်သာမက သင့် app တွင် ပေါ်သည်ကို အတည်ပြုပါ။ App က webhook များ (ငွေပေးချေသူက သင့် server သို့ ပို့သော မက်ဆေ့ချ်များ) ကို အမှန်တကယ် သုံးပါက published app တွင် ရောက်လာသည်ကို စစ်ပါ၊ development တွင်သာ မဟုတ်ပါ။ ထို့နောက် launch မတိုင်မီ live key သို့ ပြောင်းပြီး သင် refund လုပ်မည့် သေးငယ်သော အစစ်အမှန် ဝယ်ယူမှု တစ်ခု လုပ်ပါ။

Email။ နိုင်ငံခြား provider သုံးမျိုး သို့မဟုတ် သုံးမျိုး ရှိ အစစ်အမှန် လိပ်စာများဖြင့် sign up လုပ်ပါ။ Email ရောက်ကြောင်း၊ spam ထဲ မရောက်ကြောင်း၊ အီးမေးလ်အတွင်းရှိ link တိုင်းက live domain ကို ညွှန်ပြကြောင်း (preview လိပ်စာ မဟုတ်ဘဲ) စစ်ပါ။

အမြန်နှုန်းနှင့် error များကို စစ်ပါ

• Browser ၏ developer tools ကို ဖွင့်ပါ (right-click → Inspect) နှင့် အဓိက စာမျက်နှာတိုင်းရှိ Console tab ကို ကြည့်ပါ။ အနီရောင် error များသည် မည်သည့်အရာမျှ မပျက်နေသယောင် ပေါ်သော်လည်း ပြင်ရန် တန်ဖိုးရှိသည်။
• Wi-Fi မဟုတ်ဘဲ mobile data ဖြင့် ဖုန်းပေါ်တွင် site ကို load လုပ်ပါ။ ပထမ screen က စက္ကန့်အနည်းငယ် ကြာလျှင် ပုံအရွယ်အစားကို ဦးစွာ ကြည့်ပါ။
• Chrome devtools ရှိ Lighthouse ကဲ့သို့ အခမဲ့ audit တစ်ခု ပြုလုပ်ပြီး စွမ်းဆောင်ရည်နှင့် accessibility ကို အမြန် ဖတ်ပါ။

Preview မဟုတ်ဘဲ ထုတ်ဝေထားသော app ကို စမ်းပါ

Preview နှင့် ထုတ်ဝေထားသော app သည် တူညီသော ပတ်ဝန်းကျင် မဟုတ်ပါ။ လူတစ်ဦးကို launch အကြောင်း မပြောမီ အဓိက ခရီးစဉ်များကို live URL ပေါ်တွင် ပြန်လုပ်ပါ:

• Environment variable နှင့် secret အားလုံးကို published app အတွက် သတ်မှတ်ထားပါသလား။
• မျှော်လင့်ထားသော ဒေတာနှင့်အတူ မှန်ကန်သော database ကို သုံးနေပါသလား။
• Login redirect နှင့် email link များက live domain ကို အသုံးပြုပါသလား။
• နက်ရှိုင်းသော စာမျက်နှာပေါ်တွင် refresh လုပ်လျှင် မှန်ကန်စွာ load ဖြစ်ပါသလား။

တစ်ဦးတစ်ယောက် အသုံးပြုနေသည်ကို ကြည့်ပါ

လူ တစ်ဦး သို့မဟုတ် နှစ်ဦးအား ညွှန်ကြားချက်မဟုတ်ဘဲ ရည်မှန်းချက် ("စနေနေ့အတွက် yoga class တစ်ခု book လုပ်ပါ") ကို ပေးပါ။ ကြည့်ပါ၊ မကူညီပါနှင့်၊ ၎င်းတို့ ဘယ်နေရာတွင် တွေဝေသလဲ မှတ်ပါ။ ရှုပ်ထွေးသော စာသားနှင့် ဖျောက်ထားသော ခလုတ်များကို ရှာဖွေရန် အမြန်ဆုံး နည်းလမ်းဖြစ်သည်။ ပိုကြီးသော ဗားရှင်းအတွက် beta test လုပ်နည်း ကို ကြည့်ပါ။

သူတို့ bug တစ်ခုကို တွေ့သောအခါ အဆင့်များ၊ မျှော်လင့်ထားသော ရလဒ်နှင့် အမှန်တကယ် ရလဒ်ဖြင့် သေချာစွာ မှတ်ပါ။ ကောင်းသော bug report ရေးနည်း တွင် format ကို ပြထားသည်။

AI ဖြင့် စမ်းသပ်ရန် ကူညီခြင်း

သင် AI ဖြင့် တည်ဆောက်လျှင် စမ်းသပ်မှု အစီအစဉ်ဆွဲရန်နှင့် လုပ်ဆောင်ရန် ကူညီစေနိုင်သည်:

ဤ app ၏ အဓိက user ခရီးစဉ်များကို စာရင်းပြုစုပါ၊ ခရီးစဉ်တစ်ခုစီအတွက် အများဆုံး ပျက်စီးနိုင်သော ထူးခြားသည့် အခြေအနေများ — ဗလာ အခြေအနေ၊ မှားသော input၊ ခွင့်ပြုချက်၊ refresh — ကို ထည့်ပါ။ သင်လုပ်နိုင်သော checklist တစ်ခုအဖြစ် ထည့်ပါ။

ဒေတာ စမ်းသပ်သူ နှစ်ဦးဖြင့် log in ဝင်ပြီး user B က user A ဖန်တီးထားသည်ကို မြင်နိုင် သို့မဟုတ် ပြောင်းနိုင်သလား စစ်ပါ၊ A ၏ record URL များကို တိုက်ရိုက် ဖွင့်ခြင်းအပါအဝင်။ ပြင်ဆင်ခြင်းမပြုမီ တွေ့ရှိသည်ကို အစီရင်ခံပါ။

AI ၏ ကိုယ်ပိုင် စမ်းသပ်အစီရင်ခံစာကို ပထမအဆင့် အဖြစ်သာ ယူပါ။ ငွေနှင့် ခွင့်ပြုချက် ခရီးစဉ်များကို သင်ကိုယ်တိုင် နှိပ်ကြည့်ပါ။

Mythex တွင် စမ်းသပ်ခြင်း

Mythex တွင် /test command သည် App Testing ကို run လုပ်သည်: agent သည် live preview ကို browser ဖြင့် ထိန်းချုပ်ပြီး စာမျက်နှာများကို နှိပ်ကြည့်ကာ screenshot ရိုက်ပြီး ပျက်နေသော flow များကို chat တွင် အစီရင်ခံသည်။ တိကျသော ခရီးစဉ် တစ်ခုဖြင့် အကောင်းဆုံး အလုပ်လုပ်သည်၊ ဥပမာ "sign-up နှင့် class တစ်ခု book လုပ်ခြင်းကို စမ်းပါ"။ တွေ့သည်များကို /fix သို့မဟုတ် ပုံမှန် မက်ဆေ့ချ်ဖြင့် ပြင်ပြီး /test ကို ထပ်ပြေးပါ။ App Testing သည် preview ကို အသုံးပြုသောကြောင့် ထုတ်ဝေပြီးနောက် အဓိက ခရီးစဉ်များကို published URL တွင် သင်ကိုယ်တိုင် စစ်ပါ။ docs ရှိ App Testing နှင့် အရာတစ်ခု ပျက်သွားသည့်အခါအတွက် AI-built app ကို debug လုပ်နည်း ကို ကြည့်ပါ။

အမှားများ

• သင့်ကိုယ်တိုင်သာ စမ်းခြင်း။ ဒေတာ အများအပြား ပါသော သင့် admin account သည် ဗလာအခြေအနေနှင့် ခွင့်ပြုချက် bug များကို ဖုံးကွယ်ထားသည်။
• Laptop တွင်သာ စမ်းခြင်း။ Site အများအပြားရှိ visitor အများစုသည် ဖုန်းမှ ရောက်လာသည်။
• ဒုတိယ account ကို ကျော်ခြင်း။ အသုံးပြုသူများကြား ဒေတာ ယိုဖိတ်ခြင်းသည် app အနေဖြင့် launch လုပ်ရန် အဆိုးဆုံး bug ဖြစ်သည်။
• Preview ကို ယုံခြင်း။ Live app တွင် ဆက်တင်များ ကွဲပြားသည်၊ ထိုအတွက်လည်း စမ်းပါ။
• ပြင်ပြီးနောက် ဘေးပတ်ဝန်းကျင်ကို ပြန်မစမ်းခြင်း။ Form တစ်ခု၏ ပြင်ဆင်ချက်က ကုဒ်ဝေမျှထားသော အခြား form တစ်ခုကို ဖျက်နိုင်သည်။

Launch မတိုင်မီ စစ်ဆေးစာရင်း

• အဓိက ခရီးစဉ်များကို စာရင်းပြုစုပြီး ဦးစားပေးစီထားသည်
• Private window တွင် အသစ်ဝင်သော အသုံးပြုသူအဖြစ် ခရီးစဉ် တစ်ခုစီ အောင်မြင်သည်
• ဗလာ၊ မှား၊ ရှည်၊ ထပ်နေသော input များကို ကိုင်တွယ်ထားသည်
• စာမျက်နှာတိုင်းတွင် refresh အလုပ်လုပ်သည်
• အသုံးပြုသူများက တစ်ဦးနှင့် တစ်ဦး ဒေတာကို မမြင်နိုင်၊ URL ဖြင့်ပင် မပြောင်းနိုင်
• Admin စာမျက်နှာများကို ပုံမှန်အသုံးပြုသူနှင့် logged-out ဧည့်သည်များအတွက် ပိတ်ထား
• အစစ်အမှန် iPhone နှင့် Android ဖုန်းတွင် အလုပ်လုပ်သည်
• ငွေပေးချေမှု စမ်းပြီး: အောင်မြင်ခြင်း၊ ပယ်ချခြင်း၊ ပယ်ဖျက်ခြင်း၊ ထို့နောက် app အပ်ဒိတ်ဖြစ်သည်
• Email ရောက်၊ spam မဖြစ်၊ live domain သို့ link ရှိသည်
• အဓိက စာမျက်နှာများတွင် console အနီ error မရှိ
• အဓိက ခရီးစဉ်များကို published URL တွင် ပြန်လုပ်ပြီး
• ပြင်ပ လူတစ်ဦးက သင်ကြည့်နေစဉ် စမ်းခဲ့ပြီး

မေးခွန်းများ