Testing Level

    ก่อนที่จะมีการปล่อยโปรแกรมสักตัวออกสู่ผู้ใช้งาน เราจะแน่ใจได้อย่างไรบ้างว่า มันสามารถใช้งานได้จริงนั้น ก็ต้องมำกระบวนการทดสอบระบบ(Testing) กันเสียก่อน เพื่อให้มันใจได้ว่า โปรแกรมที่นักพัฒนาสร้างขึ้นมานั้น สามารถใช้งานได้จริงนั้นเอง

   กระบวนการการทดสอบระบบนั้นแบ่งออกเป็น 4 ส่วนส่วนด้วยกัน ก่อนที่จะปล่อยไปสู้ผู้ใช้งาน โดย 4 ส่วนนั้นมีดังนี้

• Unit testing
• Integration testing
• System testing
• Acceptance testing

    หลายคนคงคิ้วโก่ง กันไปล่ะ แล้ว " Regression testing" หายไปไหนล่ะ ในส่วนนี้  Regression testing ไม่ใช่ Level ของการทดสอบนั้นเอง แต่  Regression testing เป็นชนิดของการทดสอบ ของทั้ง 4 Level ข้างต้นเลยต่างหาก   Regression testing เป็นการ Endure ว่าที่เราทำการทดสอบมาเนี่ย ได้ผลตามนั้นจริงๆๆนะ ซึ่งสามารถเกิดขึ้นได้ทั้ง 4 Level ของการทดสอบรพบบเลย

      ทีนี้ เรามาดูกันว่าทั้ง 4 Level นั้นแต่ละส่วนเค้าทำอะไร หรือมีกระบวนการอย่างไรบ้าง

