QA တွေကို သိစေချင်

Enhancing Communication Between Developers and QA

QA မရှိခင်က မိမိဘဝ

လုပ်သက် ၄နှစ်လောက်ရောက်မှ QA တွေနဲ့ စပြီး အလုပ်လုပ်ဖူးတယ်။ အရင်တုန်းက ကိုယ်တိုင်ရေး၊ ကိုယ်တိုင်စစ်၊ ပြီးရင် upper management က စမ်းကြည့်လို့ pass ဖြစ်ရင် server ပေါ် တန်းတင်လိုက်တာပဲ။ အဲဒိတုန်းက နောက်နေကျ စကားလေးတောင်ရှိတယ်၊ Customer = Tester ဆိုပြီး၊ တကယ်လည်းအဲလိုလုပ်ခဲ့တာ၊ Customer က ဖုန်းဆက်တော့မှ ဖုတ်ဖက်ခါပြီး bug fix ထလုပ်ကြတာပဲ။

QA ဆိုတာ ဂျိုနဲ့လား

QA တွေနဲ့ စတွဲလုပ်ရတုန်းက တအားစိတ်ညစ်တယ်၊ ဒီအတိုင်းလည်း tasks တွေက ပုံမှန်ပြီးနေတာကို ဘာတွေစစ်ဖို့လိုတာလဲပေါ့။ အထူးသဖြင့် improvement label နဲ့ issue လာဖွင့်တဲ့အခါ စိတ်ထဲဘဝင်မကျဘူး။ ဒီအတိုင်းလည်း အလုပ်ဖြစ်နေတာ၊ အရစ်ကို ရှည်တယ်ဆိုပြီး။ စစချင်း project ၂ခုလောက်အထိက အဆင်မပြေဘူး၊ အလုပ်သဘောအရသာ ဆက်ဆံနေရပေမယ့် ကြိုက်လှတယ်လို့မဟုတ်ဘူး။

QA အရေးပါမှုကို နားလည်လာပုံ

နောက်တော့မှ တဖြည်းဖြည်းနဲ့ သူတို့တန်ဖိုးကို သိလာတာ။ အခုနေများ လက်ရှိ projects တွေကို QA မထည့်ပဲ လွှတ်မယ်ဆို ထိပ်ဆုံးက ဆန္ဒပြမည့်သူဟာ ကိုယ်ပဲလို့ မှတ်ပါလေ။ အဓိက က Bug ကင်းစင်သွားတာထက် သူတို့ဆီက ပညာပြန်ရတယ်။ Developer တွေက code ရေးရင် pseudocode အရင်ရေးကြတယ်။ အဲဒိမှာ ကိုယ်မစဉ်းစားမိပဲ လွတ်သွားတာတွေ သူတို့မြင်တယ်။ Their suggestions really improve my logical thinking. UX သဘောအရလည်း သူ့တို့ အကြံပြုချက်တွေ ကောင်းတယ်။ ခုဆိို design ပိုင်းတွေ ရေးတိုင်း ငါသာ user တစ်ယောက်ဖြစ်ခဲ့ရင်ဆိုတဲ့ စိတ်က အမြဲရှိတယ်၊ thanks to them.

QA ထားတဲ့ အလေ့အကျင့်ကို local က software company တွေမှာ ရှိစေချင်တယ်။ International မှာလို testing service သီးသန့်ပေးတဲ့ company မျိုးတွေ နောက်တစ်ချိန်မှာ ပေါ်လာရင် ကောင်းမယ်လို့လည်း တွေးမိတယ်။

ဒီ Article မှာတော့ သူတို့နဲ့တွဲအလုပ်လုပ်ဖူးတဲ့ အတွေ့အကြုံအရ တစ်ချို့ကိစ္စလေးတွေ အပြုသဘောနဲ့ အကြံပြန်ပေးချင်ပါတယ်။

(၁) Release တစ်ခုကို သံယောဇဉ်အမျှင်တန်းပြီး မစစ်ဖို့

