Posts Tagged "TDM"

การทดสอบข้อมูลโดยวิธี Test Data (ต่อ)

ครั้งก่อนผมได้ยกตัวอย่างขั้นตอนของการจัดทำ Test Data ในระบบ On-line โดยได้แยกเป็นการเตรียมการก่อนการทดสอบ, ระหว่างการ Key ข้อมูล และเมื่อเสร็จสิ้นการ Key ข้อมูล ซึ่งจะทำให้เข้าใจในกระบวนการของการจัดทำได้ง่ายขึ้น นอกเหนือจากขั้นตอนที่ได้กล่าวไปแล้ว ยังมีข้อควรพิจารณาในการจัดทำ Test Data รวมถึงข้อดี ข้อเสีย ของการนำ Test Data มาใช้งาน ที่เป็นสิ่งที่ควรรู้และเข้าใจซึ่งผมจะได้กล่าวถึงในวันนี้ ก่อนที่จะได้นำเสนอตัวอย่างของการจัดทำ Test Date ในระบบงานเงินฝากในโอกาสต่อไป

ข้อควรพิจารณาในการจัดทำ Test Data
1. ความถี่ในการใช้ Test Data ทดสอบโปรแกรมขึ้นอยู่กับการเปลี่ยนแปลงแก้ไขโปรแกรม เนื่องจากเทคนิคนี้ใช้ในการประเมินการควบคุม และความถูกต้องเหมาะสมของโปรแกรมได้เฉพาะช่วงเวลาที่ทดสอบเท่านั้น

2. ผู้ตรวจสอบต้องศึกษาระบบงานให้เข้าใจโดยละเอียด เพื่อเป็นแนวทางในการกำหนดวัตถุประสงค์ และประเด็นที่จะทดสอบได้อย่างมีประสิทธิภาพ และครอบคลุมถึงการควบคุมที่สำคัญได้ครบถ้วน

3. ระบบงาน On-line ขนาดใหญ่ที่ยุ่งยากซับซ้อน การใช้เทคนิค Test Data จะทำได้ยากในทางปฏิบัติ เนื่องจากจะมีอุปสรรคในการจัดเตรียมอุปกรณ์คอมพิวเตอร์ และแฟ้มข้อมูลสำหรับการทดสอบ ประกอบกับผู้ตรวจสอบจะต้องเสียเวลามากในการศึกษาระบบงานให้เข้าใจโดยละเอียด

4. ต้องแน่ใจว่าโปรแกรมที่จะนำมาประมวลผลต้องเป็นโปรแกรมเดียวกับที่ใช้ในการปฏิบัติงานจริง โดยเปรียบเทียบชื่อและเลขที่โปรแกรมที่นำมาใช้ กับที่บันทึกไว้ในทะเบียนการนำมาใช้การประมวลผลงานตามปกติครั้งล่าสุด

5. ควรใช้โปรแกรมที่ได้แปลงรหัสแล้วพร้อมที่จะนำมาประมวลผลได้ทันที ไม่ควรใช้โปรแกรมที่ได้จากการนำ Source Program มาแปลงรหัสใหม่ เมื่อนำมาประมวลผลข้อมูลทดสอบโดยเฉพาะ

6. แฟ้มข้อมูลและรายการทดสอบต้องไม่ปะปนกับข้อมูลจริงที่องค์กรใช้งานอยู่ ควรป้องกันมิให้ข้อมูลที่ใช้งานอยู่มีข้อผิดพลาด

7. ควรกำหนดให้มีจำนวน Cycle มากพอที่จะทดสอบได้ครอบคลุมทุกเงื่อนไข และสามารถทดสอบรายการที่ได้ป้อนข้อมูลผิดพลาดไปแล้วเมื่อ Cycle ก่อน ๆ ได้

8. ควรพยายามจำกัดปริมาณข้อมูลทดสอบไม่ให้มีมากนัก เพื่อผู้ตรวจสอบจะได้มีเวลาในการเตรียมข้อมูล วิเคราะห์ผลลัพธ์ และเวลาในการทำงานของเครื่องคอมพิวเตอร์ให้น้อยที่สุด

9. ควรจำกัดบุคคลที่จะได้รับอนุญาตให้ดูผลการทดสอบเฉพาะแต่เพียงผู้ตรวจสอบเท่านั้น ไม่ควรเปิดโอกาสให้บุคคลอื่นได้พบเห็น

ข้อดี ข้อเสีย ของการ Test Data มาใช้งาน

ข้อดี
1. ไม่จำเป็นต้องใช้บุคลากรที่มีความรู้ความชำนาญสูงในการเตรียมข้อมูลทดสอบ

2. การใช้ Test Data เป็นการรวมรายการธุรกิจ ตลอดจนรายการผิดปกติประเภทต่าง ๆ ไว้ด้วยกัน ทำให้ผู้ตรวจสอบสามารถพบข้อผิดพลาด/บกพร่องในโปรแกรมได้ง่ายกว่าที่จะตรวจสอบผลลัพธ์จากการประมวลผลโดยปกติ ซึ่งอาจจะต้องตรวจสอบนับพันรายการ จึงจะสามารถครอบคลุมรายการผิดปกติทั้งสิ้น เนื่องจากรายการเหล่านี้อาจมีโอกาสเกิดขึ้นจริงน้อยมาก

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

โดยทั่วไปองค์กรจะไม่เปลี่ยนแปลงระบบงานโดยสิ้นเชิงในช่วงระยะเวลาอันสั้น ดังนั้น เมื่อผู้ตรวจสอบได้จัดเตรียม Test Data ในครั้งแรกแล้ว จะสามารถใช้ Test Data ชุดเดิมทำการทดสอบโปรแกรมได้ไม่จำกัดจำนวนครั้ง ซึ่งต่างจากการตรวจสอบ Source Program Listing ที่ต้องตรวจสอบใหม่โดยละเอียดทุกครั้งเมื่อมีการแก้ไขโปรแกรม เพราะการแก้ไขจุดใดจุดหนึ่งอาจกระทบถูกส่วนอื่น ๆ ของโปรแกรมด้วย

4. ผู้ตรวจสอบสามารถใช้ผลลัพธ์จากการทดสอบเป็นหลักฐานในการปฏิบัติงานตรวจสอบของตน

5. ในการเตรียมข้อมูล Test Data และคำนวณผลลัพธ์ที่คาดไว้ล่วงหน้าตรวจสอบ ไม่จำเป็นต้องเกี่ยวข้องกับขั้นตอนการประมวลผลข้อมูลด้วยคอมพิวเตอร์มากนัก

ข้อเสีย
1. วิธีนี้จะทำการทดสอบได้เฉพาะบางจุดของโปรแกรม ได้แก่ การควบคุมที่กำหนดและการคำนวณเท่านั้น ไม่สามารถตรวจสอบโปรแกรมได้โดยละเอียดทุกขั้นตอน จึงไม่สามารถตรวจพบการทุจริตประเภท Trojan Horse (เป็นการแทรกคำสั่งที่ต้องการ เพื่อการทุจริตแฝงอยู่ในโปรแกรมการทำงานปกติขององค์กร) ได้

ดังนั้น ผู้ตรวจสอบควรตรวจสอบ Source Program Listing ควบคู่ไปด้วย โดยเน้นเฉพาะการค้นหาคำสั่งผิดปกติที่ประมวลผลรายการใดรายการหนึ่งเป็นกรณีพิเศษ

2. ผู้ตรวจสอบต้องเสียเวลามากในการจัดเตรียม Test Data และคำนวณผลลัพธ์ที่คาดไว้ล่วงหน้า

3. การใช้ Test Data บางครั้งอาจจะต้องใช้เวลาการทำงานของเครื่องคอมพิวเตอร์ในการประมวลผลเป็นเวลานาน ซึ่งทำให้ต้องเสียค่าใช้จ่ายสูง

4. ประสิทธิภาพและประสิทธิผลที่จะได้รับ ขั้นอยู่กับความสามารถของผู้ตรวจสอบแต่ละคน ผู้ตรวจสอบอาจมองข้ามประเด็นสำคัญที่ควรทดสอบไปได้

 

การทดสอบข้อมูลโดยวิธี Test Data (ต่อ)

สำหรับเรื่องของ Test Data ที่ผมนำเสนอไปในครั้งที่แล้ว และได้กล่าวถึงขั้นตอนของการจัดทำ Test Data ไว้ในหัวข้อที่ 1 นั้น วันนี้ผมจะขอยกตัวอย่างขั้นตอนของการจัดทำ Test Data ในระบบ On-line ต่อเป็นหัวข้อที่ 2 โดยเป็นตัวอย่างการปฏิบัติงานตรวจสอบระบบเงินฝากขององค์กรโดยทั่วไป ซึ่งการปฏิบัติงานจริงอาจมีรายละเอียดบางอย่างแตกต่างกันไปบ้างในแต่ละองค์กร

2. ตัวอย่างขั้นตอนการจัดทำ Test Data ในระบบ On-line

2.1. การเตรียมการก่อนการทดสอบขององค์กร

2.1.1. ต้องศึกษาและทำความเข้าใจในระบบการปฏิบัติงานขององค์กรก่อนลงมือทดสอบในแต่ละระบบอย่างละเอียด

2.1.2. ต้องศึกษาและทำความเข้าใจใน Format และ Transaction Code ต่าง ๆ

2.1.3. ทำความเข้าใจในระบบการจัดเก็บ File และ Program ของระบบงานต่าง ๆ

2.1.4. ทำความเข้าใจในการทำ Copy ข้อมูล และโปรแกรมที่จะนำมาใช้ในการทดสอบ

2.1.5. ทำความเข้าใจและเจรจากับหัวหน้าศูนย์คอมพิวเตอร์ขององค์กรในเรื่องต่อไปนี้
ก) เวลาที่จะเริ่มทำการทดสอบ
ข) ระยะเวลาที่จะใช้สำหรับการทดสอบ
ค) ชื่อ Report ที่จะขอให้องค์กรพิมพ์มีทั้งสิ้นเท่าใด
ฆ) Printer และ Keyboard ที่จะใช้สำหรับการทดสอบมีจำนวนเท่าใด
ง) เจ้าหน้าที่ผู้ประสานงานขององค์กรมีกี่คน และใครบ้าง
จ) Passbook หรือ Slip ต่าง ๆ ที่จะใช้สำหรับการทดสอบ จะต้องเตรียมการไว้ให้พร้อม เช่น Debit Slip, Credit Slip และ Transfer Slip รวมทั้งแบบพิมพ์อื่น ๆ ที่เกี่ยวข้อง
ฉ) ในกรณีที่องค์กรมีเครื่องคอมพิวเตอร์จำกัด ก็จะต้องทราบว่าหลังจากเสร็จสิ้นงาน On-line แล้ว จะต้องทำงาน Batch อีกนานเท่าใด จึงสามารถเริ่มต้นให้เวลาสำหรับการ Test Data การออก Report และการ Load ข้อมูลกลับเข้าไปในเครื่อง เพื่อทำงานปกติขององค์กรต่อไปได้
ช) ให้องค์กรเตรียม PASS-WORK และUSER-ID กับกุญแจเครื่องของเจ้าหน้าที่ระดับ Authorized แล้วจะเปลี่ยนแปลงใหม่ เมื่อการทดสอบข้อมูลเสร็จสิ้นลงแล้ว