1. Unit testingในส่วนนี้ถ่อเป็นการทดสอบระดับแรกเลยก็ว่าได้ จะเป็นการทดสอบที่เจอาะจงลงไปแต่ละ Unit ของตัวโปรแกรม หรือส่วนประกอบของตัวโปรแกรมว่าครบถ้วนหรือไม่ ซึ่ง Unit Test อาจจะมากไประดับของ Function เลยก็ว่าได้ และในส่วนนี้เราอาจะใช้การทดสอบแบบ  White-box Testing method ก็ได้  ในส่วนนี้เมื่อมีการเปลี่ยนแปลง Code จะส่งผลมายังส่วนนี้ เพราะฉะนั้น ควรที่จะทำส่วนนี้ให้เสร็จโดยเร็วถ้าเป็นไปได้ และส่วนนี้เองผู้ทำการทดสอบจะต้องเป็นโปรแกรมเมอร์ หรือผู้พัฒนาระบบนั้นเองที่จะเป็นผู้ทำการทดสอบในส่วนนี้ให้ถูกเสียก่อนที่จะส่งมอบงานให้ทาง Tester ทพการทดสอบระบบต่อไป
2. Integration testing หลังจากที่นักพัฒนาระบบทำการทดวอบ Unit Test เรียบร้อยแล้ว และพร้อมที่จะส่งให้กับ Tester เพื่อทำงานต่อนั้น  Tester หรือ นักทดสอบระบบ จะทำการทดสอบในส่วนของ Unit Testing แอบแฝงอยู่ด้วยนั้นเอง แต่การทดสอบในส่วนหลักๆคือ การทดสอบในแต่ละFunction/Module ว่าสามารถทำงานได้หรือไม่นั้นเอง เมื่อมีการส่งค่าของแต่ละ Field ไปตาม Function/Module แล้ว มีผลกระทบอะไรหรือไม่ ซึ่งจะต่างจาการทำ Unit Testing ของ โปรแกรมเมอร์ ในส่วนนี้จะใช้วิธีการทดสอบที่หลายหลายวิธีในการทดสอบ แล้วแต่ผู้ทดสอบเห็นสมควร เนื่องจากแต่ละระบบมีการจัดการหรือกระบวนการไม่เหมือนกัน
3. System testing ในส่วนนี้ถือเป็นด่านแรกของการ การทดสอบทั้งหมดของโปรแกรม เพื่อดูว่าโปรแกรมสามารถทำได้คสามความต้องการของผู้ใช้งานหรือไม่ ในส่วนนี้เราจะเริ่มมองเห็นความเป็นมาตราฐานของโปรแกรม มีการแบ่งผู้ใช้งานในการเข้าระบบให้เห็น เหมือนการใช้ระบบจริง มีการจะลองสภาพแวดล้อมการทำงานให้เหมือนกับการทำงานจริงๆ ทั้งทางด้านArchitecture หรือแม้แต่ตัว Software อื่นๆ ที่ต้องติดตั้ง ในเครื่องของผู้ใช้งานเอง   ในส่วนนี้จะมีความสำคัญมาก เนื่องจากจะเป็นจังหวะที่ มีการรวมเอา Technical,Architecture,Functional และ Business requirement มาทำการทดสอบให้เหมือนกับผู้ใช้งานจริงๆ ทำการใช้งาน  
4. Acceptance testing ในส่วนนี้เป็นขั้นตอนสุดท้ายในการทดสอบ ในระหว่าง SDLC นี้อาจจะมีบางขั้นตอนที่มีความต้องการของผู้ใช้หายไปในระหว่างกระบวนการ ขั้นตอนนี้ ผู้ใช้งานจริงๆ จะเข้ามามีสาวนร่วมในการทดสอบระบบก่อนที่จะใช้งานจรืง ว่ามีส่วนไหนไม่เหมาะสมกับความต้องการหรือไม่ ถ้าตัวโปรแกรมตอบสนองตามความต้องการหรือเสร็จเรียบร้อยก็จะนำเอาตัวโปแกรมนี้ไปใช้งานจริง

      สุดท้ายนี้ การที่ผ่านการทดสอบระบบนี้จะทำให้ตัวโปรแกรมมีคุณภาพเพิ่มมากขึ้น แต่ก็ไม่ได้มายความว่า Defect ที่เเกิดขึ้นหลังจากนี้จะมีอีกไม่ได้ แน่นอนถ้าการทดสอบดีอาจจะไม่เกิดขึ้นหลายคนคงคิดแบบนี้ แต่เมื่อมี Technology ที่สูงขึ้น มีระบบ หรือมีSoftware บางตัวที่มีผลกับโปรแกรมก็อาจจะเกิดขึ้นได้ จากหลายปัจจัย เช่น บางครั้งอาจจะมีการ Update ตัว Software บางตัวในเครื่อง ผู้ใช้งานก็อาจจะมีผลต่อหน้าจอของโปรแกรมก็ได้ บางครั้งโปรแกรมที่พัฒนาขึ้นต่างมีข้อจะกัดที่แตกต่างกันไปนั่นเอง หากจะให้ดีแล้ว ควรจะมีการทดสอบระบบเพื่อเป็นการการันตีได้ระดับนึงว่า ระบบที่ท่านจะนำเอาไปใช้นั้น จะได้ไม่ใช้งานได้จริง และไม่ผิดวุ๖ถุประสงค์

Define Testing dictionary (1)

 วันนี้เรามานั่งดูความหมายของ คำแต่ละคำของการทดสอบร้นที่มีใช้ๆกันะบบ (Software Testing) กันว่า ในแต่ละคำที่ใช้ๆกันนั้น มีความมายว่าอะไรกันบ้าง เพื่อให้สามารถแยกความแตกต่าง และจุดประสงค์ในหารทำได้อย่างชัดแจนมากขึ้นกว่าเดิม

 •Peak load testing:  เป็นการทดสอบการทำงานของระบบในช่วงเวลาหนึ่งที่ มีการทำรายการมากที่สุดที่ระบบสามารถจะรองรับได้ เพื่อทดสอบประสิทธิภาพของระบบนั้นเองว่าสามารถรองรับการประมวลได้มากแค่ไหน

•Performance testing: จะเป็นการทดสอบประสิทธิภาพของระบบว่าสามารถใช้ระยะเวลามากน้อยแค่ไหน ในการทำรายการ

•Recovery testing: การทดสอบการกู้ระบบ เป็นการทดสอบในกรณีที่เกิดระบบล่ม

