งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

1 Test Methodology. 2 Test Process Role and Responsibility V Model Test Technique Test Type Test Flow Documents Test Tool AGENDA.

งานนำเสนอที่คล้ายกัน


งานนำเสนอเรื่อง: "1 Test Methodology. 2 Test Process Role and Responsibility V Model Test Technique Test Type Test Flow Documents Test Tool AGENDA."— ใบสำเนางานนำเสนอ:

1 1 Test Methodology

2 2 Test Process Role and Responsibility V Model Test Technique Test Type Test Flow Documents Test Tool AGENDA

3 3 การ Test คืออะไร การ Test คือกระบวนการทดสอบระบบว่าสามารถทำงานได้อย่างถูกต้อง ได้ผลลัพธ์ตรงกับความ ต้องการของ User หรือไม่ โดยจะต้องทดสอบให้ครอบคลุมทุกๆ Business Requirement และ จะต้องไม่เกิดข้อผิดพลาด (Error) ต่างๆ ขึ้น เมื่อ User นำระบบไปใช้งาน นิยาม "การทดสอบโปรแกรม ทำขึ้นเพื่อลดความเสี่ยงที่จะเกิดความผิดพลาดขึ้นกับโปรแกรมก่อนจะถึงมือ ผู้ใช้“ กระบวนการTest มีความสำคัญอย่างไรต่อองค์กร เนื่องจาก Error จะเกิดขึ้นตลอดเวลา ทุกๆ Phase ของการพัฒนา Application ตั้งแต่ requirement analysis, design and build ระดับความรุนแรงของ Error จะแตกต่างกันออกไป ซึ่ง จะก่อให้เกิดความเสียหายต่อองค์กร ดังนั้นจึงต้องมีกระบวนการ Test ขึ้นมาเพื่อตรวจสอบระบบ ทำ ให้ระบบมีคุณภาพ (Quality) มากยิ่งขึ้น และลดความเสี่ยง (Risk) ที่จะเกิด Error (bug) ลง จนทำ ให้ % ในการเกิด error = 0% แต่ในความเป็นจริงแล้ว % error จะเป็น 0% นั้นเป็นไปได้ยากมาก ดังนั้นในการทำงานจริง จะต้อง มีการจัด priority ของ Case ต่างๆ ว่า Case ไหนจำเป็นที่จะต้องกำจัด error ไม่ให้เกิดขึ้น ถ้าเกิด error ประเภทนี้ขึ้นแล้วจะก่อให้เกิดผลเสียต่อองค์กรมาก ก็จะถูกจัดไว้เป็น Priority แรกๆ Case เหล่านี้จะถูกเรียกว่า Critical Case TEST PROCESS

4 4 อะไรคือข้อจำกัดของการทดสอบระบบ (Limitation of testing) >> Knowledge >> Time >> Resource (Human, Software, Hardware) >> Unlimited Change Requirement (not good) เมื่อไหร่จึงจะหยุดทำการทดสอบระบบ (when to stop testing) >> Meet Objective – ทดสอบจนครบวัตถุประสงค์ที่ได้ Plan เอาไว้ >> Exit Criteria – หยุดทดสอบเมื่อเงื่อนไขต่างๆ ครบตามที่ระบุไว้ใน exit criteria TEST PROCESS (CONT)

5 5 ในมุมมองของ Programmer และ Tester จะมีแนวความคิด (View) ที่แตกต่างกันใน เรื่องของการ Test ตัวอย่างเช่น TEST PROCESS (CONT) ProgrammerTester Test only coding, not test in business viewNeed to test in business view Test only code that their changeTest integration flow and possible error occur, need to be test Testing is no need for a little bit code change, not impact other (ถ้ามีการแก้ไขเล็กๆน้อยๆ จะ ไม่สนใจทำการทดสอบ และจะไม่ดูว่ามีผลกระทบ กับส่วนอื่นๆ หรือไม่) Every change need to be test, and not change impact area need to be test (Test ทั้งที่มีการแก้ไขและไม่มีการแก้ไข) Make data to test, no need data from other system Positive and Negative case need to be test

6 6 Test Process (cont) Test Planning Test Planning Requirement Analysis Requirement Analysis Create Test Scenario Create Test Case Create Test Case Review Test Case Review Test Case Cover all requirements? Create test coverage matrix Create test coverage matrix Test Environment Set up Test Environment Set up Run Test Case Record Defect Log Record Defect Log Record Test Result Record Test Result Analyze Defect Execute PASS? Create. Summary Test Report Create. Summary Test Report YES NO YES NO Test Planning ประกอบด้วย - Test strategy หมายถึงการกำหนดวิธีการทดสอบให้เหมาะสมกับ Application หรือ ระบบที่เราจะทำการทดสอบ ว่าควรจะมีการทดสอบแบบ ใดบ้าง - Test schedule หมายถึง Task งานต่างๆ ที่สามารถแตกแยกย่อยออกมา และระบุวันในการทดสอบได้ - Test Resource หมายถึง Resource ต่างๆ ที่จะต้องใช้ในการทดสอบ ไม่ว่าจะเป็น Human, S/W, H/W หรือ Time Test Creation Test Execution Create Test data Create Test data Test Preparation

