อุปสรรคของการนำ Automate Test มาใช้งาน

จาก Course The Whole Team Approach to Agile Testing ที่สิงคโปร์ มีสิ่งที่น่าสนใจมากมาย หนึ่งในนั้นคือ

เรื่องอุปสรรคที่มักพบเจอจากการนำเอา Automate Test เข้ามาประยุกต์ใช้งาน

ดังนั้น ก่อนจะนำเอา Automate Test มาใช้งาน ลองกลับมาดูตัวเราเอง ทีม และ องค์กร ว่า มีอะไรที่อาจจะเป็นอุปสรรคบ้าง ?

1. เรื่องทัศนคติของ Programmer

คำถามที่ Programmer จะถาม หรือ คิดอยู่ในใจคือ ทำไมต้อง Automate ด้วยล่ะ ? มีทีม Tester/QA ทำหน้าที่ทดสอบอยู่แล้วมิใช่หรือ ? มี function ตั้งเยอะ ทดสอบได้ไง !! ถ้าขั้นตอนการพัฒนาเป็นแบบเดิม ต้องใช้เวลานานมากกว่าจะทำการทดสอบ และกว่าจะได้ผลการทดสอบกลับมายัง programmer ก็นาน ส่งผลให้การแก้ไขช้าไปอีก !! ดังนั้น เราจึงตัดสินใจกันว่า จะไปแก้ไขใน release ต่อไปล่ะกัน !! หรือ Programmer บางคนดีขึ้นมาหน่อย ทำการทดสอบ code ของตัวเอง ด้วยการนำแนวคิด Test-Driven Development (TDD) มาใช้งาน แต่ก็สนใจเพียงการทดสอบในระดับ Unit test โดยไม่ได้สนใจการทดสอบระดับที่สูงกว่า หรือ ภาพใหญ่ เช่น Functional test และ Acceptance test อีก ดังนั้น สิ่งที่ต้องแก้ไข และ ปรับปรุงก็คือ การให้ความรู้เรื่องความสำคัญของ Automate test การให้ความรู้ความเข้าใจของ Automate test แก่ programmer ซะ อย่าเพียงแต่สั่ง สั่ง สั่ง และ สั่ง

2. เรื่องของ Learning curve ที่สูง และ น่ากลัว !!

เนื่องจากการทดสอบมันคือเรื่องที่ยาก ยิ่ง Automate test มันยากยิ่งกว่า ยิ่งถ้าต้องทำให้มันดี มีประโยชน์ มันจึงยากกว่ามากมาย ซึ่งกว่าจะได้ผลลัพธ์ที่ต้องการ ต้องลงทุนทั้งแรง ทั้งเวลา และ เงิน โดยแสดง Learning curve ของการเรียนรู้ Automate test ด้วย Hump of Pain อธิบายว่า หลาย ๆ ทีมมักจะต้องใช้ความพยายามอย่างมากในช่วงแรก สำหรับการนำ Automate test มาใช้งาน ตัวอย่างเช่น ต้องเรียนรู้ TDD, Refactoring รวมทั้งเลือกเครื่องมือ แน่นอนว่า มันยากมาก ๆ ดังนั้น ถ้าทีมขาดความรู้ในเรื่องต่าง ๆ จำเป็นต้องให้เวลาในการเรียนรู้ จำเป็นต้องได้รับการสนับสนุนฝ่าย management หรือไม่เช่นนั้นก็ต้องหาผู้เชี่ยวชาญมาช่วย เมื่อความรู้ในเรื่องต่าง ๆ ของ Automate test เริ่มดี และมีความเชี่ยวชาญในวิธีการ และ เครื่องมือแล้ว ทุก ๆ อย่างมันจะดีขึ้นตามลำดับ

ดังนั้น การลงทุนในช่วงเริ่มต้นจึงมีความสำคัญอย่างมาก

ลองดูสิว่า ทีมของคุณอยู่ตรงไหน ?

3. เพราะว่า Code มันเปลี่ยนแปลงบ่อย การทดสอบมันจึงไร้ประโยชน์

