การทำงานของเราเน้น Quality (คุณภาพ) หรือ Quantity (ปริมาณ) แน่นอนว่าส่วนใหญ่เราโฟกัสที่ Quality อยู่แล้ว
ทีมที่สามารถส่งมอบ software ได้จะต้องมีทักษะเหล่านี้ ถ้าเราดูจากตัว Large-Scale Scrum มันจะมีทักษะเยอะมาก ซึ่งถ้าสังเกตดูจะเห็นว่าจะมีที่เกี่ยวกับ test อยู่เยอะมาก ตัวที่น่าสนใจเลยคือ Think about testing ซึ่งเป็นการคิดก่อนทำ
แต่ที่พบเจอบ่อยๆ เรามักจะใช้
ประมาณว่า Deadline ถูกกำหนดแล้ว แต่ยังไม่รู้เลยว่าทำเสร็จไหม แถมต่อให้เรารู้อยู่แล้วว่าไม่ทัน แต่ก็ยังพยายามทำให้มันทัน
เราไม่ได้คิดก่อนทำเลย
เราต้องสร้าง Quality ไปพร้อมกัน Trust ทั้งแต่คนในทีมและลูกค้า
ทำไมต้องทำการทดสอบ
การทดสอบช่วยเราในการจับบั๊ก (bug) ช่วยเพิ่มความมั่นใจ โค้ดที่มีคุณภาพ และช่วยให้คุณพัฒนาฟีเจอร์ต่างๆ ได้เร็วขึ้น รวมถึงสร้างเอกสารประกอบ (documentation) ได้ดีขึ้น
ถ้าเรามาดู v model มันจะเริ่มต้นจาก Requirements ไล่ลงไปเรื่อยๆ และเราก็จะทดสอบย้อนกลับมาจาก unit testing ไปจนถึง acceptance testing
ที่พบเจอทั่วไป เรามักทำให้การทดสอบอยู่ช่วงท้ายของการทำงาน แล้วมันก็เจอปัญหามากมาย
เรามักจะแก้ด้วยการเปลี่ยนการทำงานมาเป็นรอบสั้นๆ เพื่อหวังให้ปัญหาหลายๆ อย่างหมดไป แต่มันก็อยู่ในช่วยท้ายของรอบการทำงานอยู่ดี
ซึ่งสิ่งนี้เป็นสิ่งที่บอกว่า เราเอามันมาใช้ แต่ไม่เปลี่ยนวิธีคิด
ที่มันควรจะเป็นเลย คือ ในแต่ละขั้นตอนจะต้องมี Test ประกบมาตั้งแต่ต้นเลย เช่น Requirements -> Acceptance Testing โดยชุดการทดสอบที่ทำขึ้นมานั้นจะต้องระบุอย่างตรงไปตรงมาและเข้าใจง่าย
สังเกตว่า จำนวนการทดสอบจะเพิ่มมากขึ้นเรื่อยๆ ไปแต่ละ step เช่น Requirements มีการทดสอบทั้งหมด 100 เรื่อง ถ้าเราหยิบเอาหนึ่งเรื่องมาลงรายละเอียดในขั้นตอนถัดไปการทดสอบมันก็จะเพิ่มขึ้นไปอีก ซึ่งมันจะเยอะมากๆ
การทำแบบนี้เวลาอธิบายแล้วมันดูดี แต่ทำจริงอาจจะทำไม่ได้ เพราะมันเยอะเกินไป ก็ต้องสนใจในส่งที่มันสำคัญเอามาทำก่อน แล้วค่อยๆ breakdown มันลงมา ซึ่งมันช้าแน่นอน แต่มันชัวร์
เพื่อไม่ให้ไปเสียเวลาในการลงรายละเอียดทั้งหมดตั้งแต่ต้น การทำงานแบบ Iterative and incremental จึงเข้ามาช่วยในการทำงานแบบนี้ โดยเราจะต้องโฟกัสไปที่การทำงานให้เสร็จไปทีละอย่าง
ที่สำคัญเลย คือ อะไรที่มันใช้งานได้ มันจะต้องยังใช้งานได้เหมือนเดิมแม้ว่าจะเพิ่มอะไรเข้าไปใหม่ก็ตาม แต่เมื่อ feature เพิ่มมากขึ้น คนจะยังทำแบบ manual test ได้อยู่หรือเปล่า
หากมองจากภาพ จะเห็นว่า เมื่อเวลาผ่านไป การทดสอบแบบ regression testing จะใช้เวลามากขึ้น จนทดสอบไม่ทัน แล้วเราก็จะยกมันไปไว้ตอนท้ายของโปรเจค พอถึงตอนท้ายปรากฏว่าเวลาไม่พอ สุดท้ายเราก็จะเลือกแค่บาง case มาทดสอบ เพราะทดสอบทั้งหมดไม่ทัน
มันจึงเกิด Automation Testing ขึ้นมา
แต่ต่อให้มี automation แล้ว เราก็เอาไปสร้างและใช้งานช่วงท้ายอยู่ดี ปัญหานี้เกิดจากที่เราเอาเครื่องมือมาใช้ แต่เราไม่ได้เปลี่ยนวิธีคิด
การทดสอบที่ดีควรเป็นอย่างไร
ควรเป็นอย่างไรบ้าง
F.I.R.S.T + U
Fast: ต้องเร็ว run ต้องเร็ว คำถามคือ เร็วขนาดได้ ก็ต้องถามตัวเองว่าปัจจุบันเร็วแค่ไหน ลดได้อีกหรือเปล่า
Isolate: จะต้องเป็นอิสระต่อกัน เพื่อให้การทดสอบสามารถแยกการทดสอบออกจากกันได้ และสามารถ run แบบ parallel ได้ รวมถึงการแยกการเชื่อมต่อกับระบบอื่นๆ ดเวย เช่น
Repeat: สามารถทดสอบซ้ำๆ ได้ จะต้องได้ผลลัพธ์จะต้องเหมือนเดิมในทุกครั้งที่ทดสอบ
Self-verify: แต่ละเทสเคสจะต้องกำหนดว่าต้องการจะทดสอบอะไร และต้องการผลลัพธ์อะไร
Timely: เทสมันจะเกิดขึ้นตอนไหน เช่น ทดสอบเลย ผ่านไปสักช่วงหนึ่งค่อยทำ แต่เร็วที่สุดยิ่งดี ความเข้าใจในการทดสอบ ถ้าเราปล่อยนานไปจะลืมว่าเราทำอะไรไปบ้าง และทดสอบยากขึ้น
Understand: เราจะต้องทำความเข้าใจระบบของเรา โดยเริ่มจากทำความเข้าใจ Requirements แล้วต่อด้วย Architecture ลงไปเรื่อยๆ เพื่อดูภาพรวมภาพใหญ่ของระบบก่อน เพื่อใช้เข้าใจว่าระบบเป็นยังไง และเราสามารถทดสอบอะไรได้บ้าง
ขอบเขตการทดสอบ (Test Strategy)
เราจะต้องมาคิดก่อนว่าจะทดสอบอะไร ตรงส่วนไหน
เช่น สมมติว่า ระบบของเราเป็นอย่างนี้
ถ้าเราต้องการทดสอบทั้งหมด โดยผ่านทาง UI ซึ่งเรียกว่า end-to-end testing ซึ่งความเชื่อมั่นจะสูงมาก แต่ทดสอบได้ไม่บ่อย เพราะมีหลายๆ ส่วนที่ต้องคุยกัน ต้องนัดประชุม เลยทำให้เกิดการเทสใน level อื่นๆ เพื่อให้สามารถทำได้บ่อยๆ
ถ้าจะทดสอบ integration test เป็นการทดสอบว่าระบบสามารถทำงานร่วมกันระหว่างฮอบ ได้หรือไม่ โดยวิธีนี้ความเชื่อมั่นจะลดลงมา
ต่อมา เราจะทดสอบแต่ละกลุ่ม เพื่อตรวจสอบว่าแต่ละกลุ่มสามารถทำงานได้ ซึ่งจะเรียกว่า isolate/component testing แล้วค่อยไปทดสอบแบบ integration test ต่อ
วิธีนี้จะไม่เรียกส่วนที่เชื่อมต่อกันจริงๆ จำเป็น ต้อง mock เพื่อให้สามารถ run และทดสอบได้
สังเกตว่าตรงที่จำลอง ถ้ามีการเปลี่ยน มีการแจ้งไหมว่ามีการเปลี่ยนแปลง หากยังไม่แจ้ง (ไม่ sync กัน) มันก็จะกลายเป็นว่า สิ่งที่เรา mock ไว้ก็จะใช้งานไม่ได้ ไม่ตรงกับส่วนนั้นจริงๆ
จึงเกิดการคิดขึ้นมาว่า ทั้งสองฝั่งมาจับมือกัน เพื่อมาตกลงกันว่าแต่ละจุดนั้นมีการปรับแก้และทำงานยังไง ออกมาเป็นข้อตกลง โดยการสร้างสิ่งที่เรียกว่า contract testing
เวลามีการเปลี่ยนแปลงอะไร ทั้งสองฝั่งจะต้องมาคุยกัน และปรับเปลี่ยนตัว contract นั้น เพื่อให้มั่นใจว่า สิ่งที่แก้ไป กระทบใครบ้าง
จากทั้งหมดที่ไล่มา เวลาทำงาน เราก็เริ่มจากการทดสอบ contract ก่อน ถ้าผ่านจะไปทดสอบในส่วนของ component testing และ integration ต่อ ไล่กลับขึ้นไป ซึ่งจะตรงกับการทำงานแบบที่มันควรจะเป็น
สุดท้าย การทดสอบแบบ unit testing เป็นการทดสอบไปทีละ step เล็กๆ
ซึ่งทดสอบแบบ unit testing จะเร็วที่สุด แต่ความเชื่อมั่นจะต่ำที่สุด (ว่าระบบสามารถใช้งานได้ไหม)
ทั้งหมดนี้เป็นการวางกลยุทธการทดสอบ ซึ่งจะต้องถูกพูดคุยและวางกันตั้งแต่ต้น ก่อนการพัฒนา ถ้าให้ดีต้องเริ่มตั้งแต่ก่อน requirements
สุดท้าย automated test เหมาะกับการทดสอบทุกอย่างไหม หรือเราควรเน้นไปที่การทดสอบแบบไหน
ต้องบอกว่า การพัฒนา software ในแต่ละจุด เราจะต้องคิดก่อนว่าเราจะทดสอบอะไร แล้วต้องทดสอบตรงไหน มองในมุมของ user แล้วมามองต่อว่ามันคุ้มค่าไหม เช่น ถ้าจะทดสอบการสมัครสมาชิกผ่านมือถือ แล้วมีการส่ง OTP เราจะลงทุนกับมันไหม เพื่อให้รู้ว่า OTP สามารถส่งถึง user ไหม เอา OTP ที่ได้มาใส่ OTP แล้วเช็คว่าถูกหรือผิด
เราต้องมาคิดก่อนว่า ถ้าจะทำมันคุ้มค่าไหม ถ้าคุ้มก็ทำ แต่ถ้าไม่คุ้มค่าก็มองหาวิธีอื่นในการทดสอบ
คิดก่อนทำ
คิดก่อนว่าเราจะทดสอบอะไร
คิดอย่างไร เราจะลงมือทำอย่างนั้น
ถ้าเราทำแบบไม่คิด ผลก็จะออกมาแบบไม่คิด
- พี่ปุ๋ย somkiat.cc