บันทึกหลังดู Live QA Meetup @LSEG

งานนี้ผมกดตั๋วไม่ทันเลย เป็น Dev อยากไปฟังด้วย 555 แต่ดีที่มี Live ด้วย ซึ่งตอนแรกผมกะว่ามาฟังวันอื่น ระหว่างทำงานแทน แต่มีคนทักมา เลยลองเอาที่จดๆมาเขียน Blog โดยมีหัวข้อดังนี้

ทำ Automation ยังไงให้เจ๊ง

Agoda สามารถ Release ใหม่ได้ทุก 1 ชั่วโมง (Fast Feedback) แต่การทำให้ 1 ชั่วโมงได้นั้น ต้องทำเป็น Automate รวมทั้ง Regression Test แต่การจะะได้มานั้นต้องมีบาดแผลกันบ้าง

  • Automation ไม่ได้ช่วยให้ Quality ดีขึ้น การทำ Test ต้องมี Objective ที่ชัดเจน ไม่ใช่ทำให้รู้ว่ามี
    - อย่ายึด ตัวเลข เช่น % Coverage / จำนวน Test Case
    - พยายามกำหนด Test Case มีประโยชน์ จำเป็น และ Regression Test ได้ Feedback ที่เร็ว +น่า เชื่อถือได้
  • Automation Strategy / Framework - เลือกให้ดี ไม่งั้นจะเจอถ้าคนทำเป็น ออกไปตัวใครตัวมัน สิ่งที่ควรดู
    - Speed ในการทำ การเรียนรู้ การส่งต่อ
    - Scale ได้ไหม
    - ต้องการ Feature อะไร ใช้ทำอะไร จะเอามาทำ E2E / Integration / Mobile Test ...
    - Community ของ Framework
  • Test Environment ไม่ Stable การไปแก้ Test Script บ่อยๆ ไม่ใช่ อาจจะต้องมาดูเรื่องของการ Initial (ในหัวนึกถึง docker) หรือ ทำพวก Mock เพื่อรับประกันว่าตอน Test Pre-Condition พร้อมแล้ว
  • ตั้งเป้าให้ Perfect คิดให้ครบ แต่ทว่ารอแบบนี้ แล้ว Automate ไม่ได้ทำสักที เช่น
    - ต้องรอทุกคนยอมรับทำแล้วดี อาจจะเริ่มที่ละเล็กน้อยแทน
    - มี DevOps พร้อม
    - ต้องมี Server Scale รอ ถ้าช้า
    - ทุกคนงานเยอะอยู่ ทำเอางานมาเพิ่มทำไม
    รอไปสุดท้ายไม่ได้ทำ
  • ขายให้เป็น ว่า Automate Test ได้ Value ยังไง
  • ทุกทาง Automate เห็นปัญหาก่อนเลย เลยไม่ได้เริ่ม - ทำแล้วติดไปหาทางแก้ ทำเป็น Common Library / Framework เข้ามาช่วยให้เร็วขึ้นสิ ตัวอย่างมีหลายตัว เช่น OTP Mock / Selfie Mock เป็นต้น

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

QA Career Path

ไม่ว่าตำแหน่งไหน QA ไม่ว่า Manual/Automate จะมี Personality ที่เหมือนๆกัน น่าจะรูปนี้นะ เรียกว่า Norm ของ QA อยู่ฝั่งไหนมากกว่ากัน

QAE = Quality-Assurance-Engineer (Ref: The Quality Assurance Engineer Personality Type on Crystal (crystalknows.com))

Hard Skill / Soft Skill ของ QA มีอะไรบ้าง

  • Hard Skill (Manual) เน้น Testing Technique / Business Knowledge สำคัญมาก >> มันจะขยับมาทาง Business Analyst ได้นะ เพิ่ม Soft Skill หรือ จะขยับมาเป็น Project Management
  • Hard Skill (Automate) เน้นไปทาง Framework (รู้หลากหลายดี แต่ในงานใช้เพียงตัวเดียว จะได้ไม่สับสน) / Mocking Service ถ้าจะเสริมด้านนี้มาดูด้าน Programming Skill + Design Pattern DevOps
  • Soft Skill - Communication / Negotiation / Information Gathering / Decision Making / Time Management

