เป็นไปได้ไหมที่จะสร้าง software โดยปราศจาก Defect

หลังจากที่จบ Lecture ที่ 1 แล้ว The Economy of Software Testing ก็มี Assignment มาให้ลองทำดู โดยโจทย์ที่ได้รับมานั้นไม่ง่ายไม่ยาก "เป็นไปได้ไหมที่จะสร้าง software โดยปราศจาก Defect" ซึ่งงานนี้อาจารย์ได้บอกว่าเนื่องจากพวกเราได้คลุกคลีอยู่ในวงการ programmer มานานย่อมที่พอจะรู้ได้ว่าการสร้าง software ที่ Bug free นั้นเป็นไปได้ไหม และนี่ก็คือความคิดเห็นที่ส่งไปครับ

การสร้างโปรแกรมโดยปราศจาก Bug หรือทำให้มีน้อยเท่าที่จะเป็นไปได้

มันคงเป็นได้ยากที่จะทำให้โปรแกรมที่เราสร้างขึ้นมานั้นไม่มี Bug เลย เพราะว่า Bug กับ Software นี้เป็นของคู่กันที่มี software ก็ต้องมี bug อย่างแยกกันไม่ออก แต่โอกาสที่ไม่มี Bug ก็มีได้หรือว่ามี Bugs น้อยที่สุดก็ขึ้นอยู่กับปัจจัยดังกล่าวต่อไปนี้

ขนาดของ Project

ขนาดของ Project นั้นค่อนข้างที่เกี่ยวข้องกับ Bugs ของ Program โดยตรงเพราะว่ายิ่งขนาดของ Project ยิ่งใหญ่การที่เราจะทำการตรวจสอบในทุกกระบวนการไม่ให้มีข้อผิดพลาดหรือว่าตก หล่นนั้นเป็นไปได้ยากซึ่งต่อให้เราใช้ Tool ต่างๆเข้ามาช่วยในการ Testing ที่ใช้ในการ Test ในส่วนต่างๆแล้วก็อาจจะยังมีการหลุดลอดของแมลงตัวน้อย (Bugs) ได้ และต่อให้เป็น Project ที่มีขนาดเล็กแล้วใช้ว่าจะไม่มี Bugs เสมอไปเพราะว่ายังขึ้นอยู่กับระดับความยากของ Business ด้วยยกตัวอย่างเช่น Business ที่เกี่ยวกับคิด ดอกเบี้ย ซึ่งอัตราดอกเบี้ยนั้นผันผวนอยู่ตลอดเวลาทำให้ช่วงเวลานี้คิดดอกเบี้ยอย่าง หนึ่งอีกช่วงหนึ่งคิดอีกอย่างหนึ่ง หรือการคิดดอกเบี้ยที่มีการใช้ Tree เข้ามาเกี่ยวข้อง เช่น การคิดดอกเบี้ยของธุรกิจพวกสินค้าขายตรง

ระยะเวลา

ระยะเวลานี่เป็นปัจจัยสำคัญเลยว่า Bugs จะเกิดขึ้นมากน้อยแค่ไหนเพราะว่าต่อให้เป็น Project ที่มีขนาดไม่ใหญ่มากแต่ถ้าให้เวลาน้อยก็ทำให้ต้องเร่งทำให้ทัน ทำให้บางครั้งความเร่งรีบทำให้อาจจะมองข้ามสิ่งสำคัญไปทำให้เกิด Bugs ได้ง่ายขึ้น

ภาษาที่ใช้

