Project Management and Software Development Blog for Thais

อุปสรรคในการทำ Automated Testing

หลักการสำคัญของ Agile Development ซึ่ง Extreme Programming (XP) นำมาประยุกต์ใช้ก็คือพยายามทำให้กระบวนการต่างๆนั้นเป็นแบบอัติโนมัติให้ได้มากที่สุด นั่นรวมไปถึงการทำ Automated Testing ด้วยครับ การทำ Automated Testing ซึ่งประยุกต์ใช้ได้กับทั้ง development test และ system test นั้นมีประโยชน์มากครับ (ซึ่งผมไม่ขอกล่าวถึงในบทความนี้) แต่ปัญหาคือว่าก่อนที่จะทำ Automated Testing ได้นั้นมันต้องลงทุนหนักเลยด้ัวยเหตุผลสองข้อครับ

• เตรียมโค๊ดของเราให้สนับสนุนการทำ Automated Testing ถ้าเราวางแผนที่จะทำ Automated Testing ตั้งแต่แรกก็ยังพอไหวครับ แต่ถ้าเราจะมาเริ่มกับโค๊ดเก่าที่มีอยู่แล้วเนี่ยะ เหนื่อยคูณสองครับผม เพราะว่าส่วนมากแล้วโค๊ดเก่าๆของเรานั้นไม่ support การทำ Automated Testing หรอกครับ เราก็เลยต้องเสียเวลามานั่งแก้นั่งปรับให้โค๊ดเก่าซะก่อนฮะ
  
• เขียน Automated Test Scripts เพื่อมาทดสอบโค๊ดของเรา ข้อนี้ก็ค่อนข้างหนักครับ บางครั้งเราจะเสียเวลาเขียน Test Scripts นานกว่าเขียนโค๊ดอีกครับถ้า developer (รวมถึง QA) ของเราัไม่มีประสบการณ์ด้านนี้มาก่อน ฮ่าๆ
  

เห็นผมพูดถึงแต่ปัญหาไม่ได้หมายความว่าผมไม่แนะนำให้ทำ Automated Testing นะครับ ผมสนับสนุนเต็มที่ถ้าเรามีเวลาจะทำจริงๆ แต่ถ้าเราไม่มีเวลาเพียงพอหละ? แล้วถ้าเราต้องทำงานแบบ Agile กับโค๊ดชุดเก่าๆของเราหละ? เราจะทำยังไงกันดี … นี่คือข้อแนะนำของผมครับ

1. ศึกษาถึงแนวทางการทำ Automated Testing ก่อน

ก่อนที่เราจะตัดสินใจว่าจะทำหรือไม่ทำ Automated Testing ใน project ของเรา อย่างแรกที่ควรต้องทำก็คือศึกษาถึงความเป็นไปได้และความคุ้มค่าก่อนครับ ปัจจัยที่เราควรพิจารณาก็จะมีดังนี้

• มุมมองด้าน Technical ส่วนใหญ่แล้วระบบ (ซอฟท์แวร์) ทั่วไปจะมีส่วนประกอบ (component) หลายๆส่วนซึ่งมีหน้าที่และเทคนิคการพัฒนาต่างกันไป เช่น User Interface, Database, Infrastructure, และ Reporting เป็นต้น ส่งผลให้การเตรียม Automated Testing? สำหรับแต่ละส่วนก็จะใช้หลักการและมีความซับซ้อนมากน้อยต่างกับไปด้วยครับ? เราควรจะศึกษาให้แน่ใจก่อนว่าในมุม Technical แล้ว การทำ Automated Testing นั้นเป็นไปได้ที่จะทำครับ จะได้ไม่เจอกับเหตุการณ์ทำๆไปได้ซักพักแล้วต้องล้มเลิกซึ่งจะเป็นการเสียเวลาและเสียแรงเปล่าครับ
  
  อีกเรื่องที่จำเป็นก็คือต้องดูถึงความคุ้มค่าทาง Technical ด้วย เช่น ทำแล้วจะมีผลดีต่อคุณภาพของงานทั้งในปัจจุบันและอนาคตเพราะว่า Testing Scripts ที่เขียนขึ้นมาจะได้นำกลับมาใช้ได้อีก (reuse) ใน project ถัดๆไป แต่ถ้าำทำมาเพื่อ project นี้อย่างเดียวก็อาจจะไม่คุ้มนะครับ
