Testing

เกริ่นก่อนว่าที่ Pronto Tools เราเปลี่ยนมาใช้ Cypress มาได้ซักพักแล้วครับแล้วเราชอบมันมาก เราเลยไม่ลังเลเลยที่จะย้ายและเพิ่ม E2E เทสมาอยู่บน Cypress ซึ่งพอเทสมันเพิ่มขึ้นอย่างรวดเร็ว เวลาที่ใช้รันมันก็เพิ่มขึ้นอย่างมีนัยยะสำคัญ ทำไม E2E เทสถึงรันช้า 🐢 ปัญหาหลักเลยคือ E2E เทสจะค่อนข้างมี Step ที่ทำงานซ้ำๆ เกิดขึ้นบ่อยๆ เพื่อ Setup ข้อมูลให้พร้อมที่จะเทสใน TestCase หลัก ปัญหาหลักๆ ก็คืองานซ้ำๆ นั้นถ้ามันใช้เวลารันนาน ถ้ามันยิ่งมีจำนวนมากขึ้นก็จะยิ่งทำให้ชุดทดสอบเราทำงานช้าขึ้นเรื่อยๆ ลองมาดูตัวอย่างของเทสกันครับ describe('Pricing plan page', () => { context('Product Plan Section', () => { it('Should see Product title', () => { cy.signUp() cy.visit('/plan') cy.get('.plan-title').should('contain', 'Basic Plan') }) it('Should see price', () => { cy.signUp() cy.visit('/plan') cy.get('.plan-price').should('contain', '$599') }) }) }) จากโค้ดตัวอย่างข้างต้น จะเป็นการเทสว่าหน้า Pricing Plan เราเนี่ยมันมีชื่อ Plan กับราคาอยู่ ซึ่งจะเห็นว่าการจะทดสอบ TestCase นึงนี่ เราต้องเสียเวลาไปรัน command cy.signUp() ซึ่งเป็น command ที่เราสร้างให้เอาไว้สมัครสมาชิกเข้า service เรา ซึ่งเวลาสมัครใช้งานเนี่ย มันจะมีการทำงานหลายอย่างเกิดขึ้นไม่ว่าจะเป็น สร้าง subscription user, ส่งอีเมล์ยืนยันการสมัคร, ฯลฯ แต่ละอย่างนี่ใช้เวลาทั้งนั้นครับ ...

ต่อจาก โพสที่แล้ว เลยนะครับเพื่อไม่ให้เป็นการเสียเวลา 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 กันเลยทีเดียว ...