Wednesday, 24 December 2008

The Economy of Software Testing(1)

Series The Economy of Software Testing
The Economy of Software Testing (1)
The Economy of Software Testing (2)
The Economy of Software Testing (3)

ก่อนจะเข้าไปในเนื้อหาเราจะเข้าไปในประวัติศาสตร์ของ software ก่อนว่ามันมีความเป็นมาอย่างไรจะได้ปรับมุมมองและทำความเข้าใจและประเด็นที่มันเกิดขึ้นและตอบคำถามหลายๆ จุด ว่าทำไมศาสตร์ของ Software Validation & Verification (V&V) นั้นมันมีความเป็นมายังไง

ในปี 1970s นั้นได้มีศัพท์คำนึงเกิดขึ้นคือ software crisis โดยในช่วงนั้น software ยังไม่ได้นิยมอย่างแพร่หลายซักเท่าไร โดยการทำงานของเครื่องสมองกลในสมัยนั้นยังทำงานโดยการพึ่งพาของตัว hardware อยู่ โดยเครื่อง Computer ในสมัยนั้นยังเป็นเครื่องที่มีความเทอะทะอยู่และยังจำกัดวงผู้ใช้อยู่ในวงที่แคบๆ โดยคนทั่วไปนั้นแทบจะไม่มีโอกาศในการได้ใช้เครื่อง Computer จะใช้ตามในเฉพาะในหน่วยงานสำคัญๆ และตอนนั้นภาษาที่นำไปใช้ในการเขียน software นั้นยังเป็นภาษาที่ค่อนข้างที่จะใกล้เคียงกับภาษาเครื่องอยู่ คือ Machine Code ทำให้มันเหมาะสมให้กับเครื่องในการตีความแต่ไม่เหมาะสมกับมนุษย์ในการทำความเข้าใจ ทำให้การเขียน software ในสมัยนั้นเป็นไปได้ยากและใช้ค่าใช้จ่ายในการผลิตสูง โดยปัญหานี้เกิดขึ้นตั้งแต่ก่อนปี 1970s เกิดมาตั้งแต่มี Computer เครื่องแรก Univac (ในปี 1960s) ดังนั้นก่อนที่จะสร้าง software ขึ้นมาซักตัว ถ้าหากมีของเก่าอยู่แล้วและสามารถนำไปใช้ได้ก็จะยอมใช้ของเก่าและทำการ maintain ของเดิมที่มีอยู่

แต่ในกลางปีของ 1970 เป็นครั้งแรกที่ cost ของการ develop ตัว software ชุดใหม่นั้นมี cost ที่ถูกกว่าการ maintain software ตัวเก่า ทำให้เริ่มมีการหันเหไปมองการสร้าง software ใหม่ แทนที่ที่จะมา maintain ของเก่าแต่ก็มีคำถามเกิดขึ้น ของใหม่ที่มีนั้นจะเทียบเท่ากับของเก่าหรือไม่ ทำให้เกิดการคำนึงถึงเรื่อง quality ขึ้นมา เพื่อทำให้เกิดความแน่ใจว่า software ที่สร้างมานั้นจะได้ไม่ต้องมีการ maintain บ่อย

แล้วในช่วงเวลานั้นใกล้ๆกันมันมีสัญญาณอีกอย่างหนึ่งได้เกิดขึ้น คือ hardware นั้นราคาได้ลดลงและ แต่มีประสิทธิภาพมากขึ้นและรองรับ software ที่มีความซับซ้อนได้มากขึ้น ทำให้นักพัฒนาสามารถพัฒนา software ที่มีความซับซ้อนมากขึ้นเช่นกัน แต่ว่าเพราะเหตุอะไรไม่ทราบทำให้ software failure (software ที่อยู่ในกระบวนการผลิตนั้นเกิดความล้มเหลว) มากขึ้นด้วย เพราะอะไร ? ทำไมถึงเป็นเช่นนั้น ? จึงได้มีการพุ่งเป้าไปที่ programming language เพราะว่าในตอนนั้นลักษณะการเขียนภาษามันเป็นเหมือน Machine Code (Assembly) ทำให้มีความคิดว่าควรที่จะมีภาษาที่ดีกว่านี้ไหม ภาษาที่เข้าใกล้ภาษามนุษย์

ในปี 1980s Computer นั้นยังเป็นพวก mainframes อยู่ และยังจำกัดอยู่ในหน่วยงานสำคัญ มีราคาแพง ทำให้เมื่อซื้อแล้วต้องพยายามใช้มันให้นาน และต้องใช้ความรู้ความสามารถมาก ดังนั้น software ที่เขียนขึ้นมาต้องมีอายุในการใช้งานได้นานเช่นเดียวกันอย่างน้อย 5 ปี แต่อายุไขของ software นั้นก็ยังน้อยกว่าตัว hardware ดังนั้นทำให้ customer นั้นค่อนข้างที่จะซีเรียสในเรื่องของ reliability และ quality ที่มาก ดังนั้นการ testing เป็นองค์ประกอบที่ไม่สามารถแยกออกจากกันจากการพัฒนา software ได้ ทำให้ในช่วงนั้นศาสตร์ของ V&V ค่อนข้างมีการพัฒนาในยุคนั้นมาก เพราะว่า tester ในสมัยนั้นค่อนข้างต้องมี degree ทางด้าน engineering ที่สูงเพราะว่าต้องมีความเชี่ยวชาญทั้งทางด้าน hardware และ software มาก แต่เมื่อเทียบกับสมัยนี้แล้ว tester โดนลดความสำคัญลงไปมากเมื่อเทียบกับสมัยปัจจุบัน

