Oz’s Blog

ตุลาคม 16, 2007

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

Filed under: Software Testing — siroz @ 10:01 pm

จากตอนที่แล้ว ที่เราพูดถึง “ยุค” ต่างๆ ของแนวคิดในการทดสอบซอฟต์แวร์
วันนี้ เราจะมาต่อจากที่ค้างไว้กันครับ
แต่่ก่อนที่จะขึ้น ยุคที่ 3 ขอพูดถึงจุดอ่อนของแนวคิดในยุคที่ 2 ซึ่งจะนำมาสู่แนวคิดในยุคที่ 3 กันก่อน


จุดอ่อนที่สำคัญ ของการตั้งเป้าหมายของการทดสอบโปรแกรม เป็น การแสดงความถูกต้องของโปรแกรม คือ ความโน้มเอียง ไปในทางที่จะพยายามทำให้โปรแกรมผ่านการทดสอบ มากกว่าที่จะพยายามทำให้โปรแกรมไม่มีข้อผิดพลาด
เมื่อ เป้าหมาย คือ การแสดงว่าโปรแกรมทำงานถูกต้อง นั่นหมายถึง การพยายามทำให้โปรแกรมผ่านการทดสอบ ด้วยกรณีทดสอบที่สร้างหรือเลือกขึ้นมา
เนื่องจาก เป้าหมายที่ว่านี้ เป็นสิ่งที่ชี้วัดความสำเร็จของการทดสอบ ดังนั้น ความสำเร็จของการทดสอบในยุค Demonstrating-Oriented คือ การที่ทดสอบโปรแกรมที่เขียนขึ้นมา แล้วได้ผลเป็นผ่าน
การมุ่งสู่เป้าหมายนี้ บางทีอาจจะทำให้ เราหลงทิศหลงทางได้
เพราะ เราอาจจะพยายามสร้าง หรือเลือกกรณีทดสอบที่จะทำให้โปรแกรมทดสอบแล้ว “ผ่าน” (คือไม่เจอข้อผิดพลาด) มากกว่า ที่จะพยายามสร้าง หรือเลือกกรณีทดสอบที่ทำให้เจอข้อผิดพลาด
ซึ่ง การทำเช่นนี้ ทำให้การทดสอบด้อยประสิทธิผล ไม่สามารถทำให้มั่นใจได้ว่า โปรแกรมที่ผ่านการทดสอบมาแล้ว จะมีข้อผิดพลาดลดน้อยลง

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

Destruction-Oriented Period (1979-1982)
ในยุคของ Destruction-Oriented นี้ จะแก้ปัญหาจุดอ่อนของแนวคิดในยุค Demonstrating-Oriented โดยการตั้งเป้าหมายของการทดสอบ เป็น การค้นหาข้อผิดพลาด
ตรงนี้ อาจจะดูน่าสงสัยว่า มันต่างจากเป้าหมายเดิมที่พูดไว้ก่อนหน้าตรงไหน
ในด้านขั้นตอนและวิธีการ อาจจะไม่แตกต่างกันอย่างเห็นได้ชัด
แต่ ในเรื่องของมุมมองและแนวคิด แตกต่างกันอย่างชัดเจน

การทดสอบเพื่อตั้งใจจะแสดงว่า โปรแกรมทำงานได้ไม่ผิดพลาด นั่นแปลว่า มีการตั้งสมมติฐานกันไว้ว่า โปรแกรมน่าจะไม่มีข้อผิดพลาด
แต่ การทดสอบเพื่อจะค้นหาข้อผิดพลาดในโปรแกรมนั้น จะเป็นการตั้งสมมติฐานว่า โปรแกรมน่าจะมีข้อผิดพลาด
ซึ่งตรงนี้ทำให้ tester ต้องมองมุมกลับจากแนวคิดเดิม จากความพยายามที่จะทดสอบให้ผ่าน เป็นความพยายามที่จะทดสอบแล้วไม่ผ่าน (พบข้อผิดพลาด)
จะเรียกได้ว่า กลับมุมจากมองโลกในแง่ดี เป็นมองโลกในแง่ร้าย ก็คงจะไม่ผิดนัก
แนวคิดนี้ กลายเป็นแนวคิดที่เป็นรากฐานของหลักการทดสอบซอฟต์แวร์ในปัจจุบัน ซึ่งเ้ป็นการเน้นที่ การตรวจหาข้อผิดพลาด (defect detection) มากกว่าที่จะเป็นการแสดงความถูกต้อง (demonstration) ในแนวคิดก่อนหน้า

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