ภาษาที่ใช้ในการเขียน Software นี่เป็นส่วนสำคัญมากเพราะว่าบางภาษานั้นอาจจะเอื้ออำนวยให้เกิด Bugs ได้ง่ายๆ ยกตัวอย่างเช่น ภาษาที่มีลักษณะที่เป็น Dynamic คือไม่ Strong Type ทำให้ Variable ที่ประกาศขึ้นนั้นสามารถเป็น Type ชนิดอะไรก็ได้ทำให้มีโอกาสที่จะเกิด Error Type Conversion ได้สูงถ้าหากไม่มีการจัดการที่ดี หรือว่าภาษาที่ต้องมีการจัดการกับหน่วยความจำเอง เช่น ภาษา C ที่เราต้องไป allocation memory และ ปลดปล่อยมันเองซึ่งถ้าหากโปรแกรมเมอร์เป็นคนจัดการเองแล้วลืมที่จะปลดปล่อย ออกมา อาจจะทำให้เกิด memory leaks ได้ หรือว่าอาจจะไม่ได้เกิดจากการ Coding ก็ได้อาจจะเกิดจาก Bugs ของการ Compile หรือ Interpreter ของตัวภาษาเองก็ได้ซึ่งต้องศึกษาในแต่ละตัวภาษาที่จะเลือกใช้ว่ามีความ เสถียรขนาดไหน

ขั้นตอนของ SDLC

ขั้นตอนของการทำ SDLC เป็นการบริการจัดการการผลิต Software นั้นถือว่าสำคัญมากเพราะว่าหากผิดพลาดในขั้นตอนใดอาจจะมีผลกระทบส่งมายัง ขั้นตอนอื่นๆได้ดังนั้นถ้าหากว่ามีการจัดการใน SDLC ที่ดีจะช่วยทำให้ Bugs นั้นสามารถลดลงได้เป็นอย่างมากซึ่ง SDLC จะแบ่งเป็น 7 ขั้นตอนย่อยๆดังนี้

1. Planning - establishing the plans for creating an information system
2. Analysis - IT specialists collaborate to collect, comprehend, and logistically formalize business requirements
3. Design - this is where the technical blueprint of the system is created
4. Development - executing the design into a physical system
5. Testing - testing the developed system
6. Deployment - the systems are placed and used in the actual workforce
7. Maintenance - keeping the system up to date with the changes in the organization and ensuring it meets the goals of the organization

ซึ่งในตามหลักในการเจอ Bugs ที่พบกันบ่อยๆนั้นมักจะพบอยู่ในช่วงของ Analysis มากที่สุดเพราะว่าเป็นช่วงของการเก็บ Requirement ซึ่งการที่จะเก็บข้อมูลให้ครบทุกส่วนหรือว่าถูกต้องตามใจลูกค้านั้นค่อนข้าง จะเป็นไปได้ยากเนื่องจากว่าลูกค้าในบางองค์กรนั้นไม่มีความรู้เรื่องของ IT เลยทำให้การไปเก็บ Requirement และการสื่อสารเพื่อทำความเข้าใจกับลูกค้าว่าสิ่งที่ลูกค้าต้องการจริงๆนั้น คืออะไรจึงเป็นไปได้ยากดังนั้น Bugs มากกว่าครึ่งจึงมักจะเกิดจากการเก็บ Requirement ที่ผิดพลาดทำให้มันลามไปยังส่วนอื่นๆอีกเช่น Design, Development, … ซึ่งการเจอ Bugs ในช่วงหลังๆแล้วจะทำให้การแก้ Bugs ยิ่งมีมูลค่าสูงขึ้น ยกตัวอย่างเช่น การแก้ functional ของ Software ที่เกิดจากการที่เข้าใจผิดมาจากการเก็บ Requirement การแก้นั้นอาจจะไปกระทบในตัว Coding ของหลายๆส่วนทำให้ต้องแก้ functional หลายระบบในส่วนที่กระทบกัน ซึ่งบางครั้งการ Design ในตอนแรกอาจจะต้องเปลี่ยนใหม่เพื่อให้รองรับกับการเลี่ยนแปลง functional

