Loading ...ความเดิม
ความเดิมจากบทความที่ผมขอให้เพื่อนๆร่วมแชร์ประสบการณ์ว่าทำไม Automated Testing ล้มเหลวนั้น ต้องขอบคุณคุณ AMp และคุณ zyracuze ที่ช่วยออกความคิดเห็นที่ผมก็เห็นด้วยว่าเป็นสาเหตุที่สำคัญของความล้มเหลวที่เกิดขึ้นเลยหละครับ ผมเองก็รวบรวมข้อมูลจากแหล่งอื่นๆด้วยก่อนสรุปมาเป็น 4 สาเหตุสำคัญที่ทำให้ Automated Testing ล้มเหลวพร้อมทั้งแนวทางป้องกันปัญหา
1. หนุ่ม-สาว QA ไม่ใช่ Developer
คงไม่ใช่เรื่องยากเท่าไรที่จะเขียน Test Script ที่สั่งให้โปรแกรมเปลี่ยนจากหน้าหนึ่งไปอีกหน้าหนึ่ง หรือตรวจสอบดูว่ามีข้อความนี้อยู่บนหน้าจอหรือไม่ แต่มันไม่ง่ายเท่าไรครับในการที่จะเขียน Test Script ที่ฉลาดพอที่จะทดสอบ input ได้ทุกรูปแบบและวนไปทุก field ที่มีบนหน้านั้นๆ รวมไปถึงการเขียน Test Script ที่เื้อื้อต่อการ reuse และ maintenance ครับ
ซึ่งคุณ zyracuze ก็ได้แสดงความเห็นไว้อย่างชัดเจนครับว่า Programming Skills เป็นปัจจัยสำคัญที่จะช่วยให้ QA ทำ Automated Testing ได้สำเร็จครับ
แนวทางป้องกันปัญหา:
- หา Developer จริงๆมาเป็นพี่เลี้ยงในช่วงแรกๆเพื่อแนะนำให้ QA วางโครงสร้างของ Test Script ได้อย่างถูกต้อง (reusability และ maintainability)
- QA ที่รับผิดชอบ Test Script ควรจะมี Programming Skills ด้วย
- จัดเวลาให้ QA หาความรู้เิพิ่มเติมเกี่ยวกับ Programming Practices
2. Automated Test นั้นเปราะบาง
การดูแลรักษา (maintenance) Test Script นั้นเป็นงานที่เสียเวลามากเพราะว่า Automated Test Script นั้น “เปราะบาง” และ “โง่” ครับ การแก้ User Interface นิดเดียว เช่น ชื่อปุ่ม หรือ warning message อาจจะทำให้ Test ทั้งหมดของเรา Fail ได้เลยครับ ถ้าอยากจะใช้งานมันได้ต่อไป เราก็ต้องมาคอยแก้ Test Script เรื่อยๆ
นึกภาพว่า QA ต้องสร้าง Test Cases, เตรียม Test Scripts, ตรวจสอบผลการ Test, และแก้ Test Scripts ทุกครั้งที่ระบบมีการเปลี่ยนแปลง กระบวนการตรงนี้เสียเวลามากกว่าทำ Manual Testing แน่ๆครับ
แนวทางป้องกันปัญหา:
- แก้ไข Test Script ให้ตรงกับการทำงานจริงๆของระบบอยู่เรื่อยๆ พยายามฝึกให้เป็นนิสัยครับ มันง่ายกว่ามากที่เราจะแก้วันละ 1 Test เมื่อเทียบกับการรอให้เวลาผ่านไป 1 สัปดาห์แล้วค่อยมานั่งแก้ทีเดียวเป็น 10-20 Test ครับ
- ตกลงกับ Developer ว่ากรุณาอย่าแก้ Interface (ไม่ว่าจะเป็น User Interface หรือ API Interface) ทุกๆวัน … หรือถ้าจะแก้จริงๆก็ให้บอกกันก่อนครับ
3. Automated Test ที่ซับซ้อนและเกี่ยวพันกันมากเกินไป
เป็นเรื่องง่ายครับที่จะเขียนให้ 1 Automated Test Case สามารถตรวจสอบได้หลายๆ Feature ของระบบ แต่แย่หน่อยครับ…ทำไมหนะหรอ? หนึ่งเป็นเรื่องยากมากๆเลยที่จะดูแลรักษา Test Case ที่ว่านี้ถ้าระบบมีการเปลี่ยนแปลงบ่อยๆ สองถ้า Test Case นี้ fail มันจะยากมากขึ้นในการหาสาเหตุว่าทำไมถึง fail ครับ และสามมันจะกลายเป็นฝันร้ายเลยครับถ้าเราเขียน Automated Test Case ไปขึ้นกับ Test Case ก่อนหน้าและก่อนหน้าครับ
เหตุผลที่จุดนี้เป็นปัจจัยอีกอย่างที่ทำให้ Automated Testing ล้มเหลวก็เพราะว่าเราต้องเสียเวลาอย่างมากในการทำ maintenance, และการหา reproducing steps เมื่อ fail จนสุดท้ายกลับกลายเป็นว่าทำ Manual Testing คุ้มค่ากว่าครับ ดังนั้นเราจึงควรทำให้ Automated Test Case นั้นไม่ซับซ้อนและเป็นอิสระต่อกันให้มากที่สุดครับ มีคนพูดไว้ว่า “ถ้าคุณไม่สามารถอธิบายจุดประสงค์ของ Test Case ได้ด้วยคำ 5 คำหละก็ Test Case ของคุณซับซ้อนเกินไปแล้ว” Test Case ของเพื่อนๆตอนนี้ซับซ้อนเกินไปรึเปล่าครับ?
แนวทางป้องกันปัญหา:
- เขียน 1 Automated Test Case เพื่องาน 1 งานเท่านั้น ห้ามขาดห้ามเกิน
- เขียน Automated Test Case ให้เป็นอิสระต่อกัน นั่นจะทำใ้ห้เราสามารถ Run Test Case ไหนก็ได้และเมื่อไรก็ได้ ผลจะออกมา Pass หรือ Fail ก็จะไม่ขึ้นกับ Test Case อื่นๆด้วย
- แตก Feature ให้ย่อยๆลงมาเพื่อง่ายต่อการเขียน Test Case และเตรียม Test Data ไว้ให้แต่ละ Test Case เลย
4. Automated Test ที่ไม่ค่อยมีประโยชน์
ทั้งคุณ AMp และคุณ zyracuze มีความเห็นตรงกันว่าปัจจัยนี้เป็นหนึ่งในสาเหตุสำคัญที่ทำให้ Automated Testing ของเราล้มเหลวครับ ผมขอขยายความนิดนึงเกี่ยวกับคำว่า “ไม่่ค่อยมีประโยชน์” นั้นหมายถึงว่า เราไปทำ Automated Test Case สำหรับส่วนงานที่ไม่สำคัญ และไม่ถูก Retest บ่อยๆนั่นเองครับ
แนวทางป้องกันปัญหา:
- เลือก Test ในส่วนที่สำคัญก่อน ถ้ามีเวลาเหลือจริงๆค่อยมาพิจารณาส่วนอื่นๆ
- ต้องเตรียมแผนที่ชัดเจนเกี่ยวกับ Test Coverage
สรุป
ทั้ง 4 ข้อนี้คือสาเหตุหลักๆที่ทำให้ Automated Testing ล้มเหลวหรือไม่ประสบความสำเร็จตามที่เราคาดหวังไว้ครับ หวังว่าจะเป็นประโยชน์กับเพื่อนๆทุกคนที่สนใจหรือประยุกต์ใช้ Automated Testing อยู่นะครับ
Related posts:
แวะมาคุยอีกรอบครับ (งวดที่แล้วกะจะพิมพ์ยาวๆ หน่อย แต่พอจะตอบจริง ดันลืมไปหมดเลย ^^’)
โดยปกติแล้วในส่วนงานที่ผมทำนั้น พูดได้ว่าแทบจะไม่มีการเทสจริงๆ จังๆ เลยครับ
เทสแค่พอเป็นพิธีเท่านั้นครับ ดังนั้นปัญหาที่มักจะเจออยู่บ่อยๆ ก็คือ
1. แก้จุดนึงไปกระทบอีกจุดนึงโดยที่ไม่รู้ตัว (และไม่ได้ทำ impact analysist อย่างละเอียดพอ)
2. เทส operation เดิมๆ บ่อยๆ ก็เบื่อ ทำให้การเทสแบบ manual ครั้งหลังๆ นั้น
ถูกบิดเบือนด้วย “ความเคยชินในการเทส” อาจจะทำให้ไม่เจอ defect อย่างที่ควรจะต้องเจอ
ซึ่งเท่าที่ผมลองศึกษา automated test นั้น ในผมเข้าใจเองว่า
automated test นั้นคือ automated unit test
และถ้ามันเป็นดังที่ผมคิด การทำ automated test นั้นจะมี cost สิ้นเปลืองค่อนข้างมาก
เพราะถ้าไม่มีใครมาคุมว่า อะไรควรเทส อะไรไม่ควรเทสเนี่ย จะเขียนเทสกันตะบี้ตะบันเลยทีเดียว
ผมก็เลยมองว่า ถ้าเอา automated test มาใช้เพียงแค่ในระดับ business test
น่าจะช่วยลด defect ที่เกิดขึ้นได้เยอะพอสมควร(ในขณะที่เสียเวลาไปไม่มากนัก)
ยิ่งเป็นระบบที่เกี่ยวข้องกับตัวเลข หรือเรื่องเงินๆ ทองๆ นั้น
ผมรู้สึกว่า defect ส่วนใหญ่จะเกิดขึ้นที่ระดับ business มากกว่า technical ครับ
ดังนั้น ถ้าระบบเราถูกออกแบบมาเป็น n-Tier ที่แยก business layer ออกมาชัดเจนแล้ว
การทำ automated test ในระดับ business นั้น น่าจะคุ้มค่า
มากกว่าไปทำ automated ในระดับ unit function หรือ ui ครับ
ป.ล. แนวคิดผม ผิดถูกแนะนำด้วยนะครับ เพราะโดยประสบการณ์
)
ยังไม่เคยเจอโปรเจกที่มีทีมเทสที่รับผิดชอบงานโดยตรงครับ (เทสกันเองด้วย …. ลูกทุ่งมากๆ
คุณ AMp ขอบคุณมากครับสำหรับความคิดเห็น
คุณAMpมีความเข้าใจที่ถูกต้องแล้วครับเกี่ยวกับความจริงที่ว่า “Automated Testing ต้องลงทุนสูงและไม่เหมาะกับการ Test ในทุกๆรูปแบบ” ผมขออนุญาตให้ความเห็นเพิ่มเติมดังนี้ครับ
หวังว่าความเห็นผมจะช่วยได้นะครับ
โอ้วววว ขอบคุณมากครับ ที่ช่วยแนะนำสิ่งดีๆ ให้
ปัญหาคือเราไปให้ QA ทำ black box testing กับ system test โดยไม่จำเป็น
ทำให้สุดท้าย boundary อยู่ที่ UI พอ test จาก UI เข้ามาตัว UI นั่นแหละคือ dependency ที่ mock ทิ้งไม่ได้และอ่อนไหวที่สุด
คนแก้ UI ก็ไม่ใช่เรา คนแก้ code ก็ไม่ใช่เรา แต่คนซวยคนเหนื่อยกลับเป็นเรา ฟังดูเป็นอาชีพที่น่าสงสารนะครับ
มา automate test เอาตอน level บนสุด มันยากมากที่จะ test ได้อย่างเต็มประสิทธิภาพ เพราะทั้งเสียเวลา และก็ไม่ได้หา bug ได้ง่ายเหมือน level ที่อยู่ล่างกว่า
ผมยังเชื่อว่า automate testing ทำได้ดีในระดับ system test ที่ QA ดูอยู่ ได้ดีในระดับหนึ่ง
Test case ที่ล้มเหลวจากการ maintain ไม่ได้เพราะตัว test case เองนั่นแหละที่ยุ่งยากและซับซ้อนเกินไป (ต้องมี test case สำหรับ test case อีกไหม?)
ทำงานเกินตัว หรือ dependency ผูกเต็มไปหมด สุดท้ายพอบางอย่างเปลี่ยน การเปลี่ยนให้ test case sync ตามกลับเป็นว่า effort ที่ใช้แก้ ไม่ได้ scale ตามเลย
สุดท้าย automated test case ก็ถูกทอดทิ้ง
พยายามทำ gray box testing ถ้าเป็นไปได้ละกันครับ พยายาม vertical เอา tester ไปอยู่ใน project นั้น นั่งรวมกลุ่มกับ developer ไม่ใช่นั่งรวมกลุ่มกันเองกับ tester
พอเราเป็นส่วนหนึ่งของทีมที่พัฒนา สิทธิ์ access และ loop feedback มันเร็วกว่าเยอะครับ ตัดปัญหา เขา vs เรา ไปได้ด้วย
บริษัทเดียวกัน ทำโปรเจ็กต์เดียวกันก็นั่งอยู่ใกล้ๆ กันแหละครับ จัดทัพแบบ vertical ผสมหลาย role ให้หลากหลาย การ test จะได้ง่ายขึ้นเร็วขึ้น จะได้ไม่ต้องรอให้ไปให้ถึงบนสุดเพื่อให้รู้ว่ามันพัง
เป็นข้อแนะนำที่ดีมากครับ “พูดกันมากขึ้น เข้าใจกันมากขึ้น” การทำงานร่วมกันระหว่าง Developer และ QA เป็นปัจจัยสำคัญที่ช่วยให้เรากรอง bugs ออกจากระบบได้เร็วขึ้น ทีมที่ผมทำงานอยู่ก็ใช้หลักการเดียวกันนี้โดยทำงานร่วมกันตั้งแต่ Requirement Analysis – Product Release เลยครับ ได้ผลดีมากฮะ คอนเฟิร์ม!!!
อ้อ … ขอบคุณที่ช่วยเพิ่มเติมข้อมูลเกี่ยวกับสาเหตุที่ทำให้ Automated Testing ล้มเหลวด้วยครับ
[...] Link: 4 สาเหตุสำคัญที่ทำให้ Automated Testing ล้มเหลว [...]
[...] จากบทความก่อนหน้าที่ผมได้รวบรวมปัจจัยหลัก 4 [...]