7 7 ROLE AND RESPONSIBILITY TASKWork ProductResponse By Test PlanningTest PlanTest Leader / QA Requirement AnalysisTest Design or Test Specification Test Leader / QA Test CreationTest Scenario Test Case / Test Script Test coverage matrix Test Leader / QA Test PreparationEnvironment set up Check listTester Test ExecutionDefect Log Test Result Summary Test Report Tester / Developer / DBA

8 8 V MODEL

9 9 V Model เป็น Methodology ที่ไว้สำหรับตรวจสอบคุณภาพของระบบ ซึ่งจะมี Stage ต่างๆ ของการ Test คอย validate & verify ตั้งแต่เริ่มต้น Requirement จนถึง phase สุดท้ายของการพัฒนาระบบ Left side “V” จะเป็น activity ของ Analysis Requirement and Design เมื่อเสร็จ สิ้นการ Design แล้ว กระบวนการ Build จะเริ่มต้นขึ้น Right side “V” จะเป็น Testing activity ซึ่งจะเริ่มต้นขึ้นหลังจาก Build เสร็จ ในช่วง แรกของการทดสอบ จะ focus เฉพาะ individual component หลังจากนั้นจะ เปลี่ยนเป็น focus ในเรื่องของ Functional, non-functional ให้ตรงกับ Business Requirement ความหมาย Verification and Validation Verification  is the process confirming that something meets its specification  “Do we build the system right?” Validation  is the process confirming that it meets the user’s requirements  “Do we build the right software?” V MODEL (CONT)

10 10 คุณภาพของ Software สามารถแสดงออกมาในรูปแบบของสามเหลี่ยม ซึ่งในแต่ละมุมจะแทนด้วย User requirement, software, Requirements Specification Software quality triangle Software Requirement Specification User Requirement Gap

11 11 1. User requirements – Requirements specification Gap ช่องว่างนี้เกิดขึ้นมาจาก Developer ไม่เข้าใจ Requirement ของ User ซึ่งอาจจะเนื่องมาจากสาเหตุ ดังนี้  Misunderstood requirements  Ignored requirements  Missing requirements  Outdated requirements  Unneeded requirements 2. Requirements specification - Software Gap ช่องว่างนี้เกิดขึ้นมาจากการพัฒนา Software ไม่ตรงตาม Requirement specification ซึ่งอาจจะเกิด มาจากสาเหตุดังนี้  Requirement not identified in the specification  Changes to requirements identified after development commenced  Wrong interpretation of requirement due to vagueness and ambiguity in the specification  Features added by the developers to exploit technical opportunities  Features removed by the developers because they were too difficult to implement Software quality triangle (cont)

12 12 3. Software – User requirements Gap ช่องว่างนี้เกิดขึ้นมาจาก Software ที่พัฒนาขึ้นมาไม่ตรงกับ Requirement ที่ได้มาจาก User ซึ่ง อาจจะต้อง re-work เพื่อแก้ไขให้ software เป็นไปตามที่ user ต้องการ  Shapes of Software Quality Triangles ช่องว่างทั้ง 3 แบบ ทำให้เกิด Quality Triangle ที่แตกต่างกันออกไป ดังนี้ Software quality triangle (cont) - SA Poor understanding of user requirements - Corrected during software development - Software meets user requirements (software ที่พัฒนาออกมาดี อาจจะเนื่องมาจาก Developer มี ประสบการณ์จึงเขียน software ออกมาใช้งานได้ดี) Software

13 13 Software quality triangle (cont) - SA,DEV Poor understanding of user requirements - Good software development - Software does not meets user requirements (Developer พัฒนา Software ได้ดี เข้าใจ Requirement Spec. เป็น อย่างดี แต่ Software ที่ได้ไม่ตรงกับความต้องการของ User) - SA Good understanding of user requirements - Poor software development - Software does not meets user requirements (Developer มีความเข้าใจ Requirement น้อย ทำให้สร้าง Software ไม่ตรงกับ Requirement) - Poor understanding of user requirements - Poor software development - Software does not meets user requirements (เป็นรูปแบบที่แย่ที่สุด เนื่องจากแต่ละส่วนไม่มีความเข้าใจกัน) Software Better alignment

14 14 Test Technique Software Requirement Specification User Requirement Internal Quality White Box Black Box External Quality

15 15 Black Box Testing >> ไม่ต้องมีความรู้เรื่องของระบบว่ามีการออกแบบหรือเขียน Code อย่างไร >> สนใจเฉพาะว่าระบบมี Function การทำงานอย่างไร และจะได้ output ออกมาเป็นอะไรบ้าง สำหรับ Technique ต่างๆ ที่ใช้ในการทดสอบแบบ Black box testing นั้นมี หลายวิธี แต่จะขอยกตัวอย่างที่รู้จักกันดีคือ Equivalence partitioning เป็นการกำหนดค่าตัวแทน ของกลุ่มข้อมูลขึ้นมา 1 ค่า แล้วนำค่านั้นมาใช้ในการทดสอบ ซึ่งจะ สามารถ Apply ได้ว่าถ้าใช้ค่าตัวแทนนี้มาทำการทดสอบได้ผลลัพธ์อย่างไร ค่าอื่นๆ ที่อยู่ภายใต้กลุ่ม นี้ ก็จะมีผลลัพธ์เช่นเดียวกัน เช่น ระบบธนาคารสามารถให้โอนเงินผ่าน ATM ขั้นต่ำคือ 100 และสูงสุดคือ 500 บาท การทดสอบจะต้องกำหนดตัวแทนของกลุ่มของข้อมูลที่จะต้องนำมาทดสอบ ตัวอย่างเช่น TEST TECHNIQUE

16 16 Black Box Testing กรณีโอนเงิน 50 บาท (เป็นตัวแทนของกลุ่มที่ < 100 ) กรณีโอนเงิน 200 บาท (เป็นตัวแทนของกลุ่มที่อยู่ระหว่าง ) กรณีโอนเงิน 1000 บาท (เป็นตัวแทนของกลุ่มที่ > 500 ) เพราะฉะนั้นจะได้ชุดของข้อมูลมาสามชุด และได้ data มาทดสอบ 3 ค่าเท่านั้น Boundary value analysis เป็นวิธีการทดสอบโดยกำหนดขอบเขตของข้อมูลขึ้นมา เพื่อจะได้ค่า input data ที่ครอบคลุม เช่น ระบบธนาคารสามารถให้โอนเงินผ่าน ATM ขั้นต่ำคือ 100 และสูงสุดคือ 500 บาท การทดสอบจะต้องกำหนดขอบเขตของข้อมูลที่จะต้องนำมาทดสอบ ตัวอย่างเช่น กรณีโอนเงิน 99 บาท กรณีโอนเงิน 100 บาท กรณีโอนเงิน 101 บาท กรณีโอนเงิน 499 บาท กรณีโอนเงิน 500 บาท กรณีโอนเงิน 501 บาท TEST TECHNIQUE (CONT)

17 17 White Box Testing >> ต้องมีความรู้เรื่องของระบบว่ามีการออกแบบอย่างไร ทำงานอย่างไร >> ต้องมีความรู้ในเรื่องของ Programming ขอยกตัวอย่าง Technique ของ white box testing ดังนี้ Statement Coverage  เหมาะกับทำในระดับ Unit Test  ทุกบรรทัดหรือทุกๆ Statement จะต้องทำการทดสอบรวมถึงส่วนที่เป็น exception error ด้วย  ใช้เวลา Test นานกว่า Technique อื่นๆ Branch Coverage  เน้นไปที่การทดสอบ case ครบทุกๆ case ที่มีการตัดสินใจในโปรแกรม  ใช้เวลาเร็วกว่า statement testing  ในการตัดสินใจนั้นๆ อาจจะมี เงื่อนไขอื่นๆ เช่น or หรือ and เข้ามาเกี่ยวข้องในการตัดสินใจนั้นๆก็ได้ TEST TECHNIQUE

18 18 ประเภทของการทดสอบ Program จะแบ่งได้เป็น 2 ประเภท ดังนี้ Functional Test  ใช้ Technique การ Test แบบ Black box  Functional Test จะทำการทดสอบโดย Tester  เป็นการทดสอบว่าระบบทำอะไร “What” a system does Non-Functional Test  เป็นการทดสอบว่าระบบทำงานดีอย่างไร “How well” the system works  ส่วนใหญ่จะเป็นการทดสอบในเรื่องการ verify capacity, reliability ของระบบ ทั้ง H/W และ S/W เช่น Performance Test, Reliability Test เป็นต้น  ตัวอย่างของ Non-function Test ได้แก่ Performance Test Reliability Usability Load Test Stress Test TEST TYPE

19 19 Level ของการทดสอบ จะถูกกำหนดไว้ใน Test Planning ในส่วนของ Test Strategy เพื่อเป็น แนวทางว่าควรจะใช้การ Test แบบใดให้เหมาะสมกับ Program และ Requirement ของ user Level of Testing จะประกอบด้วย Unit test(white box & black box testing technique) Integration Test (For small size) System Test Functional Non-Functional Test  Performance Test  Load Test  Stress Test  Security Test  Reliability / Availability Test  Disaster & Recovery Test (data backup & data recovery Test)  Horizontal Scalable System Integration Test (SIT – For large size) End to End Test (E2E) Regression Test User Acceptance Test (UAT) Alpha (in-house test) Beta LEVEL OF TESTING (cont)

20 20 สำหรับการทำ Performance Testing จะขึ้นอยู่กับความเหมาะสมและ Requirement ว่า ต้องการจะวัดคุณภาพหรือประสิทธิภาพในเรื่องใด ซึ่งจะต้องมีข้อมูลต่างๆ เหล่านี้ เช่น objectives of performance testing problems in performance testing Understand measurement in performance test Able to select types of performance test appropriately LEVEL OF TESTING (cont)

21 21 Unit Test จุดประสงค์ เพื่อตรวจสอบผลการทำงานของ module ย่อยทั้งหมดของระบบ เปรียบเทียบ กับสิ่งที่ design ไว้ ว่ามีความแตกต่างกันหรือไม่ Response by : Programmer Skill:Programming skill, Internal program design Test technique:Black box and White box Test environment:Develop environment Integration Test จุดประสงค์ เพื่อตรวจสอบความถูกต้องของ Function การทำงานต่างๆ เมื่อมีการ Integrate unit / module เข้าร่วมกัน โดยจะให้ความสำคัญในส่วนของการ Interface ระหว่างกันว่าสามารถใช้งาน ร่วมกันได้หรือไม่ ซึ่งอาจจะอยู่ในรูปแบบ Client/Server และ distributed system Response by : Programmer, Tester or QA Skill:Programming skill, Testing skill Test technique:Black box and White box Test environment:Develop environment and Test environment LEVEL OF TESTING (cont)

22 22 System Test จุดประสงค์ เพื่อ Verify ระบบว่าระบบทำงานได้ถูกต้องและได้ผลลัพธ์ตรงตาม Requirement โดย จะทำการทดสอบแบบ Functional และ Non-Functional Test ขึ้นอยู่กับว่าแบบใดจะเหมาะสมกับ Requirement ของ User Response by : Tester or QA Skill:Testing skill Test technique:Black box Test environment:Test environment System Integration Test จุดประสงค์ เพื่อ Verify ว่าระบบต่างๆ สามารถทำงานร่วมกันได้อย่างถูกต้อง ตรงตามวัตถุประสงค์ และ Requirement ที่มี โดยจะ verify ทั้ง Network integration และ Product integration ซึ่งจะ รวมไปถึง Infrastructure ของระบบ เช่น Operating system, file system, hardware, middleware, network configuration Response by : Tester or QA Skill:Testing skill Test technique:Black box Test environment:Test environment LEVEL OF TESTING (cont)

23 23 Regression Test จุดประสงค์ ทำการทดสอบเพื่อดูว่าการเปลี่ยนแปลง (change) ในจุดหนึ่ง จะไปกระทบกับส่วนอื่นๆ ที่ไม่ได้ทำการเปลี่ยนแปลงหรือไม่ ซึ่ง Regression test นั้นจะเป็นการทดสอบทั้งระบบอีกครั้งหนึ่ง เป็นการ Test ซ้ำกับ Case เดิมที่เคย Test ไปแล้ว เพื่อที่จะได้ verify ได้ว่า Function เดิม ยังใช้ งานได้อยู่ เช่น  กรณีที่มีการแก้ไข Function กลางที่ใช้งานร่วมกันของระบบ จำเป็นจะต้องทำการทดสอบใหม่ทั้งหมด เพื่อดูว่าการแก้ไข function กลางจะไปมีผลกระทบกับส่วนอื่นๆ หรือไม่  หรือกรณีที่ มีการ Upgrade software จาก oracle8i เป็น oracle10g ในกรณีนี้จะต้องทำการทดสอบ Application ใหม่ทั้งหมด เพื่อที่จะ verify ให้ได้ว่าเมื่อ upgrade oracle แล้วจะไม่มีผลกระทบใดๆ ต่อ application เดิม Response by : Tester / QA Skill:Testing skill Test technique:Black box Test environment:Test environment ** จะทำการทดสอบก็ต่อเมื่อมี Requirement แจ้งมาว่าให้ทำการทดสอบใหม่ทั้งระบบ LEVEL OF TESTING (cont)

24 24 User Acceptance Test จุดประสงค์ เพื่อ Confirm business requirement กับ User โดย Verify และ Validate ว่าระบบ ทำงานได้ถูกต้องและได้ผลลัพธ์ตรงตาม Requirement โดยจะต้องทำการทดสอบบน environment ที่เสมือนจริง (production) และจะใช้ข้อมูลจริงในการทดสอบ  ALPHA : on developer site เป็นการทดสอบแบบ in-house โดยจะให้ User เป็นคนทดสอบระบบ พร้อมกับจะมี Tester/ QA เป็นคนแนะนำ  BETA : on customer site เป็นการทดสอบโดย User สามารถทำการทดสอบได้เองบน environment ที่จัดเตรียมไว้ให้ หรือสามารถนำ software กลับไปทดสอบเองได้ และถ้าเจอ Error ก็สามารถแจ้งให้ Developer ทำการแก้ไข Response by : User Skill:Testing skill Test technique:Black box Test environment:Test environment (Realistic & Representative) LEVEL OF TESTING (cont)

25 25 Load Test จุดประสงค์ เพื่อทำการทดสอบ performance ของเครื่องในเรื่องของ Time ว่าในเวลาหนึ่งๆ ต่อ จำนวน Transaction ที่ส่งเข้าไปพร้อมๆ กันในระบบ จะมี Response time เป็นไปตาม Business Requirement ของ User หรือไม่ ซึ่งสามารถแยกได้เป็น 2 ข้อ คือ - Response time : The end to end response time associated with a specific user- system interaction - Throughput : The ability of the business system to execute a given number of businesses or system related processes within a given unit of time Response by : Tester / QA Skill:Testing skill specify performance testing Test technique:Black box Test environment:Test environment (Realistic & Representative) Test tool: >> Load Runner (สำหรับ Web application or windows application) สามารถ จำลอง Request เป็น Time Interval ได้คือ ให้เริ่มจาก load น้อยๆ ไปหา load มากๆ แล้วกลับมาน้อยใหม่ เพื่อดูเรื่องการคืน Memory ของตัวระบบ >> Script ต่างๆ เช่น unix shell script (สำหรับงาน Process) LEVEL OF TESTING (cont)

26 26 Stress Test จุดประสงค์ เพื่อทำการทดสอบ Capacity ของเครื่องว่ามี limitation ในการรองรับปริมาณข้อมูลได้ มากที่สุดเท่าไหร่ จนกว่าเครื่องจะ down Response by : Tester / QA / Developer Skill:Testing skill specify performance testing Test technique:Black box Test environment:Test environment (same as production environment) LEVEL OF TESTING (cont)

27 27 Security Test (Non-functional) จุดประสงค์ เพื่อทำการทดสอบว่าระบบมีความปลอดภัยมากเพียงพอ ที่บุคคลภายนอกไม่สามารถ hack เข้ามาดึงข้อมูลของลูกค้าได้ สำหรับวิธีในการป้องกันระบบจากบุคคลภายนอก มีได้หลายวิธี ตัวอย่างเช่น Password rules (Single sign on, LDAP) Access rights (user roles, file system security) Set time outs Response by : Tester / QA / Developer Skill:Testing skill, network security, programming skill Test technique:Black box Test environment:Test environment (Realistic & Representative) LEVEL OF TESTING (cont)

28 28 Availability & Reliability test จุดประสงค์ 1. เพื่อทำการทดสอบว่าระบบสามารถทำงานได้ตลอดเวลา โดยไม่เกิดปัญหาขึ้น 2. เพื่อทำการทดสอบความน่าเชื่อถือของระบบ เช่นกรณีที่ระบบ down ไป ก็สามารถที่จะกู้กลับคืน มาได้ โดยข้อมูลทุกอย่างยังถูกต้อง สำหรับวิธีในการทดสอบจะยกตัวอย่าง 2 แบบคือ Disaster & Recovery Test (data backup & data recovery Test)  Data Backup To perform regular and ad-hoc back-ups as part of normal operational life- cycle and perform backups of data prior to, or during batch processing.  Data Recovery Backed up data can be re-loaded and the system fully restored to the back- up point without loss or corruption of data. Recovery data at each commit point within an on-line transaction process without corruption of existing data. To verify maximum recovery time (SLA) Rollback data entry or batch process without corruption or loss of data ** ถ้าระบบไม่มี requirement ในส่วนนี้ ก็ไม่จำเป็นต้องทำการทดสอบ LEVEL OF TESTING (cont)

29 29 Availability & Reliability test (cont) Horizontal Scalable หมายถึง เมื่อระบบมีการใช้งานมากขึ้น และเครื่องที่มีอยู่เริ่มรับ request ไม่ไหว คือเริ่ม มี response time ที่ช้าลง ก็ควรจะทำการ upgrade ระบบให้รับ request ได้มากขึ้น ซึ่งทำ ได้ 2 วิธีคือเลือกที่จะเพิ่ม CPU เพิ่ม Ram หรือเลือกที่จะเพิ่มเครื่องแทน (Load Balance) การทดสอบจะต้องรู้ spec ของ hardware ต่างๆ ที่ใช้งานอยู่ ที่ต้องการจะเพิ่ม CPU หรือ RAM หรือ เครื่องใหม่ เพื่อที่จะได้เตรียมอุปกรณ์ต่างๆ ได้ถูกต้องและเหมาะสมเพื่อพร้อมต่อการ ทดสอบ Response by : Developer / DBA Skill:Technical skill Test technique:Black box Test environment:Test environment (same as production environment) ** ถ้าระบบไม่มี requirement ในส่วนนี้ ก็ไม่จำเป็นต้องทำการทดสอบ LEVEL OF TESTING (cont)

30 30 Test FLOW Unit Test Integra tion Test System Test * SIT UAT PRODUCTIONPRODUCTION * Performance Test * Regressi on Test * Security Test * Disaster & Recovery Test * Horizontal Scalable Test * Means optional testing stage

31 31 Documents (cont) แผนผังการจัดทำเอกสารที่เกี่ยวข้องกับกระบวนการทดสอบ Test Planning Test Specification / Test Design Test Case/ Test Script Requirement traceability matrix Test Result Defect Log Test Summary Report Integration Test Test Case/ Test Script Requirement traceability matrix Test Result Defect Log Test Summary Report System Test Test Case/ Test Script Requirement traceability matrix Test Result Defect Log Test Summary Report System Integration Test

32 32 Documents Input Document  Requirement (มีชื่อเรียกที่แตกต่างกันในแต่ละองค์กร เช่น Project Proposal, High Level Architecture Design etc.)  Program Specification (มีชื่อเรียกที่แตกต่างกันในแต่ละองค์กร Software Requirement Specification, Program Specification, Functional Specification etc.)  Work flow process Output Document (deliverable document)  Test Plan  Test Specification / Test Design*  Test Scenario  Test Case / Test Script  Requirement traceability matrix  Test Summary Report *  Defect Log  Test Result * Optional document

33 33 Documents (cont) ตัวอย่าง Requirement Document

34 34 Documents (cont) ตัวอย่าง Program specification Document

35 35 Documents (cont) ตัวอย่าง Work Flow Process

36 36 Documents (cont) Output (Deliverable Document) ขั้นตอนต่างๆ ในการทำเอกสารสำหรับ Test Phase จะเริ่มต้นตั้งแต่การทำ Requirement Analysis จนถึงกระบวนการ Build ระบบ ซึ่งเอกสารที่จะกล่าวถึงจะมีดังนี้ Test Planning เป็นเอกสารที่จัดทำขึ้นเพื่อไว้สำหรับเป็นแนวทางในการทดสอบเป็นมุมมองแบบ High Level โดยจะ มีการกำหนด objective ในการทดสอบ, การกำหนด Test strategy ต่างๆ, การกำหนด Role & Responsibility โดยใน Test Plan ประกอบด้วยหัวข้อที่สำคัญดังนี้  Test strategy หมายถึงการกำหนดวิธีการทดสอบให้เหมาะสมกับ Application หรือ ระบบที่เราจะทำ การทดสอบ ว่าควรจะมีการทดสอบแบบใดบ้าง เช่น >> ระบบ A เป็นระบบงานที่มีขนาดเล็ก ไม่มี Interface ติดต่อกับระบบงานอื่นๆ จะต้องทำการ ทดสอบ เริ่มตั้งแต่ Unit test -> Integration Test (ภายใน module ตัวเอง) -> System Test -> UAT >> ระบบ B เป็นระบบงานธนาคาร มี Interface ติดต่อกับองค์กรภายนอก และต้องรองรับปริมาณ Transaction ที่เข้ามาในแต่ละวันเป็นจำนวนมาก ก็จะทำการทดสอบเริ่มตั้งแต่ Unit test -> Integration Test (ภายใน module ตัวเอง) -> System Test -> System Integration Test (SIT) - >Regression Test -> UAT และจะต้องทำการทดสอบในส่วนของ Non-Functional เพิ่มเติมคือ Performance Test, Security Test, Disaster& Recovery Test, Scalable Test และ Test แบบอื่นๆ ที่เหมาะสมและครอบคลุมกับ Business Requirement  Test schedule หมายถึง Task งานต่างๆ ที่สามารถแตกแยกย่อยออกมา และระบุวันในการทดสอบได้  Test Resource หมายถึง Resource ต่างๆ ที่จะต้องใช้ในการทดสอบ ไม่ว่าจะเป็น Human, S/W, H/W หรือ Time

37 37 Documents (cont) จาก Test Plan สามารถแตกออกมาเป็น Element ต่างๆ เพื่อให้เห็นรายละเอียดได้ดังนี้  S [Scope] : What to test (In scope), what not to test (Out scope)  P [People] : Training, Responsibility, Schedule  A [Approach] : To testing  C [Criteria] : Entry / Exit Criteria  E [Environment] : Environment needs  D [Deliverables] : Deliverables as part of test process  I [Incidentals] : Introduction, Identification  R [Risks] : Risks and Contingencies  T [Tasks] : Tasks involves in testing

38 38 Documents (cont) ตัวอย่าง Test Planning Document Test Strategy Test Scheduling

39 39 Documents (cont) ตัวอย่าง Test Planning Document ตัวอย่าง Entry Criteria & Exit Criteria ในแต่ละ Test Level

40 40 Documents (cont) Test Design / Test specification เป็นเอกสารที่จัดทำขึ้นเพื่อแสดงรายละเอียดของ Test condition ที่จะนำไปใช้ Run Test รวมถึง ระบุถึง Input data แบบคร่าวๆ ที่ใช้ในการทดสอบ โดยจะยังไม่ได้เฉพาะเจาะจงลงไป ถ้าจะ กล่าวถึง Input data แบบเจาะจง จะไปอยู่ในเอกสาร Test Case Test Design/ Test specification จะถูกเขียนขึ้นในภาพรวมของแต่ละ Test phase ซึ่งจะมีความใกล้เคียงกับ Test Plan เพียงแต่ว่าจะเฉพาะเจาะจงลงไปในแต่ละ phase ของการ Test มากกว่า

41 41 Documents (cont) Test Scenario เป็นเอกสารที่จัดทำขึ้นเพื่อร้อยเรียง flow ต่างๆของระบบเข้าไว้ด้วยกัน เหมือนเรียบเรียงไว้เป็น storyboard เพื่อเอาไว้ใช้สำหรับแตกออกมาเป็น Test Case ในขั้นตอนต่อไป โดยจะบอกใน ภาพรวมว่า การจะเกิดรายการขึ้นมาได้ 1 รายการนั้น จะต้องผ่านขั้นตอนตั้งแต่เริ่มต้น จนกระทั่ง สิ้นสุด อย่างไร ตัวอย่าง Test Scenario

42 42 Documents (cont) Environment Set up Test Check list เป็นเอกสารที่จัดทำขึ้นเป็น Check list เพื่อไว้สำหรับตรวจสอบว่าการ Set up / config environment ต่างๆ ครบถ้วน เป็นไปตาม List ที่ได้ทำไว้ ตัวอย่าง Environment Set up Test Check list

43 43 Documents (cont) Environment Set up Test Check list ตัวอย่าง Environment Set up Test Check list

44 44 Documents (cont) Test Case / Test Script เป็นเอกสารที่จัดทำขึ้นเพื่อไว้สำหรับใช้ในการทดสอบระบบ โดยหลักการทำ Test Case อย่างง่าย ที่สุดนั้น จะต้องอยู่บนพื้นฐานของ Business Requirement และวัตถุประสงค์ของระบบ ในเอกสารจะ ระบุถึง Step / procedure รวมถึงวิธีการ Set up อย่างละเอียด เพื่อที่ผู้ที่ Run Test ตาม Test Case จะสามารถทำตามได้ง่าย หลักการของการคิด Test Case จะต้องคำนึงถึง  Negative Case / Invalid Case  Positive Case / Valid Case ในส่วนของเอกสาร Test Case จะต้องประกอบไปด้วย  ชื่อ Test Case โดยปกติแล้วจะตั้งชื่อให้สื่อ เช่น การ login เข้าระบบ  คำอธิบาย Case ต่างๆ ว่าต้องการ Test กรณีใดบ้าง  Expected Result (ผลลัพธ์ที่คาดหวังว่าจะได้ออกมา ซึ่งจะต้องตรงกับ Requirement)  ข้อมูล Input ที่จะใช้ทดสอบใน Case ต่างๆ  Step ในการทดสอบ  Actual Result (ผลลัพธ์ที่ได้จาก Program)  Test Result เพื่อระบุว่า Test case ข้อนี้ PASS หรือ FAIL

45 45 Documents (cont) ตัวอย่าง Test Case

46 46 Documents (cont) Test Coverage Matrix เป็นเอกสารที่จัดทำขึ้นเพื่อให้แน่ใจว่า ทุก ๆ Business requirement ได้มี Test case control เอาไว้แล้ว เพื่อที่จะไม่ตกหล่น Requirement ใดไป เอกสาร Test Coverage Matrix มีหลายรูปแบบขึ้นอยู่กับความถนัดของผู้ใช้งาน ตัวอย่าง Test Coverage Matrix

47 47 Documents (cont) Test Result มีอยู่หลายแบบ บางครั้งก็จัดทำเป็นเอกสารแยกออกมาอีกชุดหนึ่ง แต่ส่วนใหญ่จะนิยมนำ Test Result ไว้เป็นส่วนหนึ่งในเอกสารTest Case เพื่อลดความซ้ำซ้อนในการทำเอกสาร ตัวอย่าง Test Result

48 48 Documents (cont) Defect Log ไว้บันทึกผลการทดสอบกรณีที่เจอ Error (bug) ตาม Test Case ที่ได้ทำไว้ และเพื่อส่งเอกสารฉบับ นี้ให้กับ SA/ Developer ทำการ analyze และดำเนินการ fix bug ในขั้นตอนต่อไป ในการบันทึก Defect จะต้องใส่ severity (ระดับความรุนแรงของ Error) ด้วย ซึ่งในส่วนนี้จะต้องเป็น ข้อตกลงร่วมกันระหว่างทุกคนที่อยู่ในทีมงานของ Project นั้นๆ ว่า จะจัด Error ต่างๆ ไว้ที่ระดับ ใดบ้าง โดยในแต่ละระดับก็จะมีนิยามที่แตกต่างกัน ตัวอย่างเช่นบางหน่วยงานจะกำหนดว่า

49 49 ตัวอย่าง Defect Log Documents (cont) Defect Log  Defect Analysis

50 50 Documents (cont) Test Summary Report เป็นเอกสารชุดสุดท้ายที่จัดทำขึ้นมาในแต่ละ Phase ของการ Test เพื่อเป็นการสรุปผลการทดสอบ ทั้งหมดว่ามีจำนวน Test case ทั้งหมดกี่ Case ทำการทดสอบไปกี่ Case Test อยู่บน Environment ใด และถ้ามี Error จะอยู่ที่ severity ใดบ้าง เป็นจำนวนกี่ Case ตัวอย่าง Summary Test Report

51 51 Documents (cont) Test Summary Report ตัวอย่าง Test Summary Report (cont)

52 52 Documents (cont) Level of Documents จากเอกสารทั้งหมด สามารถจัดกลุ่มแบ่งเป็น Level ได้ตามแผนผัง ดังนี้ Test Planning Test Specification / Test Design Test Case/ Test Script Requirement traceability matrix Test Result Defect Log Test Summary Report Integration Test Test Case/ Test Script Requirement traceability matrix Test Result Defect Log Test Summary Report System Test Test Case/ Test Script Requirement traceability matrix Test Result Defect Log Test Summary Report System Integration Test

53 53 Test Tool Quick Test เป็น Automate test tool ที่ช่วยในการทดสอบแบบ Functional Test และ Regression Test โดยที่ Tester ไม่จำเป็นที่จะต้องมา run test case ที่ซ้ำๆ กันเป็นจำนวนหลายๆ ครั้ง สามารถใช้ Tool นี้ช่วยได้ โดยที่ต้อง capture flow การทำงานของหน้าจอเพื่อให้ tool รับรู้ก่อน หลังจาก นั้นเมื่อจะเริ่มทำการทดสอบจริง Tool ก็จะจดจำการทำงานที่เคยบันทึกไว้ ข้อดี คือ ไม่เปลือง Resource/effort ที่จะต้องมาทำการทดสอบแบบซ้ำๆ Load Runner เป็น Automate test tool ที่ช่วยในการทดสอบ Performance Test และ Load Test เพื่อดู Capacity ของระบบ, Response time, throughput, bottleneck etc. และสามารถที่จะ วิเคราะห์ออกมาได้ว่าเกิดปัญหาหรือ bottleneck ที่ส่วนใด เพื่อให้สามารถ tuning performance ได้มีประสิทธิภาพมากยิ่งขึ้น HP Quality Center (QC) เป็น Quality Tool ไว้สำหรับควบคุมคุณภาพของระบบ จะประกอบไปด้วยหลาย Module แต่ที่ นิยมนำมาใช้งานในเรื่องการ Test คือ Requirements, Test Plan, Test Lab และ Defect Manager เราสามารถที่จะนำ Requirement และ Test Case ใส่เข้าไปในระบบ เมื่อเราทำการ ทดสอบตาม Test case แล้ว ให้มาบันทึก Defect ไว้ใน QC หลังจากนั้น QC จะทำการส่ง alert mail แจ้งไปยังผู้ที่เกี่ยวข้องต่างๆ ให้รับทราบว่ามี defect เกิดขึ้น เมื่อทำการแก้ไข defect และ re-test เสร็จเรียบร้อยแล้ว ให้ทำการ close defect ด้วย จาก Tool ตัวนี้จะสามารถ Track Status ของการทดสอบและสามารถที่จะทราบได้ว่ามีการทำ Test Case ครอบคลุมทุก Requirement แล้วหรือยัง