•Storage testing:  เป็นการทดสอบในการเก็บข้อมูลว่าระบบนั้นมาใสรถเก็บข้อมูลได้มากน้อยเพียงใด

•Procedure testing: การทดสอบกระบวนการ การจัดทำคู่มือเอกสารการใช้งาน ว่าผู้ใช้งานสามารถที่จะเข้าใจเอกสารที่ได้ทำขึ้นมากน้อยแค่ไหน

•User testing: เป็นการทดสอบการใช้งานจริง โดยมีผู้ใช้งานเป็นผู้ทดสอบเอง เพื่อให้แน่ใจว่าผู้ทดสอบนั้นสามารถแก้ปัญหา หรือสามารถทำอย่างไรได้บ้างเมื่อพบปัญหาที่เกิดขึ้น

•Validation Test: เป็นการตรวจสอบระบบที่ทำงานขึ้นมานั้นถูกต้องหรือไม่ ในส่วนนี้จะถูกเริ่มหลังจากที่มีการพัฒนาระบบเรียบร้อยแล้ว พร้อมที่ทีม Tester จะเข้ามาทำการทดสอบระบบ ในส่วนนี้เราจะตรวจสอบว่า ระบบทำงานถูกต้อง ตรงกับที่ Requirement ที่  user ต้องการ เช่นการทำ unit Testing, Integration Testing และ System Testing

•Verification:การตรวจสอบว่าการพัฒนาสร้างระบบทำอย่างถูกต้องหรือไม่ จะถูกเริ่มขึ้นตั้งแต่การพัฒนาระบบและจะดำเนินไปจนระบบถูกพัฒนาจนเสร็จ คือตั้งแต่ ความถูกต้องครบถ้วนของ requirement ของ user ขั้นตอนการเก็บ requirement ของ user, การออกแบบระบบงานเป็นไปตาม requirement ที่ user ต้องการ และ ความถูกต้องของการพัฒนาโปรแกรมว่ามาสามารถพัฒนาโปรแกรมเป็นไปตามเอกสารที่ได้ทำการออกแบบหรือไม่นั้นเอง

•Black Box Testing:เป็นการทดสอบโดยไม่คำนึงถึงCoding ภายในโปรแกรม สเป็นการทดสอบในส่วนของ Functionต่างๆ ของโปรแกรมว่าทำงานได้ถูกต้องหรือไม่ เช่น สามารถคิดคำนวณ ค่าต่างๆได้ถูกต้อง ในส่วนนี้เราจะดูแค่ ค่า Input ที่กรอกลงในโปรแกรม และค่า Output ที่เป็นผลที่ได้ออกมา ว่าโปรแกรมสามารถทำงานได้ถูกต้องหรือไม่

•White Box Testing:เป็นการทดสอบเพื่อดูโครงสร้างของโปรแกรม

      ทั้งหมดนนี้เป็นส่วนหนึ่งเท่านั้นที่เป็นศัพท์ที่ใช้ในการทดสอบระบบ ซึ่งส่วนมากผู้ที่ทำงานเกี่ยวกับการทดสอบระบบจะมีการแบ่งส่วนมนกรทดสอบที่แยกลึกๆ ออกไปอีก ขึ้นอยู่กับการใช้งาน และความต้องการของแต่ละระบบ และองค์กรนั้นเอง

Functional Testing Vs Non-Functional Testing

               Functional Testing : จะเป็นการทดสอบให้มีความขัดแย้งกับ Business requirement ว่า Function นั้นสามารถทำตามที่ ผู้ใช้งานต้องการได้หรือไม่ ฟังดูเหมือนงง เช่น ในหน้าจอ log in เข้าระบบ ระบบต้องการให้มี user และ Password ในการ เข้าระบบ Functional Testing จะทดสอบว่า เมื่อเราใส่ user และ password ผิด เราจะสามารถเข้าระบบได้หรือไม่นั้นเอง

            ในส่วนนี้ Functional Testing จะมีการทดสอบดังต่อไปนี้คือ

