วิเคราะห์ Software Requirements ง่ายๆภายใน 3 ขั้นตอน

ตอนนี้แอดเรียน QA bootcamp มาได้ประมาณเดือนหนึ่งแล้ว มีสมาธิหลุดไปบ้าง สัปดาห์ที่ผ่านมาเข้าเรียนน้อยมาก เอาเวลาไปเขียน Suddenly Talented เยอะไปหน่อย 555+

ถ้าใครยังไม่ได้อ่านบทความนั้น อยากให้แวะไปอ่านกันนะครับ เก่งแบบปุบปับแค่เข้าใจคอนเซ็ปต์ ECS – Energy Confidence และ Skill ใช้เวลาเขียนบทความ 10 ชั่วโมง จุกๆ

Newsletter ฉบับนี้มาคุยกันต่อเรื่อง Requirement Analysis ในคอร์ส QA Engineering สอนแอดทำ 3 ขั้นตอนง่ายๆคือ decomposition, visualization และ gray areas

Decomposing Requirements

การวิเคราะห์ requirements จะเริ่มด้วยการ break down ข้อมูล requirements ซอยย่อยเป็นหน่วยเล็กที่สุดที่ QA engineer เรียกว่า atomic blocks

กฏสามข้อสำหรับการทำ decomposition

1. Requirements ส่วนใหญ่จะสามารถซอยย่อยเป็น parts เล็กๆได้
2. Requirements ควรถูก decomposed เป็น atomic blocks
3. Requirements ไม่ควรถูก decomposed เกินกว่า description ที่เขียนไว้ในเอกสาร

ตอนแอดเรียนถึงตรงนี้คือร้อง “โอ้โห” เลย งาน QA คือแบบโคตรละเอียด 555+

เรื่องที่เราเคยคิดว่าง่ายๆ แต่ถ้าอยากทำเป็น QA engineer ต้องคิดลึกกว่าคนทั่วไปอีก step ตัวอย่างเช่น การกรอกข้อมูลชื่อ first name, last name และ email ในแอป

Title	Requirements	Required Field?
First Name	รับเฉพาะภาษาอังกฤษ ความยาว 2-25 ตัวอักษร	Yes
Last Name	รับเฉพาะภาษาอังกฤษ ความยาว 2-25 ตัวอักษร	Yes
Email	รับเฉพาะภาษาอังกฤษ _ . @ ความยาว 5-50 ตัวอักษร	Yes

คำถามคือ requirements แบบนี้มันเขียนได้เคลียร์หรือยัง?

QA ต้องคิดต่ออีกว่า แล้วเวลา user พิมพ์ตัวอักษรภาษาอื่นๆ เช่น ไทย จีน เกาหลี ลงไปในช่อง first name เราจะจัดการยังไง แสดง error message แบบไหน

แล้วถ้าเขียนใส่ลงไปแค่ 1 ตัวอักษร หรือ 30 ตัวอักษร แอปจะจัดการกับ invalid input ยังไงดี email ลงทะเบียนซ้ำได้ไหม หรือต้อง unique อย่างเดียว

นี่คือเหตุผลที่เราต้อง decompose requirements ให้เป็นหน่วยย่อยที่สุดคือ atomic

Atomic block is the smallest, most basic part of a feature

ตัวอย่างของ atomic blocks ช่อง first name

• ตรวจสอบว่าชื่อจริง “first name” ถูกกรอกเรียบร้อย (required field)
  • ตรวจสอบว่าชื่อจริง “first name” เขียนได้ถูกต้องตาม requirements
    • รับเฉพาะตัวอักษรภาษาอังกฤษ
    • ความยาวระหว่าง 2-25 ตัวอักษร
• Positive Test Cases
  • first name มีความยาวระหว่าง 2-25 ตัวอักษร
  • first name รับเฉพาะภาษาอังกฤษเท่านั้น
• Negative Test Cases
  • first name มีความยาวน้อยกว่า 2 ตัวอักษร
  • first name มีความยาวมากกว่า 25 ตัวอักษร
  • first name มีตัวอักษรภาษาอื่นๆที่ไม่ใช่ English เข้ามา

✅ Tests ในงาน QA/ Software สามารถแบ่งได้เป็น positive และ negative เนื้อหานี้อยู่ใน sprint หน้า เดี๋ยวแอดเขียนสรุปให้อ่านอีกทีครับ

ตอนทำ decomposition เราจะคิดและเขียนในกระดาษ หรือจดใน digital note ก็ได้ แต่อีกวิธีหนึ่งที่ได้ผลดีมากๆคือการทำ visualization

Visualizing Requirements

ขั้นตอนที่สอง visualization คือการแสดง requirements ด้วย charts หรือ diagrams ง่ายๆเพื่อให้เราเห็นความสัมพันธ์ของ atomic blocks ทั้งหมด

สอง charts ที่เราใช้บ่อยๆคือ mind maps และ flow charts

ตัวอย่าง mind map ของแอป recipe เราสามารถแยก requirements เป็น functional vs. non-functional แล้วก็แตกย่อยไปเรื่อยๆ (ทำ decomposition)

ด้านขวาสุดของ mind map คือ atomic blocks ที่เราต้องการ

ถัดมาคือ flow chart ในงาน BA/ QA ต้องใช้กันแทบทุกวัน แอดก็เพิ่งเข้าใจมันจริงๆตอนเรียนคอร์สนี้ 555+ กล่องแต่ละแบบจะมีความหมายตามนี้

