สรุปสิ่งที่แบ่งปันเรื่อง Secure Test-Driven Development

วันนี้ไปแบ่งปันเรื่อง Secure Test-Driven Development ในงาน IT Connect :: MiSS Day จัดที่มหาวิทยาลัยเกษตรศาสตร์ ซึ่งสามารถสรุปเนื้อหาหลัก ๆ ได้ดังนี้

ปัญหาของการพัฒนา Software ในปัจจุบัน

โดยเฉพาะเรื่องของ Security testing ที่มักจะอยู่ในช่วงท้ายของการพัฒนา หรือ ก่อนทำการ deploy ระบบงาน และมักจะมีทีมแยกมาทำการทดสอบโดยเฉาะ ผลที่ได้รับมามันไม่ช่วยทำอะไรให้ดีขึ้นเลย !! คำถามคือ ทำการทดสอบอะไรบ้าง ? หรือ สอย อะไรบ้าง ? ถ้าถามทางทีมพัฒนา ก็จะได้คำตอบว่า ไม่รู้ หรือ น่าจะทดสอบ 1, 2, 3 ... สุดท้ายก็ไม่ผ่านการทดสอบ บางครั้งทีมพัฒนาก็ไม่อยากส่งระบบงานไปให้ทดสอบอีกต่างหาก !! สิ่งเหล่านี้มันสะท้อนถึงขั้นตอนการทำงานนั่นเอง

ดังนั้นเราต้องการแนวทางอื่น ๆ สำหรับการพัฒนา

หนึ่งในนั้นคือ Iterative and Incremental approach นั่นคือ การทำงานเป็นรอบสั้นและสร้างระบบให้โตขึ้นเรื่อย ๆ เพื่อต้องการ feedback loop ที่รวดเร็วที่สุดเท่าที่จะทำได้ เพื่อให้รู้ปัญหาได้อย่างรวดเร็ว จะได้แก้ไขได้ทันท่วงที โดยในขั้นตอนการทำงานนั้น ต้องมีการทดสอบต่าง ๆ เข้าไปในแต่ละ feature เสมอทั้ง

• Unit testing
• Integration testing
• Acceptance testing
• Security testing
• Performance testing

สิ่งที่เน้นอย่างมากคือ Unit testing ทำตามแนวคิด TDD (Test-Driven Development) นั่นก็คือ

• จะไม่เขียน production code ใด ๆ เลย จนกว่าจะมี test case ที่มัน fail
• ลด code ที่ซ้ำซ้อนลงไป (Reduce duplication code)

เมื่อเรานำแนวคิดนี้มาใช้กับเรื่อง Security มันจะกลายเป็น Secure Test-Driven Development (STDD)

แต่มิใช่ว่า จะทำได้เลย เนื่องจากมีปัญหา และ ความท้าทายมากมาย เช่น

• ทีมพัฒนาไม่มีความรู้เรื่องของ Security !! เช่น OWASP Top 10 Risks ทั้งระบบ web และ mobile
• ทีมพัฒนาไม่มีความรู้ว่าจะสร้าง test case ที่เกี่ยวกับ security อย่างไร !!
• ไม่มี process ที่เป็นทางการออกมาเท่าไร แต่ก็มีนะ เช่น Secure Development process ของ Microsoft และ OWASP Software Security Assurance Process เป็นต้น

จากปัญหาเหล่านี้ เราจึงต้องปรับปรุงกระบวนการมากมาย

แต่ให้เริ่มทำทีละอย่างและปรับปรุงอย่างต่อเนื่อง (Continuous Improvement) ถ้าทีมพัฒนาขาดความรู้แล้ว จำเป็นต้องมีการ training จากผู้เชี่ยวชาญ ถ้าทีมพัฒนาไม่สามารถคิดหรือสร้าง test case ได้แล้ว จำเป็นต้องมีการคุยและสรุปจากคนหลาย ๆ กลุ่ม เพื่อให้เห็นความต้องการในแต่ละมุมมอง เช่น

• Business
• Development
• QA/Tester
• Security
• Performance
• Operation

เพื่อให้ได้ข้อมูลที่ครอบคลุม เพื่อนำมาสร้าง test case ต่อไป โดย test case เหล่านั้น เราจะเรียกว่า Acceptance test ใช้สำหรับการตรวจสอบ และ ส่งมอบ feature นั้น ๆ ที่สำคัญทำให้ทุกคนเข้าใจความต้องการของ feature นั้น ๆ ตรงกัน

สุดท้ายเรื่องแนวคิดที่ต้องปรับเปลี่ยนไป เช่น

• แต่ละคนแต่ละฝ่ายที่เกี่ยวข้องต้องคุยกัน และ ทำงานร่วมกัน (Communication and Collaboration)
• ทำงานเป็นทีม ทีมจะต้องประกอบไปด้วยคนที่มีความสามารถต่าง ๆ สำหรับการสร้างระบบ
• ต้องการ feedback ในเรื่องต่าง ๆ อย่างรวดเร็ว ทั้งการเพิ่ม และ การเปลี่ยนแปลง ว่าทำงานได้ตรงตามความต้องการหรือไม่ ?
• การทดสอบเรื่องต่าง ๆ มันคือ กิจกรรมที่เกิดขึ้นอยู่ตลอดเวลา อย่ารอทดสอบตอนท้ายของการพัฒนา เราต้องการรู้ให้รวดเร็วที่สุด !!

เรื่องที่สำคัญมาก ๆ คือ คุณภาพนั้นไม่สามารถต่อรองได้ Quality Build-in อยู่ในทุกส่วนเสมอ

คุณพร้อมที่ปรับปรุงแล้วหรือยัง ? Slide :: Secure Test-Driven Development http://www.slideshare.net/up1/secure-testdriven-development