แต่ถึงแม้ว่าตัว programming language นั้นจะสามารถพัฒนาให้เข้าใกล้ภาษามนุษย์มากที่สุดแล้ว แต่ปรากฎว่ามันไม่ได้ช่วยในการลดลงของจำนวน software failure ได้เลยดังนั้นปัญหาของ software crisis นั้นก็ยังไม่หมดไป จึงมีความพยายามอื่นๆที่ตามมาเพื่อทำให้ software นั้นได้เกิด reliability และ quality ของ software

จึงได้มีความคิดโดยการมองลงไปในส่วนของกระบวนการพัฒนา software ตั้งแต่การเก็บ requirement เพราะว่าการเก็บ requirement นั้นเราต้องเก็บมาเป็นภาษามนุษย์ (natural language) ซึ่งเป็นภาษาที่ดิ้นได้คือ คือมีความกำกวมในของมันอยู่ ดังนั้นเมื่อเราจะนำมาแปลงเป็น code แล้ว ถ้าความกำกวมนั้นทำให้แปลความหมายผิดพลาด ย่อมทำให้ program ที่เขียนมาย่อมผิดพลาดอย่างแน่นอน ทำให้นำไปสู่ความเสื่อมถอยของคุณภาพของ software ในที่สุด ดังนั้น High Programming Language จึงไม่ใช่แนวทางที่แก้ปัญหาจากต้นเหตุ จึงทำให้ได้มีแนวคิดในการกำเนิดภาษาที่ใช้เก็บ requirement และต้องเป็นภาษาที่ไม่เกิดความกำกวม เราเรียกภาษานั้นว่า formal language ยกตัวอย่างของภาษานั้นก็คือ HAL/S, VDM-SL และ Z (ไม่รู้จักซักตัว รอผู้มาอธิบาย + แสดงอายุ 555+)

การใช้ High Programming Language หรือการใช้ Formal Language นั้นก็ยังไม่สามารถที่จะช่วย Software Failure นั้นหายไป มันก็ยังคงมีอยู่ ซึ่งมีด้วยกันหลายประเด็นที่ทำให้มันไม่สามารถขจัดปัญหานี้ได้ เช่น ความยากในการทำความเข้าใจ ความยากในการนำไปใช้งาน และ มันไม่สามารถรองรับปัญหาที่มีความซับซ้อนได้ทั้งหมด

ต่อมาในปี 1985 โดยในปีนั้นอุตสาหกรรม software มีมูลค่าสูงขึ้นแต่ราคาของ hardware นั้นมีราคาลดลง (ราคาต่อชิ้น) ทำให้ความสำคัญในด้านคุณภาพของ software ก็สูงขึ้น ดังนั้นเพื่อที่จะลด software failure จึงมีการมองไปที่กระบวนการของผลิต software เพื่อที่จะลดปัญหาของ software failure ดังนั้นจึงได้มีการนำเอา software engineering เข้ามาใช้ โดยในปีนั้น software engineering ได้เข้ามาเป็นสาขาหนึ่งใน engineer

ในช่วงนั้นเป็นช่วงของ computer workstation กำลังเป็นที่ได้รับความสนใจ และกลายเป็นองค์ประกอบหนึ่งของสถาบันการศึกษาที่สำคัญ ซึ่งการมาของ computer workstation มาพร้อมกับตัวที่จะมาแก้ปัญหาของ software failure คือ CASE Tool (Computer Aided Software Engineering) ที่เข้ามาช่วยในกระบวนการใดกระบวนการหนึ่งในการพัฒนา software

ซึ่งการมาของ CASE Tool นั้นเหมือนจะมาช่วยในการพัฒนา Software แต่ในความเป็นจริงแล้วตัว CASE Tool นั้นยังห่างจากความเป็นจริงในการแก้ปัญหาที่ค่อนข้างมาก จึงมีคำเปรียบเทียบว่า CASE Tool isn’t silver Bullet เนื่องจากว่า CASE Tool นั้นถ้าจะนำไปใช้จริงๆแล้วมันจะเกี่ยวข้องกับกระบวนการ การพัฒนา Software ขององค์กรนั้น โดยที่ส่วนใหญ่องค์กรเหล่านั้นเอา CASE Tool เข้ามาช่วยด้วยก็จริงแต่ก็ไม่รู้วิธีที่จะทำให้ CASE Tool เหล่านั้นผสมผสานเข้ากับองค์กรยังไงถึงจะเกิด performance มากที่สุด ซึ่งหากเลวร้ายที่สุด กระบวนการของ CASE Tool จะไปเกิดการ crash กันกับกระบวนการเดิมทำให้การใช้ CASE Tool นั้นไม่ได้ performance อย่างสูงสุดทำให้ทฤษฎีนี้ยังห่างจากความเป็นจริงอย่างมาก

จบก่อนหละครับยาวมากแล้วเดี๋ยวจะง่วงก่อน ไว้มาติดตามกันในตอนที่สอง

ref :
SW Verification and Validation for Practitioner and Manager 2 Ed.
Software Testing Fundamwntals: Method and Metrics
Lecture วิชา SWE613 Software Verification and Validation

เพิ่มเติม
พอดีได้ไปเจอบทความของคุณ Siroz แล้วมันมีความคล้ายกันเพียงแต่ว่ามองกันคนละแนวกันโดยบทความของคุณ Siroz นั้นจะเน้นไปในวิวัฒนาการของการทดสอบ software จริงๆ ซึ่งถ้าใครสนใจสามารถเข้าไปดูตาม link ด้านล่างครับ

พัฒนาการของการทดสอบซอฟต์แวร์ ตอนที่ 1
พัฒนาการของการทดสอบซอฟต์แวร์ ตอนที่ 2

No comments: