TPSE Conference 2013 ตอนที่ 2 : Robot Framework

ต่อจาก โพสที่แล้ว เลยนะครับเพื่อไม่ให้เป็นการเสียเวลา

Robot Framework: Generic test automation framework for acceptance testing and acceptance test-driven development (ATDD)

       สำหรับ Session นี้ผมถือว่าเป็น Session ที่สนุกที่สุดของงานนี้แล้วโดย Speaker เป็นพี่รูฟ @roofimon โดย Session นี้คนเยอะมากๆ เข้ามาแทบไม่ขาดสายจนที่นั่งไม่พอเลยทีเดียว สำหรับ Robot Framework อธิบายง่ายๆ คือเป็น Automate test framework ตัวนึงที่ช่วยให้งานของ Tester นั้นง่ายขึ้นแต่ก่อนจะเริ่มนั้นพี่รูฟถามว่า "ใครรู้สึกตัวว่าอยู่ผิดห้องมั้ยครับ ?" ประมาณ 4-5 รอบเลย

       พี่รูฟเริ่มต้นด้วยการอธิบายคอนเซปของ Requirement ลูกค้าว่าก็เหมือนการสอบสมัยเรียนมหาลัยโดยอาจารย์จะมีโจทย์ที่อลังการงานสร้างที่สุดเท่าที่คิดออกมาให้เราพร้อมกับ... กระดาษหนึ่งแผ่น หน้าที่ของเราคือเขียนคำตอบไปให้มันตรงกับความต้องการของอาจารย์ให้มากที่สุด โดยพี่รูฟยกตัวอย่างเช่นถ้าสมมติอาจารย์เฉลย 80 แล้วเราตอบ 160/2 แทนที่เราจะได้ซักครึ่งคะแนน แต่กลับกลายเป็นว่าเราไม่ได้เลย "สัส มึงทำผิด !!" พี่รูฟยังยกตัวอย่างข้อสอบ Tense ภาษาอังกฤษที่จะมีการ Guideline มาเป็น Passage แล้วให้เราหยอดคำลงไปในช่องว่าง (ซึ่งยังพอมั่วได้แม่นกว่า) ซึ่งถ้าเปรียบเทียบกับ S/W แล้วการที่เรามี Guideline ในการตรวจรับที่ชัดเจนจะทำให้เรามีความสุขกับงานที่ทำมากกว่า

     หลังจากนั้นพี่รูฟพูดถึงบริษัท Odd-e นิดหน่อยอันนี้ผมขอข้ามละกันเพราะไม่เกี่ยวกับเนื้อหา ประเด็นต่อไปที่พี่รูฟพูดถึงคือถึงแม้เราจะใช้ Agile มาช่วยในการทำงานแล้วก็ตามเราก็ยังคงเจอปัญหา Requirement แบบนี้อยู่เสมอเนื่องจากเรามักจะคิดว่า "สิ่งที่เรารู้เป็นสิ่งที่ลูกค้าอยากได้" ทำให้เกิดปัญหาเมื่อถึงตอนจบแล้วลูกค้าจำไม่ได้แล้วตอบเรากลับมาว่า "ผมไม่ได้พูดอย่างนั้นนะ" ซึ่งพี่รูฟก็ได้ชี้ให้เห็นว่าแท้จริงแล้วนั้นของที่ถูกต้องมันอยู่ในมือของ Tester ไม่ใช่ Programmer แต่เนื่องจาก Programmer เป็น "สิ่งมีชีวิตที่คิดว่าตัวเองฉลาดที่สุดในโลก" มีความผยองและเป็นอย่างนี้มาหลายชั่วอายุคน ปัญหานี้จึงยังเกิดขึ้นอยู่เสมอ วิธีแก้คือ ให้ Programmer หา Tester มาเป็นแฟน... ไม่ใช่ !!! แต่ให้เราเขียน Test ตั้งแต่ขั้น Design กันเลยทีเดียว

       ต่อมาพี่รูฟก็ได้พาเราไปรู้จักกับ Acceptance Test Driven Development โดยเริ่มต้นบอกไว้ก่อนเลยว่า เราไม่สามารถจะทำ ATDD ได้ในตอนแรกทั้งหมดทีเดียว ซึ่งการทำ Agile ก็จะเข้ามาช่วยในจุดนี้โดยเราจะเลือก Requirement ที่สำคัญที่สุดมาทำก่อนและต้องสามารถทำเสร็จได้ภายใน 2 อาทิตย์ด้วย (ตรงนี้ฮามากเพราะดูเหมือนพี่รูฟจะโดนปรับถ้าเผลอพูดศัพท์เกี่ยวกับ Agile ขึ้นมา แต่ก็มีเหตุผลที่น่าสนใจตามมาว่าเพราะในช่วง 2 สัปดาห์นั้นคนเรายังสามารถจำสิ่งที่ตัวเองพูดได้อยู่) โดยเอามาเข้า Discuss in workshop ซึ่งสามารถทำได้ตรงช่วง Sprint Planning Part 1 โดยใน Workshop นี่คนทั้งหมดที่มีส่วนร่วมจะต้องมาคุยกันแล้วถามไปเรื่อยๆ ว่าสิ่งที่ลูกค้าอยากได้คืออะไร โดยถ้าเริ่มคุยกันไม่รู้เรื่องพี่รูฟแนะนำว่าให้จบด้วยคำว่า "ยกตัวอย่างเช่น" เพื่อให้คนที่อธิบายได้จำลองตัวเองไปเป็นคนผู้ใช้งาน (Walkthrough Scenario) ซึ่งผลลัพธ์ที่ได้ออกมาก็คือ Test Scenario หรือตัวอย่าง Scenario ทั้งหมดที่ผู้ใช้ต้องการออกมาเป็นชุดๆ เลย นอกจากนั้นแล้วพี่รูฟยังบอกถึงความแตกต่างระหว่างตัวอย่างดีและไม่ดีโดย การเล่าขึ้นมาแบบลอยๆ นั้นเทียบไม่ได้กับตัวอย่างแบบ Concrete (ผมก็ไม่รู้จะใช้คำไหนอธิบาย) โดยผู้เล่าจะเล่าออกมาเป็นเหตุการณ์ประมาณว่า เมื่อถึงหน้านี้ จะกรอกชื่อ... กรอกอะไรลงไป... ได้หน้าจอ... ถ้าสำเร็จ... ถ้าไม่สำเร็จ... เป็นต้น

       หลังจากนั้นแล้วทีมก็จะเอา Test Scenario ที่ได้นี้มาเขียนลงใน Acceptance Criteria ซึ่งเป็นเหมือนเส้นที่คอยวัดว่าของที่เราสร้างตรงกับสิ่งที่ลูกค้าอยากได้หรือยัง (และไว้ป้องกัน Bug ด้วย) ซึ่งการมี Acceptance Criteria นั้นจะช่วยป้องกันไม่ให้ Programmer เขียนโปรแกรมออกทะเลที่มีพายุตั้งเค้าอยู่ โดยยกตัวอย่างเช่นการ Login เพื่อเข้าใช้งาน เราก็จินตนาการตามไปว่ามี 2 Field คือ Email กับ Password ซึ่งเราก็ได้ฟังตัวอย่างการไล่รายละเอียดของแต่ละ Scenario ไปจนได้ออกมาเป็น Acceptance Criteria ดังตารางข้างล่าง

