Doppio Tech OTP Test Automation Framework

Doppio_Toasty-EDlT0R

Automation Test

March 24, 2026

Table of Content

ว่ากันด้วยเรื่องของ Test Automation กับการ test อะไรก็ตามที่ต้องใช้ OTP ส่วนใหญ่คนที่ทำ test automation น่าจะต้องเคยมีจุดที่ปวดหัวกับ OTP ไม่มากก็น้อย เพราะว่า มันเป็นส่วนที่ต้อง interact ระหว่าง test automation ที่เราเขียน กับ SMS ที่ได้ข้อมูลมาจาก sim card ของค่ายโทรศัพท์มือถือ เท่าที่ดูๆ Solution ที่มีคนแนะนำใน internet ทั่วๆไปก็จะมีประมาณนี้

1. ให้ Dev ในทีมช่วย Fix ค่า OTP ให้ใน code เลย คือประมาณว่าถ้าใส่ 1234 คือให้ผ่านนะ อะไรแบบนี้ วิธีนี้ ข้อดีคือ ง่าย (ถ้าสามารถคุยกับ Dev ให้ช่วยทำได้) ส่วนข้อเสียคือ 1. ยาก (ถ้าไม่สามารถคุยกับ Dev ให้ช่วยทำได้) 2. ต้องมีการแก้ code ทำให้ code ที่เรา test ไม่ใช่เวอร์ชั่นที่จะเอาขึ้น production เป๊ะๆ 3. ความเสี่ยงในการเอา code test fix OTP นี้ขึ้น production โดยไม่ได้ตั้งใจ

2. ให้ Dev ช่วย provide API ให้ โดยจะเป็น API ที่เราเรียกเพื่อส่ง parameter แล้วขอ OTP ที่ทาง product generate ส่งไป SMS นั่นแหล่ะ วิธีนี้ ข้อดีคือ ไม่ต้องแก้ไขตัว product under test ดังนั้นจะเป็นการ test ที่เสมือนจริง ข้อเสียคือ ต้องพึ่งพา Dev ที่จะ provide API ตัวนี้ให้ คือถ้าเค้าไม่ทำให้ก็จ๋อย ทำไม่ได้จ้า

3. ท่าอ้อมโลก แต่ก็ทำได้ถ้าจะทำ คือให้มี automation script 2 scripts แล้วให้ script แรกรัน test ไป พอถึงจุดที่เป็นการขอและรอ OTP ก็ไปเรียก อีก script (เป็น Appium ก็ได้) ให้ control มือถือเครื่องนึงที่มี sim card อยู่ แล้วให้ไปเปิด message box อ่าน OTP มา แล้วให้ script นี้ส่ง OTP ไปให้ script แรกใช้กรอกข้อมูลแล้วไปต่อ ข้อดีคือ ก็ทำได้ ไม่ต้องการความช่วยเหลือจากใคร ข้อเสีย คือ ทำยาก และโอกาสเจอ flaky test สูงมากเพราะ script มีโอกาสตายได้จากหลายๆส่วน ถ้าสะดุดที่นึงไม่ว่าจะจาก script 1 หรือ 2 ข้อนั้นทั้งข้อก็จะ fail ไปเลย และด้วยความเป็น Appium มันจะทำให้เทสรันนานมาก กว่าจะรัน case OTP ได้แต่ละ case จะใช้เวลานานนน น หนูล้านตัว

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

ไปดูตัวอย่างการทำงานให้พอเห็นภาพได้จากลิ้งนี้นะครับ แล้วมาดูกัน solution เบื้องหลังกันว่ามันทำยังไง

สิ่งที่ต้องมี/เตรียม

1. โทรศัพท์มือถือหนึ่งเครื่องใส่ sim card ไว้ สมมติในตัวอย่างนี้ ใส่ sim เบอร์ 081–1111111 ไว้ และโทรศัพท์เครื่องนั้น install Doppio OTP application ไว้

2. API server ซึ่งมี Doppio OTP api รันอยู่

คำอธิบายสั้นๆของ tool สองตัวนี้

Doppio OTP mobile app คือ App ง่ายๆ ที่เราเขียนให้มันดัก SMSจากโทรศัพท์แล้วเอา content ที่ได้ไป post ข้อมูลเข้า api server