แต่ในที่สุดแล้ว การทดสอบต้องมีที่สิ้นสุด เพื่อที่จะนำโปรแกรมที่ทดสอบนั้นไปใช้งาน
ซึ่งตรงนี้ มีสิ่งที่เรียกว่า adequacy criteria สำหรับเทคนิคการทดสอบในแต่ละแบบ เพื่อที่จะใช้บอกว่า เมื่อไหร่ที่การทดสอบ ถึงจุดที่เรียกได้ว่า “พอเพียง” แล้ว
ตรงนี้ ไม่ได้หมายความว่า ทดสอบจนกระทั่งโปรแกรมไม่มีข้อผิดพลา่ด (เพราะขัดกับสมมติฐานของแนวคิดที่ว่า โปรแกรมใดๆ น่าจะมีข้อผิดพลาดเสมอ)
แต่เป็นการตั้งเงื่อนไขว่า เมื่อทดสอบจนถึงจุดนี้แล้ว ไม่จำเป็นที่จะต้องทดสอบต่อไป เพราะด้วยเทคนิคการทดสอบที่เลือกมาใช้นั้น การทดสอบที่ได้ทำไปแล้ว ได้ครอบคลุมในระดับที่กำหนดไว้แล้ว (พอเพียงแล้ว)
หรือ แปลได้ในอีกความหมายว่า ถึงแม้จะทดสอบต่อไป ด้วยเทคนิคการทดสอบนั้น โอกาสที่จะพบความผิดพลาดอีกมีแนวโน้มที่จะมีน้อยมาก (นั่นคือ ด้วยความสามารถและข้อจำกัดของเทคนิคการทดสอบนี้ ข้อผิดพลาดที่ควรจะพบ ได้ถูกค้นพบแล้วโดยการทดสอบที่ทำไปแล้ว)
ซึ่งจะทำให้การทดสอบต่อไป (ด้วยเทคนิคนั้นๆ) ไม่คุ้มค่าในการทำแล้ว เมื่อพิจารณาถึงค่าใช้จ่ายที่เกิดขึ้น เทียบกับผลที่ได้รับ
ขอจบเรื่อง adequacy criteria ไว้ที่ตรงนี้ก่อน จริงๆ แล้วรายละเอียดมีเยอะมาก แต่ผมกลัวว่าจะออกนอกเรื่องไปไกลกว่านี้

นอกจากนั้น ในยุคนี้ เส้นแบ่งระหว่าง test และ debug ก็ชัดเจนขึ้นด้วย จากเดิมที่ดูเหมือนจะแตกต่างกันไม่ชัดเจน เพราะแนวคิดเดิม มองให้การทดสอบเป็น การแสดงความถูกต้องของโปรแกรม ซึ่งก็ยังใกล้เคียงกับเป้าหมายของการ debug
ในแนวคิดใหม่นี้ การทดสอบเป็นการตรวจสอบข้อผิดพลาด ว่ามีหรือไม่
และ การ debug เป็นกิจกรรมที่เข้ามาช่วยเสริม หลักจากพบว่ามีข้อผิดพลาด โดย ใช้สำหรับค้นหาตำแหน่งของข้อผิดพลาด ชี้ต้นเหตุของปัญหา และแก้ไขให้ถูกต้อง
ซึ่งความแตกต่างที่ชัดเจนนี้ ก็เป็นผลมาจากการเปลี่ยนแนวคิดการตั้งสมมติฐาน เรื่องของข้อผิดพลาดในโปรแกรม เช่นกัน

ถ้าอ่านตอนที่แล้วของเรื่องนี้ คงจะพอเดาทางผมออกแล้วว่า ตอนนี้ ก็ยังไม่ happy ending
ถึงแม้ แนวคิดนี้ จะเป็นแนวคิดที่ยอมรับกัน ในการทดสอบซอฟต์แวร์
แต่ มันยังแก้ปัญหาเรื่องข้อผิดพลาดในซอฟต์แวร์ได้ไม่สมบูรณ์
หรือ จะเรียกง่ายๆ คือ ยังมีแนวคิดที่ก้าวหน้าไปกว่านี้อีก (นี่เพิ่งจะช่วงยุค 80’s ต้นๆ เอง)
ซึ่งเราจะมาต่อกันในตอนหน้าครับ

22:01 นาฬิกา
16 ตุลาคม 2550

