Software Requirements คืออะไร อธิบายสั้นๆฉบับผู้เริ่มต้น

สัปดาห์ที่ผ่านมาแอดงานเข้าเพียบ 555+ แล้วก็เพิ่งจัดงาน Duck Con 2024 ของเพจเราไปด้วย เลยใช้เวลาเรียนได้ไม่เยอะเท่าไหร่แค่สองชั่วโมงนิดๆ นอนน้อยแต่นอนนะ

เพิ่งขึ้น sprint 02 เรื่อง Test Design and Documentation

พอนั่งเรียนไปเรื่อยๆ แอดว่าเนื้อหามันประยุกต์ใช้ได้สองตำแหน่งพร้อมกันเลยคือ QA – QA Engineer และ BA – Business Analyst โดยเฉพาะเรื่องการเก็บ requirements

กำลังคิดว่า The Weekend Engineer ต้องขยาย scope ให้ครอบคลุมเรื่อง Business Analysis มากขึ้นแล้ว จริงๆเรื่อง requirement analysis ใช้ได้กับทุกตำแหน่ง

สารภาพว่าแอดก็เพิ่งทำเป็นเหมือนกัน ถ้าไม่ได้เรียนคอร์สนี้ ก็คงไม่เข้าใจ 555+

SDLC vs. STLC

มารีวิวความสัมพันธ์ของ Software Development Life Cycle (SDLC) กับ Software Testing Life Cycle (STLC) กันก่อน

จริงๆตำแหน่ง QA engineer จะมีส่วนร่วมกับทุก phases ของ SDLC แต่งานหลักของเราจะเริ่มจริงๆที่ Testing โดย STLC จะมีทั้งหมด 6 ขั้นตอน

1. Requirement analysis
2. Plan
3. Design หรือ test case creation
4. Environment setup
5. Execution
6. Closure สรุปงานทั้งหมด เขียน bug report และ documentation ต่างๆ

สรุปสั้นๆคือ STLC เป็นส่วนหนึ่ง (subset) ของ SDLC ดูแลโดย QA engineer

What Are Requirements

Requirements คือสิ่งที่ software ของเราต้องทำให้สำเร็จ ตอบสนองความต้องการของผู้ใช้งาน โดยเราจะรับ requirements มาจากลูกค้าหรือ BA ของทีมเราอีกที

เอกสาร requirements ที่ส่งหาเราปกติจะมีความยาว 3-4 หน้า หรือยาวกว่านั้นตาม scope ของโปรเจ็ค มีชื่อเรียกหลายชื่อ แต่ที่เราเห็นกันบ่อยๆคือ

• BRD – Business Requirements Document
• SRS – Software Requirement Specification
• บางที่ก็เรียกตรงๆเลยว่า “The Requirements” ง่ายดี อ้าว 555+

QA engineer จะเขียน tests เพื่อทดสอบว่า software ทำ requirements ทั้งหมดได้ครบถ้วนสมบูรณ์ ตอบโจทย์ users ทุกคน happy เฉียบ

When creating a piece of software, there will be particular needs that the software must fulfill.

ประเภทของ requirements จะแบ่งออกเป็น 2 แบบใหญ่ๆคือ

• Functional คือสิ่งที่ software ทำได้ หรือทำไม่ได้
• Non-Functional ใช้อธิบายคุณลักษณะของ software เช่น qualities, attributes และ characteristics ครอบคลุมเรื่อง performance, security และ reliability

ตัวอย่างของ functional vs. non-functional เช่น

• Functional เวลาลูกค้ากดปุ่ม add to cart ให้แสดงสินค้า item นั้นในตะกร้า
• Non-Functional เว็บไซต์ต้องโหลดได้เร็ว หรือ แสดงผลได้ในเวลา 3 วินาที

สรุปตามความเข้าใจของแอดเรื่อง functional คือ features ของตัว software ที่ users สามารถใช้ได้ เช่น การกดปุ่มต่างๆบนหน้าเว็บหรือแอปเพื่อทำงานสักอย่าง ในคอร์สจะใช้คำว่า “What a software product must do”

ส่วน non-functional คือสิ่งที่ user อาจจะไม่ได้เห็นตรงๆบนหน้า UI เช่น ความเร็วในการโหลดของต่างๆ ความปลอดภัยของข้อมูล หรือการเข้ากันได้ของระบบ OS

