Quality Gate ของ Wongnai POS Android

บทความนี้จะพาทุกคนไปรู้จักกับการรักษาคุณภาพของอีกหนึ่งโปรดักส์ฝั่ง Merchant นั่นก็คือเจ้า Point of Sale หรือเรียกง่ายๆว่า POS ออกเสียงว่า พี-โอ-เอส

ใช่แล้ว เจ้าเครื่องสีขาวที่วางอยู่บนลิ้นชักเก็บเงินนั่นแหละ

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

No Trade off between Speed & Quality

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

Quality Gates คืออะไร

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

Android POS development workflow

จากรูปด้านบนสิ่งที่เรามักจะเข้าใจผิดคือคุณภาพเกิดขึ้นตอนประตู Testing โดย QA หรือ Tester เท่านั้น แต่ถ้าเราดูกันจริงๆแล้วมันสามารถเกิดขึ้นได้ทุกประตูและทุกคนสามารถมีส่วนร่วมได้ ไม่ว่าจะเป็น Developer, Product manager หรือแม้แต่ Customer support เราจึงเร่ิมลงรายละเอียดเรื่องคุณภาพในแต่ละประตูเพื่อให้คุณภาพเกิดขึ้นตั้งแต่ต้นกระบวนการ(Quality ship left) เกิดขึ้นเร็ว เจอปัญหาเร็ว แก้ไขได้เร็ว

Android POS Quality Gate

จากรูปเราตั้งประตูไว้ตาม development workflow ต่างๆเพื่อให้ง่ายต่อการนำไปประยุกต์ใช้ งั้นเรามาดูรายละเอียดของแต่ละส่วนเพิ่มเติมกันดีกว่า

Analysis

จุดประสงค์คือการเข้าใจปัญหา รวบรวมข้อมูลเพื่อหาโซลูชันในการแก้ไข โดยจะมี PM เป็นตัวแทนในการบอกความต้องการของลูกค้าเพื่อให้ตอบโจทย์ธุระกิจ มี What/Why ที่ชัดเจน, มีการเรียงลำดับความสำคัญ(Priority) และมีวิธีวัดผลความสำเร็จ(Success metric)

• Acceptance criterias เป็นสิ่งที่บอกว่างานชิ้นนี้จะสำเร็จ ซอฟต์แวร์ต้องทำอะไรได้บ้าง เราสามารถสร้างช่วยกันสร้างคุณภาพได้ด้วยกันตรวจสอบดูว่าครอบคลุมหรือยัง, มี flow ครบสำหรับ user ทุกประเภทหรือยัง, มี non-functional requirement เป็นแบบไหน สามารถแยกเป็นชิ้นงานที่เล็กลงได้ไหม เป็นต้น
• Request for comment(RFC) ถ้าเป็นงานชิ้นที่ใหญ่หน่อย ต้องออกแบบระบบ เราสามารถเขียน RFC เพื่อขอความเห็นของพี่ๆเพื่อนๆคนอื่นได้ โดยปกติเราจะมี template สำหรับเขียน เช่น ปัญหาที่ต้องการแก้ไขคืออะไร, โซลูชันเราเป็นแบบไหน อาจมี Diagram เพื่อช่วยให้คนอื่นเขาใจมากขึ้น, มีวิธีทดสอบยังไง หรือถ้าเกิดปัญหาในภายหลังเราป้องกันแก้ไขยังไงได้บ้าง เพื่อสุดท้ายเราจะได้โซลูชันที่แข็งแรงก่อนจะเขียนโค้ดกันจริงๆ
• Test cases จะเป็นเอกสารของ set of action ที่บอกว่าความสามารถของซอฟต์แวร์ ประกอบไปด้วยเงื่อนไขในการทดสอบ(Business condition) ข้อมูลที่ใช้ทดสอบ(Data test) และความคาดหวังของแต่ละชุดทดสอบ(Expected result) จะถูกแยกไว้ตามหมวดหมู่ อาจเป็น feature ก็ได้ เราสามารถช่วยกันสร้างคุณภาพได้โดยเข้าไปตรวจสอบได้ว่าต้องเพิ่ม edge case ลด duplicate case หรือแก้ไขส่วนไหนหรือป่าว

Development

ส่วนนี้จะเป็นช่วงเขียนโค้ด ซึ่งซอร์สโค้ดเราก็สามารถตรวจสอบคุณภาพได้เช่นเดียวกัน

• Unit test ส่วนมากก็มักจะเขียนด้วยภาษาเดียวกับโค้ดนั้นๆ ส่วนคำว่า Unit ก็แล้วแต่เราจะนิยามว่าจะเป็นหนึ่งฟังก์ชั่น หนึ่งคลาส หรือหนึ่งโมดูล สิ่งที่สำคัญของ Unit test คือต้องเร็ว และผลลัพท์ต้องเหมือนเดิมทุกครั้ง อาจมีการใช้ Test double เข้ามาช่วยเพื่อจำลองข้อมูลในการทดสอบ ถ้าเขียวหมดทั้ง Local และ CI ก็ถือว่าผ่านประตูไปได้
• Integration test ทำเพื่อช่วยให้มั่นใจว่าในแต่ละ Unit เมื่อเอามาทำงานร่วมกันแล้วยังคงทำงานได้ถูกต้อง อาจเป็นตั้งแต่ 2 Unit ขึ้นไป และถ้าเขียวหมดก็ผ่าน
• Static code analysis เป็นการทดสอบแบบไม่ต้องรันโค้ดจริง จะเป็นการตรวจสอบ syntax ของโค้ดว่าเป็นไปตาม rules ที่ตั้งไว้หรือไม่ เพื่อช่วยประหยัดแรงของคนรีวิวโค้ดให้โฟกัสเฉพาะตัวลอจิก ตัวอย่างเช่น อย่าใช้ฟังก์ชั่นที่เลิกใช้แล้ว, broadcast receivers ทุกตัว register ที่ AndroidManifest แล้วแน่นะ, ห้าม hard-coded color ใน layout เป็นต้น ซึ่งถ้าไม่มี error ขึ้นมาฟ้องก็ถือว่าผ่านไปต่อได้
• Code Review ก่อนที่เราจะ Merge code จะต้องมีการทำ Merge request(MR) บางยี่ห้อเรียก Pull request(PR) เพื่อให้เพื่อนๆในทีมมาช่วยกันตรวจสอบโค้ดที่เขียนเพิ่มไปใหม่ บางครั้งก็อาจมีการแนะนำเทคนิคในการปรับปรุงโค้ดให้ดีขึ้นอีกด้วย ถ้าได้ Approval ก็ถือว่าผ่าน