• Rounded คือจุดเริ่มต้น start และ end ของ workflow
• Rectangle คือ action เช่น กดดูสินค้า กดใส่ตะกร้า จ่ายเงิน เป็นต้น
• Diamond คือ decision หรือจุดที่ต้องตัดสินใจ มีเงื่อนไขเหมือนเขียน if-else

ตัวอย่างของเว็บไซต์ online shopping และขั้นตอนการสั่งซื้อสินค้า

ตรง payment เราอาจจะเพิ่มกล่อง <Diamond> เพื่อให้ user เลือกว่าอยากจะจ่ายด้วยเงินสด หรือบัตรเครดิต แบ่ง flow หรือ journey เป็นสองเส้นทางก็ได้

สรุปคือ BA, QA ใช้ flow chart เพื่อแสดง process หรือ steps การทำงานของ application หรือ user journey ตั้งแต่ต้นจนจบ เป็น artifact สำหรับคิด test plan ต่อไป

Visualization is very helpful if you are testing end-to-end

การผสมผสาน decomposition กับ visualization จะทำให้งาน QA เราง่ายขึ้นเยอะเลย เรา break down requirements ที่มีความซับซ้อน แสดงผลให้มันเข้าใจง่ายขึ้น

ทุกวันนี้มีซอฟต์แวร์ที่ช่วยให้สร้าง mind map, flow chart ได้ง่ายๆ เช่น Miro, Figjam, draw.io หรือ whiteboard บนแอปต่างๆ Canva และ Microsoft มีครบทุกเจ้า 555+

Gray Areas

ขั้นตอนสุดท้ายคือการหา gray areas หรือ “พื้นที่สีเทา” ที่ requirements ยังไม่ค่อยเคลียร์ ประเภทของ gray areas เช่น

• Unclear or Incomplete – เขียนไม่เคลียร์ หรือไม่สมบูรณ์
• Hidden – บาง requirements อาจจะซ่อนอยู่
• Conflicting – บาง requirements อาจจะขัดกันเอง

Unclear เช่น เวลาลูกค้ากดปุ่ม add to cart แล้ว ให้แสดง “confirmation message” บนหน้าจอ แต่ไม่ได้บอกว่าต้องเขียน message แบบไหน แสดงผลอะไรยังไง

Hidden เกิดขึ้นเวลาที่คนเขียน requirements “assume” ว่าทุกคนรู้อยู่แล้ว เช่น เวลา user คลิกที่ชื่อหรือโลโก้ของเว็บ จะกลับไปที่หน้า homepage ได้ เลยไม่เขียนสิ่งนี้ลงใน requirements

Conflicting เช่น BA คนหนึ่งบอกว่าขอดูรายงาน web traffic 12 เดือนหลังสุด แต่อีกคนบอกว่าขอดู 6 เดือนก็พอ อ้าว เอาไงแน่ 555+

วิธีรับมือกับ gray areas อย่างแรกคือการ “ถาม” อ้าว 555+ เพื่อ clarify หรือทำความเข้าใจจุดที่เราไม่เข้าใจ จริงๆมันก็ชัดเจนอยู่แล้วเนอะ communication is key

ลองจินตนาการว่าแอปมันควรจะทำงานยังไง (ideal) คิดในมุมของ users แล้วลองตรวจสอบ requirements อีกทีว่ามัน make sense หรือเปล่า

QA อาจจะลองออกแบบ Test Plan ว่าต้องทดสอบฟีเจอร์อะไรแบบไหน เพื่อทำให้ requirements มันชัดเจน โปร่งใสขึ้น ภาษาอังกฤษใช้คำว่า “more transparent”

3 Simple Steps

สรุป 3 ขั้นตอนง่ายๆในการวิเคราะห์ software requirements คือ decomposition, visualization และ gray areas

แอดคิดว่านี่คือ fundamental skill สำหรับทุกอาชีพเลย จะเป็น QA, data analyst หรือ marketer ก็ต้องมีทักษะนี้ไว้ติดตัว จะได้คุยงานรู้เรื่อง ยั๊งงง 555+

Newsletter ฉบับนี้ก็เช่นกัน ความรู้แน่นๆเลย แถมฟรีด้วย ทุกคนควรได้อ่าน เย้ย 555+ ส่งต่อให้เพื่อนๆ หรือทีมที่บริษัทอ่านกันได้นะครับ sharing is caring

แอดสนุกมากเลยที่ลงเรียนคอร์ส QA แล้วมาเขียนสรุปแชร์ทุกคน ทบทวนความรู้ ฝึกเขียนไปในตัว philosophy ใหม่ของแอดคือ

Good things come to those who wait WRITE

เมื่อวานแอดเพิ่งสอนคลาส WEB FOR IMPACT รุ่นแรก เพื่อนๆมากัน 50 คนเลย สนุกและเลิกตรงเวลา 555+ ถ้าใครสนใจเรียนเรื่อง web, writing และ SEO

รอติดตามรุ่นสองได้บนเพจนะครับ โปรเจ็คเยอะเหลือเกิน นอนตอนไหนแอด ยั๊งงง 555+

Podcast Coming Soon

Podcast คิดว่ามาวันพุธนี้ ถ้าไม่มีงานใหม่เข้าแอดก่อน 555+

รอฟัง episode แรกได้ในรายการ “เด็กติดเรียน” เลยครับทุกคน แอดน่าจะอัปโหลดขึ้นสองช่องทางบน DataRockie และ YouTube เดี๋ยวนี้ YouTube ทำซีรีส์ podcast ได้แล้ว เย้

ปีนี้มาเรียนและเก่งขึ้นด้วยกันนะครับ ไม่ทำแล้ว Data อยากเป็น QA หยอกๆ ✌️