CHAPTER 1
SE345
Software Verification and Validation
วัตถุประสงค์เฉพาะบท
1. เพื่อให้ นกั ศึกษารู้จกั และเข้ าใจศัพท์ เทคนิคและพื ้นฐานความรู้
ที่ใช้ ในการทดสอบซอฟต์แวร์
2. เพื่อให้ นกั ศึกษาเข้ าใจกระบวนการ พัฒนาซอฟต์แวร์





บรรยาย
ศึกษาและนาเสนอกรณีตวั อย่าง
Pre-Test
Post-Test
ศึกษาด้ วยตนเอง
(2 ชม.)
(30 นาที)
(15 นาที)
(15 นาที)
(6 ชม.)
Pre-Test
ให้ นกั ศึกษาทา Pre-Test บทที่ 1 ลงในกระดาษที่อาจารย์
ผู้สอนได้ จดั เตรี ยมไว้ ให้ ใช้ เวลา 15 นาที

ความรูเ้ บื้องต้นเกี่ยวกับกระบวนการพัฒนาซอฟต์แวร์
และการทดสอบซอฟต์แวร์
1.1 วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC)
1.2 ความรู้เบื ้องต้ นเกี่ยวกับการทดสอบซอฟต์แวร์ (Software
Testing
 ค่าใช้ จา่ ยที่เกิดขึ ้นเมื่อเกิดบัค (The Cost of Bugs)
 ทีมการทดสอบซอฟต์แวร์ (Software Testing Teams)
1.3 การทวนสอบและการทดสอบซอฟต์แวร์ (Software Verification
and Validation)
1.4 คาศัพท์ที่เกี่ยวข้ อง (Terminologies)
1.5 ศึกษากรณีตวั อย่างผลกระทบที่เกิดจากการไม่ทาการทดสอบ
วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC)
ในกระบวนการพัฒนาซอฟต์แวร์ มีแบบจาลองที่หลากหลายเพื่อ
ใช้ เป็ นแบบจาลองในการพัฒนาซอฟต์แวร์ เช่น Waterfall
Model , Spiral Model , Incremental Model , Agile , Scrum ,
XP Model , V Model , RUP Model , RAD Model ฯลฯ ซึง่
แบบจาลองเหล่านี ้มีขนตอนต่
ั้
าง ๆ ที่แตกต่างกันไปในกิจกรรม
ย่อยของแต่ละขันตอน
้
การบ้าน บทที่ 1
งานเดี่ยว (12 คะแนน)
1. ให้ นกั ศึกษาทาการศึกษาค้ นคว้ าด้ วยตนเองเกี่ยวกับแบบจาลองต่างๆ
มาอย่างน้ อย 3 แบบจาลอง พร้ อมทังท
้ าสรุปส่งภายในวันศุกร์ ที่ 29
ตุลาคม ก่อน 16.30 น. ส่งใน E-learning
 รายละเอียดกิจกรรม / ขันตอนของแบบจ
้
าลอง
 รู ปภาพแบบจาลอง
 ข้ อดี / ข้ อเสีย
ส่งช้ าหักวันละ 1 คะแนน
ให้ Save ชื่อไฟล์  HW1-1_รหัสนักศึกษา.docx
วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC)
สรุปได้ วา่ วงจรชีวิตการพัฒนาซอฟต์แวร์ (Software Development Life
Cycle) มีขนตอนดั
ั้
งนี ้








Project planning, feasibility study:
Systems analysis, requirements definition:
Systems design:
Implementation:
Integration and testing:
System Testing
Acceptance, installation
Maintenance:
เอกสารที่เกิดขึน้ ในกระบวนการพัฒนาซอฟต์แวร์
เอกสารใน Project planning, feasibility study:
 Software Project Management Plan (SPMP)
 Feasibility study
 Software Configuration Management Plan (SCMP)
 Test Plan (TP)
 Systems analysis, requirements definition:
 Software Requirement Specification (SRS)

เอกสารที่เกิดขึน้ ในกระบวนการพัฒนาซอฟต์แวร์
Systems design:
 Software Design Documentation (SDD)
 Test Case (TC)
 Test Script (TS)
 Implementation:
 Source Code (SC)
 Unit Testing Report (UTR)

เอกสารที่เกิดขึน้ ในกระบวนการพัฒนาซอฟต์แวร์
Integration and testing:
 Integration Test Report (ITR)
 System Testing
 System Test Report (STR)
 Acceptance, installation
 Acceptance Test Report (ATR)
 Installation Document (ID)
 Maintenance:
 User Manual (UM)

