Author Archive

สวัสดีครับพี่น้อง หลังจากห่างหายจากการเขียนไปนาน เนื่องจากภารกิจรัดตัว วันนี้ขอนำเสนอเรื่องราวเบาๆเกี่ยวกับ Retest, Confirmation test และ Regression test แล้วกันครับ มาเริ่มกันจากสองคำแรกก่อน Retest กับ Confirmation test จริงๆแล้วสองคำนี้มีความหมายเท่ากันเลยครับ Retest = Confirmation test คือ การ test เพื่อ confirm ว่าปัญหาที่เคยเจอก่อนหน้านี้ถูก fixed ไปแล้ว ตัวอย่างเช่น เรา test software เจอบั๊กแล้ว report ไป เมื่อทาง Dev แก้มาแล้วเราเอา software กลับมาแล้วเทสตรงจุดที่เราเคยเจอ bug เพื่อ confirm ว่า bug นั้นถูกแก้ไปแล้วจริงๆ อันนี้เรียกว่า retest หรือ confirmation test เที่ยบเท่าได้กับการที่ลูกค้าหรือคนใช้งาน software แจ้ง bug [...]

วันนี้ขอเอา Seminar มาบอกเล่าเก้าสิบกันครับ ซึ่งคนที่ไปร่วมพูดในวันนั้นคนนึงก็คือผมนี่เอง 55 เอามาเกริ่นไว้ก่อนนะครับเนื่องจากมีบางคนร้องขอมาหลังไมค์หลังจากได้เห็น Ad อันนี้แล้ว แต่เนื่องจากอยู่ไกลมาก (ตรัง) จึงไม่สามารถมาร่วมได้แต่อยากรู้เนื้อหาที่คุยกันอย่างละเอียด (เน้นว่า ขอละเอียดๆ นะคะ)

วันนี้เราลองมาพูดถึงเรื่องของ Testing Term ที่เรามักจะได้ยินกันบ่อยๆ แต่ชวนให้สับสนเป็นอย่างยิ่งกันนะครับ คำที่เราจะพูดถึงคือ Test Plan, Test Specification รวมถึงคำอื่นๆอย่างเช่น Test case, Test script, Test condition, etc… ว่ามันคืออะไรกันแน่ มาเริ่มกันจาก Test plan เลยดีกว่าครับ   Test plan: คือมุมมองแบบกว้างๆ ( high level ) ที่เอาไว้ใช้บอกเราว่าการทำเทสจะเกิดขึ้นในลักษณะไหน อะไรจะถูกนำมาเทสบ้าง รวมถึง ใครเป็นคนทำ ทำอย่างไร ทำเมื่อไหร่ และ Quality level อยู่ในระดับไหนด้วย โดยใน Test plan จะประกอบไปด้วย element ต่างๆดังนี้ครับ –        S [Scope] : What to test, what not to test [...]

