อบรมหลักสูตร (Interactive Online) Basic Software Testing วันที่ 7 - 8 ตุลาคม 2567

 สถาบันไอเอ็มซี ขอแจ้งยืนยันพร้อมสรุปรายละเอียดของการอบรมหลักสูตรดังนี้ค่ะ

ชื่อหลักสูตร : (Interactive Online) Basic Software Testing

ผู้สอน : อาจารย์จิรภา วรรณสุข

วันที่ : 7 - 8 ตุลาคม 2567

เวลา : 2 วัน (09:00 น. - 16:30 น.)

Course Description


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

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

ทั้งนี้หากอ้างอิงตาม CMMI Framework แล้ว จำเป็นจะต้องมีการนำกระบวนการทดสอบเข้าไปเกี่ยวข้องในทุกขั้นตอนของการพัฒนา ซึ่งเรียกว่า Verification และ Validation Process Area เพื่อช่วยให้สามารถมั่นใจได้ว่างานส่งมอบนั้นและเสร็จสมบูรณ์ทันกำหนดและมีคุณภาพตามความต้องการของลูกค้า

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

Benefits
  • เข้าใจและทราบถึงวิธีการเตรียมความพร้อม และขั้นตอนต่าง ๆ ในการทดสอบระบบงาน

  • สามารถปฏิบัติตามกระบวนการ ตั้งแต่การวางแผน การเตรียมกรณีทดสอบ การเตรียมข้อมูล การทดสอบ การวิเคราะห์ผล และการจัดทำรายงาน

  • เข้าใจพื้นฐานในการทำงานทดสอบระบบเบื้องต้น และสามารถพัฒนาตนเองไปสู่การจัดการ และการวิเคราะห์ทดสอบในระดับสูงต่อไป

Course Outline

    • แนะนำพื้นฐานและทฤษฎีในการทดสอบระบบที่นิยมใช้กันโดยทั่วไป

    • กระบวนการทดสอบระบบงาน

    • แนวทางการทดสอบ

    • ประเภทของงานทดสอบ 

    • การฝึกปฏิบัติในการทดสอบระบบงาน

    • สถานการณ์งานที่ต้องให้ความสำคัญเพื่อให้งานสำเร็จ

    • การศึกษาความต้องการ

    • การประเมินเวลาที่ใช้ในการทดสอบระบบงาน

    • การอ่านแผนการทดสอบระบบ

    • การเขียนกรณีทดสอบ

    • การสร้างข้อมูลทดสอบ

    • การทดสอบระบบงาน

    • การรายงานผลการทดสอบ

    • การจัดเก็บข้อมูลการทดสอบในรูปแบบต่าง ๆ

เรียน คุณปวีนัฐ

 

ทางสถาบันไอเอ็มซี ขอขอบคุณที่ให้เกียรติเข้าอบรมหลักสูตร (Interactive Online) Basic Software Testing อบรมในวันที่ 7 - 8 ตุลาคม 2567 ค่ะ

 

ทั้งนี้ทางสถาบัน IMC ได้ร่วมมือกับ AIS Academy ทำการอัป Digital Badges และ Digital Credential ของหลักสูตร (Interactive Online) Basic Software Testing ขึ้นในระบบ Credly เรียบร้อยค่ะ

 

โดยคุณปวีนัฐ จะได้รับ E-mail แจ้งการรับ badge เมล์จาก AIS Academy via

Credly <admin@credly.com> กด “Accept your Badge” เพื่อดำเนินการค่ะ

(e-certificate สามารถเข้าลิงค์เพื่อดาวน์โหลดได้ค่ะ)

 

จะทำการส่งไปที่อีเมล paveenuc@bot.or.th ที่ใช้สมัครหลักสูตร (Interactive Online) Basic Software Testing เข้ามาค่ะ

 

สามารถดูคู่มือการรับ Digital Badges ได้ที่ https://drive.google.com/file/d/1vBGpnRhARb__1n5b_91JY1gq_eaf9keG/view หรือ ตามไฟล์แนบค่ะ

 

ตัวอย่าง Badge ตามภาพค่ะ

อ ทำ manual test  โดย downloan มาทดสอบ ทดสอบบน web  รายได้ถ้า bug 30 US ถูกๆ 1US 

 