54 54 ในปัจจุบันการพัฒนา Software Application แบบ Agile process กำลังถูกนำมาใช้ จึงมีการนำวิธี Agile เข้ามาประยุกต์ใช้ร่วมกับ Test Process เพื่อปรับให้การ Develop Application มี ประสิทธิภาพมากขึ้น การทำงานแบบ Agile จะนิยมการติดต่อสื่อสารแบบ Real Time มากกว่าการติดต่อสื่อสารโดยการเขียนเป็นเอกสาร โดยทีมงานจะต้องประกอบไปด้วยบุคคลที่เกี่ยวข้องที่จะมีส่วนช่วยในการพัฒนา Software ให้สำเร็จ อย่างน้อย ได้แก่ SA, Programmer, Business Analyze, Tester, manager Concept ของ QA ใน agile คือ “ต้องช่วย support Developer เพื่อให้ได้ Software คุณภาพดีเยี่ยมไปถึงมือลูกค้า “ นั่นหมายถึงว่า Tester จะต้อง ยอมรับการเปลี่ยนแปลงอยู่ตลอดเวลา เพื่อให้ Software ออกมามีคุณภาพ ดังนั้นจึงไม่สามารถวางแผนการ Test ได้ล่วงหน้านานๆ เนื่องจาก Developer สามารถที่จะเปลี่ยนแปลง Program ได้ตลอดเวลาเพื่อให้งานออกมามี คุณภาพ จากหลักการของ Agile ทำให้ Tester ต้องลดงานบางส่วนลง เพื่อจะได้มีเวลาในการทดสอบได้หลายครั้งมาก ยิ่งขึ้น งานที่ควรจะลดลงคืองานเอกสาร เนื่องจากเอกสารบางอย่างอาจจะสามารถยุบรวมกัน หรือตัดทิ้งได้ หรือ เขียนให้กระชับมากยิ่งขึ้นได้ ยกตัวอย่างเช่น เอกสาร Test Case อาจจะถูกเปลี่ยนมาเป็น Test Check List เท่านั้น เพื่อลดเวลาในการทำงานลง แต่ไม่ได้หมายความว่าให้ลดจำนวน Test Case ลง ทุกอย่างยังคงอยู่บนพื้นฐาน business requirement Concept ของ Agile จะต้องร่วมทำการทดสอบกับ Developer ทุกๆ สัปดาห์ โดยใช้เวลาให้น้อยที่สุด คือไม่เกิน 1 ชม. Developer จะต้องทำการ demo program ที่กำลังทำการ develop อยู่ให้กับ Tester เพื่อทำการตรวจสอบ แบบคร่าวๆ ว่าทำงานได้หรือไม่ ซึ่งการทำ Test ทุกๆ สัปดาห์จะมีข้อดีคือ ทำให้ Developer ต้องใส่ใจในคุณภาพ งานของตัวเองอยู่ตลอดเวลา ทำให้ช่วยลดปัญหาที่ปลายเหตุ หลังจากที่ deploy program ออกมาให้กับ Tester แล้วเจอ Error ทำให้ต้องวนกลับไปแก้ไขใหม่ AGILE Testing

55 55 เมื่อเริ่มต้นทำการทดสอบในส่วนของ System Integration Test (SIT/E2E) Developer จะทำ Demo ให้ดูอีกครั้ง หลังจากนั้น Tester จะทำการทดสอบ Program ทั้งหมดเองตาม Check List ที่ ได้ทำไว้ ซึ่งจะต้องทำการทดสอบใหม่ทั้งหมด เนื่องจากว่าเราไม่สามารถมั่นใจได้ว่า Code ที่กำลัง ทำการทดสอบอยู่เป็น Code ตัวเดิม เนื่องจากหลักการของ Agile จะมีความยืดหยุ่นมากในเรื่องของ การ Develop Program คือสามารถแก้ไขได้ตลอดเวลา จากหลักการดังกล่าว เมื่อมาถึงขั้นตอนสุดท้ายของการทดสอบ จะพบว่า Error น้อยลงกว่าปกติหรือ อาจจะไม่มีเลย เนื่องจากได้ผ่านการทดสอบกับ Developer มาแล้วทุกอาทิตย์ AGILE Testing (cont)

56 56 Agile development เป็นแหล่งรวมวิธีการพัฒนา Software ที่ใช้วิธีแบบ IID (Iterative and Incremental Development) เช่น Extreme Programming (XP), Scrum, Crystal, Feature Driven Development (FDD) เป็นต้น Crystal Process

57 57 FDD– Feature driven development

58 58 Deployment Discipline Workflow


ดาวน์โหลด ppt 1 Test Methodology. 2 Test Process Role and Responsibility V Model Test Technique Test Type Test Flow Documents Test Tool AGENDA.

งานนำเสนอที่คล้ายกัน


Ads by Google