กว่าจะมาเป็น TEST SCRIPT (ตอนที่ 2 : Test Design vs. การกินBuffet นานาชาติ)

.. หลังจากที่เราได้ทำ Test Analysis โดยผลลัพธ์คือมีส่วนร่วมในการทำให้ software spec ครอบคลุมมากขึ้น ชัดเจนเจาะจงมากขึ้นแล้ว ชีวิตเราในช่วง Test Design ก็จะง่ายขึ้นด้วย ส่วนตัวแล้วช่วง Test Design เป็นช่วงที่ต้องใช้สมาธิสูง เพราะต้องออกแบบ Input condition และ Output condition มองเห็น universe แล้วค่อยๆ ตัด combination ที่จะไม่เกิดขึ้น หรือโอกาสเกิดขึ้นน้อยๆมากๆและ impact ต่ำออก

หากเราทำ Test Analysis มาไม่ดี จะเกิดแต่คำถามขึ้นเรื่อยๆในช่วงทำ Test Design ว่า case นี้ case นั้นจะเป็นไปได้มั๊ย แล้วถ้าเกิดขึ้น expect result จะเป็นอย่างไร
ทีนี้จะทำให้เกิด looping ของคำถามที่จะต้องคอยย้อนกลับไปกลับมาถามคนอื่น ทำให้เราไม่สามารถคงสมาธิในการคิด Test Design ได้อย่างต่อเนื่อง

 

  • Style การทำ Testing ของผมจะเป็นรูปแบบ front load นั่นคือ ลงทุนให้เยอะๆในช่วงต้น ถ้าเราทำ Analysis ได้ดี ช่วง Design จะง่ายถ้า Design มาดี ตอน Implement (เขียน script) จะสะดวก แล้วถ้า Script มาดี ตอน Execute เราจะมีแรงกดดันน้อย และไม่ต้องใช้ความคิดมาก รู้ๆกันอยู่ว่าช่วง execute จะเป็นช่วงที่ความกดดันสูง และเป็นช่วงความสร้างสรรค์ถูกบดบังเพราะความกดดัน ฉะนั้นผมถึงให้ความสำคัญกับ front load style (คำศัพท์ส่วนตัว) เป็นอย่างมาก

อ่านมาถึงตรงนี้แล้ว บางคนอาจจะสงสัยว่าแล้ว test design กับ การกิน buffet นานาชาติเกี่ยวกันยังไง??? คำตอบอยู่อีกไม่ไกลข้างล่างนี้แล้วคับ มาติดตามกัน

Test Design คือการจัดการกระบวนการความคิดอย่างเป็นระบบ เพื่อที่ใช้ข้อมูลภาพใหญ่ที่เราได้จาก Test Analysis มาระบุ test condition และ output condition ที่จะ test และที่จะไม่ test ออกมาทั้งหมด โดยอาจจะยังไม่มีการเรียบเรียงลำดับ ว่าอะไรต้องทำก่อนอะไร แต่ควรจะต้องมี note ไม่ว่าจะในใจหรือเขียนออกมาว่า test condition priority แต่ละอันสูงต่ำอย่างไร

 

  • Technique ในการทำ Test Design มีหลากหลาย แล้วแต่มิติของการมองตัวระบบ ไม่มี technique ไหนดีที่สุด ขึ้นอยู่กับลักษณะของระบบนั้นๆ

ถ้าจะให้เขียนเรื่อง Technique ออกมาคงได้เป็นเล่ม เพราะมันลึกซึ้งและรายละเอียดเยอะมาก

สำหรับ blog วันนี้ ผมจะเปรียบเทียบให้เห็นภาพนะครับ ผมคิดว่าการทำ test design ของ project นึงเหมือนการไปกิน buffet นานาชาติครับ buffet ที่เดียวมีอาหารหลายอย่าง

 

เราเริ่มด้วยซุบด้วยช้อนซุป ใช้ส้อมกินสลัด (หรือส้มตำ)ใช้มีดกิน steak ใช้ตะเกียบกินซูชิ และใช้มือกินcalifornia roll … เห็นมั๊ยครับแค่กินมื้อเดียวยังต้องใช้เครื่องมือตั้งหลายอย่าง ถึงจะกินได้คุ้ม+กินได้เร็ว 🙂

ฉันใดก็ฉันนั้น การ test project แม้จะมี application ตัวเดียว มันก็มีหลายมิติให้จัดการโดยจะต้องใช้ technique คนละแบบในแต่ละส่วนของ app เช่น ส่วน user input, interface format, report หรือส่วน business logic ซึ่งมีการคำนวณหรือ transition ของ status ของข้อมูล เราก็ต้องเลือก technique ที่เหมาะสม จะใช้อันไหนมากก็ขึ้นอยู่กับว่าส่วนหลักๆของ buffet มื้อนี้เน้นส่วนไหนครับ

 

ผมมีเอกสารดีในมีอชุดนึงเกี่ยวกับการจัดกลุ่ม test design technique ตามมิติที่ต่างๆกัน ถ้าใครสนใจ email มาคุยกันได้ที่ ekaluckc@gmail.com นะครับ ผมจะส่งให้