Why do we test?
มี 2 เหตุผลที่ต้องทดสอบซอฟต์แวร์ คือ คุณภาพ (หรื อการ
ยอมรับ) และการค้ นพบปั ญหา
 สาเหตุที่ต้องทาการทดสอบเพราะว่ามีข้อผิดพลาด โดยเฉพาะ
อย่างยิ่งความเที่ยงตรงของซอฟต์แวร์ และระบบต่าง ๆ ที่ได้ รับ
การควบคุม

If You Don’t Do Both …
Per The Requirements
As Systems Specified It
As Engineering Designed It
You Can Meet the Spec, But …
As the Factory Built It
As Integration Installed It
What the Customer Wanted
Without Validation as part of the process, you will waste:
• Time
• Energy
• Money
• Resources
… and still not get it right.
Why Do Bugs Occur?


There are several reasons specifications are the largest bug
producer. In many instances a spec simply isn’t written. Other
reason may be that the spec isn’t thorough enough, it’s constantly
changing, or it’s not communicated well to the entire development
team. Planning software is vitally important. If it’s not done correctly,
bugs will be created.
The next largest source of bugs is the design. This is where the
programmers lay out their plan for the software. Compare it to an
architect creating the blueprints for a building. Bugs occur here for
the same reason they occur in the specification. It’s rushed,
changed, or not well communicated.
Bugs are caused for numerous reasons, but, in this
sample project analysis, the main cause can be traced to
the specification
What Exactly Does a Software Tester Do?
The goal of a software tester is to find bugs.
 The goal of a software tester is to find bugs and find
them as early as possible.
 The goal of a software tester is to find bugs, find them as
early a possible, and make sure they get fixed.

Software tester should have:
They are explorers.
 They are troubleshooters.
 They are relentless.
 They are creative.
 They are (mellowed) perfectionists.
 They exercise good judgment.
 They are tactful an diplomatic.
 They are persuasive.

Software tester should have:

They are explorers.
 ผู้ทดสอบต้ องทาตัวเป็ นนักสารวจ และไม่กลัวที่จะอยู่ในเหตุการณ์
ที่เขาไม่เจอพบ และมีใจรักที่จะทดสอบซอฟต์แวร์ ใหม่ ๆ

They are troubleshooters.
 ผู้ทดสอบต้ องเป็ นนักแก้ ไขปั ญหา
 ผู้ทดสอบที่ดีควรหาเหตุผลว่าทาไมงานนันถึ
้ งไม่ผา่ นการทดสอบ
มีสาเหตุเกิดจากอะไร
Software tester should have:

They are relentless.
 ผู้ทดสอบต้ องมีความอดทนที่จะค้ นหาข้ อผิดพลาด และต้ องมี
ความพยายาม เขาจะเกิดความรู้สกึ ว่าปั ญหาถูกคลี่คลายไปอย่าง
รวดเร็วหรื อยากที่จะเกิดขึ ้นมาอีก
 บางครัง้ การพบข้ อผิดพลาดอาจเกิดจากความบังเอิญก็เป็ นได้
 ผู้ทดสอบต้ องทาทุกวิถีทางที่จะให้ พบข้ อผิดพลาดให้ ได้
Software tester should have:

They are creative.
 วิธีการทดสอบที่ทาอยูน
่ นหากไม่
ั้
เพียงพอที่จะกาจัดข้ อผิดพลาดให้
ออกไปได้ ผู้ทดสอบจึงต้ องมีการคิดสร้ างสรรค์เพื่อหาวิธีในการหา
ข้ อผิดพลาดหรื อข้ อบกพร่อง

They are (mellowed) perfectionists.
 ผู้ทดสอบต้ องมีความสุขม
ุ รอบคอบ มุง่ ที่จะหาข้ อผิดพลาด
Software tester should have:

They exercise good judgment.
 ผู้ทดสอบต้ องมีการฝึ กฝนในการตัดสินใจและใช้ ดล
ุ พินิจในการ
ตัดสินใจเกี่ยวกับสิ่งที่เขากาลังทดสอบว่าสิง่ เหล่านันเป็
้ น
ข้ อผิดพลาดหรื อข้ อบกพร่องหรื อไม่

They are tactful an diplomatic.
 ผู้ทดสอบต้ องมีความเชี่ยวชาญ มีไหวพริ บ และมีชนเชิ
ั้ ง
 เขาควรมีชนเชิ
ั ้ งในการพูดที่จะบอก Programmer ถึงข้ อผิดพลาด
ที่เกิดขึ ้น
Software tester should have:

They are persuasive.
 ผู้ทดสอบต้ องมีความสามารถในการโน้ มน้ าวจิตใจ หรื อสามารถ
เกลี ้ยกล่อม
 ข้ อผิดพลาดหรื อข้ อบกพร่ องที่ผ้ ท