Staging server ပေါ်တင်လိုက်တာနဲ့ ငါးကန်ထဲ ပိုက်ကွန်ပစ်လိုက်လို issue တွေ အုံလိုက်ကျင်းလိုက် ဖွေးဖွေးလှုပ်မိတာမျိုးက Developer တွေ အတွက် အဆင်အပြေဆုံးပဲ။ တစ်ခါထဲပြင်၊ တစ်ခါထဲတင်၊ လုပ်ရ ကိုင်ရတာရှင်းတယ်။ Feature အနည်းအများအလိုက် QA ဘက်က လွတ်သွားတာ မျိုးရှိနိုင်ပေမယ့် သင့်တင့်တဲ့ ရက်အတွင်း ပြန်ဖမ်းမိရင်တော့ အဆင်ပြေတယ်။ Post-release testing period အတွင်း 85–90% လောက် cover ဖြစ်ရင်တောင် မဆိုးဘူးထင်တာပဲ။

ဆန့်ကျင်ဘက်အနေနဲ့ ကိုယ်သေချာမစစ်ခဲ့လို့ ရက်အတော်ကြာတဲ့အထိ issue တွေတက်နေတုန်းပဲဆိုရင်တော့ အဆင်မပြေဘူး။ PM ကကြည့်ရင်လည်း QA fault ဆိုတာ မြင်မှာမဟုတ်ဘူး၊ ဒီ​ feature က ပြီးခဲ့တာကြာပြီ၊ issues တွေ ခုထိရှိနေတုန်းပဲဆိုတာမျိုး developer ဘက်ကပဲ အထင်လွဲခံရမှာ။

(၂) မဲမဲမြင်တိုင်း issue မဖွင့်နဲ့

Bug fix တွေကတော့ ဖွင့်သာဖွင့်၊ အားပေးတယ်။ ဒါပေမယ့် improvement လို ဟာမျိုးကျတော့ အခြေအနေနဲ့ အချိန်အခါလေးကို တစ်ချက်ကြည့်စေချင်တယ်။ ငါ ဒါကိုဖွင့်လိုက်တာက ဟုတ်တယ်၊ အဲဒါကို fix လုပ်ရတာက တကယ်ရော တန်ရဲ့လားပေါ့။ Developer ဘက်က ပေးလိုက်ရတဲ့လုပ်အားရယ်၊ နောက်ဆုတ်သွားမယ့် timeline ရယ်၊ ​fix လိုက်လို့ error ထပ်တက်လာနိုင်တဲ့ risk ရယ်၊ client က ဘယ်လောက်အကျိုးရှိသွားမယ်ဆိုတာရယ် အကုန်လုံးကို ပြန်ချိန်စေချင်တယ်။

(၃) Test Case လေးတွေ ကြိုပေးထားဖို့

QA တိုင်းမှာ feature တစ်ခုချင်းစီကို ဘယ်လို စစ်မယ်ဆိုတဲ့ test case တွေ ကိုယ်စီရှိကြတယ်။ ဖြစ်နိုင်ရင် အဲဒိ test case တွေကို tech team ကို ကြိုပေးထားရင် ပိုအဆင်ပြေတယ်။ အဲဒါဆို flow စဉ်းစားတဲ့အခါ ထည့်လိုက်ရင် နောက်ဖြစ်မည့် issues တော်တော်များများကို ကြိုရှင်းပြီးသား ဖြစ်သွားမယ်။

ပြီးတော့ test case အပြင် QA ရဲ့ personality နဲ့ experiences အလိုက် သူတို့ ဖြစ်စေချင်တာလေးတွေ ရှိတက်တယ်။ ဥပမာ web apps တွေဆို view source ကို ပိတ်စေချင်တာမျိုး၊ mobile app တွေဆို API ခေါ်နေတုန်း skeleton loading ဖြစ်ဖြစ် ပြထားတာမျိုးပေါ့။ အဲဒိလိုမျိုး personal preferences တွေကိုပါ သက်ဆိုင်ရာ tech team ကို ပေးထားရင် အကောင်းဆုံးပဲ။

(၄) Issue ဖွင့်ရင် scernio ပြည့်ပြည့်စုံစုံရေးဖို့