หลังจากห่างหายจากการเขียนบทความไปนาน วันนี้เลยขอหยิบยกเอาเรื่องใกล้ตัวที่ต้องทำกันเป็นประจำมาเล่าให้ฟังนะครับ เริ่มแรกต้องย้อนกลับไปสมัยยังเอ๊าะๆ เริ่มทำงานใหม่ๆเมื่อซักหกเจ็ดปีที่แล้ว จำได้ดีเลยว่าเริ่มทำเทสโปรเจคแรกเนี่ย ทาง Project Manager ก็จะบอกให้เรามา Estimate ว่าโปรเจคนี้จะใช้เวลาทำเทสเท่าไหร่ เอาหล่ะสิ ทำยังไงดีหล่ะทีนี้ ตอนนั้นสิ่งที่มีอยู่ในมืออยู่อย่างเดียวคือ requirement list ซึ่งก็เพิ่งเคยเห็นมันมาแค่สองวัน ยังไม่ได้ทำความเข้าใจและเรียนรู้กับมันซะด้วยว่าrequirementแต่ละตัวมันมีอะไรบ้าง พอถึงเวลาประชุมสรุป estimation ตัวเลขที่ออกไปจากปากตอนนั้นคือ 2 อาทิตย์ครับ ซึ่งตัวเลขนี้ได้ออกมาจากการนั่งเทียนครับ นั่งเทียนล้วนๆ คำว่านั่งเทียนในที่นี้คือการนั่งหลับตา ปล่อยสมองให้ว่างเปล่าแล้วตัวเลขหรือข้อมูลอันนึงจะโผล่แว๊ปเข้ามาในสมองของเราทันที หลังจากนั้นก็ลืมตาแล้วเอาตัวเลขนั้นหล่ะมาใช้ (คำว่านั่งเทียนนี้สามารถใช้กับ tester ที่ต้องออกแบบเทสเคสโดยที่ไม่รู้อิโหน่อิเหน่ไม่มีเทคนิคด้วยนะครับ หึๆๆ) ทีนี้เรามาลองสรุปข้อผิดพลาดที่เกิดขึ้นจากคำว่า 2 อาทิตย์ที่พูดไปเมื่อเจ็ดปีที่แล้วกันดีกว่าว่าความผิดพลาดหลักๆที่เกิดขึ้นจากการนั่งเทียนนั้นมีอะไรบ้าง

สวัสดีครับ หลังจากที่คราวที่แล้วเล่าเรื่อง Test Efficiency & Effectiveness ให้ฟังกันไปแล้ว คราวนี้มาลองคุยกันเรื่องเบาๆ (แต่อาจจะเป็นเรื่องที่ทำให้หลายๆคนเกิดอาการเซ็งกันได้บ่อยๆ) กันหน่อยดีกว่าครับ คำพูดที่หลายๆคนคุ้นหู “ตัวนี้มันไม่ใช่ Bug นะครับคุณTester นี่มัน Expect Behavior มันต้องเป็นอย่างนี้แหล่ะ เชื่อผมๆ” มีใครเคยได้ยินประโยคคลาสสิคแนวๆนี้มั่งมั๊ยครับ แล้วลองคิดดูนะครับ ว่าที่ผ่านมาเรามี reaction อย่างไรกับคำพูดนี้ เท่าที่ผมเคยเห็น หรือเคยได้ฟังคนมาบ่นบ่อยๆ ก็จะมีสองกรณีหลักๆ 1. “เอ่อออ เหรอ จริงเหรอ มันต้องเป็นอย่างนี้จริงๆเหรอ… อ่า แต่มันดูแปลกๆนะ อ่า…. เหรอ ไม่ใช่จริงๆ หรอ… อืมๆๆ ไม่ใช่ก็ได้แหล่ะมั้ง เดี๋ยวไป reject ให้ละกันนะ” หรือแบบที่สอง (หลังจากที่โดน Reject มาสิบตัว อารมณ์กำลังคุกรุ่น อาจจะเป็นแบบนี้) 2. “อะไรนะ ไม่ใช่อีกแล้วเหรอ ทำไม Report มาสิบตัว [...]

QA หลายๆคนคงเคยมีคำถามว่า เราจะรู้ได้ยังไงว่าสิ่งที่ทำไปอยู่ทุกวันเนี่ย มันดีแล้วรึเปล่า ทำงานได้ Effective รึยังน้อ จะคุ้มเงินค่าจ้างที่เค้าให้เรามามั๊ยนะ (อันนี้อาจจะไม่ค่อยได้คิดกัน) เรื่องนี้แม้แต่ผู้บริหาร หรือ QA Manager หลายๆท่านที่เคยได้เข้า class ที่ผู้เขียนสอน ก็มักจะมีคำถามว่า เราจะมีวิธีวัดประสิทธิภาพ และประสิทธิผลของการทำเทสยังไงได้บ้าง จริงๆแล้วการวัด Effectiveness & Efficiency นั้นมีหลากหลายวิธีด้วยกัน แต่ขอเริ่มจากอันง่ายๆ ที่เคยเห็นเคยใช้มาก่อนแล้วกันนะครับ


top