Doppio OTP api server คือ service ที่เราเขียนขึ้นเพื่อรับ Post จาก mobile app แล้วเอา data ที่ได้ไปเก็บใน DB และสามารถให้ automate script ยิง api มา Get ค่านั้นได้ โดย parameter เบื้องต้นคือ 1. เบอร์โทรศัพท์ 2. SMS sender (ในคลิปตัวอย่างคือ Shopee) 3. Date/Time (from-to) ใส่เป็น range เพื่อช่วยหา SMS ที่เรา target

มาไล่ step การทำงานกัน

Step (1) ตัว automate script ของเราไปใส่เบอร์โทรในช่องเบอร์โทรศัพท์ของ product under test เพื่อขอ OTP กด submit

Step (2) ตัว web/product under test ก็จะไปทำงานของมัน สุดท้ายก็จะมีการส่ง OTP ผ่านระบบโทรศัพท์มือถือมาที่ตัวโทรศัพท์ที่เราเตรียมไว้

Step (3) Doppio OTP app ที่รันไว้เป็น background บนโทรศัพท์เครื่องนั้นจะดักเจอ SMS ที่วิ่งเข้ามาแล้วเอาข้อมูลใน sms พร้อมทั้ง sender ส่ง Post request ไปที่ Doppio OTP api server ซึ่งข้อมูลจะถูกเอาไปเก็บไว้ใน Database

Step (4) ตัว automate script หลังจาก submit เบอร์โทรศัพท์ไปใน Step (1) ก็วนหลูปคอย Get OTP information จาก API server ด้วย parameter ต่างๆตามที่บอกไว้ด้านบน

Step (5) พอเจอข้อมูล OTP ของตัวเองก็เอารหัส OTP มากรอกที่ Product under test แล้วก็ไหล flow ต่อไปตาม script ได้ เย่

จะเห็นว่าด้วย Framework นี้ไม่ใช่แค่ test OTP แต่ใช้ test SMS feature ได้หมดเลย เช่น SMS ที่ส่งเพื่อ confirm การสั่งซื้อ การจ่ายตังค์ อะไรพวกนี้

ตัว solution นี้ เหมือนจะยุ่งยาก ต้องมีการเขียนทั้ง mobile app และ api server แต่มันเป็น solution ที่ทำแล้วจบ ตัว automate script ที่ใช้ solution นี้ จะทำ test ได้เสมือนจริงเพราะไม่มีการไปแตะ ไปแก้ code ของ product under test และเป็น solution ที่ stable และเร็ว ไม่ต้องไปสร้าง dependency กับ appium script อีกหนึ่งตัว ส่วนปัญหาที่ต้อง implement ตัว app กับ api server ก็ไม่ต้องห่วง เดี๋ยวแจก Doppio OTP app ให้ใช้จ้า ซึ่งจะมาต่อกับ api server ที่เราตั้งไว้ให้ใช้ได้โดยอัตโนมัติ ขอเวลาทำตัว app กับ api ให้พร้อม support คนใช้หลากหลายอีกนิส แล้วเดี๋ยวแจกให้เอาไปใช้ได้เน้อ ไปรอของกันได้ที่ page ของ Doppio Tech ได้นะครับ ไว้จะไปประกาศแจกที่ช่องทางนั้นละกัน

Related Blog

Automation Test

คิดและเลือก automation framework อย่างไรในปี 2023

จริงถึงแม้จะจั่วหัวไว้ว่าเป็นปี 2023 แต่จริงๆหลักการนี้ใช้ได้ทุกปีแหละครับ แหะๆ ซึ่งบทความนี้ได้แรงบันดาลใจจากที่ว่า ช่วงนี้น้องๆ หลายคนที่เคยทำงานด้วยกัน ทักมาปรึกษาโน้นนี่นั่นกันอยู่เป็นระยะๆ หลายๆครั้งมีน้องบางคนเข้าไปทำงานในบริษัทที่ยังไม่มี Automation เลย พูดง่ายๆ คือการเข้าไปเริ่มตั้งไข่ให้เองนักเลงพอ และหลายคนจะกลับมาถามคำถามเดียวกัน (คำถามเดียวกันจริงๆนะ) บทสนทนาจะเป็นประมาณนี้ น้อง : พี่โอ ว่างไหมพี่โอ : ครับน้อง : สบายดีนะครับโอ : สบายดีครับ เราล่ะเป็นไงบ้างน้อง : พี่โอ cypress นี่ดีไหมครับ (ไม่พูดพร่ำทำเพลง get to the point ดีมาก) พอคุยไปคุยมา เรามักจะได้คำตอบว่า น้องได้รับมอบหมายว่าให้เริ่มต้นทำ Automation โดยเริ่มตั้งแต่เลือก Framework ไปจนถึงวาง Project structure วันนี้เลยอยากจะมาลองแชร์ว่า ปกติเวลาเราจะเลือก Framework มาใช้เนี่ยเราควรดูอะไรบ้าง แต่ก่อนจะเข้าเรื่องบอกก่อนเลยว่า มันไม่มีคำว่า “ดี” หรือ “ไม่ดี”…