2.1.6. สร้าง Logic และข้อมูลต่าง ๆ เพื่อใช้สำหรับการทดสอบ การสร้างข้อมูลนี้จะต้องคำนึงถึงความสะดวก และจุดมุ่งหมายในการทดสอบด้วย คือ
ก) สร้างข้อมูลขึ้นมาใหม่ทั้งหมด วิธีนี้จะต้องเปิดบัญชีขึ้นมาใหม่ สร้างรายการทั้งที่เกี่ยวกับตัวเลข และประวัติที่อยู่ของลูกค้าขึ้นใหม่ทั้งหมด คงจะเสียเวลาไปบ้าง แต่จะได้ประโยชน์สำหรับการทำงานของเครื่อง คือ ใช้เวลาในการ Sort และการออก Report สั้นและเร็ว เพราะมีจำนวน Data เฉพาะส่วนที่ Key เข้าไปเท่านั้น
ข) ใช้ข้อมูลหรือบัญชีเดิมขององค์กรมาทำรายการต่อไป เช่น ยอดคงเหลือวงเงินต่าง ๆ Clearing Cheque จะมีการเปิดบัญชีและเพิ่มเติมข้อมูลใหม่เข้าไปบ้าง แต่จะน้อยกว่าการสร้างบัญชีขึ้นมาใหม่ วิธีการนี้จะทำให้ใช้เวลาสำหรับการ Key สั้นลง เพราะมีข้อมูลอยู่ใน File แล้วจำนวนหนึ่ง แต่จะมีข้อเสียคือ ใช้เวลาในการทำงานของเครื่องมาก เพราะการ Sort การออก Report จะใช้เวลานาน เนื่องจากมีจำนวน Data อยู่ใน File มาก

ในเรื่องนี้ ผู้ตรวจสอบจะต้องตัดสินใจให้ได้ก่อน แล้วจึงแจ้งแก่องค์กรให้เตรียมการล่วงหน้าก่อนการทดสอบ เพราะมีบางครั้งที่องค์กรไม่สามารถจะสนองความต้องการของผู้ตรวจสอบได้ เช่น องค์กรนัดให้ทำการทดสอบแล้ว แต่พอถึงเวลาจริง องค์กรไม่สามารถจะหา Tape ม้วนที่ Copy ไว้ได้ หรือการทำ Copy Data File ผิดพลาด จึงต้องเปลี่ยนเวลาการในการทำ Test Data ออกไปใหม่อีก
ผู้ตรวจสอบจะต้องแบ่งงานการทดสอบออกเป็นระบบงาน และแยกความรับผิดชอบเป็นรายบุคคล เพื่อไม่ให้เกิดความยุ่งยากสับสน และอาจทำให้ล่าช้าลงได้

2.1.7. ต้องพยายามแบ่งงานการ Key ให้เสร็จไปพร้อม ๆ กันทุกงาน โดยเฉพาะการปลด Lock Cheque ควรจะทำไปในเวลาพร้อม ๆ กัน หรือใกล้เคียงกัน เพื่อบริการเวลาให้สูญเสียน้อยที่สุด เพราะหากงานหนึ่งเสร็จก่อน แต่จะทำรายการต่อไปไม่ได้ต้องรอให้ปลด Lock Cheque ก่อน ในขณะเดียวกันงานอื่นยังไม่สามารถให้ทำรายการปลด Lock Cheque ได้ จึงทำให้งานที่ทำเสร็จก่อนต้องเสียเวลารอคอย

2.2. ระหว่างการ Key ข้อมูล

2.2.1. ต้องแจ้งให้องค์กรทราบว่า วันที่ในระบบงานที่กำหนดให้ทำ Test Data เป็นวันเดือนปี ใด Yesterday และ Next day เป็นวันที่เท่าใด Clearing Hold กี่วัน ทั้งนี้ เพื่อใช้สำหรับการออกวันที่ใน Report และการคิดดอกเบี้ย ฯลฯ

