Chapter 1

1. Chapter 1 SE345 Software Verification and Validation

2. วัตถุประสงค์เฉพาะบท 1. เพื่อให้นักศึกษารู้จักและเข้าใจศัพท์ เทคนิคและพื้นฐานความรู้ที่ใช้ในการทดสอบซอฟต์แวร์ 2. เพื่อให้นักศึกษาเข้าใจกระบวนการ พัฒนาซอฟต์แวร์ • บรรยาย (2 ชม.) • ศึกษาและนำเสนอกรณีตัวอย่าง (30 นาที) • Pre-Test (15 นาที) • Post-Test (15 นาที) • ศึกษาด้วยตนเอง (6 ชม.)

3. Pre-Test • ให้นักศึกษาทำ Pre-Test บทที่ 1 ลงในกระดาษที่อาจารย์ผู้สอนได้จัดเตรียมไว้ให้ ใช้เวลา 15 นาที

4. ความรู้เบื้องต้นเกี่ยวกับกระบวนการพัฒนาซอฟต์แวร์ และการทดสอบซอฟต์แวร์ 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 ศึกษากรณีตัวอย่างผลกระทบที่เกิดจากการไม่ทำการทดสอบ

5. วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) ในกระบวนการพัฒนาซอฟต์แวร์ มีแบบจำลองที่หลากหลายเพื่อใช้เป็นแบบจำลองในการพัฒนาซอฟต์แวร์ เช่น Waterfall Model , Spiral Model , Incremental Model , Agile , Scrum , XP Model , V Model , RUP Model , RAD Model ฯลฯ ซึ่งแบบจำลองเหล่านี้มีขั้นตอนต่าง ๆ ที่แตกต่างกันไปในกิจกรรมย่อยของแต่ละขั้นตอน

6. การบ้าน บทที่ 1 งานเดี่ยว (12 คะแนน) 1. ให้นักศึกษาทำการศึกษาค้นคว้าด้วยตนเองเกี่ยวกับแบบจำลองต่างๆ มาอย่างน้อย 3 แบบจำลอง พร้อมทั้งทำสรุปส่งภายในวันศุกร์ที่ 29 ตุลาคม ก่อน 16.30 น. ส่งใน E-learning • รายละเอียดกิจกรรม / ขั้นตอนของแบบจำลอง • รูปภาพแบบจำลอง • ข้อดี / ข้อเสีย ส่งช้าหักวันละ 1 คะแนน ให้ Save ชื่อไฟล์  HW1-1_รหัสนักศึกษา.docx

7. วงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) สรุปได้ว่าวงจรชีวิตการพัฒนาซอฟต์แวร์ (Software Development Life Cycle) มีขั้นตอนดังนี้ • Project planning, feasibility study: • Systems analysis, requirements definition: • Systems design: • Implementation: • Integration and testing: • System Testing • Acceptance, installation • Maintenance:

8. เอกสารที่เกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์เอกสารที่เกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์ • เอกสารใน 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)

9. เอกสารที่เกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์เอกสารที่เกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์ • Systems design: • Software Design Documentation (SDD) • Test Case (TC) • Test Script (TS) • Implementation: • Source Code (SC) • Unit Testing Report (UTR)

10. เอกสารที่เกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์เอกสารที่เกิดขึ้นในกระบวนการพัฒนาซอฟต์แวร์ • 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)

11. Why do we test? • มี 2 เหตุผลที่ต้องทดสอบซอฟต์แวร์ คือ คุณภาพ (หรือการยอมรับ) และการค้นพบปัญหา • สาเหตุที่ต้องทำการทดสอบเพราะว่ามีข้อผิดพลาด โดยเฉพาะอย่างยิ่งความเที่ยงตรงของซอฟต์แวร์ และระบบต่าง ๆ ที่ได้รับการควบคุม

12. Per The Requirements As Systems Specified It As Engineering Designed It If You Don’t Do Both …

13. As the Factory Built It As Integration Installed It What the Customer Wanted You Can Meet the Spec, But …

14. … and still not get it right. • Without Validation as part of the process, you will waste: • Time • Energy • Money • Resources

15. 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.

16. Bugs are caused for numerous reasons, but, in this sample project analysis, the main cause can be traced to the specification

17. 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.

18. 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.