•  Unit Testing
• Smoke testing / Sanity testing
• Integration Testing (Top Down, Bottom up Testing)
• Interface & Usability Testing
• System Testing
• Regression Testing
• Pre User Acceptance Testing(Alpha & Beta)
• User Acceptance Testing
• White Box & Black Box Testing

                Non-Functional Testing:ในส่วนนี้จะเเกี่ยวก็ป็นการทดสอบกับความต้องการใช้งานของ Client เอง เช่น มีจำนวน user มากแค่ไหนที่เข้ามาใช้ระบบ เมื่อเข้ามาใช้ระบบพร้อมกัน ระบบอ่จจะ load มาก เราก็จะทดการจะลองในส่วนนี้ หรือแม้แต่ Performance ของระบบเอง

 ในส่วนนี้ Non-Functional Testing จะมีการทดสอบดังต่อไปนี้คือ

• Load and Performance Testing
• Ergonomics Testing
• Stress & Volume Testing
• Compatibility & Migration Testing
• Data Conversion Testing
• Security / Penetration Testing
• Operational Readiness Testing
• Installation Testing
• Security Testing (Application
• Security, Network Security,System Security)

Test Plan เขียนแบบไหนกัน

หลักการเบื้องต้นเพื่อเขียน Test Plan

1.       อธิบายจุดประสงค์ในการทดสอบ เช่น โปรแกรม, ระบบและ Hardware ที่คุณจะทำการทดสอบนั้นเป็นอย่างไร
2.       อธิบายรายการที่ทำการทดสอบในระบบว่าจะมีการทดสอบอย่างไร แบ่งการทดสอบในโปรแกรมเป็นอะไรบ้าง
3.       อธิบายถึงวิธีที่จะทำการทดสอบ และหลักทางด้านวิชาการที่จะใช้ทดสอบนั้นเองว่ามีอะไรบ้าง แต่ละส่วนจะทดสอบอะไรบ้าง
4.       อธิบายว่าเมื่อไหร่การทดสอบระบบถึงจะเริ่มขึ้น ตั้งแต่การจัดเตรียมข้อมูลในการทดสอบ, การทดสอบ, ผลของการทดสอบพร้อมการวิเคราะห์ผลที่ได้ ในแต่ละช่วงที่ทำการทดสอบ
5.       การลำดับความสำคัญ  Criteria for beginning of testing ว่าควรจะให้ความสำคัญกับส่วนไหนเป็นอย่างแรกก่อนที่จะเริ่มการทดสอบระบบ เช่น
-       Test Platform  เป็นอย่างแรกว่าพร้อมสำหรับการใช้งานหรือไม่
-       Functional ของโปรแกรมสามารถพัฒนาได้ทันตาม requirement ของ Functional
-       ความพร้อมของเอกสารทั้งหมดที่จะใช้ในการทดสอบจะต้องเรียบร้อยไม่มีการแก้ไข
6.       การลำดับความสำคัญ Criteria for ending of testing ว่าหลังจากที่ทำการทดสอบระบบแล้วจะได้อะไรบ้าง
-       ผลการทดสอบระบบ ที่พบว่ามีคุณภาพมากน้อยแค่ไหนโดยจะวัดได้จาก defect ที่เกิดขึ้น เช่น เมื่อได้ใช้โปรแกรมไประยะหนึ่งและไม่มีการพบdefect ที่เกิดขึ้นกับตัวโปรแกรม และไม่มีการแก้ไข source code ในช่วงเวลาดังกล่าว
-       แต่สุดท้ายแล้วจะต้องมีเอกสารเพื่อแสดงรายละเอียดเหล่านี้ด้วย
-       สภาพแวดล้อมของระบบภาพใต้การทดสอบ ว่ามีการ set up hardware อะไรบ้าง มีการติดตั้งตัว software อะไรบ้างในระบบ
-       มีการใช้ Tool อะไรบ้างในการทดสอบระบบ และตัว software เองมีการ configuration ค่าอะไรบ้าง เพื่อใช้ในการทดสอบ Automated Testing
-       การบริหารความเสี่ยง และการจัดการความเสี่ยงที่อาจจะเกิดขึ้น
นอกจากนี้ก็ยังจะมี
                                A. Master Plan or Master Test Plan:  Master Plan จะมีการเขียนล้อตามกับ Master Test Plan ซึ่ง Master Plan จะอยู่ใน level ที่สูงกว่านั้นเอง ในส่วนของ Master Test Planนั้น จะบ่งบอกเจาะจงถึงสิ่งที่จะทดสอบ, ชนิดของการทดสอบ และ ระยะเวลาที่จะใช้ในการทดสอบ ในการทำ 1 Project นั้นจะมี Master Test Plan แค่หนึ่งเดียว แต่แตกออกเป็นหลายรายละเอียด
                               
                              B. Test Plan
                              C. Product Acceptance Plan: อธิบายถึงรายละเอียดการทดสอบ หลัการทดสอบ UAT วันที่ในการทดสอบเป็นต้น