2.2.2. ผู้ตรวจสอบควรจะต้องมีโจทย์ไว้ 2 ชุด คือ ชุดรูปถ่ายที่ไม่มีผลที่คาดว่าจะเกิดขึ้นมอบให้แก่ Operator 1 ชุด เพื่อใช้สำหรับ Key ได้อย่างรวดเร็ว ส่วนอีกชุดหนึ่งมีผลที่คาดว่าจะเกิดขึ้น (Expectation) ผู้ตรวจสอบจะต้องถือไว้คอยกำกับการ Key และจด Output หรือ Response ที่เครื่องแสดงออกมา

2.2.3. ในระหว่างที่ Operator ทำการ Key แล้ว แจ้งแก่ผู้ตรวจสอบว่า อาจจะ Key ไม่ได้หรือขัดข้องแน่ จะขอข้ามไปหรือแก้ไขโจทย์ได้หรือไม่

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

2.2.4. ก่อนการปลด Lock Cheque Clearing อย่าลืมให้ Operator ผู้รับผิดชอบทำรายการ Key รายละเอียดเช็คฉบับที่คืน (Return Cheque) เสียก่อน หากไม่ทำ Step นี้โดยปลด Lock เช็คแล้วจะถือว่าทั้งหมดผ่านการ Clearing

2.3. เมื่อเสร็จสิ้นการ Key

2.3.1. เมื่อเสร็จสิ้นการ Key ข้อมูลแล้ว ควรจะให้มีการพิมพ์รายละเอียดและยอดรวมของ Teller ทุกคน

2.3.2. ขอให้ออก Journal Roll จากเครื่อง Printer และเก็บโจทย์ที่มอบให้แก่ Operator กลับคืนโดยครบถ้วน

2.3.3. ก่อนจะปิดเครื่อง ตรวจนับ PASS-BOOK และ SLIP ต่าง ๆ ว่าได้รับคืนมาครบถ้วนหรือไม่ เพราะบางองค์กรหากปิดเครื่องไปแล้วจะให้เปิดและทำรายการใหม่ไม่ได้

2.3.4. ตรวจนับ Report ที่ได้รับว่าครบถ้วนตามที่ต้องการหรือไม่

 

การทดสอบข้อมูลโดยวิธี Test Data (ต่อ)

ครั้งที่แล้วผมได้เล่าสู่กันฟัง ถึงเรื่องของการทดสอบข้อมูลและกระบวนการทำงานในระบบคอมพิวเตอร์ โดยวิธี Test Data (TDM) ว่า เหตุใดหรือมีความจำเป็นใดที่ต้องใช้วิธี Test Data ในการตรวจสอบ และวิธีการดังกล่าวจะนำมาใช้ในกระบวนการตรวจสอบได้อย่างไร ซึ่งวันนี้ผมจะมาเล่าในรายละเอียดของ TDM ต่อ แต่เนื่องจากรายละเอียดนั้นค่อนข้างเยอะ ผมจึงขอนำเสนอเป็นตอน ๆ พร้อมยกตัวอย่างประกอบ เพื่อให้เข้าใจได้ง่ายยิ่งขึ้นครับ

Test Data คือ อะไร

Test Data เป็นข้อมูลที่ผู้ตรวจสอบจัดทำขึ้น เพื่อใช้ตรวจสอบความถูกต้องของการทำงาน และการควบคุมของโปรแกรมระบบงาน โดยนำข้อมูลที่สมมติขึ้นไปประมวลผลกับโปรแกรมที่องค์กรใช้งานอยู่จริง แล้วนำผลลัพธ์ที่ได้ไปเปรียบเทียบกับผลลัพธ์ที่ผู้ตรวจสอบคำนวณหรือคาดไว้ล่วงหน้า ด้วย Manual ดังรูป

Test Data Method

การสร้างข้อมูลตัวอย่างทดสอบ (Audit Test Data)
การใช้ตัวอย่างข้อมูลเพื่อประเมินคุณภาพของโปรแกรม เป็นเทคนิคเบื้องต้นในการเก็บรวบรวมหลักฐานอย่างหนึ่ง โดยตั้งอยู่บนพื้นฐานที่ว่า ผู้ตรวจสอบจะให้ความเชื่อถือต่อโปรแกรมที่ใช้งาน หากผลการทดสอบเป็นที่น่าพอใจ

ผู้ตรวจสอบจะใช้เทคนิค Test Data ในการทดสอบ และตรวจสอบประเด็นต่าง ๆ ดังต่อไปนี้
1. ขั้นตอนและวิธีการในการอนุมัติรายการข้อมูลนำเข้า การหาสาเหตุของข้อผิดพลาด และการควบคุมระบบงาน
2. ความสมเหตุสมผลของขั้นตอนการประมวลผล และการควบคุมการสร้างและปรับปรุงแก้ไขข้อมูลในแฟ้มข้อมูลหลัก
3. ความถูกต้องในการทำงานของโปรแกรมคำนวณต่าง ๆ เช่น ดอกเบี้ย ค่าใช้จ่าย ค่าเสื่อมราคา
4. การบันทึกการเปลี่ยนแปลงแก้ไขโปรแกรม

ขั้นตอนการจัดทำ Test Data และตัวอย่าง

1. ขั้นตอนการจัดทำ Test Data

1.1. กำหนดวัตถุประสงค์หรือเป้าหมายของากรทดสอบในแต่ละเรื่องของกิจกรรม ที่พิจารณาว่าอาจก่อให้เกิดความเสี่ยง
1.2. กำหนดจำนวนรอบเวลาบัญชีหรือข้อมูล (Cycle) ที่จะใช้ในการทดสอบ ให้สอดคล้องกับเป้าหมายของการทดสอบที่กำหนดไว้
1.3. สร้างเงื่อนไขหรือประเภทของรายการที่จะทดสอบให้สัมพันธ์กับเป้าหมาย ให้สามารถคาดคะเนผลลัพธ์ที่จะออกมาได้
1.4. จัดเตรียมข้อมูลที่จะทดสอบตามเงื่อนไขที่ได้สร้างไว้ และจำแนกตามรอบเวลา (Cycle) ที่ได้กำหนดไว้
1.5. คำนวณผลลัพธ์ที่คาดว่าจะได้รับด้วย Manual (ขั้นตอนนี้จะเป็นการฝึกฝน และเพิ่มพูนความเข้าใจของผู้ตรวจสอบ ต่อระบบงานที่ตรวจสอบได้โดยละเอียด)
1.6. ประมวลผลข้อมูลทดสอบที่ได้เตรียมไว้ ตามกระบวนการที่กำหนดไว้ในการประมวลงานตามปกติ
1.7. ตรวจสอบผลลัพธ์ที่ได้จากการประมวลผลด้วยคอมพิวเตอร์ โดยนำไปเปรียบเทียบกับผลลัพธ์ที่คาดว่าจะได้รับตามที่คำนวณได้ด้วย Manual
1.8. สรุปผลการทดสอบและระบุจุดอ่อนที่พบ ซึ่งผู้ตรวจสอบจะต้องระบุสาเหตุของจุดอ่อนแต่ละประเด็น และให้คำแนะนำในการปรับปรุงแก้ไข

โปรดติดตามขั้นตอนต่อไปในครั้งหน้านะครับ

 

การทดสอบข้อมูลและกระบวนการทำงานในระบบคอมพิวเตอร์ โดยวิธี Test Data (TDM)

วันนี้ผมจะพาท่านผู้อ่านที่สนใจทั้งทางด้าน IT Audit และทางด้าน Manual Audit เพื่อจะก้าวไปสู่การควบคุมภายใน และการตรวจสอบภายในตามฐานความเสี่ยงขององค์กร ที่ประมวลผลโดยคอมพิวเตอร์ว่า ข้อมูลทางด้าน Input – Process – Output ถูกต้อง และน่าเชื่อถือได้หรือไม่นั้น เป็นกระบวนการสำคัญยิ่งของการตรวจสอบภายใน ซึ่งมีหน้าที่หลัก 2 ประการใหญ่ ๆ ก็คือ การให้ความมั่นใจอย่างสมเหตุสมผลว่า ข้อมูลและรายงานถูกต้องน่าเชื่อถือได้และสมบูรณ์ในเวลาที่ต้องการ ไม่ว่าจะเป็นเป้าหมายในการตรวจสอบ Around The Computer หรือ Through The Computer ซึ่งเทคนิคหลังเป็นการตรวจสอบความน่าเชือถือได้ของโปรแกรมที่ใช้ในการประมวลงาน

เทคนิคการทดสอบข้อมูลและกระบวนการทำงานโดยใช้ TDM นี้ ไม่จำเป็นต้องเสียค่าใช้จ่ายในการซื้อโปรแกรม หรืออุปกรณ์ใด ๆ แต่ต้องอาศัยความรู้ความเข้าใจระบบงานและกระบวนการทำงานทางด้านคอมพิวเตอร์ที่เกี่ยวข้อง โดยเฉพาะอย่างยิ่ง ความเข้าใจในการสร้างข้อมูลทดสอบตาม Logic หรือ ตรรกะ ที่เกี่ยวข้องและเชื่อมโยงกับเป้าประสงค์ในการทดสอบกระบวนการควบคุมและกระบวนการประมวลงาน ในมุมมองต่าง ๆ ที่ผู้ตรวจสอบต้องการ โดยเฉพาะอย่างยิ่ง การเปรียบเทียบข้อมูลและผลลัพธ์ที่คาดไว้ก่อนการทดสอบ TDM และข้อมูลผลลัพธ์ที่ผ่านการทดสอบ TDM เพื่อแปลให้ได้ความหมายว่า Process และ/หรือ Output ถูกต้องตามที่ควรจะเป็นหรือไม่

ทั้งนี้ กระบวนการทดสอบดังกล่าว อาจทำความเข้าใจได้ดังจะได้อธิบายตามลำดับดังนี้

Test Data Method

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

เครื่องมือและเทคนิคที่ใช้ในการตรวจสอบมี 2 กลุ่มใหญ่ ๆ คือ
1. เทคนิคการตรวจสอบคอมพิวเตอร์ที่ใช้ตรวจสอบภายหลังจากการประมวลผล
2. เทคนิคการตรวจสอบคอมพิวเตอร์ที่ใช้ตรวจสอบขณะที่ทำการประมวลผล

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

การใช้ Data จัดอยู่ในกลุ่มเทคนิคการตรวจสอบคอมพิวเตอร์ที่ใช้ตรวจสอบภายหลังจากการประมวลผลเป็นเทคนิคที่นิยมแพร่หลาย โดยมีเหตุผลของการนำมาใช้ คือ

1. เพื่อทดสอบระบบการควบคุมภายในของโปรแกรม คือ พิจารณาว่าได้มีการพบรายการที่ไม่สมเหตุสมผล ไม่เหมาะสม ไม่สมบูรณ์ ไม่ถูกต้อง จากระบบการควบคุมของโปรแกรม และมีการแก้ไขที่ถูกต้องหรือไม่

2. เป็นวิธีที่มีประสิทธิผลในการยืนยันความเข้าใจของผู้สอบบัญชี ต่อระบบงานที่สลับซับซ้อน ผู้ตรวจสอบอาจต้องการใช้ Test Data นี้แตกต่างจากการใช้ เพื่อทดสอบการปฏิบัติตามระบบการควบคุมภายในที่ได้กำหนดไว้ ซึ่งเป็นข้อหนึ่งของการตรวจสอบ

การนำ Test Data มาใช้ในการตรวจสอบ
1. ขั้นตอนการตรวจสอบงานด้านคอมพิวเตอร์

การนำ Test Data มาใช้ในการตรวจสอบ

จากผังแสดงขั้นตอนงานตรวจสอบงานด้านคอมพิวเตอร์ข้างต้น จะเห็นว่าเมื่อผู้ตรวจสอบเข้าทำการตรวจสอบจะต้องศึกษาและประเมินประสิทธิภาพการควบคุมภายในเสียก่อน ทั้งนี้ เพื่อใช้กำหนดขอบเขต วิธีการตรวจสอบ และ ระยะเวลาที่จะใช้ หากผู้ตรวจสอบมีความพึงพอใจและเชื่อมั่นในระบบการควบคุมภายใจของกิจการ ก็จะทำการทดสอบว่ามีการปฏิบัติตามระบบการควบคุมที่วางไว้หรือไม่ เรียกว่า ทำ Compliance Test ซึ่งประกอบด้วยการสอบทาน General Controls และ Application Controls หากพบว่าระบบที่วางไว้ดีแต่ยังไม่พอใจในการปฏิบัติตามระบบ ก็ต้องพิจารณาว่ามีการควบคุมอย่างอื่นมาชดเชยหรือไม่ (เช่น การควบคุมทางด้านผู้ใช้) หากไม่มีก็จะต้องจัดทำ Substantive Test ที่ครอบคลุมถึง 100% เพื่อให้ได้มาซึ่งหลักฐานในการยืนยันความถูกต้องของยอดคงเหลือทางบัญชี เช่นเดียวกับในกรณีที่ประเมินประสิทธิภาพการควบคุมภายใน แล้วผู้ตรวจสอบไม่มีความเชื่อถือในระบบก็ต้องจัดทำ Substantive Test 100% เช่นกัน

ในการจัดทำ Compliance Test และ Substantive Test ผู้ตรวจสอบสามารถเลือกใช้วิธีการตรวจสอบที่มีอยู่อย่างมากมายได้ตามความเหมาะสม “Test Data” เป็นเทคนิคอย่างหนึ่งที่สามารถเลือกใช้ในการทำ Compliance Test ภายหลังจากทำการศึกษาและประเมินประสิทธิภาพการควบคุมภายในแล้วมีความเชื่อถือในระบบพอสมควรก็จะใช้ Test Data เพื่อทดสอบการปฏิบัติตามระบบการควบคุมภายในที่กำหนดไว้ แต่เทคนิคนี้ค่อนข้างจะเน้นการทดสอบการควบคุมภายในของ Program หรือ Application Software คือ การควบคุมด้านข้อมูลนำเข้า (Input) การประมวลผล (Processing) และข้อมูลผลลัพธ์ (Output)

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

วิธีการตรวจสอบความถูกต้องของโปรแกรมวิธีหนึ่ง คือ “การตรวจสอบจาก Source Program Listing” ผู้ตรวจสอบจะต้องไล่ดูทีละ Statement ตามลำดับ เพื่อค้นหาข้อผิดพลาดและจุดอ่อนของโปรแกรม ซึ่งกระทำได้ยากในทางปฏิบัติ ด้วยเหตุผลดังต่อไปนี้

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

2) ผู้ตรวจสอบอาจมองข้ามจุดอ่อนเสียเอง การพัฒนาโปรแกรมให้ใช้งานได้จะต้องใช้เวลานานและทำการทดสอบนับครั้งไม่ถ้วน การตรวจสอบในช่วงเวลาสั้น ๆ จึงไม่อาจมองแง่มุมต่าง ๆ ที่แฝงอยู่ได้อย่างถี่ถ้วน

3) โปรแกรมที่ใช้มักมีการเปลี่ยนแปลงแก้ไขอยู่ตลอดเวลา ถ้าผู้ตรวจสอบวางแผนการตรวจสอบแบบกระจายเป็นระยะตลอดปีบัญชี การที่จะติดตามรายการเปลี่ยนแปลงซึ่งมีจำนวนมาก ทุกรายการย่อมเป็นไปได้ยากในทางปฏิบัติ

ด้วยเหตุผลดังกล่าว การตรวจสอบความถูกต้องของโปรแกรม จึงนิยมใช้วิธีการตรวจสอบทางอ้อม คือ การใช้ เทคนิค Test Data มากกว่า การตรวจสอบจาก Source Program Listing