QA

สามเหลี่ยม’ ที่จะช่วยจัดการ project ให้ดี

"สามเหลี่ยมกู้ชีพ" เคล็ดลับการบริหารโปรเจกต์และต่อรองฉบับสายเทค ในการทำงานสาย Tech ไม่ว่าจะเป็น Developer, QA หรือ Software Tester ปัญหาที่พบบ่อยที่สุดคือ "เวลาไม่พอ" หรือ "สโคปงานที่เพิ่มขึ้นกะทันหัน" หลายคนเลือกที่จะแก้ปัญหาด้วยการทำงานหนักหรืออยู่ล่วงเวลา (OT) แต่วิดีโอนี้ได้นำเสนอทางออกที่ยั่งยืนกว่าผ่านแนวคิด "สามเหลี่ยมบริหารจัดการ" 1. รู้จัก 3 แกนหลักของสามเหลี่ยม หัวใจสำคัญของการบริหารโปรเจกต์ประกอบด้วย 3 ส่วนที่สัมพันธ์กันคือ เวลา (Time), ขอบเขตงาน (Scope) และ ทรัพยากร (Resource) กฎเหล็กของสามเหลี่ยมนี้คือ "ถ้าแกนใดแกนหนึ่งเปลี่ยน อีก 2 แกนที่เหลือต้องเปลี่ยนตามเพื่อรักษาความสมดุล" ตัวอย่างเช่น หากเวลาลดลง (Deliver ช้าลง) สิ่งที่ต้องพิจารณาคือ: เพิ่ม Resource: อาจจะขอคนเพิ่ม แต่ต้องเป็นคนที่มีความรู้อยู่แล้ว (Knowledge) ถึงจะช่วยได้จริง ซึ่งในความเป็นจริงนั้นหาได้ยาก ลด Scope: นี่คือสิ่งที่ควรตั้งคำถามกับ PM หรือลูกค้าว่า "มีส่วนไหนที่ตัดออกได้บ้างเพื่อให้เราส่งมอบงานได้ทันเวลา?"…

QA

Software Tester/QA 100.1

วันนี้มาด้วยชื่อ blog แปลกๆ คือปกติมันต้องเริ่มด้วย 101 แต่ว่าอันนี้มันยิ่งกว่า 101 มันเป็นจุดเริ่มต้นยิ่งกว่านั้นเอาเป็นชื่อ 100.1 ละกันนะ Inspiration เริ่มมาจากมีน้องๆหลายคนมากมาสมัครงานแบบที่ไม่มีประสบการณ์ software testing เลย มีทั้งแบบ new grad และแบบที่อยากเปลี่ยนสายงาน จาก IT support มั่ง Sale มั่ง Admin มั่งทั้งที่จบตรงและไม่ตรงสาย เอาจริงๆเห็น potential น้องๆหลายคนเลยนะ ที่สามารถเรียนรู้และเปลี่ยนสายงานได้ (แล้วก็หางาน QA ให้ได้สำเร็จ ของไม่ตรงสายได้แล้วหนึ่งคน เย่) คือที่เห็น น้องๆหลายคนอยากเปลี่ยนสาย ก็พยายามไปหาความรู้ บางคนเริ่มไปดู automate บางคนไปอ่านกับเรียนวิธีการ test text box ต่างๆ เอาจริงๆก็ดีใจที่เห็นน้องอยากเปลี่ยนสายแล้วลงทุนเรียนรู้ แต่อีกมุมนึงก็รู้สึกว่าหลายๆคนไปกันแบบโหวงๆ ยังไม่รู้ด้วยซ้ำว่าจุดที่ชั้นไปอ่านไปเรียนมันคือตรงไหนของงาน ไม่เข้าใจลักษณะงานหลักๆเลยด้วยซ้ำ ก็เลยตั้งใจเขียนอันนี้ไว้เป็น guideline ให้มือใหม่อยากเข้าวงการ ให้อ่านแล้วเห็นภาพใหญ่ ก่อนจะเจาะลึกแต่ละส่วนละกันนะ…