ในการเปลี่ยน tester จาก manual testing ไปทำ automation testing นั้น หลายๆ คนคิดว่ามันเป็นเรื่องง่าย ก็แค่เอาสิ่งที่ทำมาไปเขียนเป็น automation ก็จบแล้ว ปัญหาใหญ่ที่สุดก็คงหนีไม่พ้น coding
แต่ๆๆๆๆ มันเป็นวิธีคิดที่ผิดมาก เพราะจริงๆ แล้วการที่ tester จะปรับตัวเองไปเป็น automation นั้น มีสิ่งที่ต้องปรับเยอะมาก
เอาจริงๆ การเอา dev มาเพิ่มทักษะด้าน test น่าจะง่ายกว่าซะด้วยซ้ำ หลังจากนั่งครุ่นคิดเรื่องนี้มาหลายชั่วโมง
ผมได้สรุปสิ่งที่เรา “ควรรู้” ออกเป็น 6 ข้อ ที่ QA/Tester สาย automation ต้องรู้ก่อนที่จะออกแบบชุดการทดสอบ
1. Core business flow
สิ่งที่ tester หลายๆ คนติดกันเลย คือ ไม่สามารถเข้าใจ business flow ได้ ซึ่งในทีนี้เราพูดถึงการเข้าใจสิ่งที่ user ต้องการทำให้เสร็จ (Job to be done ของ user)
หลายๆ ครั้งเราจะพบว่า tester มันจะออกแบบชุดการทดสอบแบบที่อ้างอิงตามหน้าจอซึ่งชุดการทดสอบแบบนั้นมันใช้กับ manual test ไม่เหมาะกับการนำไปใช้กับ automation testing ได้ เพราะรายละเอียดที่จะทดสอบมันไม่เพียงพอ และ ต้องเสียเวลามาแยกส่วนต่างๆ ออก เพื่อเอาไปใช้กับ automation test อีก
เราจึงมักพบว่า developer มักจะคิดชุดการทดสอบสำหรับ automation ใน level unit, component, และ integration เอง ซึ่งเหมือนจะดี แต่ถ้าชุดการทดสอบมันไม่ relate กัน มันก็จะมีปัญหากันอีก และ ตรวจสอบได้ยากขึ้น
สิ่งที่ควรระวังในการออกแบบชุดการทดสอบ หรือ ระบบ โดยอ้างอิงจากหน้าจอ คือ เราอาจจะหลุดพวก business condition ได้ เพราะสิ่งเหล่านั้นจะถูก wrap ไว้บนหน้าจอเดียว มันเลยค่อนข้างเสียเวลาที่ทีมพัฒนาจะต้องมานั่งแกะ business condition ใหม่อีกรอบ
2.System Flow
ในการทำ automation testing เป็นไปไม่ได้เลยที่ tester จะปฏิเสธว่าจะไม่ทำความเข้าใจการทำงานของระบบ (หลีกเลี่ยงเรื่องเทคนิคคอล) เพราะก่อนที่เราจะคิดการทดสอบออกมาได้เราจำเป็นต้องรู้ก่อนว่าระบบของเราทำงานยังไง
- user flow หลัก คือ อะไร
- data วิ่งยังไง
- condition เป็นยังไง
- error อะไรที่เกิดขึ้นได้บ้าง
เช่น:
login → call API → validate → return token → call service อื่น
เราต้องรู้สิ่งเหล่านี้เพราะ เราต้องเอาไปใช้ในการออกแบบ end to end testing และ หา critical path ที่จะเกิดขึ้น
3. System boundary
เราจำเป็นต้องรู้ว่า ส่วนที่เราจะทดสอบนั้น:
- มี service อะไร คือ ของเรา
- ใช้ data storage อะไร (เช่น database เป็น postgresql, และ เก็บข้อมูลแคชบน redis)
- อะไรเป็น 3rd party ทั้งที่เป็นของภายในเองและภายนอก (เช่น payment, API อื่น, pub/sub, file storage)
สิ่งนี้สำคัญมาก เพราะ เรา control ไม่ได้ทุกอย่าง, ต้อง mock / stub ให้ถูกจุด ถ้าหากเราพยายามทำให้ทุกอย่างมันทดสอบได้ automation test ของเรา จะซับซ้อนเกินไปจนยากในการทดสอบ (ถ้าทำ automation testing ไม่ได้ก็ผลักจุดนั้นไปทำ manual testing)
การที่รู้ภาพรวมเหล่านี้จะช่วยให้เรารู้ว่า:
- ต้อง mock ตรงไหน
- เลือกรูปแบบของการ mock
- test แค่ไหนถึงจะพอ
tester ไม่จำเป็นต้องรู้ code แต่ต้องรู้ว่า ในระบบนี้ อะไรคุยกับอะไร และ มี dependency อยู่ตรงไหนบ้าง
4.Data flow
ไม่ว่าจะ Core business flow และ System Flow จะเห็นว่ามีการพูดถึงเรื่อง data flow ด้วยเสมอ เพราะมันเป็นตัวบอกให้เรารู้ว่า:
- data เข้ามาจากไหน → ผ่านอะไร → ส่งต่อไปที่ไหน
- จุดไหน transform / validate
- state เปลี่ยนยังไง
ถ้าไม่เข้าใจตรงนี้ test จะมั่วทันที
เพราะในการทำ automation ที่ดี เราจะต้องจับตรงนี้ให้ได้ เพราะมันจะทำให้เรา scope ได้ว่าชุดการทดสอบของเราจะ cover ถึงไหน และเอาไปใช้กับการทดสอบ level ไหนได้บ้าง
เช่น
- API test
- contract test
5. จุดเสี่ยง (Risk-based thinking)
สิ่งที่ tester แบบ manual test มันจะทำเสมอ คือ การหา bug ให้ได้เยอะที่สุด ไม่ว่า bugs เหล่านั้นจะยิ่งใหญ่หรือเล็กน้อยเพียงใด ซึ่งเป็นแปลก เพราะถ้าเราให้การทดสอบเป็น Quality gate แล้ว + การทดสอบตามหลัง (Defensive) การหา bug ให้เยอะที่สุดจึงเป็นเรื่องที่ make sense (มั่งนะ)
ในทางกลับการ การออกแบบชุดการทดสอบก่อน (Test first) เราจะไม่ได้เน้นที่การออกแบบชุดการทดสอบให้เยอะที่สุด แต่เราจะโฟกัสที่ว่า ชุดการทดสอบของเราเพียงพอหรือเปล่า และไม่ใช่ทุกที่จะสำคัญเท่ากัน
ดังนั้นเราต้องถามตัวเองเสมอว่า:
- ถ้าพัง จุดไหน impact สูงสุด?
- feature ไหนทำเงินจริง?
- flow ไหน user ใช้เยอะ?
เราต้องซึ่งในมุมของการ develop ก็เช่นเดียวกัน เราเรียกสิ่งนี้ว่า design by failure หมายถึง ออกแบบระบบให้พังอย่างตั้งใจ รู้แล้วว่าจุดไหนจะพัง และ เราจะ handle error นั่นยังไง
ในมุมของ tester ก็เหมือนกัน เราต้องรู้เหมือนกันว่า ชุดการทดสอบของเราจะ cover จุดไหนบ้าง และจุดไหนที่เราจงใจปล่อยให้มัน error เพื่อให้ effort ที่ใช้มัน align กับ risk
เราจะชี้ได้ว่า นี่จุดนี้ คือ ที่ “ต้องทำ automate test”
6.จัดกลุ่มการทดสอบ
ถ้าเรารู้ภาพรวมจริงๆ แล้ว เราจะตัดสินใจได้ว่า อะไรควรเป็น automation และ อะไรควรเป็น manual
เพราะในการทดสอบแล้ว การที่จะทำให้ระบบเป็น 100% automation แทบเป็นไปไม่ได้เลย ดังนั้นเราจำเป็นที่จะต้องระบุให้ได้ว่า:
- อะไรควรเป็น Unit test
- อะไรควรเป็น API test
- อะไรควรเป็น E2E
- อะไรควรเป็น Manual test
จาก 6 ข้อที่กล่าวมา จะเห็นได้ว่า เราไม่ได้แค่ออกแบบชุดการทดสอบแล้ว แต่เราต้องเข้าใจ Business, System, และ Test เราถึงจะสามารถออกแบบวิธีการทดสอบออกมาได้มีประสิทธิภาพ ไม่ใช่แค่แปลงจาก manual testing เป็น automation testing