7 ความเห็น »

  1. มาลงชื่อไว้ว่าอ่านจบทั้งสองตอนแล้วค่ะ ขอบคุณสำหรับข้อมูลดีๆค่ะเป็นเทสเตอร์ซะเปล่าแต่ไม่เคยรู้ประวัติความเป็นมาแบบละเอียดแล้วก็แบ่งเป็นยุคๆของการทดสอบ Software มาก่อนเลยค่ะ แต่เท่าที่ทำอยู่ตอนนี้น่าจะเป็นการรวมกันทั้งสามยุคนี้ด้วยแล้วส่วนหนึ่ง ยังไงหน้าที่การค้นหาความผิดพลาดก็ต้องทำ และในขณะเดียวกันโปรเจคก็ต้องเสร็จตามกำหนดเช่นกัน ตอนนี้เริ่มเข้าใจแล้วว่าทำไมเค้าถึงมีงานวิจัยชิ้นหนึ่งชื่อ when to stop testing ออกมาเพราะเหตุนี้นี่เอง

    และขอสนับสนุนสมมติฐานนี้ด้วยคนค่ะ “โปรแกรมใดๆ น่าจะมีข้อผิดพลาดเสมอ ” อยู่ที่ว่าเราจะค้นหามันเจอหรือเปล่ากรณีที่ Free bug นี่ไม่น่าจะมียิ่งเจอโปรแกรมเมอร์ที่เป็นระดับซีเนียร์ประสบการณ์สูงด้วยแล้ว บอกตรงๆว่ายิ่งค้นหาลำบากมากๆ ไม่ใช่เพราะโปรแกรมเมอร์เขียนดีนะ แต่เค้าบอกว่าเค้าซ่อน bug เก่งหน่ะซิเลยหาไม่เจอ คราวนี้ความหายนะจะมาเยือนเทสเตอร์เอาง่ายๆ..พอเริ่มหาไม่เจอก็คงต้องขอให้เปิด source code ให้ดูกันไปตามเรื่องอิอิ

    เอาเป็นว่าจะมารออ่านจนกว่าจะถึงยุคปัจจุบัน หวังว่าท่านเซอร์อ๊อดจะ update ทุกๆอาทิตย์นะค่ะ เที่ยวนี้นานไปหน่อย แวะเวียนมาดูหลายรอบยังไม่ up พอเห็นแล้วก็รีบอ่านทันทีเลย..

    ความเห็น โดย ShijiemiS — ตุลาคม 21, 2007 @ 1:41 pm

  2. ตรงนี้ มองได้สองแง่นะครับ
    แง่นึง อาจจะมองได้ว่า design ที่ดี ควรจะเรียบง่าย ตรงไปตรงมา เข้าใจง่าย ซึ่งน่าจะทำให้มีโอกาสเกิดข้อผิดพลาดได้น้อย
    คนที่ออกแบบ หรือเขียนโปรแกรมได้ดี ควรจะทำให้โปรแกรมมีลักษณะแบบนี้

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

    ในทั้งสองแง่ คือ มองในด้านเทคนิคและกระบวนการ ถ้าได้ทั้งสองทางก็จะยิ่งดี
    แต่อย่างไรก็ตาม ยังไม่ได้พูดถึงปัจจัยเรื่อง “คน” .. ขอ(ยัง)ไม่พูดถึงละกันนะครับ เพราะตอนนี้ เรากำลังคุยกับเรื่องกระบวนการอยู่😛

    ความเห็น โดย siroz — ตุลาคม 30, 2007 @ 7:50 pm

  3. ขอบคุณค่ะพี่ อ่านแล้วเข้าใจ

    ความเห็น โดย IT@KMITL — ธันวาคม 27, 2008 @ 6:38 pm

  4. เมื่อไหร่จะเอาอีก 2 ยุคที่เหลือมาหล่ะค่ะ
    รอจะอ่านอยู่อ่ะค่ะ

    ความเห็น โดย sandwich — ตุลาคม 29, 2009 @ 9:19 am

  5. […] พัฒนาการของการทดสอบซอฟต์แวร์ ตอนที่ 1 พัฒนาการของการทดสอบซอฟต์แวร์ ตอนที… […]

    Pingback โดย >The Economy of Software Testing(2) | Oracle in Thai | Oracle in Thai | Oracle User Group in Thailand | — มีนาคม 23, 2011 @ 4:42 pm

  6. […] พัฒนาการของการทดสอบซอฟต์แวร์ ตอนที่ 1 พัฒนาการของการทดสอบซอฟต์แวร์ ตอนที… […]

    Pingback โดย The Economy of Software Testing(3) | Oracle in Thai | Oracle in Thai | Oracle User Group in Thailand | — มีนาคม 23, 2011 @ 4:46 pm

  7. […] พัฒนาการของการทดสอบซอฟต์แวร์ ตอนที่ 1 พัฒนาการของการทดสอบซอฟต์แวร์ ตอนที… […]

    Pingback โดย The Economy of Software Testing(1) | Oracle in Thai | Oracle in Thai | Oracle User Group in Thailand | — เมษายน 25, 2011 @ 1:58 pm


RSS feed for comments on this post. TrackBack URI

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s

สร้างเว็บไซต์หรือบล็อกฟรีที่ WordPress.com.

%d bloggers like this: