Test Methodology.

Test Methodology

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

TEST PROCESS การ 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 (CONT) อะไรคือข้อจำกัดของการทดสอบระบบ (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) ในมุมมองของ Programmer และ Tester จะมีแนวความคิด (View) ที่แตกต่างกันใน เรื่องของการ Test ตัวอย่างเช่น Programmer Tester Test only coding, not test in business view Need to test in business view Test only code that their change Test 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

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

ROLE AND RESPONSIBILITY
TASK Work Product Response By Test Planning Test Plan Test Leader / QA Requirement Analysis Test Design or Test Specification Test Creation Test Scenario Test Case / Test Script Test coverage matrix Test Preparation Environment set up Check list Tester Test Execution Defect Log Test Result Summary Test Report Tester / Developer / DBA

V MODEL

V MODEL (CONT) 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?”

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

Software quality triangle (cont)
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

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

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

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

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

TEST TECHNIQUE (CONT) 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 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 TYPE Functional Test Non-Functional Test
ประเภทของการทดสอบ 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

LEVEL OF TESTING (cont)
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

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

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 environment: Develop environment and Test environment

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

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 แจ้งมาว่าให้ทำการทดสอบใหม่ทั้งระบบ

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)

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)

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)

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)

Availability & Reliability test จุดประสงค์ เพื่อทำการทดสอบว่าระบบสามารถทำงานได้ตลอดเวลา โดยไม่เกิดปัญหาขึ้น เพื่อทำการทดสอบความน่าเชื่อถือของระบบ เช่นกรณีที่ระบบ 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 ในส่วนนี้ ก็ไม่จำเป็นต้องทำการทดสอบ

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 ในส่วนนี้ ก็ไม่จำเป็นต้องทำการทดสอบ

* Disaster & Recovery Test * Horizontal Scalable Test
Test FLOW P R O D U C T I N Unit Test Integration Test System Test * SIT * Regression Test UAT * Performance Test * Security Test * Disaster & Recovery Test * Horizontal Scalable Test * Means optional testing stage

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

Documents Input Document Output Document (deliverable 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

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

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

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

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

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

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

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

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 มากกว่า

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

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

Documents (cont) Environment Set up Test Check list

Documents (cont) Test Case / Test Script
ที่สุดนั้น จะต้องอยู่บนพื้นฐานของ 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

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

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

Documents (cont) Test Result
Result ไว้เป็นส่วนหนึ่งในเอกสารTest Case เพื่อลดความซ้ำซ้อนในการทำเอกสาร ตัวอย่าง Test Result

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

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

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

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

Documents (cont) Test Planning Level of Documents
Test Specification / Test Design Test Case/ Test Script Requirement traceability matrix Test Result Defect Log Test Summary Report Integration Test System Test System Integration Test

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 แล้วหรือยัง

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

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

FDD– Feature driven development

Deployment Discipline Workflow

Test Methodology.

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

งานนำเสนอเรื่อง: "Test Methodology."— ใบสำเนางานนำเสนอ:

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

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

Test Methodology.

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

งานนำเสนอเรื่อง: "Test Methodology."— ใบสำเนางานนำเสนอ:

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

เรื่องโครงการ

การติดต่อกลับ