ู ดสอบพบนันอาจจะไม่
้
รุนแรง
หรื อไม่สง่ ผลกระทบที่จะทาให้ ระบบเสียหาย ดังนันผู
้ ้ ทดสอบต้ อง
แสดงให้ เห็นว่าเพราะเหตุใด
 หรื อข้ อผิดพลาดหรื อข้ อบกพร่ องนันสมควรที
้
่ต้องได้ รับการแก้ ไข
( Fixed) ผู้ทดสอบต้ องแสดงให้ ทีมเห็นว่าเพราะอะไรข้ อผิดพลาด
หรื อข้ อบกพร่องนี ้ควรได้ รับการแก้ ไข (Fixed)
ทีมการทดสอบซอฟต์แวร์
(Software Testing Teams)
Software Customers
Those who contract for the software to be developed
 Software Users
Those who will use the software

ทีมการทดสอบซอฟต์แวร์
(Software Testing Teams)
Software Developers
 Those who involve or assist in
Writing requirements from the software user,
Designing the software,
Building the software, and
Changing and maintaining the software as needed
 Development Testers / Software Testers
 Those who perform the check function on the software

ทีมการทดสอบซอฟต์แวร์
(Software Testing Teams)
Senior Management
 CEO of the organization and other senior executives who are
responsible for fulfilling the organization mission. Information
technology is an activity that supports fulfilling that mission.
 Auditor
 The individual or group responsible for evaluating the
effectiveness, efficiency, and adequacy of controls in the
information technology area. Testing is considered a control
by the audit function.

ทีมการทดสอบซอฟต์แวร์
(Software Testing Teams)

Project manager
 The individual responsible for managing the building,
maintaining, and/or implementing of software.
The Cost of Bugs

The costs are logarithmic – that is, they increase tenfold
as time increase. A bug found and fixed during the early
stages when the specification is being written might cost
next to nothing, or 1$ in our example. The same bug, if not
found until the software is coded and tested, might cost
$10 to $100. If a customer finds it, the cost could easily be
thousands or even millions of dollars.
The cost to fix bugs can increase dramatically
over time.
Software Verification and Validation
Software Verification
Verification helps answer the question “Are we building the
product right?”
 Verification activities are defined around three basic
processes: inspection, measurement, and configuration
management.
 เราได้ สร้ างระบบอย่างถูกต้ องหรื อไม่
 ซอฟต์แวร์ ที่พฒ
ั นาตรงกับข้ อกาหนดที่ระบุไว้ หรื อไม่

Software Validation
Validation activities are performed after the software is
developed to determine if the software correctly
implements the requirements.
 Validation helps answer the question “Did we build the
right product?”
 เราได้ สร้ างระบบที่ถก
ู ต้ องหรื อไม่
 ซอฟต์แวร์ ที่พฒ
ั นาตรงกับความต้ องการหรื อไม่

คาศัพท์ที่เกี่ยวข้อง (Terminologies)

Software Testing (การทดสอบซอฟต์แวร์ )
 เป็ นกิจกรรมที่จด
ั ทาขึ ้นเพื่อประเมินและปรับปรุงคุณภาพของ
ซอฟต์แวร์ โดยการตรวจหาข้ อผิดพลาดและปั ญหาที่เกิดขึ ้น แล้ วทา
การแก้ ไขข้ อผิดพลาดหรื อปั ญหาดังกล่าวให้ ถกู ต้ อง [IEEE, 2004]
วัตถุประสงค์ของการทดสอบซอฟต์แวร์ ก็เพื่อพิสจู น์วา่ ซอฟต์แวร์
ทางานได้ ครบทุกฟั งก์ชนั ตามข้ อกาหนดความต้ องการ และ
ตรวจสอบว่าแต่ละฟั งก์ชนั สามารถประมวลผลข้ อมูลได้ อย่างถูกต้ อง
คาศัพท์ที่เกี่ยวข้อง (Terminologies)

Errors (ความผิดพลาด)
 คนทาผิด หรื อเกิดจากการเข้ าใจความหมายในเอกสารผิดก็จะทาให้
การเขียน Code ผิดไปด้ วย ซึง่ เรี ยกข้ อผิดพลาดนี ้ว่าความผิดพลาด
ที่ทาให้ เกิด Bug ความผิดพลาดจากความต้ องการ (Requirement)
อาจขยายความผิดพลาดไปยังการออกแบบ (Design) และ Code
คาศัพท์ที่เกี่ยวข้อง (Terminologies)


Fault (ความคลาดเคลื่อน)
 ความคลาดเคลื่อนเป็ นผลมาจากความผิดพลาด (Error) ที่นาเสนอ