• มุมมองด้าน Business จุดนี้จะเน้นไปที่ความคุ้มค่าของเวลาและแรงงาน (effort) ที่จะเสียไปในการทำ Automated Testing ครับ อย่างที่กล่าวไ้ว้ตอนต้นว่าการเตรียม Testing Scripts นั้นอาจจะกินเวลามากกว่าการเขียนโค๊ดด้วยซ้ำ ดังนั้นตรงนี้ต้องพิจารณาดีๆครับว่าการที่เราเขียนโค๊ด 2 วันแต่เตรียม Testing Scripts 3 วันมันจะคุ้มกันมั้ย ฟังดูเหมือนจะไม่คุ้มใช่ปะครับ? ฮ่าๆ จริงๆแล้วไม่แน่นะ เพราะว่าถ้าในอนาคตเรา reuse Scripts นี้ได้เรื่อยๆหละ … อาจจะคุ้มเหมือนกันนะ

2. เลือกทำ Automated Testing เป็นบางงาน

ถ้าคับขันจริงๆเราไม่จำเป็นต้องทำ Automated Testing กับทุกส่วนทุกงานก็ไ้ด้นะครับ เมื่อพิจารณาถึงความเป็นไปได้และความคุ้มค่าแล้ว เราค่อยเลือกทำ Automated Testing กับเฉพาะงานที่คุ้มค่าจริงๆดีกว่าครับ เช่น ลงทุนกับ User Interface คุ้มค่าแต่ลงทุนกับ Database ไม่คุ้มค่าก็ไม่เป็นไรครับ เลือกเฉพาะ User Interface ก็ได้ ส่วนอื่นๆเราก็มาวางแผนการ Test ที่รัดกุมรอบคอบยิ่งขึ้นเพื่อคุณภาพงานที่ดีภายหลังได้ (ดูหัวข้อสุดท้าย)

สำหรับ project ที่ต้องทำงานกับโค๊ดเก่าซึ่งไม่สนับสนุน Automated Testing ผมแนะนำว่าควรเลือกที่จะทำ Automated Testing กับงานใหม่ๆ ที่ต้องทำใน project ก่อนครับ เพราะว่าเราสามารถเตรียมโค๊ดที่เราจะเขียนใหม่ให้พร้อมสำหรับ Automated Testing ไปในตัวเลย และเราก็ไม่ต้องเสียเวลาในการกลับไปแก้โค๊ดเก่าๆให้ทำงานกับ Automated Testing ด้วย

3. ลองผิดลองถูกดูซักตั้ง

ยากครับที่เราจะมองเห็นปัญหาที่อาจจะเกิดขึ้นก่อนเริ่มทำงานจริงๆ ดังนั้นเราควรจะพร้อมที่จะัเปลี่ยนแปลงแนวทางการเลือกใช้ Automated Testing ในระหว่าง project ด้วย นั่นคือเมื่อเราตัดสินใจที่จะทำ Automated Testing กับส่วนไหนงานไหนแล้ว เราควรจะเริ่มทำตั้งแต่ช่วงแรกๆ (iteration แรกๆ) ของ project เลยครับ เพื่อที่จะดูผลลัพธ์ว่าออกมาได้ตรงตามที่คาดหวังมั๊ย ถ้าตรงเราก็ลุยต่อไป ถ้าเกือบตรงเราก็มาหาทางปรับปรุง แต่ถ้าไม่ตรงเลย ไม่ใกล้เคียงซักนิดหละก็ … เราต้องพร้อมที่จะยกเลิก Automated Testing ครับ

ยกเลิก!!! ฟังดูน่ากลัวอยู่ แต่ผมไม่ได้หมายความว่ายกเลิกไปหมดเลยนะ ยกเลิกตัวเลือกหรือวิธีการแบบเก่าแล้วลองแบบใหม่ดูครับ เช่น ตอนแรกเราเลือกทำ Automated Testing ให้กับ User Interface ทั้งหมดแล้วผลลัพธ์ออกมาไม่ดีอย่างที่หวัง งั้นลองแบบนี้ครับ แบ่งงานในส่วน User Interface ให้ย่อยลงไปอีกแล้วลองตัดสินใจดูอีกซักตั้ง ตัวอย่างนะครับ ถ้าพูดถึง Web Development งานที่เป็น User Interface มันก็มีหลายส่วนอยู่นะ เอาที่โดดเด่นก็เช่น JSP/ASP/PHP และ Javascript ถ้าทำ Automated Testing กับทั้งสองส่วนแล้วเหนื่อยไป ไม่คุ้ม ก็เลือกทำส่วนใดส่วนหนึ่ง(ที่น่าจะคุ้มกว่า)ดูซิครับ อาจจะได้ผลลัพธ์ที่ดีขึ้นก็ได้นะ