Username	Password		Expect
Varokas	Password	Press login	Home page
-	-	"	แสรด
Varocas	-	"	"
-	Password	"	"
Roof //ใส่ผิด	Xxx	"	ไม่มี user

     ซึ่งถ้าเราทำได้กับ Scenario ทั้งหมดความชัดเจนในเป้าหมายของ Programmer ก็จะมากขึ้นด้วย แต่พี่รูฟก็ย้ำกับเราอีกทีว่าเรา "ทำแบบนี้ทั้งหมด" ไม่ได้โดยต้อง

• เลือกเอางานที่สำคัญที่สุด โดยให้ลูกค้าเลือก
• งานนั้นต้องเล็กพอจะเสร็จใน 2 สัปดาห์ (1 Sprint)
• เอามาคุยกันจนได้ Acceptance Criteria แล้วค่อยเริ่มงาน

     อย่างไรก็ตามการทำแบบนี้พี่รูฟก็ยังบอกว่ามันยังคงเหนื่อยอยู่แต่ "เหนื่อยน้อยกว่า" ไม่ทำและนอกจากนั้นแล้วจะทำให้ทีมมีโฟกัสที่ชัดเจน, คนทำเสร็จดีใจและลูกค้าได้ของตามต้องการจนมีอารมณ์เลือกของตัวถัดไปที่อยากได้ถูก แต่เนื่องจากงานนี้มีคำว่า Practical อยู่พี่รูฟจึงยังยกตัวอย่างอีกว่า ถ้าระบบเล็กๆ นั้นไม่มีปัญหาที่จะใช้บริการของ Tester ในแบบ Monkey see, monkey do ซึ่งเป็นงานที่น่าเบื่อและแพงมาก การที่เราเอากระบวนการ Automate มาช่วยในจุดนี้ไม่ได้เป็นการลดภาระของ Tester แต่จะทำให้เกิด Value ในตัว Tester มากกว่าเดิมเพราะขยับมาก่อน Implement และเป็นการ Preventive Mode หรือกันไว้ดีกว่าแก้นั่นเอง ทำให้ Tester สามารถเอาเวลาไปทำประโยชน์อย่างอื่นได้มากขึ้นด้วย

     สำหรับ Tools นั้นแน่นอนว่าจั่วหัวไว้แล้วว่า Robot Framework แต่พี่รูฟเกริ่นด้วย Selenium ซึ่งเป็น Tool ที่ใครทำ UX Test ต้องเคยได้ยินแน่นอนซึ่งผมก็เพิ่งรู้ตอนนี้เองว่า Selenium มันมีข้อเสียตรงที่จะเขียน Script เพื่อสั่งมันจริงๆ ได้ยากมากถึงแม้จะรองรับหลายภาษาก็ตาม โดยวิธีแก้ปัญหานี้คือหลายๆ คนพยายามจะเขียน Script มาครอบ Selenium อีกชั้นนึงเพื่อให้ใกล้กับภาษาคนที่ฝั่ง Business อ่านออกมากขึ้น

     มาต่อที่ Robot Framework ตัวนี้ก็เป็นตัวที่สามารถครอบ Selenium ดังที่กล่าวไปแล้วโดยมันจะทำหน้าที่ในการแปลง Acceptance Criteria หรือ Test Scenario ให้ไปเป็น Keyword ซึ่งเราสามารถเขียนมันออกมาเป็น HTML Table ธรรมดาๆ ได้โดย 1 Scenario จะแทนด้วย 1 Table นั้นเองซึ่งข้อดีที่มันเป็น HTML ธรรมดานั้นที่ก็คือ เราสามารถใช้ VCS เช่น Git มาควบคุมมันได้ด้วย