7.  Review and Approval
     ในส่วนนี้จะเป็นการเพิ่มรายชื่อสมาชิก ที่เกี่ยวข้อง เช่น Lead Tester, Test Manager (Quality Manager),
Head of Development, Project Manager เพื่อreview ผลและเอกสารที่ได้จัดทำขึ้น และเป็นการแจ้งผลเพื่อรับทราบโดยทั่วกันและรับทราบโดยทั่วกันด้วย

Software Development Life Cycle (SDLC)

          

            SDLC คือกระบวนการการทำงานของการพัฒนา software project ภายในองค์กร ซึ่งจะประกอบไปด้วย รายละเอียดการPlan ในการทำงาน เช่น จะมีการพัฒนาอย่างไร, มีการดูแลรักษาอย่างไร, จะมีsoftwareระบบอะไรมาใช้แทน ระบบเก่า ระบบใหม่ควรจะเป็นอย่างไร SDLC จะเป็นตัวกำหนดกระบวนการการพัฒนาและคุณภาพของตัว Software ที่ได้ทำการพัฒนาขึ้นมา โดยสามารถแบ่งการทำงานได้ดังนี้

1.       Planning and Requirement Analysis

2.       Defining Requirements

3.       Designing the product architecture

4.       Building or Developing the Product

5.       Testing the Product

6.       Deployment in the Market and Maintenance

 

                เมื่อทราบถึงขั้นตอนไปแล้วก็มาดูกันว่าในแต่ละส่วนที่มีนั้นรายละเอียดเป็นอย่างไรกันบ้าง

·         Planning and Requirement Analysis

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

·         Defining Requirements

ในส่วนนี้จะเป็นการเก็บรวบรวมข้อมูลความต้องการของระบบจากผู้ใช้งานโดยตรง โดยมีการจัดทำขึ้นเป็นเอกสาร ที่เรียกว่า “Software Requirement Specification  document หรือ SRS” เอกสารจะประกอบไปด้วย ความต้องการทั้งหมดของผู้ใช้งาน  ในส่วนนี้จะถูกนำไปวิเคราะห็เพื่อ ทำการ designed และพัฒนาระบบนั่นเอง

·         Designing the product architecture

 ในส่วนนี้เราจะใช้เอกสาร SRS ในการอ้างอิงเพื่อใช้ในการ design โครงสร้างของระบบที่เรียกว่า “ Design Document Specification หรือ DDS”  ภายในเอกสาร DDS จัมีการระบุรายละเอีดยของsoftware ว่ามีโครงสร้างเป็นอย่างไร มีการแบ่งโครงสร้างเป็นส่วนย่อยอะไรบ้าง มีการไหลของข้อมูลเมื่อใช้งานอย่างไร ไปเชื่อมกับระบบอื่นๆอย่างไรบ้าง ในส่วนไหนบ้างที่มีการเชื่อมต่อบ้าง

·         Building or Developing the Product

ในส่วนนี้จะเป็นการพัฒนาsoftware โดยจะมีการเขียน Coding ของโปรแกรม โดยอ้างอิงจาก เอกสาร DDS  เพื่อให้เป็นไปตามความต้องการของผู้ใช้งาน

·         Testing the Product