จากประสบการณ์ app ที่ผมทำส่วนใหญ่เน้นพวก business logic และการคำนวณ การส่งคำสั่งซื้อขายไปตลาดหลักทรัพย์ (ส่ง ผ่าน ไม่ผ่าน เพราะเงื่อนไขต่างๆ) ถ้าส่งแล้วตัวเลขใน port เช่น position, ผลกำไรขาดทุน และ purchasing power ที่จะยังซื้อได้อีกเป็นเท่าไหร่ สถานะของ account จะเป็นอย่างไร ผมชอบใช้ ตารางmatrix ที่เขียนขึ้นมาเองเพื่อที่จะระบุ test condition และ expected result ได้ โดยอิงจาก initial state -> action -> expected output เป็นหลัก ตารางที่ได้ออกมาจะมีสองแกนครับ แกนตั้งผมจะlist possible initial state, possible action, expected output condition ออกมาที้งหมด และแกนนอนผมจะทำเป็น test condition เช่น TC1, TC2, TC3, จากนั้นผมก็จะ Map combination ที่ make sense เข้าหากัน ว่าในแต่ละ TC ผมจะเก็บ Initial State ตัวไหน, action ที่ทำคืออะไร และ expect output condition แบบไหน

การที่มี matrix แบบนี้จะทำให้เราเห็นได้ง่าย ว่าเรา cover หรือยังไม่ cover อะไร หากมีคนมา review เค้าก็ไม่ต้องอ่าน text เยอะแยะ และช่วย feedback ได้ง่ายว่าตกหล่นอะไร

การกาเครื่องหมายลงใน matrix เพื่อระบุ test coverage ถือเป็นศิลปะอย่างนึง ซึ่งคงต้องใช้เวลานานในการอธิบาย ที่บอกได้คือผมไม่พยายามที่จะ cover ทุก possible combination แต่จะเน้น combination ที่เกิดขึ้นตาม use case หลักมาก่อน หากตีตารางออกมาแล้ว แล้วนึก combination ทั้งหมดแล้วตาลายเพราะมันเยอะมาก ผมจะพยายามนึกดูว่าถ้าจะตัด test focus เป็นส่วนๆ ตาม sub module หรือ sub business rule แล้วแตกออกมาเป็นหลายๆ test matrix น่าจะ manage ได้ง่ายกว่าหรือไม่ เพราะว่าถ้าเราเอาทุก input กับ output combination มาร่วมกันทั้งระบบ มันอาจจะเยอะมากจนไปต่อไม่ถูกเลยก็เป็นได้

 

อีกหนึ่งประสบการณ์ที่ผมใช้คือ หาก requirement มันซับซ้อนมาก แล้วเราไม่มั่นใจว่าเรา cover จริงๆ ผมจะเอา mind map มาใช้แล้วค่อยไล่จากกิ่งของ mindmap เพื่อที่จะคิดว่าเราจะ cover หรือไม่ cover แต่ละกิ่งเพราะอะไร อีกอย่างเราสามารถสื่อสารกับคนอื่นได้ง่ายว่าความเข้าใจเราถูกไหม และยังมี detail use case อะไรที่ตกไปอีกบ้าง

 

ผมมีตัวอย่างงานจริงในการทำ test matrix และ mind map แต่เนื่องจากข้อมูลอาจจะ sensitive และไม่อาจเปิดเผยผ่าน public บนwebโดยตรงได้ หากใครต้องการดูตัวอย่างผมคงต้องขอส่งเป็น email offline ไปครับ

 

สุดท้ายสำหรับหัวข้อนี้ ยังมี tool ดีๆ เช่น pairwise technique ที่สามารถนำมาลด test condition ลงได้หรือเพื่อเอามา cross check กับ coverage ที่เราคิดไว้ใน matrix ได้อีกนะครับ

 

จะเห็นได้ว่ามาถึงจุดนี้ Test Engineer อย่างเราๆ ก็ใช้พลังงานไปพอสมควร และยังจะพบว่าเรายังไม่พร้อมที่จะ execute test หรอก เพราะมีแค่ test condition แต่ยังไม่มี expect result ที่เป็นค่าสุดท้าย, และยังขาด test step แถมยังไม่ได้มีการเรียบเรียงว่าจะทำ test condition ไหนก่อน และจะใช้ data จากไหน … นั่นคือสิ่งที่เราจะต้องจัดการในขั้นตอนต่อไปคือ Test Data Preparation and Test Implementation (scripting) นั่นเองครับ

7 thoughts on “กว่าจะมาเป็น TEST SCRIPT (ตอนที่ 2 : Test Design vs. การกินBuffet นานาชาติ)”

  1. อยากได้ตัวอย่าง test matix กับ mind map ค่ะรบกวนส่งตามอีเมล์์ด้านล่างหน่อยค่ะ ขอบคุณค่ะ

    Kanpichaya.tang@gmail.com

  2. อยากได้ตัวอย่าง test matix กับ mind map ที่พูดถึงจังเลยคะ รบกวนส่งทางอีเมลืได้ไหมคะ

    salaaoi@hotmail.com

Leave a Reply

Your email address will not be published. Required fields are marked *