Test case	Step
Valid login	Given login page is open when valid username and password are inserted and credentials are submitted then welcome page should be open

       จากตารางจะเห็นได้ว่า Step ที่อยู่ใน Test Case นั้นมันเป็นภาษาที่เราให้ใครอ่านก็รู้เรื่อง ซึ่งเป็นภาษา Level บนสุดของการเขียน Test แล้ว (พี่รูฟยังบอกอีกว่ามี Tool บางตัวเขียนเป็นภาษาได้เลย เอาเข้าไป !!) ในส่วนของ Robot Architecture นั้นพี่รูฟอธิบายว่าตัว Test Scenario ที่เป็นตารางของเรานี้จะอยู่ชั้นบนสุดซึ่งก็คือ Test Data ซึ่งในชั้น Robot Framework จะเป็นตัวไปเรียก Library ให้ไปสั่ง Tool เช่น Selenium ในการทำงาน โดยข้อดีของ Robot ยังไม่จบแค่นี้ สำหรับอะไรที่เราทำซ้ำๆ เราสามารถดึงมันออกมาแยกเก็บไว้ได้แล้วเรียกใช้ทีหลังสิ่งนั้นเรียกว่า Resource 

 

       ช่วงท้ายๆ ก่อนถามตอบพี่รูฟพูดถึง Specification Pyramid (จากหนังสือ Agile Testing) ซึ่งหาภาพประกอบได้ยากมากประมาณว่าในส่วนของ Rule กับ Workflow นั้น Tester จะสามารถทำตรงนี้ได้เก่งมาก (ส่วนบนของพีระมิด) และในส่วนของ Technical Activity ซึ่งก็คือฐานของพีระมิดนั้นก็เป็นส่วนที่ Programmer ต้องทำให้สอดรับกันพอดี (Unit Test) อีกเรื่องคือ Principle of Symmetric Change ซึ่งเขียนไว้ว่า One small change in the business domain results in one small change in software. ซึ่งพี่รูฟก็บอกว่าในสมัยอดีตนั้นจริงอยู่แต่ปัจจุบันมันกลับด้านกันแล้ว!! 

ปล.ผมว่ามันเริ่มยาวเกินไปละสำหรับ 1 Session ไม่ได้สรุปแต่เก็บเต็มเม็ดเต็มหน่วยเลย...