ในส่วนการทดสอบระบบจะเป็นส่วนที่ค่อนข้างจะซับซ้อนใน SDLC เนื่องจากจะมีการค้นหาข้อผิดพลาดของตัวsoftware ซึ่งก็จะมีการ reporting, Tracking, Fixed และ retested จนกว่าจะได้software ที่มีคุณภาพ ตาม SRS ที่เขียนขึ้นมา

·         Deployment in the Market and Maintenance

เมื่อsoftware ผ่านการทดสอบเรียบร้อยแล้ว จะมีการนำตัวsoftware มาทดสอบเพื่อใช้ในงานจริงในสภาพแวดล้อมที่เกิดขึ้นจริงตามแต่ละธุรกิจในส่วนนี้ จะเรียกว่าเป็นการทีสอบแบบนึงด้วยคือ UAT- User acceptance testing ซึ่งถ้าsoftware สามารถตอบโจทย์ของธุรกิจได้อย่างครบถ้วนแล้ว ก็จะมีการเอาไปใช้งานอย่างจริงจัง

Quality Assurance vs Quality Control

              วันนี้เรามาคลายความสงสัยของ สองคำนี้กันดีกว่า ว่ามันต่างกันอย่างไร เวลาเราสมัครงาน คงมีบางคนสงสัยเหมือนกันว่า คำสองคำนี้ต่างกันอย่างไรหนอ แต่เราด็ต้องยอมรับว่าแต่ละองค์กรให้คำจำกัดความ ของ สองตำแหน่งนี้ต่างกัน วันนี้เราจะมาหาคำตอบกันว่า สองคำนี้มีหน้าที่ต่างกันอย่างไรบ้าง Quality Assurance (QA) คือ กระบวนการที่มุ่งเน้นไปในการป้องกันการเกิดข้อผิดพลาดของตัว Application หรือ Defect นั้นเอง ในขณะที่ Quality Control คือ กระบวนการที่มุ่งเน้นไปเพื่อที่จะทำการหาตัว Defect ของApplication ที่อาจจะเกิดขึ้น ถ้ายังงง เรามาดูให้ล฿กกันเข้าไปอีกว่ามีหน้าที่อย่างไรในแต่ละตำแหน่ง QA QC นิยาม เป็นการควบคุมกระบวนการการพัฒนา softwareว่าถูกต้องตามกระบวนการหรือควรทำหรือไม่ เป็นการตรวจสอบว่าคุณภาพของตัว software ที่ทำการพัฒนาเรียบร้อยแล้วนั้นสามารถทำงานได้จริงหรือไม่ Focus on เป็นการป้องกันไม่ให้เกิด defect ในระหว่างที่ทำการพัฒนา software ทำการทดสอบเพื่อหาdefect ของระบบหลังจากที่มีการพัฒนา software เรียบร้อยแล้ว
จุดประสงค์ จะเป็นการควบคุมกระบวนการพัฒนา และกระบวนการทดสอบระบบเพื่อไม่ให้มี defect เกิดขึ้น ทำการค้นหา Defect จาก software ที่ได้ทำการพัฒนา ก่อนที่จะมีการส่งให้ผู้ใช้งานใช้ ทำอย่างไร

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

         ตัวอย่าง การตรวจสอบ การตรวจสอบ และการทดสอบ QA คือคบที่จะมาคอยจัดการกระบวนการในการพัฒนาsoftware และตรวจสอบระบบการพัฒนา software ว่าเป็นไปอย่างมีประสิทธิภาพหรือไม่ เพื่อป้องกันให้สุดท้ายแล้วได้software ที่มีประสิทธิภาพ ออกมาให้ดีที่สุดให้กับผู้ใช้งาน โดยทางQA ก็จะมีการตรวจสอบเอกสาร การวางแผนการพัฒนา ว่ามีกระบวนการถูกต้องหรือไม่ แต่ละกระบวนการต้องแต่การเก็บ requirement จนถึง การส่งมอบงานให้ลูกค้า มีการทำงานที่ถูกต้องและมีประสิทธิภาพพอไหมนั่นเอง ส่วน QC จะป็นแค่ส่วนหนึ่งของกระบวนการพัฒนาระบบ คือหลังจากที่กระบวนการพัฒนาระบบทำการพัฒนาระบบเรียบร้อยแล้ว QC จะเข้ามาทำการทดสอบระบบต่อ โดบจะมีการทดสอบหลายอย่างเช่น กระบวนการการทพงานของ software ว่าสามารถทำงานได้ถูกต้องหรือไม่ ตรงตามความต้องการของผู้ใช้งานหรือไม่ สามารถรองรับการใช้งานของ user ได้จริงหรือไม่ ก่อนจะทำการส่งมอบงานไปยังผู้ใช้งาน เพื่อเตรียมความพร้อมของระบบให้เหมาะสมกับการใช้งานนั้นเอง