19. Software tester should have: • They are explorers. • ผู้ทดสอบต้องทำตัวเป็นนักสำรวจ และไม่กลัวที่จะอยู่ในเหตุการณ์ที่เขาไม่เจอพบ และมีใจรักที่จะทดสอบซอฟต์แวร์ใหม่ ๆ • They are troubleshooters. • ผู้ทดสอบต้องเป็นนักแก้ไขปัญหา • ผู้ทดสอบที่ดีควรหาเหตุผลว่าทำไมงานนั้นถึงไม่ผ่านการทดสอบ มีสาเหตุเกิดจากอะไร

20. Software tester should have: • They are relentless. • ผู้ทดสอบต้องมีความอดทนที่จะค้นหาข้อผิดพลาด และต้องมีความพยายาม เขาจะเกิดความรู้สึกว่าปัญหาถูกคลี่คลายไปอย่างรวดเร็วหรือยากที่จะเกิดขึ้นมาอีก • บางครั้งการพบข้อผิดพลาดอาจเกิดจากความบังเอิญก็เป็นได้ • ผู้ทดสอบต้องทำทุกวิถีทางที่จะให้พบข้อผิดพลาดให้ได้

21. Software tester should have: • They are creative. • วิธีการทดสอบที่ทำอยู่นั้นหากไม่เพียงพอที่จะกำจัดข้อผิดพลาดให้ออกไปได้ ผู้ทดสอบจึงต้องมีการคิดสร้างสรรค์เพื่อหาวิธีในการหาข้อผิดพลาดหรือข้อบกพร่อง • They are (mellowed) perfectionists. • ผู้ทดสอบต้องมีความสุขุม รอบคอบ มุ่งที่จะหาข้อผิดพลาด

22. Software tester should have: • They exercise good judgment. • ผู้ทดสอบต้องมีการฝึกฝนในการตัดสินใจและใช้ดุลพินิจในการตัดสินใจเกี่ยวกับสิ่งที่เขากำลังทดสอบว่าสิ่งเหล่านั้นเป็นข้อผิดพลาดหรือข้อบกพร่องหรือไม่ • They are tactful an diplomatic. • ผู้ทดสอบต้องมีความเชี่ยวชาญ มีไหวพริบ และมีชั้นเชิง • เขาควรมีชั้นเชิงในการพูดที่จะบอก Programmer ถึงข้อผิดพลาดที่เกิดขึ้น

23. Software tester should have: • They are persuasive. • ผู้ทดสอบต้องมีความสามารถในการโน้มน้าวจิตใจ หรือสามารถเกลี้ยกล่อม • ข้อผิดพลาดหรือข้อบกพร่องที่ผู้ทดสอบพบนั้นอาจจะไม่รุนแรง หรือไม่ส่งผลกระทบที่จะทำให้ระบบเสียหาย ดังนั้นผู้ทดสอบต้องแสดงให้เห็นว่าเพราะเหตุใด • หรือข้อผิดพลาดหรือข้อบกพร่องนั้นสมควรที่ต้องได้รับการแก้ไข ( Fixed) ผู้ทดสอบต้องแสดงให้ทีมเห็นว่าเพราะอะไรข้อผิดพลาดหรือข้อบกพร่องนี้ควรได้รับการแก้ไข (Fixed)

24. ทีมการทดสอบซอฟต์แวร์ (Software Testing Teams) • Software Customers • Those who contract for the software to be developed • Software Users • Those who will use the software