ถ้าอยากได้ตังเยอะๆต้องหา bug ได้มากๆ ละเอียด บางเดือนได้ 6 หลัก  ขึ้นกับความขยัน

 

ช่วง มค กะ มี request หางาน ให้องค์กร จาก local เพราะหาคนไม่ได้  อ จะช่วยทำจนกว่าจะได้คน  ทำมาเป็น 10 ปี 

 

การที่จะได้คนจริงๆ และทำานได้ต้องใช้เวลา 

 

ตปท ค่อนข้างจะมั่นใจว่าทำงาน remote 

 

 

ส่ง API มาให้ตรวจ ทีม dev อาจจะหลุด ได้ความรู้ใหม่ๆ ห้ามทำ automate ให้ทำ manual tester   review flow / interface 

 

ความคาดหวัง expectation มีหลายอย่าง การใช้งาน ใน 1 interface ไ่ม่อยากให้ข้อมูลกระจัดกระจาย ให้อยู่ในหน้าเดียว อย่างทำระบบประกัน หน้าใบสมัคร บันทึกในหน้าจอเดียวกัน เราต้องดูว่า user เค้าทำแล้วใช้ได้จริงไหม บางอย่างไม่ได้เขียนมาใน spec อยากให้ดูก่อนที่จะออกแบบ ถึงจะเปลี่ยนprocess เป็น agile แล้วก้อตาม เราต้องไปพูดคุยกัน  ให้ tester ไปมีส่วนร่วมตั้งแต่เริ่ม project จะได้เข้าใจ 

 

การ key in ต่างๆ บางอย่างควร key หรือให้ auto เช่น ร้าน 7-11 ต้องออกแบบให้พนักงาน key ข้อมูลให้ได้น้องสุด  เช่น มี 3 items ถ้ายิงถูก 3 ที ไม่ต้อง key จะลด key stoke ให้น้อยลง หรือขั้นตอนการทำงานที่ผิดพลาด ลักษณะของ app ที่ดีจะต้องบอกได้ว่าทำตามขั้นตอน 123 ถ้าไม่ดีจะไม่บอก 321 ได้งี้  message ต้องบอกได้ ว่าทำผิดเพื่อลด service desk ได้  ต้องออกแบบ sw ให้ช่วยเหลือตัวเองได้ในระดับหนึง หรือมี message บอกได้ ของ ตปท จะเป็นแนวนี้ 100% จะเป็น FAQ หรือ chat bot ให้ได้ ถ้ามีโอกาสเห็น coding จะช่วยแก้ได้ แต่ถ้าไม่เห็นเราก้อจะบอกได้ช้านิดนึง  เราบอกได้แค่ว่า coding ชุดนี้มีปัญหา 

 

เราใช้ data ในการหาการตรวจสอบ sw app คิดที่จะผลิตขึ้นมา จนถึง test ถ้า sw นี้ยังไม่ได้ใช้งานเราจะ test ไปเรื่อยๆ  process นี้ถูก load เข้า memory แล้วใช้ หรือมันช้า เพราะยิ่งใส่ยิ่งช้า ถูกใช้งานที่ memory  

 

2 เปิด word /excel ดูว่ามี program อะไร แล้ว load ขึ้นมาแล้ว test ถ้ายิ่งทำยิ่งช้า ต้องกลับไปคุยกับทีม dev ว่าเป็นเพราะอะไร เราต้องใช้งานแบบเดียวกับ user ให้เราคิดถึงว่า user ทำงาน current environment เป็นแบบไหน work as expect  เราทำได้แค่เดา ว่าเครื่องลูกค้าใช้เป็น tablet pc nb ว่ายังไง

 

ถ้าคนใช้อยู่บ้านต้องเปิด netflix / youtube เรา test on WIFI /Cellular การ test connection อย่าง cellular จะปลอดภัยกว่า  ดังนั้น SW testing เป้น process ที่ใช้ตรวจสอบว่าเราทำได้ตาม requirement ไหม test เพื่อหา defect แล้วแก้ก่อนใช้งานจริง 

 

เช่น การเกิดอุบัติเหตุทางรถยนต์ เครื่องบิน ถือว่าเป็น critical เพื่อให้แน่ใจว่าไม่มีผลกระทบต่อคนใช้งาน เนื่องจากเป็ชีวิตคน บางทีต้องทดสอบ 2 ปี level of quality งานของเราต้องให้ข้อมูลที่ชัดเจนแต่ละเรื่องมี defect อะไรบ้าง มุมมองยังไง ต้องผ่านกระบวนการยังไงบ้าง

 

ถ้าเราคุยกันก่อนว่าจะ test เรื่องงี้ๆๆ dev ก้อจะไปเขียน program ป้องกันไปหมดแล้ว เราทดสอบจะเจอน้อย ใน community ของการ test จะมีคนอื่น test เหมือนกัน คนที่ดูก้อจะวิเคราะห์ว่าทำไรเราเจอ ใน process ที่ถูกต้องเค้าจะ design และป้องกันการเกิด 

 

การเจอที่ project นี้อาจไปใช้ป้องกันกับ project อื่นได้

 

ทีมทดสอบเอา case ที่เจอมาคุยกัน เช่น ทดสอบ หน้าร้าน หลังร้าน จะทำให้การ rotate หรือ ย้ายงานจะมี knowledge รู้แนวทาง วิธีการหาจะใกล้กัน  เรา test อะไร 1 ดู core function เราต้องหาให้เจอว่าคืออะไร จริงๆ ทั้งหมดถูกเขียนที่ req spec แล้ว ทีนี้เราจะมี req ที่เพิ่มเติม เช่น POS การขายสินค้า ถามว่าการขายเมื่อเสร็จแล้วจบไหม ตอบ ยังไม่จบ ตัวระบบจะถูกผูกเรื่อง VAT register ไหม ดังนั้นนอกจากจะเห็นงานของเราคู่กับกฎระเบียบของภาครัฐ ใบเสร็จรับเงิน ในกำกับภาษี ภาษีมูลค่าเพิ่ม เก็บหลักฐานให้สรรพากรตรวจสอบได้ ต้อง test ได้ว่าหลัง 4 ทุ่มจึงจะขายเหล้าเบียร์ ได้ จึงหยิบ case core fuc hi priority ก่อน

 

2 concentrate  ดูว่าเค้าใช้งานอย่างไร เช่า login ปุ๊ปใช้งาน

 

image

 

ตอน test ต้องดูว่า user เค้า มี envion ไหน เช่นเรามี mac user มี windows มันต้องเหมือนกัน  ถ้าเปลี่ยนเครื่องให้ user ใหม่ต้องดูว่า app เก่าๆ user จะใช้งานต่อได้ไหม

 

เราต้องรู้ regulation บางที่ BA เค้าก้อไม่ได้เขียนหรอก นึกว่ารู้อยู่แล้ว  เราควรศึกษา เช่น กรมสรรพสามิตร แก้โปรแกรมโดยไม่ได้ขอ สูตรคนละแบบ ทำใหเไม่ได้รับการอนุมัติ ทำให้เสียเวลาแก้ไป 4 เดือน test SW แล้ว กม ยังไม่อนุมัติ 

 

บ ประกันข้ามชาติ เราต้องอ่าน กฎต่างๆ ว่าจะ compile ได้กับองค์กรเรา 

 

image

 

เราต้องอ่าน comment ที่ user เขียนมาประกอบ แต่ถ้าในองค์รกเราก้อต้องขอ feedback บางทีเราต้องเป็น user test บอก dev   สอบถามว่า user ใช้งานยังไง เช่น user เอาข้อมูลที่ load มาแล้วมาทำข้างนอกหมดเลย ไม่ใช้ report ที่มีให้

 

แสดงว่า app ตัวนี้ไม่มีปย กัน user ในการวิเคราะห์เลย เราอยากจะปรับ process ในการทำานให้ user เรา finding แล้ว ก้อแจ้งผู้บริหาร ว่าทำไมเสียเวลาในการทำงานมาก

 

การ compact ใครใช้บ้าง ระบบที่เราทำอยู่ operate ได้ทุก platform ไหม

 

เมื่อก่อนเคยทำอะไรได้ของใหม่ได้ของเก่าต้องทำงานได้ แบบเดิม  เช่น เคยมีการ launch ระบบ ได้ 10 นาทีระบบล่มเลย ตายเพราะ performance ไม่ได้  อย่างตอน 7-11 ขายบัตรเดี่ยวไมโครโฟน ทุกคนเข้ามาซื้อบัตร แล้วเลือก ticket ขายไม่ถึง 10 นาที ระบบไม่รองรับการ search ค้นหาข้อมูลกับคนเยอะๆ กลับไปขายที่ Thaiticket เช่นเดิม 

 

ระบบจ่ายยา ต้องตรวจละเอียด เพราะถ้าให้ยาผิด อาจเกี่ยวกับชีวิตได้  วิเคราะห์ข้อมูลผิดพลาด  การแสดงผลใส่แล้วต้องใส่เลยห้ามแก้ ถ้ามีการตรวจใหม่ก้อจะเป็นครั้ง 2 3 อย่างนี้คือ area ที่สำคัญ  เกี่ยวกับชื่อเสียงของ องค์กร

 

image

 

image

 

อาจารทำงานกับ ตปท online 

 

image

 

 

image

 

image

 

ถ้า envi ไม่อยู่กับเรา ก้อ test ไม่ได้ แต่ server มีประเด็นเหมือนกัน  ถ้า down แล้วต้อง resite ไปที่ไหนได้ กำลังอยู่ในการปรับปรุง  ถ้าหายไปเลยลุกค้าจะตีหัวเรา

 
 

image

 

image

 

image

 

image


 

image

 

พอเราเก็บ req เสดเราต้อง review req เพื่อให้มั่นใจว่า cover กับสิ่งที่ stake holder ต้องการจริง

 

กระบวนการ test ต้อง check ความถูกต้องของ req ถ้าเรามีส่วนร่วมตั้งแต่เก็บ req เช่นทำระบบ หน้าบ้านหลังบ้านมา ทำระบบ supermarket  มาก่อนทำ 7-11 และทีมงานที่ทำรู้จักกันมาก่อน แนะนำให้เรารู้ เพราะว่าเราเข้ามาทำให้ระบบดีขึ้น สะดวกขึ้น เลือกร้านที่เราจะไปฝึกงานที่ 7-11 เป็นเวลา 7 วัน 3 กะ ทำให้เรา review req ถ้าเราเป็น ผจก ต้องการอะไรในร้าน เป็นการ train เล็กๆ 

 

พออ่าน requirement แต่ละบรรทัด สิ่งที่เราคิดคือถ้ามันทำเสร็จแล้วจะใช้งานอย่างไร ต้องหาให้ได้ว่าอะไรที่เราจะทดสอบ 

 

ระบบ ordering ของร้าน การสั่งสินค้า วิธีการสั่งสินค้าสั่งอย่างไร เมนู order ใส่ barcode ใส่จำนวน รวบรวม  พอสิ้นวัน auto ส่ง สนญ  การสั่งบน pc กับ pantel ต้องสั่งได้ user interface --> final ที่ สนญ จากร้านเรา

 

ถ้าระบบมีปัญหาจะสั่งสินค้าอย่างไร ที่ pc มีแต่รหัสสินค้า ไม่มี barcode ระบบต้องบอกได้ว่าเรา key รหัสสินค้าผิด ฝั่งรับต้องบอก error ได้ด้วย มีการ handel ไว้ด้วยหรือเปล่า บางครั้ง business rule ไม่ได้เขียนใน functional spec 

 

file size ไม่เกินเท่าไร รับไปแล้วจะ spit ส่งอย่างไร ต้องรับ order ถูกวันด้วย 

 

ถ้ามันไม่เขียนที่ req spec เราต้องถาม

 

image

 

ต้องดูว่าแต่ละ func มีอะไรบ้าง แต่ละ task ทำงานอะไรบ้าง ตรง web app เราไม่ได้เขียน เราเขียนที่ app เท่านั้น  อย่าง database server ไม่ทำงานเราจะทำไงต่อ

 

ถ้าเราเปิด web แล้วมันใช้งานได้จริง ใช้อย่างรวดเร็ว ต้องตีความคำว่าเร็ว กด confirm ต้องใช้เวลาภายในกี่วินาที  บางอันไม่ได้เขียนแต่ว่าเป็นมาตรฐาน นับ 12345 ต้องขึ้นหมด  แต่อย่าเขียนกดดัน dev มากนัก

 


http://103.122.245.122/crudApp/index.php
link ของ app ที่จะทดสอบกันค่ะ


ความคิดเห็น

บทความที่ได้รับความนิยม