วันนี้มาพบกับไอริในโหมด Geek (ใส่แว่นแปป)
อะแฮ่ม!!
เชื่อว่าคนที่เป็น Programmer/ Software Engineer/ Developer หลายคนเขียนโค๊ดที่เป็นในส่วนของงานเสร็จแล้ว ก็ส่งงานให้ลูกค้าTest รันผ่าน ไร้บัค ลูกค้าบอก Go-Live ก็จบใช่มั๊ยคะ!!
ตอบบบบบ!!
นั่นการเขียนโค๊ดที่ไร้ซึ่ง Quality นะคร๊ะะะะ (ว่าไปนั่น)
ดังนั้นเราจะมา Control Quality ด้วยการเขียน Test Case กันค่าา O wO/
แล้วการเขียน Test Case คืออะไรล่ะ?
Test Case ก็คือการเขียน Code เพื่อพิสูจน์ว่า Code ที่เราจะส่งงานไปเนี่ย มันทำงานได้จริงๆนะตะเอง ไม่ได้โกหกไก่กาอาราเล่
แล้วไอ้ Test Case มันคืออะไรล่ะ?
มันก็คือสถานการณ์ และความเป็นไปได้ทั้งหมดที่ๆโค๊ดเราควรจะเป็น ยกตัวอย่างเช่น การ Log in เข้าหน้าเว็บ Test case ทั้งหมดควรจะมีก็คือ
- User สามารถ Log in ได้โดยการใส่ Username และ Password ที่ถูกต้อง
- User ไม่สามารถ Log in ได้ ถ้า Username หรือ Password ไม่ตรงกับค่าที่เก็บไว้
- User ไม่สามารถ Log in ได้ ถ้าไม่ได้ใส่ค่า Username หรือ Password
- ถ้า User ไม่ได้ใส่ Username หรือ Password ต้องมีข้อความแจ้งเตือนว่าไม่ได้ใส่
- ฯลฯ
แค่เขียนโค๊ดส่งงานให้ลูกค้าก็จะตายละ ทำไมต้องมาเขียน หรือทำอะไรแบบนี้ด้วยเนี่ย?
อย่างที่บอกในตอนแรกคือเพื่อการ Control Quality โค๊ดค่ะคุณ ลองนึกสิว่าเราส่งงานไปทั้งๆที่ไม่มี Test Case เนี่ย แล้ววันดีคืนดีคนอื่นกลับมาแก้งานของเรา แล้วโค๊ดที่เค้าแก้มันดั๊น ทำให้งานที่เราทำไปเมื่อชาติที่แล้วพังจะทำยังไงคะ? แล้วยิ่งไปกว่านั้น ถ้า QC/QA หรือใครก็แล้วแต่ไม่มา Test งานเก่า เอาแต่ Test งานใหม่ แล้วลูกค้าผู้น่ารักมาเจอเข้าเองจะทำอย่างไรคร๊ะ แน่นอนความฉิบหายบังเกิดค่ะ (ว่าไปนั่น) นอกจากนี้ยังเป็นการช่วยลดระยะเวลา/cost ในการ Test ที่จะเกิดขึ้นในอนาคตด้วยค่ะ
แล้วทำไมถึงไม่ให้คนที่มีหน้าที่ Test ทำเองล่ะ ทำไมต้องเป็นไอ้คนที่เขียนโปรแกรมมันเขียนด้วย?
การเขียน Test Case ถือได้ว่าเป็น White Box Testing อย่างนึงคือคนเขียนเนี่ยมันจะต้องรู้ Flow ข้างในแล้วว่าทำยังไงมันถึงจะเกิด Error หรือทำยังไงโปรแกรมมันถึงจะรันผ่าน แล้วก็ถือได้ว่าเป็นการ Verify “เบื้องต้น”ว่า โค๊ดเรารันไม่ผิดพลาด ส่วนคนที่มีหน้าที่ Test เค้าก็จะ Test ในส่วนของ Black Box Testing คือแกกดหรือแกทำไงก็ได้ให้โค๊ดมันทำงานไม่ตรง Spec อ่ะ (ควานหาบัค)
Tools ที่ใช้ในการเขียน Test Case มีอะไรบ้าง?
โอ๊ยย หลายอย่างเลยค่ะคุณ ขึ้นอยู่กับว่าคุณใช้ภาษาอะไรในการเขียน แล้วที่เขียนเนี่ยจะ Test อะไร อย่าง Java ก็จะมี JUnit , Perl ก็มี Module Test การ Test หน้าเว็บส่วนมากก็ใช้ Selenium ขนาดตัว Ruby on Rails ยังมี Folder Test เพื่อไว้ใช้สำหรับเขียน Test case ของ Web application เลยค่า (รู้แค่นี้)
Step การเขียนมีอะไรบ้าง?
อย่างอื่นก็ต้อง List Cases ทั้งหมดออกมาก่อนว่าจะเขียนกรณีไหนบ้าง จากนั้นดูว่าขั้นตอนการ Test ทั้งหมด มี Step ไหนที่เป็นเหมือนๆกันก็ให้เอาไปใส่ใน Test Setup จากนั้นลงมือเขียนแต่ละ Case ส่วนไหนที่ต้องทำการคืนค่าทั้งหมดในระหว่างที่ Test ก็ให้เอาไปใส่ใน Test Tear down ค่ะ ยกตัวอย่างการ Test Log in แบบเมื่อกี๊ละกันเราให้ Step คร่าวๆในการ Test คือ
- เปิดหน้าเว็บ
- ไปที่หน้า Log in
- ป้อนข้อมูล
- กด Submit
- ตรวจค่าที่ได้ว่าควรจะเป็นอะไร
- clear cache และ ปิด Browser
จาก Step คร่าวๆนี้เราควรที่จะเอา 1 & 2 ไปไว้ที่ Test Setup เพราะทุกๆ case ของการ login ต้องทำแบบนี้ และ เอา 3&4&5 ไปเขียนแยกในแต่ละ Test case เพราะแต่ละ case มี Step การ Test ย่อยที่ไม่เหมือนกัน การตรวจค่าก็ไม่เหมือนกัน จากนั้นก็เอา 6 มาเขียนไว้ที่ Test Tear down เพราะทุก case ต้อง clear cache และ ปิด Browser ค่ะ
ข้อเสียของการทำ Test Case คืออะไร?
ใช้ Cost มากกว่าการเขียนแค่ code เพียวๆค่า ไอริว่ากรณีแบบนี้มันเหมาะกับ Long Term maintenance มากกว่านะ ถ้าเขียนแล้วใช้งานในระยะเวลาสั้นๆก็ไม่ต้องเขียนก็ได้(มั้ง?)
มีอะไรเพิ่มเติมที่อยากบอกมั๊ย?
โดยอุดมคติแล้ว เราควรที่จะเขียน Test Case ก่อนการเขียน Source code ที่ใช้งานจริงๆเพราะจะทำให้เราเห็นภาพรวมในการ Test มากขึ้น แล้ว Test case ที่เราเขียนก็จะไม่ไปในทาง bias คือเขียนเข้าข้างตัวเองว่ามันรันผ่านค่ะ ลองนึกภาพว่าถ้าคุณเขียน Test case ก่อน คุณก็จะนึก Case ขึ้นมาแล้วลงมือเขียนว่าแต่ละ Case ควรจะเป็นไปในทิศทางไหน ทำให้การ Test มีประสิทธิภาพมากขึ้น แต่ถ้าคุณเขียนโค๊ดก่อนแล้วค่อยมาเขียน Test Case ก็กลายเป็นว่าคุณเขียนเพื่อให้มัน prove ว่าโค๊ดของฉันรันผ่านไปงั้นๆ ( มั้งนะ ในความรู้สึก =__=a? )
เพราะฉะนั้นมาทำให้โค๊ดที่เราเขียนมีคุณภาพมากขึ้นกันเถอะค่า \O wO/
~จบแล้น~
