Requirement Gathering,Testing

เมื่อการเทสไม่ใช่การทดสอบผลงาน …

ใน Class CSD ที่ผมได้ไปเรียนในสัปดาห์ก่อนนั้น มีหัวข้อนึงที่น่าสนใจมากเกี่ยวกับการทำ ATDD หรือ Acceptance Test Driven Development ซึ่งว่าด้วยการคิด Acceptance Test หรือ Acceptance Criteria ก่อนที่จะเริ่มทำงาน ซึ่งแน่นอนว่าชื่อมันก็บอกอยู่แล้วว่ามันคือการ Test ในความเข้าใจของผมการ Test มันก็คือการทดสอบผลงานของเราที่สร้างขึ้นมาเพื่อ ดูว่ามันตรงกับสิ่งที่ลูกค้าต้องการหรือไม่ มันจะมีปัญหาอะไรหรือไม่ถ้ามันถูกเอาไปใช้งาน แต่ผมมาสะดุดประโยคหนึ่งประโยค ที่ Terry (ผู้สอน) พูด และเหมือนจะเป็นการให้ความหมายของคำว่า Test ได้ไม่เหมือนกับที่ผมเข้าใจมานาน จนผมต้องหยุดฟังและทำความเข้าใจ ประโยคที่ว่านั้นคือ

Test is the way to understand something that you don’t know

ผมแปลความหมายของมันว่า “เทสมันเป็นทางที่จะทำให้เราเข้าใจจริง ๆ ว่าสิ่งที่เรากำลัง … อยู่นั้นมันคืออะไร”  อ้าว … นี่มันไม่ใช่ Requirement Gathering ซึ่งเป็น Step แรก ๆ ในการพัฒนาระบบให้ตรงกับความต้องการของลูกค้าหรอกเหรอ Terry ย้ำต่อไปว่า Software Development ไม่เหมือนกับงาน Manufacturing อื่น ๆ ตรงที่เรากำลังสร้างสิ่งที่ไม่มีอยู่จริง (ก็มัน Soft อะนะ) แถมยังเป็นสิ่งที่ไม่เคยมีจริงมากก่อนในโลกนี้ (ถ้ามันมีอยู่แล้วก็ Copy เลยสิ) แถมบางครั้งมันเป็นสิ่งที่อยู่ในจิตนาการของลูกค้า ซึ่งเรามีหน้าที่ดึงความเป็นตัวตนของสิ่งนั้นออกมาแล้วสร้างเป็นสิ่งใหม่ของโลก มาถึงจุดนี้ Terry เลยพาเราเข้าไปเล่นเกมส์ง่าย ๆ อย่าง 20 คำถาม โดย Terry คิดชื่อของ คน ๆ นึง ไว้แล้วให้เราช่วยกันถามคำถามที่คำถามจะต้องออกมาเพียงแค่ 2 ทางเลือก เช่น ใช่/ไม่ , ดำ/ขาว เหล่านักเรียนจึงลุยตั้งคำถามกันอย่างไม่บันยะบันยัง สุดท้ายเราก็ตั้งคำถามไม่ถูก ไม่สามารถหาชื่อคนที่ Terry นึกได้ (ต้องให้จั้วมาเป้นช่วย จึงจะได้คำตอบ)

Terry จึงสรุปให้เราฟังว่า การตั้ง 20 คำถาม ก็เหมือนกับการทดสอบสมมุติฐานของเรา ว่าสิ่งที่เราคิดกับสิ่งที่ลูกค้าคิดมันตรงกันหรือไม่ แน่นอนว่าเรามันจะเริ่มจากคำถามกว้าง ๆ ที่สามารถตัดตัวเลือกได้มากที่สุด เช่น ชาย/หญิง, อายุเกิน 40 หรือไม่ แล้วค่อย ๆ เริ่มบีบตัวเลือกของเราให้แคบลง ไปทาง อาชีพ เล่นหนัง? ลองกลับมาตรงจุดที่ ถ้าเราต้องทำความเข้าใจสิ่งที่ลูกค้าต้องการ แน่นอนว่าวิธีการฝึกง่าย ๆ อย่างนึงคือ การตั้ง 20 คำถามกับลูกค้า เพื่อให้เราเข้าใจว่าสิ่งที่เราคิดกับสิ่งที่ลูกค้าเข้าใจตรงกัน และสามารถสร้างสิ่งที่ลูกค้าต้องการจริง ๆ ได้ เพราะฉะนั้นการเทสจึงไม่ใช่การทดสอบผลงานของเรา แต่น่าจะเป็นการทดสอบความเข้าใจของเรากับลูกค้ามากกว่า แต่ส่วนที่เราจะเอาสิ่งที่เราได้จากการตั้งคำถามมาสร้างเป็น Script ที่เป็น Manual หรือ Automate มันก็จะกลายเป็นผลพลอยได้จากการทำความเข้าใจ Requirement นั่นเอง

 

ปล. ตอนนี้เกมส์ 20 คำถามเป็นเกมส์ที่ผมกับลูกชอบเล่นกันมาก ผมรู้สึกว่ามันฝึกทักษะอะไรหลาย ๆ อย่างให้ลูกไปในตัวด้วย

Advertisements

One thought on “เมื่อการเทสไม่ใช่การทดสอบผลงาน …

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s