QA
QA คนไหนมี Hardskill ดีแล้ว อย่าลืมฝึก Softskill ไว้ด้วยนะ #doppiotech #สายเทค #softwaretester
QA เก่งแค่ Hard Skill พอไหม? ทำไม Soft Skill ถึงเป็นอาวุธลับที่ทำให้คุณกลายเป็น "Star" ในทีม ในคอมมูนิตี้ของคนทำงานสายเทคและ QA มักจะมีคำถามยอดฮิตว่า "ถ้าอยากเก่งขึ้นต้องเรียนรู้อะไร?" หรือ "อยากย้ายสายต้องฝึกสกิลไหน?" ซึ่งคำตอบส่วนใหญ่มักจะพุ่งเป้าไปที่ Hard Skill เช่น การทำ Automation, การเรียนรู้เครื่องมือใหม่ๆ หรือเทคนิคการเขียน Test Case แต่ในมุมมองของผู้สัมภาษณ์งานและหัวหน้าทีม ความจริงที่น่าสนใจคือ มีผู้สมัครจำนวนมากที่ไปเรียนรู้ทักษะทางเทคนิคมาสารพัด แต่กลับไม่มีความโดดเด่นเพียงพอที่ทำให้บริษัทรู้สึกว่า "ต้องรับคนนี้เข้าทำงานให้ได้" Hard Skill คือพื้นฐาน แต่ความเก๋าอยู่ที่ "การจัดการ" สำหรับ QA ที่มีประสบการณ์ 4-5 ปี การเขียน Test Case ให้ดีเป็นเรื่องที่ควรทำได้อยู่แล้ว แต่ความแตกต่างระหว่าง Test Case ที่สมบูรณ์แบบ (Perfect) กับเกือบสมบูรณ์แบบนั้นไม่ได้สร้างความแตกต่างให้ตัวคุณดู "เฉิดฉาย" ในสายตาหัวหน้าเท่ากับ "สกิลในการจัดการ"…
QA101 รวมทุกสิ่งที่ Software Tester มือใหม่ควรรู้
เจาะลึกโลก Software QA: จากมือใหม่สู่เส้นทางมือโปร (QA 101) ในโลกของการพัฒนาซอฟต์แวร์ ไม่ว่าจะเป็นแอปพลิเคชันช้อปปิ้งออนไลน์หรือแอปธนาคาร หน้าที่ในการเขียนโค้ดเป็นของโปรแกรมเมอร์ (Developer) แต่คนที่จะตอบได้ว่าแอปนั้นใช้งานได้จริงและมีคุณภาพหรือไม่ คือ Software QA (Quality Assurance) หรือ Software Tester 1. หัวใจของการทดสอบ: Functional vs Non-functional งานของ QA แบ่งออกเป็นสองมิติหลักที่ต้องตรวจสอบ Functional Test: คือการดูว่าซอฟต์แวร์ "ทำอะไรได้บ้าง" ตามที่กำหนดไว้หรือไม่ เช่น ต้องล็อกอินได้ ค้นหาสินค้าได้ หรือชำระเงินสำเร็จ Non-functional Test: คือการดูว่าซอฟต์แวร์ "ทำงานได้ดีแค่ไหน" (How well) เช่น ความเร็วในการตอบสนอง (Performance), ความง่ายในการใช้งาน (Usability/UX), และความปลอดภัย (Security) ตัวอย่างเช่น หากล็อกอินผ่านแต่ต้องรอถึง 2 นาที แบบนี้ถือว่าสอบตกในแง่ Non-functional…
Dev ส่งงานไม่ทัน ทำยังไงกะ QA ดี#doppiotech #softwaretester #สายเทค #QA #testing #DEV
เมื่อ Dev ส่งงานไม่ทัน... ควรทำอย่างไรกับ QA? ในสถานการณ์ที่ Developer (Dev) เล็งเห็นว่าไม่สามารถส่งงานได้ทันตามกำหนดเวลา สิ่งสำคัญไม่ใช่การปกปิดปัญหา แต่คือการบริหารจัดการร่วมกับทีม โดยเฉพาะฝ่ายประกันคุณภาพ (QA) ซึ่งมีแนวทางที่น่าสนใจดังนี - การสื่อสารที่โปร่งใสและตรงไปตรงมา: ทีมที่มีประสิทธิภาพควรมีการสื่อสารกันอย่างชัดเจน เมื่อรู้ว่างานจะล่าช้า Dev ควรเดินเข้าไปแจ้ง QA พร้อมขอโทษและระบุระยะเวลาที่คาดว่าจะดีเลย์ (เช่น ล่าช้าไป 2 วัน) เพื่อให้ทุกฝ่ายเตรียมตัวรับมือได้ทัน - การทำ Impact Analysis ร่วมกัน: แทนที่จะปล่อยให้ QA ต้องทดสอบตามแผนเดิมทั้งหมด Dev และ QA สามารถนำ Test Case มาพิจารณาร่วมกันเพื่อวิเคราะห์ผลกระทบ เช่น จากเดิมที่มี 500 เคส Dev สามารถช่วยระบุได้ว่าโค้ดส่วนไหนที่แก้ไขแล้วมีความเสี่ยงต่ำ เพื่อพิจารณาคัดเลือก Test Case บางส่วนออก ช่วยลดระยะเวลาในการทดสอบลงได้ - Dev…
สามเหลี่ยม’ ที่จะช่วยจัดการ project ให้ดี
"สามเหลี่ยมกู้ชีพ" เคล็ดลับการบริหารโปรเจกต์และต่อรองฉบับสายเทค ในการทำงานสาย Tech ไม่ว่าจะเป็น Developer, QA หรือ Software Tester ปัญหาที่พบบ่อยที่สุดคือ "เวลาไม่พอ" หรือ "สโคปงานที่เพิ่มขึ้นกะทันหัน" หลายคนเลือกที่จะแก้ปัญหาด้วยการทำงานหนักหรืออยู่ล่วงเวลา (OT) แต่วิดีโอนี้ได้นำเสนอทางออกที่ยั่งยืนกว่าผ่านแนวคิด "สามเหลี่ยมบริหารจัดการ" 1. รู้จัก 3 แกนหลักของสามเหลี่ยม หัวใจสำคัญของการบริหารโปรเจกต์ประกอบด้วย 3 ส่วนที่สัมพันธ์กันคือ เวลา (Time), ขอบเขตงาน (Scope) และ ทรัพยากร (Resource) กฎเหล็กของสามเหลี่ยมนี้คือ "ถ้าแกนใดแกนหนึ่งเปลี่ยน อีก 2 แกนที่เหลือต้องเปลี่ยนตามเพื่อรักษาความสมดุล" ตัวอย่างเช่น หากเวลาลดลง (Deliver ช้าลง) สิ่งที่ต้องพิจารณาคือ: เพิ่ม Resource: อาจจะขอคนเพิ่ม แต่ต้องเป็นคนที่มีความรู้อยู่แล้ว (Knowledge) ถึงจะช่วยได้จริง ซึ่งในความเป็นจริงนั้นหาได้ยาก ลด Scope: นี่คือสิ่งที่ควรตั้งคำถามกับ PM หรือลูกค้าว่า "มีส่วนไหนที่ตัดออกได้บ้างเพื่อให้เราส่งมอบงานได้ทันเวลา?"…
รวมสิ่งที่ควรรู้เกี่ยวกับ Regression Test EP.1
สรุป Regression Test คืออะไร? พร้อมเทคนิคการเลือก Test Case ให้มีประสิทธิภาพตามหลัก 80/20 ในการพัฒนาซอฟต์แวร์ เมื่อมีการเปลี่ยนแปลงเกิดขึ้นในระบบ สิ่งที่ชาว QA หรือ Software Tester ต้องเผชิญคือการตรวจสอบว่าสิ่งที่เปลี่ยนไปนั้นส่งผลกระทบต่อส่วนเดิมที่มีอยู่หรือไม่ ซึ่งกระบวนการนี้เรียกว่า Regression Test นั่นเอง Regression Test คืออะไร? โดยนิยามแล้ว Regression Test คือการทดสอบเพื่อหา Bug (Defect) หรือผลกระทบ (Impact) ที่เกิดจากการเปลี่ยนแปลง (Change) ซึ่งในโลกของการพัฒนาซอฟต์แวร์ การเปลี่ยนแปลงสามารถเกิดขึ้นได้จาก 2 ปัจจัยหลัก คือ: 1.การเพิ่มฟีเจอร์ใหม่ (Add new feature) เข้าไปในระบบ 2.การแก้ไขBug (Bug fix) หรือการปรับปรุงโค้ดต่าง ๆ ดังนั้น ในการทดสอบซอฟต์แวร์จึงมักประกอบด้วย 2 ส่วนสำคัญ คือการทดสอบฟีเจอร์ใหม่ว่าทำงานได้ปกติหรือไม่ และการทำ…
รวมสิ่งที่ควรรู้เกี่ยวกับ Regression Test EP.2 #doppiotech #QA #softwaretester #testing
เจาะลึกการจัดการ Regression Test และ Automation: จากเวอร์ชันแรกสู่ระบบที่ยั่งยืน ในการพัฒนาซอฟต์แวร์ เมื่อระบบมีการเติบโตและเพิ่มฟีเจอร์ใหม่ๆ เข้ามา สิ่งหนึ่งที่ทีม QA และนักพัฒนาต้องเผชิญคือความท้าทายในการควบคุมคุณภาพ ไม่ให้ฟีเจอร์ใหม่ไปส่งผลกระทบต่อการทำงานเดิม บทความนี้จะสรุปกลยุทธ์การจัดการ Regression Test และแนวทางการทำ Automation ให้มีประสิทธิภาพ 1. ทำไมต้องทำ Regression Test? สมมติว่าเราเริ่มพัฒนาผลิตภัณฑ์ในเวอร์ชันแรก (v0.1) โดยมีฟีเจอร์ A, B และ C ซึ่งในตอนแรกเราจะเน้นไปที่การทำ "Test Change" หรือการทดสอบการเปลี่ยนแปลงของฟีเจอร์นั้นๆ โดยตรง เมื่อฟีเจอร์เหล่านี้ผ่านการทดสอบและถูกปล่อย (Release) ลงสู่ Production ไปแล้ว ชุดทดสอบเหล่านั้นจะกลายเป็นฐานข้อมูลสำคัญ ปัญหาจะเกิดขึ้นเมื่อเราก้าวสู่เวอร์ชันถัดไป (เช่น v1.1) และมีการเพิ่มฟีเจอร์ใหม่ D และ E เข้ามา แม้ว่าเราจะทดสอบ D และ E ผ่าน แต่เราไม่สามารถมั่นใจได้เลยว่าการเพิ่มฟีเจอร์ใหม่นี้จะทำให้…
วิธีคิด Bug Severity 🐞📲 #doppiotech #QA #tech #softwaretester #regression #testing #De…
แนวคิดการกำหนด Bug Severity: Bugนี้รุนแรงแค่ไหน? เมื่อเราทดสอบซอฟต์แวร์แล้วพบข้อผิดพลาด (Bug) ปัญหาที่พบบ่อยคือเราไม่แน่ใจว่าจะระบุระดับความรุนแรง หรือ Severity อย่างไรดีเพื่อให้ทีมเข้าใจตรงกัน โดยมีเฟรมเวิร์กหรือคอนเซปต์ง่าย ๆ ที่ประกอบด้วย 2 ปัจจัยหลัก ดังนี้ 1. Impact (ผลกระทบ) เราต้องพิจารณาว่าหากลูกค้าหรือ User มาเจอBugตัวนี้ จะส่งผลเสียมากน้อยแค่ไหน - ระดับ Critical หรือ High: เช่น เว็บไซต์ Shopping แสดงราคาผิดพลาด ซึ่งส่งผลเสียต่อธุรกิจโดยตรง หรือกรณีการสะกดคำผิดในจุดที่เป็น Branding (เช่น ชื่อแบรนด์ผิด) หรือคำที่มีผลทางกฎหมาย ซึ่งกระทบต่อชื่อเสียง (Reputation) ขององค์กรอย่างมาก - ระดับ High หรือ Medium: กรณีที่ฟังก์ชันหรือฟีเจอร์บางอย่างใช้งานไม่ได้ แต่ User ยังมีทางอื่น (Workaround) ให้ไปใช้งานฟังก์ชันนั้นจนจบกระบวนการได้ - ระดับ Low…
Test แค่ไหนถึงจะพอ #doppiotech #QA #tech #softwaretester #testing
Test แค่ไหนถึงจะพอ? แนวคิดการทดสอบซอฟต์แวร์ให้สมดุลระหว่าง Quality และ Business Value คำถามที่ว่า "ต้องเทสแค่ไหนถึงจะพอ?" เป็นคำถามที่ไม่มีคำตอบตายตัวสำหรับทุกโปรเจกต์ แต่เราสามารถหาคำตอบที่เหมาะสมที่สุดได้โดยใช้แนวคิดเรื่องการประเมินความเสี่ยงและมูลค่าทางธุรกิจ ดังนี้ 1. พิจารณาจากประเภทและความสำคัญของโปรดักต์ (Product Criticality) ระดับความเข้มข้นในการทดสอบควรแปรผันตาม "ความเสียหาย" ที่จะเกิดขึ้นหากเกิดข้อผิดพลาด ตัวอย่างเช่น เว็บไซต์ให้ข้อมูล (Informative Website):เว็บไซต์ท่องเที่ยว, บทความต่างๆ หากมี Bug อาจไม่ได้สร้างความเสียหายรุนแรง การ Test สามารถทำแบบ "Lightweight" หรือไม่เข้มข้นมากได้ แต่หากเป็นระบบที่เกี่ยวข้องกับการเงิน (Financial/Banking/Shopping) ความผิดพลาดมักมีผลกระทบสูง ดังนั้นการลงทุนกับการทดสอบ (Investment) และเวลาที่ใช้ในการเทสต้องเพิ่มมากขึ้นตามลำดับ หรือเป็นระบบที่เกี่ยวข้องกับชีวิต (Medical/Aerospace): เช่น ซอฟต์แวร์ทางการแพทย์หรือยานอวกาศ กลุ่มนี้ต้องทดสอบอย่างหนักหน่วงที่สุดเพราะเกี่ยวข้องกับชีวิตคน 2. อย่าลืมคำนวณ "ค่าเสียโอกาส" (Time to Market) การเทสเยอะไม่ได้ดีเสมอไปหากมองในมุมธุรกิจ ลองพิจารณาสถานการณ์สมมตินี้: Scenario A: คุณใช้เวลาเทสอย่างละเอียดนานถึง 3…
Non-Functional Test นั้นหรือ คืออะไร (Non-Functional Test 101)
หลายๆคนคงเคยได้ยิน หรือผ่านหูผ่านตามากับคำว่า Non-Functional Test มาบ้าง แต่ยังสงสัยอยู่ว่ามันคืออะไร มันใช่ Performance Test รึเปล่า แล้ว Performance Test คืออะไร ลองมาอ่านบทความนี้กันครับจะได้เข้าใจมันกันมากขึ้น เกริ่นนิดนึง ถ้าจะแบ่งกันตามหลักการแล้ว คำว่า Functional/Non-Functional test เนี่ยมันเป็นส่วนหนึ่งของ System Test นะ จากรูปด้านบนจะเห็นว่า keyword ของ Functional Test คือคำว่า “What?” คือการ test เพื่อทดสอบในมุมที่ว่า ระบบทำอะไรได้บ้าง พูดง่ายๆคือในแง่ของ function/feature นั่นแหล่ะ ทีนี้มาถึงพระเอกของเราในบทความนี้กันบ้าง keyword ของ Non-Functional Test นั้นคือคำว่า “How well?” ที่แปลว่า ดีแค่ไหน พูดง่ายๆคือ function/feature ที่เรา test แล้วว่ามันทำงานได้เนี่ย มันทำงานได้ดีแค่ไหน ตัวอย่างเช่น…
สิ่งที่ควรเข้าใจและพึงระวังเมื่อเป็น QA
บทความนี้ขอเป็นฉบับสั้นๆที่รวบรวมสิ่งต่างๆที่คอยเตือนน้องๆในทีม (จากคนที่เคยเจ็บมาก่อน) จงเข้าใจ 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…
มาใช้ testing technique กันเถอะ ตอนที่ 1 Equivalence Partitioning
สืบเนื่องจาก blog ที่แล้ว Software Tester/QA 100.1 วันนี้มายกตัวอย่างการเป็น tester เก่งๆในหัวข้อที่ (2) ของ blog นั้นละกันนะ ให้เห็นภาพว่าการเป็น tester เก่งๆที่ใช้ test technique ในการออกแบบ test case เนี่ยมันคืออะไร เตือนไว้ก่อน อันนี้ยาว ย๊าว ยาววว นะ ใครไม่ชอบอ่านเยอะๆอนุญาตให้ข้ามไปได้ 555 อันว่า test technique นั้นมีมากมายหลากหลายประเภท วันนี้ยก technique ที่โดยส่วนตัวใช้บ่อยสุด หรือเกือบบ่อยสุด และเข้าถึงได้ง่ายที่ชื่อว่า Equivalence Partitioning (EP) Technique มาพูดให้ฟังละกันนะ EP มาจากศัพท์สองคำคือ Equivalence ที่แปลว่า เท่ากัน กับคำว่า Partition ที่แปลว่า การแบ่งกั้นเป็นส่วนๆ แปลแยกกันก็จะงงๆนิดนึง ไหนลองแปลรวมซิ สรุปง่ายๆแบบรวบรัด EP คือ…
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 ให้มือใหม่อยากเข้าวงการ ให้อ่านแล้วเห็นภาพใหญ่ ก่อนจะเจาะลึกแต่ละส่วนละกันนะ…