Test Double

วันนี้ได้อ่านบทความที่เกี่ยวกับการทำ test และได้รู้คำใหม่ๆ เช่น Test Double ที่ใช้เรียก class ที่ใช้ในการกันส่วนที่ไม่เกี่ยวข้องกับส่วนที่ต้องการทดสอบออกไป ซึ่ง Test Double มีหลายตัว คือ

Dummy <-- and="" fake="" mock="" p="" spy="" stub="">
ที่เขียนแบบนี้เพราะมีบทความจาก Robert C. Martin ที่บอกว่า Mock เป็นประเภทหนึ่งของ Spy และ Spy เป็นประเภทหนึ่งของ Stub และ Stub เป็นประเภทหนึ่งของ Dummy แต่ว่า Fake เป็นประเภทที่แตกต่างออกไป (ทั้งนี้ควรจะอ่านบทความควบคู่ไปด้วย เพื่อความเข้าใจมากขึั้น มิฉะนั้น อาจจะเข้าใจผิดได้ เช่น ถึงแม้ Stub จะเป็นประเภทหนึ่งของ Dummy แต่ว่าการใช้ในการทดสอบก็ต่างกัน เพราะว่า Dummy มักใช้เป็น parameter ในการส่งเข้า method แต่ว่า Stub เราใช้แทน class เพื่อให้ทำงานบางวัตถุประสงค์)

ทั้งนี้จากบทความเอง ก็ช่วยให้เรารู้ว่าโดยปกติการเขียน unit test เค้ามักจะใช้ Stub กับ Spy ส่วน Dummy ใช้น้อยมาก และจะใช้ Mock น้อยมากๆ เนื่องจาก syntax ในการเขียนที่ดูยุ่งๆ ของ Mocking Tools (ตามบทความนะจ๊ะ แต่เราก็รู้สึกแบบนั้น)

ก็ถือเป็นการเปิดหูเปิดตาในการทำ Unit Test อย่างมาก

Reference:
The Little Mocker

Software Quality

สำหรับคนทำงาน IT ทั้งคนวิเคราะห์ คนเก็บ requirement และทั้งสำหรับลูกค้าที่กำลังมองหา software


Software Quality (หรือเรียกว่า Quality Attribute) ซึ่งมีด้วยกันหลายตัว โดยระบบซอฟต์แวร์ควรจะต้องคำนึกถึง

• Availability ความพร้อมในการให้บริการ
• Modifiability สามารถปรับเปลี่ยนความสามารถได้
• Customizibility customize ได้ (เช่น หน้าจอ) 
• Extensibility เพิ่มเติมความสามารถ (feature) ภายหลังได้
• Integrability ทำงานติดต่อกับ legacy system ได้ เน้นด้าน low level เช่น OS, network, protocol
• Interoperability ทำงานร่วมกันได้ โดยปราศจากข้อจำกัด เน้น high level เช่นทำงานร่วมกับ function ต่างๆ
• Manageability 
• Maintainability
• Portability ทำงานข้ามแพลตฟอร์มได้
• Scalability รองรับการขยายตัวของการประมวลผลที่เพิ่มขึ้น (vertical, horizontal)
• Supportability รองรับ เช่น OS, virtual machine, hardware
• Performance ประสิทธิภาพ, การใช้ resource
• Security ความปลอยภัย (hardware, network, software)
• Safety ปลอดภัยต่อชีวิตและทรัพย์สิน สำหรับ software ที่เกี่ยวข้องกับความปลอดภัย เช่น software ควบคุมลิฟต์
• Testability ทดสอบได้
• Usability ใช้งานง่าย, ได้ประโยชน์ (การประมวลผล และความรู้สึก)

• Reliability มีความน่าเชื่อถือ (การประมวลผล และความรู้สึก)

โดยในระบบหนึ่งๆ อาจจะมี Key Quality (หรือเรียกว่า Architectural Driver) ประมาณ 4 - 7 ตัว ถ้ามากกว่า 7 ตัวจะเยอะเกินไป ยกเว้นในกรณีระบบใหญ่ๆ เท่านั้น

Thailand SPIN 2013

พอดีได้มีโอกาสไปงานค่ะ ไปงานสัมมนาหลังจากไม่ได้ไปงานแบบนี้มานานมาก เพราะไปทีไรก็รู้สึกว่าไม่ได้อะไรเท่าไร แต่อยากบอกว่างานนี้เป็นงานที่คิดว่าคุ้มค่ะที่ไป ไม่เคยได้เจองานสัมมนา IT แบบเสวนาแบบนี้เลย แต่ต้องบอกว่าประทับใจค่ะ ได้อะไรมากกว่าที่คิด

และอยากแชร์บางอย่างที่ได้มาเอาไว้ค่ะ ในงานช่วงเช้ามี section ของการเสวนา Do and Don't ซึ่งจากที่ได้ฟังมาย่อยได้ดังนี้ค่ะ (ขออภัยที่ใช้ภาษาอังกฤษ เพราะว่าตอนจดมาภาษาอังกฤษมันพิมพ์ได้เร็วกว่า)

Requirement phase

- Don't collect requirement from template. หรือถ้าจะใช้ก็ต้องใช้อย่างเข้าใจค่ะ
- Find problem first before requirement.
- Don't use same practice in different project.
- Tester should involve in requirement at requirement phase (almost finish phase), don't wait until test phase
- Don't call it requirement, because customer will be afraid to commit.

Analysis phase

- Don't use much time - do analyse very short, because requirement will continuously change .
- Reuse design as much as you can.
- If testers are for testing function, don't ask technical specification.
- Don't design alone. Do it with all team, with tester, BA, PM, customer, etc.
- Don't over design.

Coding phase

- Don't forget unit test.
- Send test data to developer.
- Tester don't need to ask developer for any to-do check list.
- Do unit test or automated test at coding phase.
- Make developer and tester work together.

Test phase

- Do defect management.
- Do root cause management.
- Do video record.
- Do test case priority.

Deploy phase

- Don't wait to deploy production at last. beware load balancing or other environment change, etc.

Maintenance phase

- Revise test case from production incident.
- Log incident.
- Don't forget production life cycle, that should include maintenance.
- Don't relocate staff frequently.

ทั้งนี้เป็นการย่อยความของตัวเอง ถ้ามีผิดพลาดประการใด ขอรับไว้แต่เพียงผู้เดียวค่ะ

นอกจากนี้ ยังได้ความรู้เกี่ยวกับ Agile Principles ด้วย ซึ่งหลายคนก็อาจจะรู้แล้ว ก็ข้ามไปค่ะ

Agile principles

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

ซึ่งทั้งนี้วิทยากรแนะนำว่าสำหรับใครที่จะทำ Agile ให้ดูเรื่อง TDD (Test Driven Development) ให้ดีๆ ค่ะ และควรจะหา automated test tools เพราะว่าการทำ Agile จะต้องทำ regression test บ่อยมาก

Reference: 

Principles behind the Agile Manifesto