QA team จะมี checklist เพื่อตรวจสอบ software ว่าได้มาตรฐาน ทำงานได้อย่างที่ลูกค้าอยากได้หรือเปล่า จริงๆมันก็ตามชื่อ quality assurance เลยเนอะ 555+

ขอพักเขียน note แป๊บ สังเกตว่าภาษาอังกฤษมาเต็ม อยากเชียร์ทุกคนฝึกภาษาอังกฤษไปด้วยกันเลยนะครับ ไม่เข้าใจคำไหน ลองเปิด google/ dict หาความหมาย

ยิ่งเราเก่งภาษามากขึ้นเท่าไหร่ เรายิ่งเรียน concept ต่างๆได้ไวขึ้นเท่านั้น ✌️

Requirement Analysis

ในคอร์สอธิบายว่า good requirements ต้องเขียนตามหลักการ SMART

• Specific เขียนได้เคลียร์ มีโฟกัสชัดเจน
• Measurable วัดผลได้
• Attainable ต้องทำได้จริง ไม่เวอร์เกินไป
• Relevant ตอบโจท์ users ช่วยให้เราเข้าใกล้เป้าหมายของโปรเจ็ค
• Testable ทดสอบได้

ตัว T สุดท้ายจะต่างจาก smart goals ปกตินิดหนึ่ง ในงาน QA เราเปลี่ยนจาก Time-Based เป็น Testable สามารถทดสอบและ verified ได้ด้วย tests

ถึงแม้ QA engineer จะไม่ใช่คนเขียน requirements ด้วยตัวเอง (ปกติเรารับมาจาก stakeholders, BA, Product Manager) ก็ควรรู้พื้นฐานนี้ไว้บ้าง

แอดคิดว่าทุกตำแหน่งควรเข้าใจเรื่องนี้หมดเลย ทีม data ตั้งแต่ DA, DS, DE หน้าที่หลักของพวกเราคือการรับ requirements และเปลี่ยนมันเป็น output บางอย่างเสมอ

พอเราได้ requirements มาแล้ว ก็อ่านและรีวิว ทำความเข้าใจ ถ้าจุดไหนเขียนมาไม่เคลียร์เป็น gray areas ให้กลับไปถามคนส่งงานมาให้เราอีกที 555+

ถ้าไม่ถาม แล้วรับไปทำเลย มีโอกาสแก้งานสูงมาก เสียเวลาหลายรอบ ยั๊งงง 🤣

Steps to Analysis

Newsletter ฉบับหน้าแอดจะมาอธิบายการทำ requirement analysis แบบเจาะลึก ใน bootcamp เค้าสอนเรื่อง decomposition, visualization และ gray areas

The New Podcast

แอดมีถามเพื่อนๆใน newsletter ฉบับก่อนหน้าว่าอยากฟังสรุปแนวๆ podcast กันหรือเปล่า ทุกคนตอบเป็นเสียงเดียวกันว่า เอาเลยครับแอด 555+

เพื่อนักเรียนทุกคน แอดทำได้อยู่แล้ว เย้

สัปดาห์หน้ารอฟัง podcast “เด็กติดเรียน” ของช่องเราได้เลยครับทุกคน ทำ EP01 ไว้เมื่อสองปีก่อน พอได้เขียนบทความ แอดก็มีไฟเลย ขอบคุณทุกคนมากๆนะครับ ✌️

นอกจากเรื่อง QA, BA เพื่อนๆอยากฟังเรื่องอะไร แนวไหนอีกบ้าง คอมเม้นต์บอกแอดได้เหมือนเดิมเลยนะครับ จะเรื่อง study tips, productivity หรือ Stoic ได้หมด 555+

แล้วความยาว newsletter แบบนี้กำลังดีไหม ยาวหรือสั้นไป แชร์ไอเดียกันได้นะครับ

วันนี้แอดกำลังเขียนสรุปเรื่อง Suddenly Talented ที่พูดในงาน Duck Con วันเสาร์ที่ผ่านมาด้วย รออ่านได้เลยบนเพจนะคร้าบ 💯

อ่าน newsletter ย้อนหลังได้ทุกฉบับที่ 📂 Category: QA Engineering