25. ทีมการทดสอบซอฟต์แวร์ (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

26. ทีมการทดสอบซอฟต์แวร์ (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.

27. ทีมการทดสอบซอฟต์แวร์ (Software Testing Teams) • Project manager • The individual responsible for managing the building, maintaining, and/or implementing of software.

28. 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.

29. The cost to fix bugs can increase dramatically over time.

30. Software Verification and Validation

31. Software Verification • Verification helps answer the question “Are we building the product right?” • Verificationactivities are defined around three basic processes: inspection, measurement, and configuration management. • เราได้สร้างระบบอย่างถูกต้องหรือไม่ • ซอฟต์แวร์ที่พัฒนาตรงกับข้อกำหนดที่ระบุไว้หรือไม่

32. 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?” • เราได้สร้างระบบที่ถูกต้องหรือไม่ • ซอฟต์แวร์ที่พัฒนาตรงกับความต้องการหรือไม่

34. คำศัพท์ที่เกี่ยวข้อง (Terminologies) • Software Testing (การทดสอบซอฟต์แวร์) • เป็นกิจกรรมที่จัดทำขึ้นเพื่อประเมินและปรับปรุงคุณภาพของซอฟต์แวร์ โดยการตรวจหาข้อผิดพลาดและปัญหาที่เกิดขึ้น แล้วทำการแก้ไขข้อผิดพลาดหรือปัญหาดังกล่าวให้ถูกต้อง [IEEE, 2004] วัตถุประสงค์ของการทดสอบซอฟต์แวร์ ก็เพื่อพิสูจน์ว่าซอฟต์แวร์ทำงานได้ครบทุกฟังก์ชันตามข้อกำหนดความต้องการ และตรวจสอบว่าแต่ละฟังก์ชันสามารถประมวลผลข้อมูลได้อย่างถูกต้อง

35. คำศัพท์ที่เกี่ยวข้อง (Terminologies) • Errors (ความผิดพลาด) • คนทำผิด หรือเกิดจากการเข้าใจความหมายในเอกสารผิดก็จะทำให้การเขียน Code ผิดไปด้วย ซึ่งเรียกข้อผิดพลาดนี้ว่าความผิดพลาดที่ทำให้เกิด Bug ความผิดพลาดจากความต้องการ (Requirement) อาจขยายความผิดพลาดไปยังการออกแบบ (Design) และ Code

36. คำศัพท์ที่เกี่ยวข้อง (Terminologies) • Fault(ความคลาดเคลื่อน) • ความคลาดเคลื่อนเป็นผลมาจากความผิดพลาด (Error) ที่นำเสนอไดอะแกรม narrative text, dataflow diagrams, hierarchy charts, source code และอื่น ๆ ความคลาดเคลื่อนที่ยากจะเข้าใจ เมื่อผู้ออกแบบ (Designer) ละเลยข้อผิดพลาด ผลของความคลาดเคลื่อนที่เกิดขึ้น อาจเกิดจากการขาดหาย (Missing) ที่ควรนำเสนอ • อาจเกิดจากข้อมูลในเอกสารขาดหาย ตกหล่น • Failure (ความล้มเหลว) • ความล้มเหลว เกิดขึ้นเมื่อเกิด Fault • ก่อให้เกิดความเสียหายต่อตัวทำงานระบบ มีผลในทางลบต่อผู้ใช้และลูกค้า

37. คำศัพท์ที่เกี่ยวข้อง (Terminologies) • Bugs • จะพบได้ตอน Coding • Crashes • มีผลกระทบทำให้ระบบล่ม / พัง ใช้ไม่ได้ • Indicant (เหตุการณ์) • เหตุการณ์ที่เกิดขึ้นที่เกี่ยวข้องกับความล้มเหลวโดยมีการแจ้งเตือนให้ผู้ใช้ทราบว่าเกิด Failure • Defects (ข้อบกพร่อง) • เป็นข้อบกพร่องที่พบก่อนการ Coding • Missing / Wrong / Extra

38. What are you test for? • A defectis 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

39. กรณีตัวอย่างผลกระทบที่เกิดขึ้นกรณีตัวอย่างผลกระทบที่เกิดขึ้น 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.

40. ศึกษากรณีตัวอย่างผลกระทบที่เกิดขึ้นศึกษากรณีตัวอย่างผลกระทบที่เกิดขึ้น กิจกรรมในชั้นเรียนใช้เวลา 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

41. Questions & Answers

42. “What we anticipate seldom occurs; what we least expected generally happens.” - Benjamin Disraeli “สิ่งที่เราคาดคิด จะไม่ค่อยเกิดขึ้น สิ่งที่เราคาดไม่ถึงส่วนใหญ่ก็จะเกิดขึ้น”

43. Post-Test (10 คะแนน) • ให้นักศึกษาทำ Post-Test บทที่ 1 ลงในกระดาษที่อาจารย์ผู้สอนได้จัดเตรียมไว้ให้ ใช้เวลา 15 นาที

44. การศึกษาด้วยตนเอง • เพื่อการเตรียมตัวเรียนในบทที่ 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 น.