Test Case & Test Scenario & Test Script

               สองคำนี้ถ้าคงเป็นที่คุ้นหู คุ้นตากันอย่างมากกับคนที่อยู่ในวงการ IT หรือจะรู้จักเป็นอย่ามากก็คงคนที่ทำอาชีพทดสอบระบบ Software ทั้งหลาย แต่เคยคิดบ้างไหมเอ๋ยว่า สองคำนี้ต่างกันอย่างไร ในทางปฏิบัติ ตามที่ส่วนตัวเข้าใจ สองคำนี้มีความหมายไม่เหมือนกัน แต่ก็ขึ้นอยู่กับบริษัท หรือองค์กร จะเลือกใช้คำนิยามนี้ขึ้มาอีก เหมือนๆกับตำแหน่ง IT อื่นๆที่ใช้กันผสมมากมาย จนไม่รู้ว่าตำแหน่งอะไรกันแน่ กลับมาเข้าเรื่องกันต่อเลยดีกว่า สองคำนี้ จากประสบการที่เคยทำงานทางด้านทดสอบ Software มาพอสมควร ก็พอที่จะแยกได้ตามความเข้าใจจากการทำงาน เพราะส่วนตัว ไม่เคยเรียนวิชานี้มาก่อนเลย แต่ปัจจุบันบางมหาวิทยาลัย น่าจะสอนกันมากขึ้น เพราะปัจจุบันมีคนเข้ามาทำงานทางนี้กันเพิ่มมากขึ้นที่เดียว Test Case & Test Scenario ถ้าจะเอา สองคำนี้มานั่งแปลอย่างตรงตัวเลยก็คือ
       
             Test Case คือ กรณีที่ใช้ในการทดสอบ
             Test Scenario คือ สถานนะการที่ใช้ในการทดสอบ 
               
              พอแปลแล้ว ก็ยังคงเกิดอาการงง กันอยู่ไม่ใช่น้อย ก่อนอื่นเรามาดูคำว่า Test Case กันก่อนเลย คำคำนี้ จะเป็นการทดสอบที่มีเพียงเงื่อนไขเดียวในการทดสอบ เช่น การทดสอบหน้า Login โดยกรอกข้อมูล Password ผิด เป็นต้น เป็นการเขียนที่จะมีการระบุเงื่อนไขในการทดสอบเพียงอย่างเดียวเพื่อดูผลที่ได้จากการทดสอบ จากตัวอย่างที่กล่าวมาข้างต้นนี้ จะแสดงให้เห็นว่า ผลที่ควรจะเป็นไปสำหรับการทดสอบนี้คือ ไม่สามารถ Login เข้าสู่ระบบได้ เมื่อมีการใส่ Password ผิดนั้นเอง ส่วนมากมักจะใช้คำเหล่านี้การเขียนTest Case ในการทดสอบ Function ของตัว Software นั้นเอง ในส่วนนี้การเขียน Test Case จะอ้างอิงจาก Function และ Business Requirement ของแต่ละ Application ที่เราจะทดสอบ


               Test Scenario นั้นจะเป็นการเขียนจำลองเหตุการณ์ ที่เกิดขึ้นจริงที่ระบบจะนำไปใช้ในแต่ละ Business โดยในแต่ละ Test Scenario อาจจะมีการแบ่งเป็น Positive และ Negative ด้วยก็ได้ ส่วนมากนิยมเขียนตั้งแต่เริ่มBusiness Flow จนจบ เพื่อให้แน่ใจว่า Application ที่ทดสอบสามารถนำเอามาใช้ควบคู่ไปกับ Business ในแต่ละเหตุการณ์ที่เกิดขึ้นจริงๆได้ ในการเขียนประเภทนี้ จะเป็นการใช้เพื่อทดสอบ ในระดับของ UAT (User Acceptance Test ) ซึ่งการทดสอบนี้ จะผ่านการทดสอบในระดับ Function มาก่อนเพื่อให้แน่ใจว่า ในแต่ละ Functionนั้ ระบบไม่เกิดการ Error หรือ ไม่สามารถใช้งานได้ Test Script คือส่วนที่จะใช้เขียนเพื่อบอก Step การทำงาน ในแต่ละ Test Case / Test Scenario เช่น ต้องไป Click ที่ไหน ปุ่มอะไรที่หน้าจอไหน ซึ่งบางครั้ง อาจจะหมายถึง Step(Script) ใน ส่วนของ Automate ด้วยก็ได้