4. ประยุกต์ใช้ Testing Technique หลายๆแบบ

การใช้ Automated Testing แบบ full option เป็นเรื่องที่ดีแน่นอนครับ แต่ถ้าเรามีข้อจำกัดเยอะจนทำแบบนั้นไม่ได้ เราควรจะหาทางปิดช่องโหว่ตรงนั้นไว้เพื่อคุณภาพของงานที่ดีครับ คำแนะนำของผมก็คือการประยุกต์ใช้ Testing Technique หลายๆรูปแบบและหลายๆชั้นใน project ของเราครับ ลองดูจากรูปครับ

ขั้นแรกก็เริ่มที่ user story ของเราครับโดยที่ developer ก็จะรับผิดชอบทำ Unit Test ในงานส่วนของตัวเอง เมื่อเรียบร้อยดีแล้วก็จะทำ Integration Test ถ้า user story นั้นเกี่ยวข้องกับงานมากกว่า 1 ส่วน (component) เช่น เพิ่มหน้าจอใหม่ (User Interface) ซึ่งทำงานร่วมกับฐานข้อมูลตารางใหม่ (Database) เป็นต้น สุดท้ายก็จะส่งงานให้กับ QA เพื่อทำ Acceptance Test ตาม Acceptance Criteria ที่เตรียมไว้ครับ ทุกๆ user story จะใช้หลักการนี้

เมื่อทำครบทุก user story แล้วก่อนปิด iteration เราก็จะมีการทำ Sanity Test โดย QA เพื่อให้มั่นใจได้ว่า user story ทั้งหมดใน iteration นั้นยังทำงานได้อย่างถูกต้อง (ตรวจสอบว่าการเขียนโค๊ดที่ผ่านมาไม่มี conflict เกิดขึ้นหนะครับ) การทำ Sanity Test นั้นจะใช้เทคนิคที่เรียกว่า Exploratory Test ซึ่งจะให้โอกาส QA ในการออกแบบและทดสอบ user story ด้วยความคิดสร้างสรรของตัวเองเลยครับ QA สามารถประยุกต์ใช้ testing technique หลายๆแบบได้อย่างอิสระ เช่น Black-Block Test, Boundary Test, Stress Test เป็นต้น ข้อดีของวิธีการนี้ก็คือใช้เวลาเตรียมตัวน้อยครับ คิดอะไร อยากเทสอะไรก็ลุยได้เลย แถมมีโอกาสเจอบั๊ิกใหญ่ๆอย่างรวดเร็วซะด้วย

ผ่านไปแว๊บเดียว เราก็จะทำงานเสร็จ Release แรกแล้วครับ เนื่องจากเราตกลงกับลูกค้าไว้ว่าเสร็จ Release แรกก็จะมี Beta version ไปให้ลองเล่น (เหตุการณ์สมมติ) เพื่อความมั่นใจของเราและความพึงพอใจของลูกค้า เราก็จะมีการทำ Preliminary Test ก่อนจะส่งของให้ลูกค้าครับ ใน Preliminary Test นี้เราค่อนข้างจะต้องละเอียดนิดนึง ดังนั้นเราจะมีการทำ Regression Test เพิ่มเข้ามาคู่กับ Exploratory Test ครับ Regression Test ก็จะเป็นการทดสอบว่า Feature เดิมๆที่มีอยู่ก่อนแล้วยังทำงานได้ถูกต้องอยู่ครับ

ตอนนี้เราก็ประยุกต์ใช้ testing technique หลายๆแบบเข้ามาใน project ของเราแล้วซึ่งเราก็จะมั่นใจได้มากขึ้นว่าถึงแม้เราจะไม่สามารถทำ Automated Testing ให้กับทุกๆส่วน ทุกๆงาน แต่คุณภาพของงานเราก็ยังดีอยู่ (หรือดีกว่าเดิม) ครับผม

Related posts:

1. Automated Testing vs. Manual Testing เลือกอะไรดี
2. ร่วมแชร์ความเห็น…ทำไม Automated Testing ถึงล้มเหลว
3. 4 สาเหตุสำคัญที่ทำให้ Automated Testing ล้มเหลว
4. Waterfall .. Iterative .. Agile เลือกใช้อะไรดี?
5. Agile Development — First Chapter Videos