ซึ่งจากหัวข้อด้านบนที่กล่าวมานั้นเป็นความคิดส่วนตัวของผมเท่านั้นซึ่ง ในการผลิต Software ที่ไม่มี Bug นั้นอาจจะจำเป็นต้องมี Environment มากกว่านี้เพื่อที่จะได้มาซึ่ง Software ที่มี Bugs น้อยที่สุด ยกตัวอย่างเช่น Software ที่นำมาใช้ในการ Testing ระบบการติดตามการเกิด Bugs (Bugtracking software) หรือว่าในกรณีที่มีการทำงานเป็นทีมต้องมีเครื่องมือในการควบคุม source code (source control) หรือกลวิธีในการ Test ระบบตั้งแต่การ Test loading การ Test Functional หรือ Test ลงในตัว source code (Software peer review) และอื่นๆอีกมากมาย

ซึ่งถ้าให้ถามผมว่าเคยเขียน Program (เน้นคำว่า Program ไม่ใช่ Software) ที่ไม่มี Bugs ไหมคำตอบคือเคยและคาดว่าทุกคนคงเคยเขียนมาแล้วนั้นก็คือ Program Hello World ถ้าใครเขียนมาแล้วมี Bugs นี่ก็คงแปลกแล้ว

นี่เป็นความคิดเห็นของผมครับถ้าใครมีความคิดเห็นที่เป็นอยากอื่นหรือว่าอยากจะลองทำ Assignment แล้วลองมาแชร์กันก็ได้ครับโดยตอบผ่าน Comment โดยใส่ Link ที่โยงไป Blog ตัวเองแล้วผมจะตามไปอ่านครับ

ปล.1 ลองไปอ่านเพิ่มเติมเกี่ยวกับเรื่องพวกนี้ตาม reference ข้างล่างนี้

ปล.2 ส่วนหนึ่งของเนื้อหาที่เขียนขึ้นมาได้นั้นเอามาจากอาจารย์ในชั้นวิชาเรียน

http://stackoverflow.com/questions/115528/how-to-make-a-program-bug-free-or-with-the-less-possible-bugs

http://my.opera.com/dparnell/blog/show.dml/23784

The Economy of Software Testing(3)

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 Validation and Verification กันแล้วเราจะมาดูกันว่า Validation และ Verification จริงแล้วมันคืออะไร และคำว่า defect นั้นคืออะไร อะไรที่เรียกว่า defect

Verification and Validation

Verification นั้นคือการ check ว่า software หรือ product ที่เราผลิตนั้นเราได้ตรงการ specification หรือไม่แต่ไม่ได้ check ว่า software ที่ทำมานั้นการทำงานนั้นถูกต้องหรือไม่ (you build it right)

Validation นั้นคือการตรวจสอบ software หรือ product นั้นว่ามีการทำงานที่ถูกต้องไหม มักจะอ้างอิงไปถึง user requirement หรือสิ่งที่ user ต้องการจริงๆว่า software หรือ product นั้นได้ให้ในสิ่งที่ user ต้องการไหม (you build the right thing)

Software Defect (ข้อผิดพลาดของ software)
Software defect นั้นอาจจะหมายถึงได้หลายๆอย่างเช่น Bug, Defect, Fault, Problem, Error, Incident, Anomaly, Variance, Failure, Inconsistency, Feature แม้ว่าหนังสือในหลายๆเล่มนั้นจะบอกว่าคำแต่ละคำนั้นจะใช้ในกรณีที่ต่างกันไปก็ตามแต่ในทีนี่เราจะเรียกทั้งหมดว่า defect และหากสังเกตว่าจะมีคำว่า feature นั้นอยู่ใน defect ด้วยเพราะ feature นั้นต่อให้เลิศหรูอลังการณ์ล้านแปดยังไงก็ตามแต่ถ้า feature นั้นลูกค้าไม่ต้องการมันก็คือ defect ดีๆนั้นเอง โดย software นั้นเป็นไปได้ค่อนข้างยากที่จะไม่มี defect เลย ซึ่งการหา defect นั้นเป็นเรื่องที่ค่อนข้างที่จะต้องใช้เวลาในการหา โดยการที่ยิ่งหาเร็วเท่าไรยิ่งดีเพราะว่า cost ในการ fixed นั้นยิ่งลดลงดังนั้นเราจึงจำเป็นที่จะต้องรู้ว่าในส่วนไหนบ้างที่มีโอกาศจะเกิด defect ได้บ้างซึ่งจะมีดังนี้

• Requirement Definition เกิดจากการเก็บ requirement ที่ผิดพลาดหรือว่าเข้าใจกันคนละอย่างกับ user ผู้ให้ข้อมูล หรืออาจจะไม่สมบรูณ์

• Design อาจจะเป็นผลกระทบมาจาก requirement การได้มาซึ่งข้อมูลที่ผิดทำให้การ design นั้นผิดตามไป

• Implementation การที่ design มาผิดหรือว่าการทำความเข้าใจในตัว design ผิดทำให้การ implement นั้นผิดตามไปด้วย

• Support System ภาษาที่ใช้ในการ programming ที่ไม่ดีนั้นก่อให้เกิด defect ได้เหมือนกันเช่น Compiler ของตัวภาษานั้นไม่ดีทำให้เกิด defect ได้

• Inadequate Testing of Software การตั้ง test case ที่ไม่ครอบคลุม ไม่ดีพอ หรือว่าการ test ที่ไม่ครบถ้วนทำให้ defect นั้นหลุดลอดออกมา

• Evolution การที่พัฒนาขึ้นมาจากตัวเดิมโดยเพิ่มบางสิ่งบางอย่างลงไปทำให้อาจเกิด defect เพิ่มขึ้น

การ test ตัว software แล้วปรากฎว่าไม่มี defect ไม่ได้แสดงว่า software นั้นไม่มี defect เพียงแต่ว่าเราหาไม่เจอ

“if you can’t say it, you can’t do it”

คำพูดที่บอกว่า ถ้าเราไม่รู้ว่ามันคืออะไรเราก็ไม่สามารถทำมันได้ เพราะว่าในการตรวจสอบว่า software นั้นมี defect ปนมาหรือไม่นั้นจะทำไม่ได้ถ้าหากขาดตัว specification (เป็นสิ่งที่บอกในการพัฒนา software เราต้องทำอะไร) ในการนำมาอ้างอิงในการ check ยกตัวอย่างเช่น specification ของ word processor ซึ่งจะแบ่งออกเป็น functional requirement เช่น save, print, check spelling, change font, …. และ Non-functional requirement เช่น security, reliability, user friendly, platform, .… โดยที่เราจะเอา functional และ non-functional ไปใช้ในการ test

Software Bug มันจะเกิด bug ขึ้นก็ต่อเมื่ออยู่ในข้อกำหนดด้านล่างนี้เกิดขึ้นอย่างน้อยหนึ่งข้อ

1. Software นั้นมี bug ถ้าไม่ได้ทำในสิ่งที่ specification บอกว่ามันควรจะทำ
2. Software นั้นมี bug ถ้าทำในสิ่งที่ specification บอกว่ามันไม่ควรจะทำ
3. Software นั้นมี bug ถ้าทำในสิ่งที่ตัว specification นั้นไม่ได้กล่าวถึง (mention) ให้ทำ
4. Software นั้นมี bug ถ้าไม่ทำในสิ่งที่ specification นั้นไม่ได้กล่าวถึง (mention) แต่เป็นสิ่งที่ควรจะทำ
5. Software นั้นมี bug นั้นใช้งานยาก ไม่สวย ช้า นั้นเป็นสิ่งที่บ่งบอกว่าลูกค้าคือพระเจ้า ถ้าพระเจ้าไม่ชอบนั้นสิ่งนั้น สิ่งนั้นก็คือ Bug
   

Bug Locations จากการศึกษาพบว่า Bugs นั้นไม่ได้เกิดจากการเขียน code โดยจะเกิดในส่วนที่ต่างๆดังนี้

• Specification (ประมาณ 55%) โดยจะพบว่า Bugs อาศัยอยู่ในชั้นนี้อย่างสนุกสนาน

• Design (ประมาณ 25%)

• Code (ประมาณ 15%)

• Other (ประมาณ 5%)

Cost กับการ Fixed Defect

การ fixed defect นั้นมี cost ที่ขึ้นเป็น Exponential คือทีละ 10x โดยสมมติว่า defect ใน specification นั้นมีค่าในการ fixed คือ 1$ แต่ถ้าไปเจอใน Design -> 10 $ แต่ถ้าเรายังไม่เจอใน Design ไปเจอในCode -> 100$ แต่ภ้าไม่เจอใน code ไปเจอใน Software Released -> 1000$
จากข้อเท็จจริงด้าน cost ในการ fixed defect นั้นแสดงว่าการ test defect นั้นจะอยู่ในกระบวนการการพัฒนา software ทุกขั้นที่ต้องคอย test อยู่ตลอด ดังนั้นเป้าหมายหลักในการหา Bugs นั้นก็คือ การหา Bugs ให้เร็วที่สุดเท่าที่เป็นไปได้ แล้วไปแจ้งแก่ developer และคอย check ว่า fixed เรียบร้อยแล้ว

จบแล้วครับสำหรับ Series The Economy of Software Testing เป็นยังไงกันบ้างครับ มีความคิดเห็นยังไงสามารถติชมได้ครับ

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

The Economy of Software Testing(2)

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 crisis แล้ว เช่น Higher Level Program Language หรือการนำ CASE Tool เข้ามาใช้แต่ยังมีอีกวิธีที่ยังไม่ได้กล่าวถึงคือ กระบวนการ Test เช่น

• Formal Proof of Correctness เป็นการใช้หลักการทางคณิตศาสตร์เพื่อนำมาใช้ในการพิสูนจ์ว่า program ที่เขียนนั้นถูกต้อง โดยเป็นการสร้าง formal language โดยอาศัย กฎเกณฑ์ semantic และ syntax โดยที่ programming language ถือว่าเป็น formal language อยู่แล้ว ดังนั้นการสร้าง formal language ขึ้นมาเพื่อตรวจสอบ formal language อีกอันนั้นย่อมเป็นไปได้ แต่ข้อเสียอย่างเลวร้ายที่สุดของการใช้วิธีการนี้คือ เราจะยังเริ่มไม่ได้ถ้ายังไม่มีการ implement software และถ้าหากเป็น software นั้นใหญ่การที่จะมาทำ formal proof ทั้งหมดของ ของ source code นั้นยิ่งทำได้ยาก

• Independent Verification and Validation (IV&V) เป็นการใช้บุคคลที่สามมาทำการ review software ซึ่งเป็นผลดีมากๆเลย ไม่มีความเอนเอียงหรือเข้าข้างกับทีมที่พัฒนา software เพราะไม่มีส่วนได้ส่วนเสีย และเป็นที่ยอมรับ แต่มีค่าใช้จ่ายสูงเพราะว่าต้องจ้างคนภายนอก จึงใช้กับ software ที่สำคัญมากๆ เช่น software ของระบบลงจอดของยานอวกาศ หรือ software ที่เกี่ยวอุปกรณ์ทางการแพทย์และต้องนำไปใช้กับส่วนต่างๆของร่างกาย (peak maker) เช่น เครื่อง X-ray

• Software Quality Assurance เรียกได้ว่าเป็น In-house IV&V แทนที่จะใช้บุคลที่สามจากภายนอกองค์กร แต่เป็นบุคคลที่สามของหน่วยงานอื่นในองค์กรที่ไม่มีส่วนได้ส่วนเสียของการพัฒนา software มาทำการ review software โดยที่การทำงานคล้าย IV&V มาก ทำให้ได้ IV&V มาใช้ในราคาที่ถูกลง แต่ข้อเสียของ SQA นั้นอยู่ตรงที่ มาตรฐานในแต่ละองค์กรค่อนข้างต่างกัน ทำให้ความเสมอต้น เสมอปลายในการทดสอบนั้น ไม่เท่ากันทำให้คุณภาพที่ได้มาอาจจะไม่เทียบเท่ากับองค์กรที่ทำ IV&V โดยตรง

• Cleanroom Process เป็นกระบวนการที่รวมการเอา formal verification (formal language) กับ กระบวนการควบคุมโดยใช้สถิติ (statistic process control : SPC) โดยจะเน้นการป้องกันไม่ให้ defect เกิดขึ้น โดยไม่ได้เน้นไปที่การหา defect โดยจะพึ่งพาอาศัยหลักการทางคณิตศาสตร์ที่จะใช้ตัวชี้วัดที่เรียกว่า Mean Time Between Failure แต่ Cleanroom process นั้นเป็นตัวที่ค่อนข้างใหม่ ยังไม่ได้รับการยอมรับให้เป็นที่แพร่หลาย เนื่องจากว่าความใหม่ของตัวมันเอง ถ้ารับนำเข้ามาใช้ในองค์กร ก็ต้องเปลี่ยนแปลง process มากทำให้ยังไม่เป็นที่นิยม ยกตัวอย่างเช่น ATM เป็น backbone ในระบบ Network โดยตอนที่มันเกิดมาใหม่ๆนั้นได้รับการคาดหมายว่าจะมาแทน LAN ด้วยความที่มันมี data rate ในการส่งที่สูงกว่าแต่ว่าในปัจจุบันนั้นไม่เป็นเช่นนั้น ATM ยังใช้แค่เป็น backbone เท่านั้นยังไม่ได้กระจายมาใช้แทน LAN ที่เป็นเช่นนั้นเพราะว่า ค่าใช้จ่ายในการเปลี่ยนระบบใหม่ค่อนข้างสูง และอีกอย่างคือ technology LAN นั้นก็พัฒนาอย่างไม่หยุดทำให้ LAN ก็ยังคงอยู่ ทำให้ ATM จึงนำมาใช้ในส่วนที่เป็น backbone อย่างเดียว ซึ่งก็เหมือนกันกับ Cleanroom process นั้นต่อให้มันดีแค่ไหนแต่ถ้าจะนับมาใช้ต้องเปลี่ยนทั้งระบบ และใช้ค่าใช้จ่ายมากมันก็คงไม่คุ้มที่จะเปลี่ยน

Reliability VS Feature and Cost

ต่อในปี 1990s นั้น Computer นั้นเร็วขึ้น ถูกลง ขนาดลดลง ผู้ใช้งานหลากหลายขึ้น PC กลายเป็นสิ่งที่แพร่หลายได้มากขึ้น ทำให้เกิดการเปลี่ยนแปลงระหว่าง hardware และ software ค่อนข้างมาก ทำให้ user กลายเป็นแรงขับเคลื่อนในการผลิต software และตลาดของ software นั้นเปิดกว้างขึ้น ทำให้ software ที่ออกมาในช่วงนี้ค่อนข้างที่จะต้องรีบออกมาอย่างรวดเร็วเพื่อให้ทันกับความต้องการของ user ทำให้ผู้ผลิตนั้นต้องรีบผลิต software ออกมาเพื่อที่จะแข่งขันกับคู่แข่งรายอื่นๆ นั้นก็คือพยายามออก version ใหม่ของ software เพื่อที่จะพยายาม update ตัว software เพื่อให้มี feature ที่นำหน้าคู่แข่งอยู่เสมอ และอีกอย่างหนึ่งก็คือ hardware นั้นมี performance ที่สูงขึ้นทำให้ software ที่ออกมานั้นมีความซับซ้อนขึ้นเป็นตามลำดับ ผลที่เกิดขึ้นทำให้ software vender นั้นต้องรีบออก product ใหม่ให้เร็วๆ จนทำให้ เวลาที่ใช้ในการผลิต software ลดลงดังนั้นการทำการ testing software นั้นลดลงส่งผลต่อคุณภาพของ software และ defect ของ software มีมากขึ้น ถึงแม้ว่าจะออก version ใหม่ออกมาแต่ defect ใหม่ก็มีมากขึ้นเช่นกัน ทำให้ user ต่างๆร้องเรียนเข้ามาทำให้ software vender นั้นต้องทำการ fixed defect เหล่านั้น และค่าใช้จ่ายในการ fixed defect นั้นสูง ทำให้เสียค่า maintain มากเนื่องจากต้องจ่ายค่าส่งไปรษณีย์(สมัยนั้นยังไม่มี internet)ในการ fixed defect แต่ละครั้ง และยังไม่รวมไปถึงค่าใช้จ่ายให้กับที่ต้องไป support ในกรณีที่ต้องแก้ไขทางด้าน technical ยังไม่รวมถึงค่า call center ทำให้การกระทำเช่นนี้เริ่มที่จะแว้งกัดกลับไปยัง software vender เพราะว่า profit ลดลงจากการที่ต้องจ่ายค่าใช้จ่ายในการ support เพื่อที่จะ fixed defect ทำให้เริ่มกลับมาคิดจากการละเลยของคุณภาพ software ทำให้เกิดการมองเรื่องของคุณภาพของ software กับ การแข่งขันทางการตลาด ทำให้เกิดการ shift ไปสู่การเน้นคุณภาพของ software ที่สูงขึ้น

ต่อมาไม่นานหลังจากการ shift ไปสู่การเน้นคุณภาพของ software ก็เกิดนวัตกรรมใหม่ขึ้นมา คือ Internet หรือที่รู้จักกันในชื่อของ www ซึ่งมีผลกระทบต่อการ communication ทำให้ค่าใช้จ่ายในการ fixed defect นั้นลดลงเพราะว่าถ้าเกิด defect ใดๆก็ตามให้แจ้งผ่านเข้ามาทาง mail หรือ track issue ต่างๆเช่น JIRA, Bugzilla อื่นๆเป็นต้น จากนั้นจึงส่ง link เพื่อที่จะ download ตัว update ของ software ทำให้ software vender นั้นพึงพอใจมากกับค่าใช้จ่ายในการ support ที่ลดลง นอกจาก software vender ที่พอใช้แล้ว user เองก็พอใจด้วยเนื่องจากได้รับบริการที่รวดเร็วขึ้นจึงเป็นผลดีทั้งสองฝ่าย ทำให้การออก version ใหม่ให้กับตัวของ software นั้นรวดเร็วเพื่อเพิ่มแข่งขันกันในทางตลาดกลับมาเหนือคำว่า คุณภาพของ software เพราะว่าถูกมองว่าไม่ใช่ความสำคัญต่อความสำเร็จของตัว software ที่ออกมาขาย ไปเน้นเรื่องของ feature ที่ออกมาเตะตาของ user มากกว่าเพื่อแย่งพื้นที่การตลาด

ต่อมาในช่วงปี 2001 – 2002 ซึ่งเป็นช่วงของ ฟองสบู่แตก ความสะพัดของเม็ดเงินนั้นลดลงธุรกิจ dot com หลายตัวที่ต้องล้มละลาย ทำให้การพึ่งพา www ที่จะลดค่าใช้จ่ายในการ support นั้นค่อนข้างที่จะใช้ไม่ได้ผลมากยิ่งขึ้น เพราะว่า user นั้นเริ่มต้องการ software ที่มีคุณภาพที่สูงขึ้น ไม่ต้องการที่จะเสียค่าใช้จ่ายในการมาไล่ตามการ update version เพื่อให้คุ้มกับเม็ดเงินที่ลงทุนไป ทำให้กระแสของ software คุณภาพนั้นได้ย้อนกลับมาอีกครั้ง ทำให้ software vender ต้องปรับตัวในการเพิ่มคุณภาพให้กับ software ซึ่งยุคนี้ก็ได้ดำเนินมาจนถึงยุคปัจจุบัน

พอจะเห็นภาพคร่าวๆกันแล้วใช่ไหมครับว่าความเป็นมาของ V&V นั้นเป็นยังไง แต่ว่าเรื่องราวของ The Economy of Software Testing ยังไม่จบครับลองติดตามต่อในตอนที่สาม ซึ่งจะเริ่มไปเข้า Concept ของ V&V ครับ

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

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