Testing

• Regression Testing เป็นส่วนที่ทดสอบเพื่อให้มั่นใจว่า Feature เก่ายังใช้งานได้ Feature ใหม่ยังใช้งานดี การทดสอบหลายส่วนยังหลีกเลี่ยง Manual Testing ไม่ได้ เช่น การพิมพ์ใบเสร็จจากเรื่อง Printer, การใช้งานลิ้นชักเก็บเงิน หรือ QR code เป็นต้น
• Manual Exploratory Testing มีวัตถุประสงค์เพื่อสำรวจพฤติกรรมของผู้ใช้ในสถานการณ์ต่างๆที่ไม่ได้ระบุไว้ในเอกสาร หรือ Test cases ทำให้อาจเจอ Edge case แปลกๆได้

Operation

อาจแบ่งได้เป็น 3 ช่วงคือ Deploy, Release, Post-release

Deploy

• E2E testing จะเป็นการทดสอบด้วย Automation โดยไม่ใช้ Test double มาจำลองข้อมูล เพื่อให้มั่นใจว่าทุก Unit ที่ทำงานร่วมกันแล้วยังใช้งานได้ปกติ ข้อควรระวังของ E2E automated testing คือจะใช้เวลานาน เพราะฉะนั้นไม่ควรจะมีเยอะจนเกินไป หรือเราอาจเลือกทำเฉพาะ Critical flow ก็ได้
• Smoke Testing เป็นการทดสอบติดตั้งแอปตัว ENV Prod เวอร์ชั่นใหม่แล้วกดเล่นรอบๆดู ถ้าไม่พังก็ถือว่าผ่าน คล้ายๆกับเครื่องใช้ไฟฟ้าที่ซื้อมาใหม่ ถ้าเสียบปลั๊กแล้วควันไม่ขึ้นถือว่าใช้ได้

Release

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

Post-release

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

• Feature flag เป็นเทคนิคที่ช่วยแก้ปัญหากรณีที่ Production มีปัญหาเกิดขึ้นแล้วเราต้องการปิดการใช้งานเฉพาะส่วนนั้น ทันที เพื่อลดการขยายผลกระทบในวงกว้างโดยไม่ต้อง Submit App ใหม่ เมื่อปัญหาถูกแก้ไขและอัปเดตไปแล้วก็สามารถเปิดกลับมาใช้งานได้ทันทีเช่นเดียวกัน
• Monitoring จะเป็นตัวช่วยเราติดตามดูคุณภาพหลังจากปล่อยขึ้น Production ไปแล้วเพื่อเอาข้อมูลมาปรับปรุงต่อในรอบ release ถัดไป เช่น Crash free rate, App start time, Screen rendering, Analytics เป็นต้น
• On-call เป็นกระบวนการที่ทำให้แน่ใจว่า หลังจากที่เราปล่อยเวอร์ชั่นใหม่ไปแล้ว จะมีคนคอยรอรับเรื่องและแก้ปัญหาที่เกิดขึ้นในช่วงดำเนินการจากร้านค้า โดยปกติร้านค้าจะแจ้งปัญหาผ่านทีม Customer support ของเรา ถ้าปัญหาเกิดขึ้นที่ตัวระบบทาง Customer support ก็จะส่งเรื่องต่อให้แก๊งค์ On-call(ปกติคนที่รับผิดชอบคือ Dev จะผลัดเปลี่ยนเวรกัน) เพื่อช่วยกันหาวิธีแก้ปัญหาต่อไป

มารู้จักกับตัวโปรดักส์เราสักหน่อยดีกว่า

Wongnai POS by FoodStory คืออะไร

โปรดักส์ Wongnai POS เกิดจากความร่วมมือระหว่าง LINE MAN Wongnai และ FoodStory เป็นระบบบริหารจัดการร้านอาหาร สามารถจัดการเมนู จัดการออเดอร์ สร้างโปรโมชั่น จัดการสินค้าคงคลัง เช็คยอดขายได้แบบทันที และที่สำคัญรองรับ Food Delivery จาก LINE MAN ช่วยเพิ่มยอดขายและทำให้ชีวิตเจ้าของร้านสะดวกสบายขึ้นตามพันธกิจ Help Thai people live better ของเรา

โฉมหน้าทีมงานเราบางส่วน

นี่ก็เป็นบางส่วนบางตอนของการรักษาคุณภาพโปรดักส์พวกเรา เราคงไม่บอกว่าที่ทำอยู่ดีแล้ว เพราะสิ่งที่ดีกว่าจะเกิดหลังจากนี้อีก ถ้าใครอยากเป็นส่วนหนึ่งหรือมีไอเดียเจ๋งๆกว่านี้ก็มาลุยด้วยกันเลย สามารถเข้าไปดูได้ที่ https://careers.lmwn.com/development เลือกช้อปปิ้งงานได้ตามสบายเลยครับ :)