สิ่งที่ควรเข้าใจและพึงระวังเมื่อเป็น QA

Doppio_Toasty-EDlT0R

QA

March 24, 2026

Table of Content

บทความนี้ขอเป็นฉบับสั้นๆที่รวบรวมสิ่งต่างๆที่คอยเตือนน้องๆในทีม (จากคนที่เคยเจ็บมาก่อน)

จงเข้าใจ product (รวม use case, business และ architecture ของมัน) ก่อนจะคิด test strategy

จงเข้าใจ requirement เป็นอย่างดีก่อนจะคิดทำ test case design (ถ้าไม่อย่างงั้น คุณจะได้มอเตอร์ไซค์ ที่ผ่านการเทสมาอย่าง perfect ในขณะที่ลูกค้าอยากได้จักรยาน ไม่ใช่มอเตอร์ไซค์)

จงเข้าใจ testing technique ต่างๆเป็นอย่างดี ข้อดี ข้อเสีย ความเหมาะสมกับ product/requirement แต่ละประเภท ก่อนที่จะคิดใช้ testing technique เพื่อ optimize test case/coverage

จงคิดก่อนว่า automation test ที่กำลังจะเขียนต้องสามารถถูก execute ได้วันละหลายร้อยรอบโดยไม่ต้องมีคนไปเตรียม data หรือมี process manual ไป clear data หลังรันเสร็จ จงทำขั้นตอนเหล่านั้นให้อยู่ใน automation step/process

จงคิดไว้เสมอว่า automation test ที่กำลังจะเขียนจะต้องถูกรันไปได้อีกเป็นปีๆ โดยที่ไม่ต้องไปคอยเปลี่ยนวันที่ใน script เมื่อเวลาผ่านไป (อันนี้เจอบ่อยมากอย่างน่าเศร้า)

จงวาง architecture และ design ของ automation ก่อนเริ่มเขียนโค้ด (รับ input จากไหน ไปเช็ค/validate expect result จากไหน)

จงวาง framework การรัน automate ซ้ำๆก่อนเริ่มเขียน first line of automation script code และเมื่อทำ framework การรันซ้ำเสร็จก็แค่ทยอยวาง script ที่เขียนเสร็จเพิ่มลงใน framework นั้นๆ (เช่นเขียน Jenkin job ให้รัน test suite ทุกๆหนึ่งชั่วโมง เพื่อวัด และปรับจูน stability/flakiness level ของ script เราตั้งแต่ script แรกตั้งแต่ day one ไม่ใช่ไปรู้เอาตอนหลัง เสร็จแต่ละ script ก็เอาไปเพิ่มใน suite)

จงคิดและเข้าใจก่อนว่า test automation ที่กำลังจะสร้างขึ้นมามันต้องมาช่วยอะไรเราซักอย่าง (ไม่ใช่ว่า แค่ให้มันมี automation และ sound cool) ไม่ว่าจะเป็นการทำให้ test ได้เร็วขึ้น (ถ้าอยากให้เร็วขึ้นคิดก่อนเลยว่าอยากให้เร็วขึ้นเท่าไหร่ ตั้งเป้าให้มันก่อนจะได้เขียน automation ได้ถูกวิธี) หรือช่วยลด effort การรันเทส

สุดท้าย ฝากไว้นิดนึงว่าความรู้ทาง technical/framework knowledge ต่างๆเป็นสิ่งที่เปลี่ยนแปลงตามการเวลา แต่พื้นฐานทางความคิด (core fundamental logic) ต่างๆเพื่อปรับและประยุกต์ใช้ framework ใหม่ๆนั้นเป็นสิ่งที่อยู่กับเราไปตลอดกาล อย่าลืมใส่ใจกับเรื่องพื้นฐานพวกนี้กันด้วยเน้อ

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

Doppio Tech — We Build And Serve Expertise

https://www.facebook.com/Doppio-TECH-101343301368721

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 ให้มือใหม่อยากเข้าวงการ ให้อ่านแล้วเห็นภาพใหญ่ ก่อนจะเจาะลึกแต่ละส่วนละกันนะ…