สรุป

  • อย่าทำตัวเป็นน้ำเต็มแก้ว ถ้าเต็มหาแก้วใหม่มาเติม ชอบคำนี้
  • Comfort Zone Balance ให้ดี ออกมา เพื่อเจอสิ่งใหม่ๆ ถ้าที่ทำงานไม่มี ต้องลองหาดู
  • อ๋อ และมี Q&A ว่า DEV กับ QA สัดส่วนเท่าไหร่ มีหลายคำตอบ
    - แนว Start Up อาจจะต้องลงมาทำกันเอง
    - ให้ QA ทำ Story Point เอา Data Driven สำคัญมากนะ เพราะแค่หน้า Login อย่างเดียว แต่ QA ต้องทดสอบ Chrome / Safari / IE (ตายไปยังหว่า) / Mobile

Principal QA Engineer

ยิ่งโตขึ้น เราจะใช้ Technical Skill ลดลง แต่ต้องมาใช้ Soft Skill (Management Skill) มากขึ้น ยากสุดก็จะเป็นเรื่องคน หรือบางทีอาจจะมีจัดให้ทำ Technical สุดๆไปเลย หรือว่าพอๆกัน

หน้าที่ Principal QA Engineer มีอะไรบ้าง

7E ของการขยับมาเป็น Principal QA Engineer

  1. Expert เป็น Subject Matter Expert ใน product
    - มุมกว้าง user flow / user journey
    - มุมลึก feature ของ Product / Config Product เพื่อให้ Test ได้
    หรือเป็นด้านอื่นๆ automation / cloud / Backend-Frontend ต่อกันยังไง ? >> แก้อะไรแล้ว รู้จุดที่ต้อง Aware และทำให้ Test มัน Cover มาขึ้น เป็นต้น
  2. Extraordinary - Outstanding เร็ว มีประสิทธิภาพ เชื่อถือได้
  3. Enthuse ความกระตือรือร้นในการทำงาน
  4. Expression - ตั้งคำถาม ทำให้ทุกคนเห็นเรา (Visibility) หรือจะเป็น Guru ในด้านนั้นๆ //ส่วนตัว ถ้าโดนถามซ้ำๆ เรื่องไม่ดีและ ผมทำ KM ทิ้งไว้ มีน้องที่ทำงาน เหตุผลนึงออกไป เพราะถามซ้ำๆ นี่แหละ
  5. Empathy - เข้าอก เข้าใจ
  6. Environmental - สภาพแวดล้อม วัฒนธรรมองค์กร
  7. Explore - Improve ออกจาก Comfort Zone ทำอะไรให้มี Value กับองค์กร

Testing Methodologies in Flutter Framework

RECAP

  • Flutter - Cross Platform UI Framework Mobile / Web / WinApp / Embed
  • Clean Code - KISS (Keep it simple, stupid)- Simple ทำงานอย่างเดียว และมีความเสถียร Run กี่รอบได้ค่าเท่าเดิม //จริงพยายามดันที่ บ ให้ Split Code ให้ย่อยๆ แต่ทุกคนไม่ทำ 55 กลัว
  • SDLC เช่น Agile จะบอกว่า แต่ละช่วงของการทำงานทุก Role มีความสำคัญกับ Quality หมดนะ ตั้งแต่ Requirement > Design > Develop > Test
    ** จริงๆ ต้องมาฟังใน Clip เราจะเห็นภาพมากขึ้น ว่า Acceptance Criteria ของแต่ละ Role User / Designer / Dev / PO PM / QA เรียกว่าต้องมีต่อมเอ๋ะ สงสัยแล้วถามตาม 7E ในหัวข้อที่ 3

Test Strategy - Testing Pyramid เน้น Unit Test เยอะๆ ถัดขึ้นมาจะเป็น Integration และ End 2 End Test ตามลำดับ

แต่ละ Level ใน Flutter

  • Unit Level
    - มีพร้อมมาให้แล้ว เพิ่มใน dev_dependency ได้เลย และมีทำ LCOV (Local Coverage) ด้วย มี Resource ที่ Speaker แนะนำ
    >> Testing Flutter apps | Flutter
    >> Testing on Flutter: generate unit test badge using LCOV to your repository - DEV Community
  • Integration / E2E Test (flutter_gherkin)
    - flutter_gherkin - 3rd Party ที่มาช่วยทำ Test ตามแนวคิดของ BDD กำหนด
    >> Feature บอก domain / scope อาจจะบอกว่า ตอนนี้เรา Run IOS Android
    >> Scenario ตาม Pattern Given When Then

    - limitation ถ้าใช้ไปนานช้า hang / dialog เช่น เด่้งของ permission จาก native อันนี้แก้โดย mock initial เข้าไป
    - best combination
  • Golden Test - Pixel Perfect Test ดูว่า UI มันไม่เปลี่ยนไป หรือพัง สัดส่วนผิดตอนแสดงผล
  • Mobile Device Farm
  • นอกจาก flutter_gherkin มีตัว Patrol Flutter ด้วยนะ (Speaker บอกว่า เดวน่าจะมี Review ในรอบหน้า)