สำหรับ code ในส่วนการสร้าง User Interface นั้น เป็นส่วนที่มีการเปลี่ยนแปลงบ่อยมาก ๆ ดังนั้นการสร้าง Automate test สำหรับ User Interface มันจึงไร้ค่าอย่างมาก คำถามว่า ต้องทำอย่างไรดีล่ะ ? คำตอบคือ การนำ Automate tool พวก record and playback มาใช้น่าจะเหมาะสมกว่ามาก ส่วน code ในส่วนอื่น ๆ ที่ทำงานอยู่หลัง User Interface ควรออกแบบและเขียนให้สามารถทดสอบได้ง่าย รวมทั้ง programmer และ tester ต้องทำงานด้วยกันนะ

4. ทำงานกับ Legacy code มันยากนะ !!

แน่นอนว่ามันยากมาก ๆ แต่สิ่งที่ต้องการอย่างมากสำหรับทีมคือ เวลาในการเรียนรู้ ความเข้าใจจากฝ่าย management เนื่องจาก Legacy code นั้น มันไม่ได้ถูกสร้างมาให้ทดสอบง่ายเลย ไม่ว่าจะเป็น unit test และ functional test ดังนั้น สิ่งที่ต้องการอย่างมาก คือ เวลาในการทำความเข้าใจการทำงาน เวลาในการ refactor code เพื่อให้ทดสอบได้ง่าย ดังนั้น ต้องให้ความรู้เรื่องต่าง ๆ ให้ทั้ง programmer, tester และฝ่าย management

ไม่เช่นนั้น จะไม่มีใครใส่ใจกับ Legacy code เลย ทั้ง ๆ ที่มันสร้างรายได้ให้กับองค์กร !!

5. ความกลัวต่อ Automate test

เนื่องจากมันคือของใหม่ ! Programmer อาจจะเขียน production code ได้อย่างดี แต่ไม่มีประสบการณ์ในการเขียน Automate test เลย Tester แน่นอนว่ามีความรู้พื้นฐานเรื่องของ programming ไม่มาก อาจจะไม่เชื่อใจ ไว้ใจ การทำงานของ Automate test อีก ยิ่ง Tester บางคนที่ไม่มีความรู้เรื่อง programming เลย ก็มักจะบอกว่า ตัวเองไม่พร้อมหรอกนะ แต่ในความเป็นจริง แล้วมันไม่เกี่ยวเลยนะ

แต่ปัญหาเรื่อง Automate test นั้น มันคือ ปัญหาของทีม ไม่ใช่ปัญหาของใครคนใดคนหนึ่งนะ

Tester ก็ทำในสิ่งที่ตนเองถนัด นั่นคือ การทดสอบ และ สอนแนวคิดการทดสอบให้ programmer สิ นั่นคือ ทำงานร่วมกันไปเลย หรือ pair programming กันซะ มันก็ช่วยทำให้ทุกอย่างดีขึ้นกว่าเดิมแล้วนะ เมื่อใดก็ตามที่เกิดความกลัว อย่าเดิน หรือ ทำเพียงคนเดียว แต่ให้ทำกันเป็นทีม

6. เรื่องของนิสัยเดิม ๆ ที่ชอบทำกัน !!

เมื่อใดก็ตาม ที่เราเผชิญกับคำว่า Deadline เรามักนำนิสัยเดิม ๆ หรือ ความคิดเดิม ๆ มาใช้ นั่นคือ การละทิ้งทุกสิ่งทุกอย่างที่เรามองว่าไม่จำเป็น หนึ่งในนั้นคือ ไม่เขียน Automate test และทำการทดสอบแบบ manual test ไปเลย และเรามักใช้เวลาทดสอบนาน พร้อมด้วยความหวังว่า มันจะดี มันจะทำงานได้อย่างถูกต้อง และค่อยกลับไปสร้าง Automate test ตามหลัง (Later is Never) หรือถ้าทำแล้วก็ยังไม่ทัน ดังนั้น ก็ลดจำนวน feature หรือลดคุณค่าที่จะส่งมอบให้ทาง business ก็แล้วกัน และเราก็จะทำแบบนี้ไปทุก ๆ รอบของการทำงาน ไปเรื่อย ๆ แล้วเราก็จะได้ข้อสรุปว่า มันก็เหมือนเดิมนะ !! โดยผลที่ออกมา มันก็แย่เหมือนกับที่เคยทำมานั่นเอง !!