เลือก Automated Testing
John Overbaugh (Microsoft) กล่าวไว้ว่า “เราควรใช้ Automated Testing ก็ต่อเมื่อค่าใช้จ่ายสำหรับการสร้างและดูแลรักษา Automated Testing น้อยกว่ากำลังและเวลาที่เราเสียไปกับการทำ Manual Testing” ซึ่งโดยทั่วไปแล้วความคุ้มค่าตรงนี้จะได้มาจากสองสถานการณ์
หนึ่ง เมื่อการทำ Test Execution แบบ Manual นั้นยากมากๆ เช่นกรณีที่เราทำ Performance Test ซึ่ง Tester ต้องมาเสียเวลากับการสร้างข้อมูลปริมาณมากๆเพื่อทดสอบครับ หรือกรณีที่เราต้อง Test ในส่วนที่มีความซับซ้อนมากๆซึ่งต้องเสียเวลาในการเตรียมข้อมูลหรือเตรียมขั้นตอนที่เป็น Prerequisite เยอะๆครับ
สอง เมื่อการ Test นั้นๆตรงทำซ้ำบ่อยๆ เช่นการทำ Build Verification Test (BVT) ตามหลักการ Continuous-Integration ของ Agile ซึ่งต้องมีการ Test บ่อยๆ อาจจะเป็นทุกครั้งที่ commit code หรือทุกวัน หรือทุกๆ Release อีกตัวอย่างหนึ่งก็ได้แก่ การทำ Regression Test เพื่อทดสอบความถูกต้องของ Software ที่ต้องทำบ่อยๆ ลองมาดูข้อดีข้อเสียของ Automated Testing เพื่อช่วยในการตัดสินใจกันครับ
Automated Testing | |
ข้อดี | ข้อเสีย |
ถ้าเราต้อง run test ซ้ำๆ Automated Testing จะช่วยได้มาก | ลงทุนสูงในช่วงเริ่มต้น สูงกว่า manual test อย่างชัดเจน |
ช่วยในการทำ compatibility testing นั่นคือ test ซอฟท์แวร์ซ้ำๆในชุด configuration ที่ต่างกัน | เราทำ automate test ไม่ได้ทุกอย่างหรอก บางครั้งก็ต้องพึ่ง manual test เหมือนกัน |
ช่วยให้เราทำ regression test ได้อย่างรวดเร็ว | ต้องใช้คนทำที่มีทักษะการเขียนโปรแกรม |
สามารถ test ได้จากเครื่องหลายๆเครื่อง ซึ่งจะช่วยลดเวลาอย่างมาก | ต้องใช้คนทำที่รู้หลักการของการทำ testing อย่างดี |
คุ้มค่าในระยะยาว | |
ประเด็นสำคัญที่อาจจะถูกมองข้ามไปสำหรับก็คือการเลือกส่วนที่จะมาทำ Automated Testing และทำให้ถูกต้องนั้นสำคัญอย่างยิ่ง ดังนั้นคนที่จะทำงานตรงนี้ได้ดีต้องมีทักษะ ความรู้ และประสบการณ์เกี่ยวกับ Test Techniques และ Software ของตัวเองดีพอสมควรครับ อีกทั้งทีมงานที่จะรับผิดชอบ Automated Testing ควรจะมีคนที่มีทักษะการเขียนโปรแกรมมาบ้างเพราะว่าการเขียน Script ก็เหมือนเขียนโปรแกรมหละฮะ ต้องคิดถึงเรื่อง reusability? maintainability และอื่นๆด้วย
หลังจากได้รู้คำแนะนำและข้อดีข้อเสียแล้ว ผมขอยกตัวอย่าง Testing Technique ต่างๆที่เหมาะในการทำ Automated Testing เพื่อให้เพื่อนเห็นภาพชัดเจนยิ่งขึ้นครับ
· Unit Test: การทำ Automated Unit Test มีประโยชน์หลายอย่างเลยครับ เช่น หนึ่งช่วยให้เราหา defect เจอตั้งแต่แรกๆซึ่งทำให้การ fix ไม่เสียเวลามากนัก (เทียบกับตอนไปเจอ defect ใน Integration Test หรือ System Test) สองเราจะใช้โอกาสนี้ในการทำ Code Review ซึ่งช่วยหา defect ได้เยอะเลยนะครับ สามเราสามารถ reuse Automated Unit Test ใน Regression Test ได้ซึ่งจะช่วยลดเวลาและกำลังคนไปได้มากเลยครับ
· Regression Test: Test case ที่ต้อง run หลายๆครั้งก่อนออก release ใหม่เพื่อตรวจสอบว่าการทำงานของซอฟท์แวร์ยังถูกต้องอยู่หรือเพื่อที่จะยืนยันว่า bug ที่แก้ไปไม่กระทบกับซอฟท์แวร์ส่วนอื่นๆ สถานการณ์แบบนี้เหมาะกับ Automated Testing สุดๆครับ
· Random Test: เทสที่ต้องส่งข้อมูลที่เป็นพวก Transaction เยอะๆหรือยาวๆเข้าไปในระบบเพื่อสุ่มตรวจสอบหา bug ก็เหมาะกับ Automated เหมือนกัน
· Capacity Test: ระบบที่ต้องรองรับการโหลดข้อมูลขนาดใหญ่เช่น รองรับ 50,000 Transaction ได้โดยระบบไม่ล่ม ทำ Manual ไม่ไหวอยู่แล้ว หาทาง Automated ไปโลด
· Performance and Reliability Test: การทำ Performance กับ Reliability Test สำหรับพวก Web application เป็นเรื่องที่ควรหาทางทำ Automated เหมือนกัน เช่น Test เพื่อหา responsive time หรือ Test เพื่อดู Scalability เป็นต้น
เลือก Manual Testing
Mike Kelly กล่าวไว้ว่า “ขอให้แน่ใจก่อนว่าทีมเรามีความสามารถในการจัดการกับความเสี่ยงที่จะเกิดขึ้น เข้าใจงานดีพอที่จะมอง Test Coverage ได้อย่างครบถ้วนและเข้าใจในหลักการเพื่อเลือก testing technique ที่เหมาะสม จากนั้นค่อยมาพูดกันเรื่องจะใช้ Automated Testing” ถ้าพิจารณาข้อดีข้อเสียและความพร้อมของเราอย่างถี่ถ้วนแล้วสรุปได้ว่าเรายังไม่พร้อม งั้นก็ต้องลุย Manual กันต่อไปครับ
Manual Testing | |
ข้อดี | ข้อเสีย |
ถ้าไม่ต้อง run test บ่อยๆ (reuse test case ไม่ได้) ก็ใช้แบบ Manual ไปดีกว่า | ลงทุนน้อยกว่า automated test แต่เสียเวลาอย่าบอกใคร |
เหมาะสมสำหรับการทำ ac-hoc test นั่นคือไม่ต้องมี test case ไว้ก่อน ทำแบบสุ่มๆได้เลย | สำหรับทุกๆ release เราต้องมานั่ง run test ซ้ำๆนะ … จะเบื่อกันมั้ย? |
คุ้มค่าในระยะสั้น | |
ชัดเจนมากว่าถ้าทำ Automated Testing แล้วเสียเวลา เสียแรงมากกว่า Manual Testing เราจะทำไปทำไมหละ? ตัวอย่างเช่น GUI-Level เพราะว่าส่วนใหญ่แล้วงานส่วนนี้จะมีการเปลี่ยนแปลงอยู่เรื่อยๆ ก็ลำบากเราที่ต้องมาตามแก้พวก Test Script ต่างๆให้ตรงกัน
Automated Testing นั้นไม่เหมาะกับ Project สั้นๆเพราะว่าส่วนใหญ่แล้วเวลาที่เราเสียไปกับการเตรียมการจะมากกว่าคุณค่าที่เราจะได้รับกลับมา ยิ่งถ้า Project นั้นทำแค่เพิ่ม feature เล็กๆน้อยๆเข้าไปโดยที่ไม่ได้มีผลกระทบต่อ feature หลัก เราก็ไม่จำเป็นต้องทำ Automated Testing ก็ได้ครับ
เราลองมาดูกันว่างานอะไรที่เหมาะกับ Manual Testing บ้าง
· Installation Test: งานเกี่ยวกับการ install, set up, หรือ maintenance ส่วนใหญ่แล้วจะเกี่ยวข้องกับการโหลดโปรแกรม เปลี่ยนแผน CD-Rom/เทป เปลี่ยนฮาร์ดแวร์ พวกนี้ไม่เหมาะจะทำ Automated Test อย่างแน่นอนครับ
· Configuration and Compatibility Test: คล้ายๆข้อที่แล้วครับ มีกระบวนการที่ต้องใช้คนเข้าไปเกี่ยวข้องอยู่เยอะ พวก reconfigure ระบบและเน็ตเวิร์คเอย ลงซอฟท์แวร์ ฮาร์ดแวร์ใหม่เอย Manual ดีกว่าฮะ
· Error Handling และ Recovery Test: เหมือนเดิมครับ ถ้าต้องสร้างสถานการณ์เพื่อการทดสอบระบบ เช่น ถอดปลั๊กไฟของ server หรือถอดปลั๊ก network พวกนี้ Manual ดีกว่า
· Localization Test: มีแต่มนุษย์เท่านั้นฮะ (นับถึงตอนนี้นะ) ที่จะบอกได้ว่าการแปลภาษาครั้งนี้มันอ่านรู้เรื่องหรือไม่รู้เรื่อง Manual ต่อไปครับ
· Usability Test: คล้ายๆ Localization Test ครับ ต้องอาศัยมนุษย์เท่านั้นในการตัดสินว่าซอฟท์แวร์นี้ใช้งานได้จริงๆ ง่าย สะดวก ดูดี Manual อีกแล้วววว
· Documentation และ Help: ตรวจสอบเอกสารและระบบช่วยเหลือ … ก็ต้องมนุษย์อีกแหละฮะ ที่จะบอกได้ว่าอ่านเอกสารแล้วเข้าใจหรือไม่ และระบบช่วยเหลือมีประโยชน์จริงๆมั้ยครับผม
