วิธีการมอง Flow และการค้นหา Bug

ในบทความนี้ จะมาอธิบายขั้นตอนการมอง Flow การทำงานของระบบซึ่งจำเป็นสำหรับ Developer และ Tester มากๆ

Flow หมายถึง การไหล

ในที่นี้หมายถึง การทำงานของโปรแกรมที่ลื่นไหนของ System เป็นแบบ End-to-End

แล้วการรู้ Flow การทำงานทั้งระบบ สำคัญยังไงล่ะ?

• Developer ส่วนใหญ่จะเป็นกลุ่ม Specialist ที่เก่งเฉพาะด้าน เมื่องานถูกแบ่งและแยกออกเป็นส่วนๆ ทำให้ไม่แปลกที่ Developer จะรู้การทำงานของ Application ในส่วนที่เกี่ยวข้องกับระบบที่ตัวเองเป็นคนพัฒนา
• การเห็น Flow ทั้งหมดของ Application จะทำให้เราเข้าใจการทำงานของ Function ที่เรากำลังทำอยู่มากขึ้น และสามารถ Trace ปัญหาที่เกิดขึ้นได้ง่าย รวดเร็วโดยไม่ต้องถึงมือ Tester เลย

☆ ถ้ามองการทำงานของ Application เป็นแบบท่อน้ำและการไหลของข้อมูลเป็นน้ำในท่อ ถ้าเรารู้เฉพาะแค่บางส่วนเราจะไม่สามารถรู้ได้เลย ว่าน้ำถูกทำให้สกปรกตั้งแต่ส่วนไหน

• ส่วนหน้าที่ของ Tester จะเป็นเหมือนนักสืบของ Application ที่ได้รับมอบหมาย ต้องรวบรวมการทำงานทั้งหมดเข้าด้วยกัน และเช็คแต่ละส่วนให้ถูกต้องทั้ง data ที่ถูก และ data ที่ผิด

จากแนวคิดของ Tester เรานำมาปรับใช้จะทำให้เราเข้าใจวิธีการมอง Flow มากขึ้น โดยหยิบ Scenario หลัก (Happy Path) ที่เป็นทางหลักการไหลของ Application เน้นว่าเราต้องการเข้าใจใน Flow การทำงานของ Application เท่านั้น

1. เริ่มต้นขั้นแรกเราต้องหาเส้นทางการไหลของข้อมูลตั้งแต่ต้นจนจบ โดยหยิบแต่ละ Function มาเรียงต่อกัน เพื่อรวบรวมกันไหลของข้อมูลอย่างถูกต้อง เช่น

A = รับข้อมูล

B = บวก

C = ส่งข้อมูลไปทางอีเมล

D = แสดงผลบวก และผลลัพธ์การส่งอีเมล

เราหยิบ Function แต่ละตัวมาต่อกันและนำ data ใส่เข้าไป -> A__B__C__D

2. การทำงานของ Application ใด Application หนึ่งจะมีความซับซ้อนในตัวของมัน เราต้องหาจุดสนใจ โดยโฟกัสไปที่ data ของเราเท่านั้น

data -> A -> new_data -> B -> new_data2 -> C -> new_data3 -> D -> result

เราไม่จำเป็นต้องเข้าใจรายละเอียดของแต่ละ Function เราจะสนใจเฉพาะ data -input และ data output เท่านั้น (มองแต่ละ Function ที่เราไม่รู้จัก เป็น Black box)

3. สนใจเฉพาะ Data Input และ Expect Result สำหรับแต่ละ Function

ในกรณีที่ยกตัวอย่าง เราสนใจเฉพาะ

data เริ่มต้น เมื่อผ่าน Function A จะต้องไป new_data เท่านั้น

new_data เมื่อผ่าน Function B จะได้ new_data2

new_data2 เมื่อผ่าน Function C จะได้ new_data3

new_data3 เมื่อผ่าน Function D จะได้ result

ถ้ามีส่วนไหนที่ผิดไปจาก Flow ที่วางไว้ หมายถึงเกิด ฺBug ที่ส่วนใดส่วนหนึ่งแล้วล่ะครับ จะพูดถึงต่อในลำดับต่อไป

*ขั้นตอนที่สำคัญที่สุดคือขั้นตอนที่จับแต่ละ Function มาเชื่อมโยงเรียงต่อตามลำดับการทำงานของมัน ตั้งต้นให้ถูกต้องจะทำให้เราจับการทำงานของ Flow ได้ง่ายขึ้น

Bug เป็นคำที่ Developer แทบจะทุกคนที่กลัวกับมัน

เมื่อเราเจอปัญหาในส่วนใดส่วนหนึ่งของ Flow การทำงานของ Application ต้องเข้าใจไว้ว่า

• เมื่อเราทดสอบแล้วไม่เจอปัญหานั้นอีก ไม่ได้แปลว่า Bug มันหายไปเองได้
• การเกิดปัญหาในระบบเราจะใช้ความรู้เรื่องการเรียงต่อของ Function ที่พูดไปแล้วข้างต้นมาช่วย กล่าวคือ ยิ่งเราเข้าใจว่า data แต่ละส่วนของ Function ที่เปลี่ยนไป ผ่าน Function ไหนมาบ้าง และไปไหนต่อ ทำให้เรา Trace ปัญหาได้รวดเร็วขึ้น
• เมื่อมีอะไรผิดไปจากปกติ เราสามารถสงสัยได้เลยว่า ต้องมีอะไรผิดปกติอยู่ในส่วนนั้นๆ (เพราะถ้ามันทำงานได้ปกติ ต้องไม่มี data ที่แปลกไปจากที่เรา Expect ไว้แน่นอน)
• Tester เป็นเพียงนักสืบ Application ที่รู้เพียงที่มาของปัญหา แต่ไม่รู้เหตุผลจริงๆ ของการเกิด Bug ซึ่ง Developer เท่านั้นที่จะสามารถหาเหตุผลให้กับปัญหาได้ (เฉพาะฉะนั้นการเข้าใจ Flow การทำงานของระบบจึงสำคัญ)

ดังนั้นผู้พัฒนาระบบทุกคนควรจะมีสกิลการมอง Flow ทั้งเส้นของ Application ตั้งแต่ End-to-End จะทำให้เราเป็น Developer ที่ Advance มากขึ้นครับ

ส่วนวิธีการลงรายละเอียดเกี่ยวกับการแยก Test case ออกมาเป็นกรณี เพื่อทดสอบ Application นอกจากเส้นทางหลัก (Happy Path) จะพูดในบทต่อๆ ไปนะครับ