Test Definition (1)

Unit Test คือ การทดสอบบางส่วนของโปรแกรมว่าเป็นไปตามเงื่อนไขหรือไม่ เช่น เมื่อมีการกรอกข้อมูลตัวเลขลงในช่องเลขบัตรประชาชน ที่มีไม่ถึง 13 หลัก , การกรอกตัวอักษรลงไปใน Field ดังกล่าว เป็นต้น

Functional Test คือการทดสอบในแต่ละ Function ของโปรแกรมว่าสามารถทำงานได้ตรงตาม Requirment หรือไม่ เช่น Member Registeration สามารถทำการลงทะเบียนได้ตามRequirment ที่ต้องการหรือไม่ 

Integrated Test คือการนำเอาการทดสอบในแต่ล่ะส่วนมาประกอบกันเพื่อทำการทดสอบในแต่ละส่วนว่าสามาถรถเชื่อมต่อ หรือติดต่อหากันได้อย่างถูกต้องหรือไม่ เช่นการนำเอาFunctional ทั้งหมด
ใน module A มาทำการทดสอบ เพื่อดูว่าระบบสามารถดึงข้อมูลจาก อีกFunction หนึ่งมาแสดงที่อีกFunction หนึ่งได้ถูกต้องหรือไม่
ยกตัวอย่างเช่น
1. Function A เป็นการ Register สมาชิกเข้าระบบ
2. Funvtion B เป็นการ Accept สมาชิกที่ทำการกรอกข้อมูลเข้าระบบ ในการทำ Intergrated Test จะเป็นการนำเอา Function A และ B มาทำต่อเนื่องกัน End to End Test คือการจับเอาแต่ละส่วนของ Integrated Test มาทำการ Test ตั้งแต่ต้นจนจบอีกครั้ง Regression Test คือ การทดสอบเพื่อดูว่าเมื่อมีการทำการเปลี่ยนแปลงในจุดหนึ่งจะมีกระทบกับส่วนอื่นในระบบหรือไม่ ซึ่งจะซ้ำกับการ Test ที่เคยทำมาแล้ว แต่จะใช้ทดสอบเพื่อให้แน่ใจว่าเมื่อมีการเปลี่ยนแปลงในจุดหนึ่งในระบบ จะไม่มีผลกระทบกับ Function เดิมที่ยังใช้งานได้อยู่ System Integration Test (SIT) คือ เพื่อ Verify ว่าระบบต่างๆ สามารถทำงานร่วมกันได้อย่างถูกต้อง ตรงตามวัตถุประสงค์ ทั้ง Network integration และ Product integration ซึ่งจะรวมไปถึง Infrastructure ของระบบ User Acceptant Test (UAT) คือ การทดสอบ เพื่อConfirm business requirement กับ User ว่าเป็นไปตามที่ต้องการหรือไม่ โดยจะทำหารทดสอบที่เหมือนกับ Enviroment เสมือนจริง พร้อมกับใช้ข้อมูลจริงในการทดสอบ