นอกจากนี้แล้ว

  • แก้ Code ถ้า Push แล้วชน อย่าลืม Run Local Test อีกรอบก่อนส่งให้ CI/CD
  • Manual Test ยังสำคัญนะ มันทำให้เห็น Transition การกระตุก อะไรอย่างนี้
  • และ Iterative Development & Improvement

1 Product 100 Squads

ระบบ LSEG Workspace เป็น Product ที่ใหญ่มากด้านตลาดเงิน และทุน และ Data Realtime เปลี่ยนแปลงเร็ว และมี Integrate ระบบหลากหลาย เลยเป็นที่มาของ 100 Squads

  • 1 Squads Dev 3 QA 1
  • แตก Squads เพิ่ม Agility

Challenge 100 Squads จัดการยังไงไม่ให้ชนกันเละ

  • Direction: ทำให้ทุก Squads ไปทางเดียวกัน
  • Planning + Dependency: ต้องจัดกลุ่มของงาน อะไรที่เกี่ยวข้อง Upstream / Downstreamและ Squads ย่อยๆคุยกัน และสรุปขึ้นมา ทำ Scrum of Scrum อีกที
  • Transparency: รู้ว่าใครทำอะไร ที่ไหน ติดอะไร จะได้ปรับแก้ได้ถูกจุด
  • Standard: App เดียวกัน System แยกย่อยกันหลาย Squads จัดการยังไง เช่น การแสดงผลทศนิยม หรือ Pattern การแสดงผลของ App ใน Component ต่างๆ

โอ๊ะทุกที่มีปัญหาเหมือนกันหมดเลย สรุปได้ประมาณนี้

  • feedback จาก Management ทำไมช้ากัน แก้ไขอธิบาย และเพิ่มคน และ Invest ใน Automate.
  • งานมัน Challenge ก็จริง แต่พวก infra ต้องพร้อมให้ทุกคนทำงาน
  • เรารู้จักตัวเอง (Product) / รู้ Upstream / Downstream เวลาพัง จะได้คุยถูกคน ไม่เสียเวลา Senior อาจจะเห็นไม่ครบ หลายหู หลายตา ดีกว่าหัวเดียวนะ
  • อย่าทำงานเป็น SILO

Q&A ปิดท้าย

  • Q: ทำไมคนที่อยากเป็น QA หรือ Tester คิดว่างานง่ายหรือเงินเดือนเยอะ
    A: งาน QA มีทั้งง่าย และยาก แต่เรื่องเงินเดือน อาจจะเป็นเคสมาจาก Non-IT เลยมองว่าเยอะ เรียกว่าเงินปรับตามความยากของงานด้วย
  • Q: QA เป็นสิ่งสำคัญแค่ไหน ถ้า ไม่มี qa testing ในบริษัท PM (Project manager) เป็นคนที่เตรียม การทำ QA เพื่อตรวจสอบว่า Product ครบตามความต้องการไหม? ได้รึเปล่า
    A: ถ้าไม่มีคนในทีมจะเหนื่อย เหมือน QA มาช่วยปิด Gap ตรงนี้
    ** ได้ยินอีก Keyword Software Engineering in Test
  • Q: ถ้าเรารู้ตัวว่า automate เรามาผิดทางแล้ว เราควร manage ยังไงเพื่อแก้ให้มันดีขึ้นครับ
    A: อย่าตัดสินใจคนเดียว คุยกับ Stakeholder รับรู้ และดู Value + Effort เพื่อตัดสินใจว่าหยุดไปต่อ
  • Q: บางครั้ง Tester จะถูกทิ้งท้ายไว้หลัง process เราจะใช้ความสามารถที่เรามีมาช่วยตั้งแต่เริ่มกระบวนการได้อย่างไรครับ
    A: ควรแสดง Visibility ตั้งแต่เริ่ม Project Tester จะได้มีโอกาสแสดง Idea ด้วย หรือปรับกระบวนการ TDD มาใช้ ไม่จำเป็นต้อง Dev นะ QA เข้ามาได้

Blog ของท่านอื่นๆ

Live

บางอย่างผมอาจจะจดมาไม่ครบนะครับลอง ดูจาก Live ของทางสมาคมโปรแกรมเมอร์ไทยครับ

Reference


Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts to your email.