ไดอะแกรม narrative text, dataflow diagrams, hierarchy charts,
source code และอื่น ๆ ความคลาดเคลื่อนที่ยากจะเข้ าใจ เมื่อผู้ออกแบบ
(Designer) ละเลยข้ อผิดพลาด ผลของความคลาดเคลื่อนที่เกิดขึ ้น อาจ
เกิดจากการขาดหาย (Missing) ที่ควรนาเสนอ
 อาจเกิดจากข้ อมูลในเอกสารขาดหาย ตกหล่น
Failure (ความล้ มเหลว)
 ความล้ มเหลว เกิดขึ ้นเมื่อเกิด Fault
 ก่อให้ เกิดความเสียหายต่อตัวทางานระบบ มีผลในทางลบต่อผู้ใช้ และ
ลูกค้ า
คาศัพท์ที่เกี่ยวข้อง (Terminologies)




Bugs
 จะพบได้ ตอน Coding
Crashes
 มีผลกระทบทาให้ ระบบล่ม / พัง ใช้ ไม่ได้
Indicant (เหตุการณ์)
 เหตุการณ์ที่เกิดขึ ้นที่เกี่ยวข้ องกับความล้ มเหลวโดยมีการแจ้ งเตือนให้ ผ้ ใู ช้
ทราบว่าเกิด Failure
Defects (ข้ อบกพร่อง)
 เป็ นข้ อบกพร่ องที่พบก่อนการ Coding
 Missing / Wrong / Extra
What are you test for?

A defect is a variance from a desired product attribute. Any
variance at all is a defect.
 Wrong – A variance from customer/user specification
 Missing – A specified or wanted requirement is not in the built
product
 Extra – May be an attribute desired by the user, but a defect
nonetheless
กรณีตวั อย่างผลกระทบที่เกิดขึ้น
Disney’s Lion King, 1994-1995:
In the fall of 1994, the Disney company released its first multimedia CD-ROM game for
children, The Lion King Animated Storybook. Although many other companies had
been marketing children’s programs for years, this was Disney’s first venture into the
market and it was highly promoted and advertised. Sales were huge. It was “the game
to buy” for children that holiday season. What happened, however, was a huge
debacle. On December 26, the day after Christmas, Disney’s customer support
phones began to ring, and ring, and ring. Soon the phone support technicians were
swamped with calls from angry parents with crying children who couldn’t get the
software to work. Numerous stories appeared in newspapers and on TV news. It turns
out that Disney failed to properly test the software on the many different PC models
available on the market. The software worked on a few systems—likely the ones that
the Disney programmers used to create the game—but not on the most common
systems that the general public had.
ศึกษากรณีตวั อย่างผลกระทบที่เกิดขึ้น
กิจกรรมในชัน้ เรี ยนใช้ เวลา 30 นาที
(10 คะแนน)
ให้ นก
ั ศึกษาทาการศึกษา “Infamous Software Error Case
Studies” และวิเคราะห์ วิจารณ์ถึงสาเหตุที่ทาให้ เกิดข้ อผิดพลาดคือ
อะไร ให้ เขียนส่งอาจารย์เป็ นรูปเอกสารและออกมาวิเคราะห์ให้
เพื่อนฟั งหน้ าห้ อง
 Intel Pentium Floating-Point Division Bug, 1994:
 NASA Mars Polar Lander, 1999:
 Patriot Missile Defense System, 1991:
 The Y2K (Year 2000) Bug, circa 1974
 Dangerous Viewing Ahead, 2004
Questions &
Answers
“What we anticipate seldom occurs; what we least expected
generally happens.”
- Benjamin Disraeli
“สิ่งที่เราคาดคิด จะไม่ ค่อยเกิดขึน้
สิ่งที่เราคาดไม่ ถึงส่ วนใหญ่ ก็จะเกิดขึน้ ”
Post-Test (10 คะแนน)
ให้ นกั ศึกษาทา Post-Test บทที่ 1 ลงในกระดาษที่อาจารย์
ผู้สอนได้ จดั เตรี ยมไว้ ให้ ใช้ เวลา 15 นาที

การศึกษาด้วยตนเอง

เพื่อการเตรี ยมตัวเรี ยนในบทที่ 2
 ให้ นก
ั ศึกษาทาการศึกษาเอกสาร “Software Test Plan” ตามเอกสาร
ใน E-Learning “Practial Support for CMMI-SW Software Project
Documentation Using IEEE Software Engineering Standards” by
Susan K. Land and John W. Walz, Wiley Interscience
Publication, 2006. แล้ วทาการสร้ างแบบฟอร์ ม Template เป็ น
ภาษาไทย เพื่อนาไปใช้ ในการวางแผนการทดสอบต่อไป (10 คะแนน)
 ส่งใน E-learning วันจันทร์ ที่ 1 พฤศจิกายน ก่อนเวลา 12.00 น.