สัปดาห์ที่ผ่านมา มีอธิบายเรื่องของการทดสอบแบบอัตโนมัติไป
ทั้ง Unit, Component, Contract และ Integration test ไป
มักจะมีคำถามมากมายมาเสมอ ยกตัวอย่างเช่น
- ใครเป็นคนออกแบบ
- ใครเป็นคนเขียน
- ใครเป็นคน run test และ สรุปผล
- ใครต้องมาทำบ้าง
- จะมั่นใจได้อย่างไร ว่ามันทดสอบถูก
และอื่น ๆ อีกมากมาย
คำถามต่าง ๆ ล้วนมาจากคนที่ไม่ทำ ไม่เคยทำ และ จะทำ
ดังนั้นมาลองตอบแบบสั้น ๆ ไว้นิดหน่อย
คำถามใครเป็นคนออกแบบ ทดสอบ และ สรุปผล ?
ตอบด้วยคำถามว่า ออกแบบตอนไหนก่อน สำหรับ test case ?
ส่วนใหญ่ได้คำตอบ 2 แบบ คือ
- ออกแบบหลักจากได้รับ requirement หรือ บางคนเข้าไปคุย requirement ด้วยเลย
- ออกแบบหลักจากที่ทีมพัฒนาส่งมาให้ และ บอกว่า เสร็จแล้ว พร้อมทดสอบ
ทั้งสองแบบมีปัญหาหรือไม่ ?
แบบแรกดูดีมาก ๆ แต่ได้เอาไปให้ทีมพัฒนาดู หรือ ประกบไปกับ requirement หรือ technical spec ไหม ?
ส่วนใหญ่บอกว่า ไม่ เพราะว่า จะรอยิง !!
แบบที่สองนี่ชัดเจนว่า รอยิง !!
ผลที่ตามมาคือ bug เพียบ
แล้วก็บ่น
แล้วก็ด่า
แล้วก็โยนงานกันไปมา
ไม่จบไม่สิ้นสัก
ถ้าเป็นแบบนี้ แล้วต้องการให้ทดสอบอบบอัตโนมัติ
คิดว่า จะมีการเปลี่ยน process การทำงานไหม
บอกเลยว่า ไม่
แสดงว่า ก็รอยิงเหมือนเดิมใช่ไหม
คำถามที่ตามมา คือ ใครจะเขียน automated test case ละ ?
คำตอบที่มักจะได้คือ ไม่มีใครทำ
ดังนั้น จ้างเลย หรือ รับสมัครงาน automated tester ไปเลย
คิดว่า จะดีขึ้นไหม ? คิดเอาเอง
ดังนั้นย้อนกลับมาที่จุดเริ่มต้นกันดีกว่า ...
ก่อนจะถามว่าใคร
มาคุย end to end process ของการ delivery software ก่อนไหม
ว่าปัจจุบันเป็นอย่างไร
มีปัญหา หรือ pain point ตรงไหนบ้าง
จะได้ทำการปรับปรุง และ แก้ไขปัญหาได้อย่างถูกจุด
ไม่ต้องมาลีลา หรือ รำไปรำมาเยอะ
เช่น process การทำงานเป็นดังนี้
- คุย requirement แล้วได้เอกสารออกมา เพื่อเอาไป design ต่อ
- ทำการ design ทั้ง architecture และ feature
- ทำการ design ในฝั่ง technical
- ทำการพัฒนา
- ทำการทดสอบ
- ทำการส่งมอบ
ปัญหามีอะไรบ้าง จาก process ข้างต้น
เน้นที่เฉพาะการทดสอบก่อนก็ได้
- ทีมออกแบบ ทีมพัฒนา ทีมทดสอบ มี requirement คนละชุด หรือ คนละ version เพราะว่า ระหว่างทางเปลี่ยนไปเรื่อย ๆ แล้วไม่พูดคุยกัน สนุกเลย !!
- คุณภาพแย่หลังส่งมอบ
- ทดสอบช้า
- ทดสอบซ้ำ ๆ ทั้งหมดไม่ค่อยได้ (regression test)
- ในการพัฒนาเจอ bug เยอะ พอมาทดสอบก็เจอเยอะ วนแก้ไปมาหลายรอบมาก ๆ บางคนแก้ไขและทดสอบจนท้อ
- ทำเอกสารการทดสอบไป ทำเองทดสอบเอง นักเลงพอ
ปัญหาข้างต้นอยากแก้ไขอะไรไหม ?
ยังไม่ต้อง automated test นะ เอา manual test ก่อนนะ
เพื่อให้ปัญหาข้างต้นมันลดลง
ยกตัวอย่างเช่น เอกสารไม่ตรงกัน
ดังนั้น ทำข้อตกลงในการทำงานร่วมกันก่อนไหม
เรื่องของการเปลี่ยนแปลง
ถ้ามีการเปลี่ยนแปลงใด ๆ ต้องนัดคุยกันก่อนเสมอเป็นต้น
บางคนบอกว่า มันช้านะ !!!
คำถามคือ สิ่งที่ทำ ๆ กันอยู่สร้างปัญหาหรือไม่ จะลดไหม ?
คุณภาพของ software มันแย่ เช่น bug เยอะ จะแก้ไขอย่างไรดี ?
ทดสอบบ่อย ๆ ได้ไหม ไม่ต้องรอให้เสร็จทุก feature
แบบนี้ทำได้ไหม
มาวางแผนกันไหม
ทั้งคนคุย requirement คนออกแบบ ทั้งคนพัฒนา และ คนทดสอบ
หรือ แทนที่จะมารอยิง
ทำไมไม่ไปทำด้วยกันเลย
นั่นคือ ก่อนเริ่มทำมาสรุปกันก่อนว่า
เข้าใจ requirement ตรงกันไหม
จะทดสอบอะไรบ้าง ถึงจะถือว่า ผ่าน หรือ ไม่ผ่าน
เป็นการสร้างข้อตกลง หรือ ความเข้าใจร่วมกัน
จะได้เข้าใจอีกว่า อะไรคือ bug อะไรคือ change อะไรคือ new requirement เป็นต้น
อยากทำงานแบบแมวจับหนู หรือ ทำงานเป็นทีม ก็เลือกเอา !!
พอชุดการทดสอบเยอะ ๆ น่าจะมีปัญหาเรื่องการทดสอบทั้งหมดซ้ำ (regression test)
ซึ่งยังไม่ต้องพูดถึงก็ได้
เอาแค่ปัญหาข้างต้นให้ลดลง จนเป็นที่น่าพอใจก่อน
เนื่องจากเรื่องหลังจากนี้
จะกลับมาที่ automated test แล้วนั่นเอง ...
แล้วจะกลับไปที่คำถามแรก เรื่อง ใครทำอีกที !!!