Issue reporting ကို ဖတ်ပြီးရင် developer တွေ အရင်ဆုံးလုပ်တာက issue replication ပါ။ Profile page ဖွင့်ရင် ဘာမှမပေါ်ဘူးဆိုတာမျိုးက track လုပ်ရလွယ်ပေမယ့် အများစုကတော့ detail steps တွေမှန်မှ ပေါ်လာတာများတယ်။ တစ်ခါတစ်လေကျ steps မှန်တောင် input data, browsers တွေ အပေါ်မူတည်သေးတယ်။ QA တွေအနေနဲ့ ဒီလိုမျိုးတွေထည့်ပေးရင်တော့ အဆင်ပြေတယ် -

## Description
[Provide a brief description of the issue you encountered. Be clear and concise.]

## Steps to Reproduce
1. [Outline the steps or actions required to reproduce the issue. Provide a numbered list of the specific actions or interactions that led to the problem.]
2. [Include any relevant input data, configurations, or settings.]

## Expected Behavior
[Describe what you expected to happen when following the steps above. Clearly articulate the desired outcome.]

## Actual Behavior
[Describe what actually happened when following the steps above. Explain the unexpected or incorrect behavior that occurred.]

## Environment
- Operating System: [Specify the operating system you're using, including the version number.]
- Browser (if applicable): [Specify the browser and its version.]
- Device (if applicable): [Provide information about the device you were using, such as mobile, desktop, or specific hardware.]

## Screenshots or Error Messages
[Attach any relevant screenshots, error messages, or console logs that help illustrate the issue. This visual evidence can assist in understanding and troubleshooting the problem.]

## Additional Information
[Include any additional information that might be helpful in resolving the issue. This could include related features, dependencies, or specific conditions that may contribute to the problem.]

(၅) Issue တွေကို private message or email မှာ လာမဖွင့်ဖို့

အဲလိုပြောတော့ ဒီလူက ပစိပစပ်များလှချည်လားလို့တော့ မထင်လိုက်ပါနဲ့။​ Onsite လုပ်နေချိန်မှာ ပခုံးလေးပုတ်ပြီး လာပြောသွားတာက မှတ်ရလွယ်ပေမယ့် remote based တွေဆို Slack, Outlook တွေမှာ messages & emails တွေ ပွထနေတဲ့အပြင် အကြောင်းကြောင်းကြောင့် issue tracking လုပ်ရတာ ခက်ပါတယ်။

အကောင်းဆုံးကတော့ Jira မှာ issue ဖွင့်ပြီး Slack ရဲ့ project channels တွေမှာ link နဲ့တကွ လာပြောတာပါပဲ။ Jira က ကြည့်ရရှင်းတဲ့အပြင်၊ record ဝင်သွားတော့ ကိုယ်အလုပ်လုပ်နေကြောင်းကို upper management ကို ပြလို့လည်းရတယ်။

Developer နဲ့ QA တွေကတော့ လုပ်ငန်းခွင်သဘောအရ tight timeline တွေမှာ pressue အပြည့်နဲ့ အလုပ်လုပ်ကြတဲ့အခါ နားလည်မှုလွဲပြီး အဖုအထစ်လေးတွေတော့ ရှိတက်ကြမှာပါပဲ။​ ကျွန်တော်ဆိုလည်း သူတို့တန်ဖိုးကို ဘယ်လောက်သိတယ်ပြောပြော released feature တစ်ခုကို တော်ရုံနဲ့မပိတ်ပဲ issue တွေဆက်တိုက်တက်နေရင် စိတ်တိုပါတယ်။

Sprint တစ်ခုပြီးသွားတိုင်းမှာ PM က ဦးဆောင်တဲ့ review meeting လုပ်ပြီး သူ့ဘက်ကိုယ့်ဘက် အခက်အခဲလေးတွေ ပွင့်ပွင့်လင်းလင်းဆွေးနွေးကြရင်တော့ ဒီလုပ်ငန်းခွင်လေးက ပျော်စရာလေးဖြစ်မှာပါ။