Rational Unified process (RUP) คืออะไร

Rational Unified process (RUP) คืออะไร 

กระบวนการพัฒนา ซอฟต์แวร์ หรือ Software development lifecycle อีกหนึ่งแบบคือ Rational unified process (Rup) นั่นเอง

เป้าหมายของ Rational Unified process เป็นการทำให้กระบวนการในขั้นตอนนั้นๆสมบูรณ์ที่สุด มีการวนและทำซ้ำเรื่อยๆจนขั้นตอนสมบูณ์ โดยจะมีเป้าหมายในแต่ละขั้นตอนว่าควรจะได้ผลอะไรออกมาบ้าง

Rational Unified process หรือเรียกสั้นๆว่า (Rup) คือ กระบวนการพัฒนาระบบซอฟต์แวร์อีกรูปแบบหนึ่งซึ่งแบ่งขั้นตอนการพัฒนาระบบซอฟต์แวร์ออกเป็นรอบๆซึ่งมีขั้นตอนหลักๆจะอธิบายดังภาพต่อไปนี้

Testing Type มีอะไรบ้าง (Software Testing)

Testing Type มีอะไรบ้าง (Software Testing)

เป็นอีกหนึ่งรายวิชาของสายการเรียน Software Engineering ซึ่งก็คือ วิชา Software Testing ซึ่งเป็นขึ้นตอนหนึ่งที่สำคัญมากๆ ในกระบวนการพัฒนาซอฟต์แวร์  และผมก็ได้หาความรู้เพิ่มเติมเกี่ยวกับวิชาจากนี้จาก Internet และก็ไปเจอเว็บนี้เข้า เนื้อ และ คำศัพท์ครอบคลุมมากๆครับ มาดูกันเลยย...

เชื่อว่าหลายๆท่านที่เคยเล่นเกมส์ออนไลน์ ที่เคยบูมในช่วงแรกๆเมื่อหลายปีก่อน คงเคยได้ยินการเรียกชื่อ version ต่อท้ายเกมส์นั้นๆ ว่า alpha , beta, closed beta อะไรทำนองนี้บ้าง  แถมล่าสุด IE9 ก็ออกตัว Beta ออกมาให้เราได้ใช้กัน ทราบกันหรือเปล่าครับว่า คำว่า alpha/beta มันคืออะไร (อย่าตอบว่าเป็นยาทาแก้สิวแก้ฝ้านะครับ) ที่จริงแล้วทั้งคู่นั้นก็คือประเภทของการ Testing อย่างนึงครับ

คำถามต่อมาก็คือ การ Testing จริงๆแล้วมันมีกันอยู่กี่ประเภท หลายคนก็คิดว่า Testing มันยังจะมีแยกอะไรไปได้อีกเหรอ Testing มันก็แค่การทดสอบว่า application ไม่เจ๊ง ทำงานได้ปกติ result ออกมาครบสมบูรณ์ก็น่าจะเพียงพอแล้ว แต่ในความจริงแล้วมันสามารถแตกยิบย่อยอะไรลงไปได้อีกเยอะแยะ ราว 20-30 ประเภท โห…เยอะจริงๆ

ตรงนี้ขอยกมาจากเวป softwaretestinghelp.com ที่พูดถึงประเภทของการ Test โดยขอใส่ประสบการณ์ที่ได้คลุกคลีกับการ Testing อธิบายเข้าไปเพื่อให้เข้าใจกันง่ายขึ้น (หรือมันจะยากขึ้นก็เหอะ) แต่ขอออกตัวไว้ก่อนว่าผมได้ทำแค่บางประเภทเท่านั้น แต่ก็ยังพอได้ยินจากในทีมที่ทำงานที่ทำมาบ้างครับ…

• Alpha Testing – เป็นการ Test การใช้งานของระบบทั้งหมด โดยทำทุกอย่างให้เหมือนการใช้งานจริงทุกอย่าง โดยไม่จำเป็นต้องมีเครื่องหรือจำนวนเครื่องเหมือนที่จะมีจริง แต่ใช้การจำลองเครื่องขึ้นมาและสามารถใช้งานได้จริง ซึ่งเรียกว่า Virtual Machine โดยทั่วไปแล้ว จะการทำ Test ที่ฝั่ง developer หรือบริษัทที่พัฒนาโปรแกรมหรือระบบเอง โดยลูกค้า หรือ user จะยังไม่มีส่วนเกี่ยวข้องในการ Test นี้
• Beta Testing หรือ Pilot Testing - เป็นการ Test ที่ผู้ใช้งานจะเข้ามาทดลองใช้ระบบจริงๆ ซึ่งระบบที่จะทดสอบนั้นสามารถใช้งานได้จริง ด้วยเครื่องจริง โดยการ Test ประเภทนี้จะเป็นขั้นตอนสุดท้ายก่อนที่จะส่งมอบให้ลูกค้า หรือทำการจำหน่ายออกไป
• Blackbox Testing – ชื่อแปลความหมายว่าเป็นการ Test กล่องดำ นั่นก็คือ การ Test โดยที่เราไม่ต้องรู้ส่วนของการ Coding, Programming หรือส่วนต่างๆ ที่อยู่ด้านหลังการทำงานของโปรแกรมหรือระบบนั้นๆ Tester จะสนใจเฉพาะสิ่งที่อยู่ตรงหน้าเท่านั้น เช่น ดูเฉพาะหน้าต่างของโปรแกรม หรือผลลัพธ์ที่ได้เท่านั้น ไม่สนว่าขั้นตอนข้างหลังจะมีกระบวนการอย่างไรบ้าง
• Whitebox Testing หรือ GlassBox Testing – ตรงกันข้ามกับ Blackbox Testing อย่างสิ้นเชิง นั่นคือเป็นการ Test code หรือ logic การคิดหรือคำนวณค่า นั่นคือดูการทำงานของ Code
• Unit Testing – ลักษณะจะค่อนข้างคล้ายกับ Whitebox Testing คือเป็นการ Test ในระดับ Module ของ Application นั้นๆ โดยที่จะผู้ที่จะ Test จะต้องมีความรู้ในเรื่อง programming design และ coding ซึ่งโดยคนที่ทำการ Test จะเป็น Developer เองหรืออาจจะสลับกัน check ระหว่าง developer กันเอง สำหรับ Tester นั้น จะไม่มีส่วนเกี่ยวข้องในประเภทนี้ แต่ถ้ารู้เรื่องก็เยี่ยมครับ
• Integration Testing – เป็นการ Test การประกอบร่าง module แต่ละ module ที่นำมาใช้งานกับ function นั้นๆ หรือในแง่ของ component ที่อยู่คนละ Server ก็จะเป็นการ Test ว่าสามารถ connect และทำงานร่วมกันได้หรือไม่ การ Test ประเภทนี้เหมาะกับระบบที่เป็น Client/Server
• Incremental Integration Testing – เป็นการ Test การประกอบร่าง โดยค่อยๆใส่ทีละ Function หรือ Module เพิ่มเข้าไป แล้ว Test ไปเรื่อยๆ เรียกว่า Bottom Up Approach สำหรับข้อจำกัดของการ Test แบบนี้คือ Function หรือ Module นั้นๆ ควรจะต้องทำงานแบบอิสระ ไม่ผูกติดกับ module อื่นๆ เป็น dependency
• Functional Testing – เป็นการ Test ที่สนใจ Function ของ application นั้นว่าสามารถทำงานจนได้ผลลัพธ์ได้ครบตรงตาม requirement ที่กำหนดมาหรือไม่
• System Testing – เป็นการ Test ระบบทั้งระบบว่าตรงตาม requirement หรือไม่ โดยที่จะ Test บนระบบที่ปิด คือทำบน environment ที่ใช้สำหรับการ Test เท่านั้น - Functional Testing เป็น sub-set ของ System Testing
• End-to-end Testing - เป็นการเทสระบบทั้งระบบเหมือนกับ System Testing โดยที่สิ่งจะต่างกันคือ Tester จะ Test บนระบบที่จะใช้ถูกงานจริงที่ประกอบร่างกันโดยสมบูรณ์แล้ว เช่น ระบบสามารถขอข้อมูล แล้ว Flow ข้อมูลที่ต้องการจากเครื่องต้นทางต้นทาง มาแสดงบนหน้าจออีกเครื่องนึง โดยที่ไปเก็บข้อมูลใน Database อีกเครื่องนึง เป็นต้น
• Sanity Testing – เป็นประเภทการ Test โดยที่จะหยิบ function หลักๆ ของการทำงานมาใช้ (ส่วนใหญ่แล้วก็จะโดนบอกว่า ที่ไหนก็สำคัญ ฮ่าๆ) ซึ่งจะใช้ Test เมื่อมีที่การ update version ใหม่ๆขึ้นมา โดย version ใหม่ๆที่ออกมาจะต้องเป็นการ fixed defect เล็กๆน้อยๆ ซึ่งการทำการ Test นี้เพื่อเป็นการ guarantee ว่าระบบสามารถทำงานได้ปกติ ไม่ทำให้ระบบ หรือ application crash (ตรงนี้ถ้าเกิดขึ้นมาหล่ะก็น่ากลัวครับ)
• Regression testing – ส่วนนี้ผมโดนทำบ่อย เป็นการ Test เพื่อทดสอบส่วนของระบบ หรือ application ที่มีการเปลี่ยนแปลง โดยเลือกเป็น function เป็นหลัก โดยทั่วไปแล้ว การ Test ประเภทนี้ เป็นการทำซ้ำๆกันแทบทุกวันเพื่อ Test functions ดังนั้นแล้วเพื่อไม่ให้เป็นการเปลืองเวลาในการ Test เราจึงมี Tool ที่ใช้ในการช่วยเรา run test เช่น Test script เป็น command line run ด้วย .bat หรือ HP Quick Test Pro ที่ช่วยในการทำ Automate Testing (ผมจะพูดถึง Test Tool ในตอนต่อๆไปครับ)
• Acceptance Testing – เป็นการ Test ระบบ ซึ่งลักษณะจะเหมือนกับ End-To-End แต่ว่าจะทำการ Test โดยลูกค้า หรือ user ที่จะใช้งานจริงให้พึงพอใจเสียก่อน ก่อนที่จะ Sign-off งาน
• Performance testing – เป็นการทดสอบระบบหรือ component ว่าสามารถรองรับการใช้งานด้วยจำนวนผู้ใช้ หรือ จำนวน data ที่เข้ามาในระบบตามที่ requirement บอกไว้หรือไม่ และเรามักใช้สลับกันกับ Load Testing และStress Testing โดยเหมารวมว่าเป็น Performance Testing ซึ่งความหมายของทั้งสองตัวนี้คือ…

• Load Testing – เป็นประเภทหนึ่งในการทำ Performance Testing เพื่อใช้ในการดูการทำงานของระบบ เมื่ออยู่ในสภาวะที่คาดว่าจะเกิดขึ้นเมื่อมีการใช้งานจริง เช่น เราคาดไว้ว่า จะมีคนเข้ามาใช้งาน app เราประมาณ 100 คน เราก็สร้าง user เพื่อเข้าไปใช้พร้อมๆกัน แล้วดูว่าระบบจะทำงานได้ช้าลง เมื่อมี user เข้ามาใช้งานพร้อมๆกัน 100 คนหรือไม่
• Stress Testing – อีก 1 ประเภทของ Performance Testing เป็น on-top ของ Load Testing คือการ Test นี้เราจะดูจำนวนมากที่สุดที่ระบบรับได้ จากตัวอย่างของ Load Testing ถ้าเราสามารถ guarantee ว่า 100 คนรับได้แน่นอน ตัวเลขต่อไปที่เราจะหาคือจำนวนที่ user ที่รองรับได้สูงสุดจนกว่าระบบจะล่ม ด้วยการเพิ่ม User ไปเรื่อยๆทีละ 5 user
  การทำ Performance นั้น เราคงไม่สามารถจะให้ user จริงๆมาใช้งานได้ ก็ต้องมีการสร้างหรือ generate user หลอกๆขึ้นมาเพื่อแทนที่ user จริงๆ และมักมีการเขียน script เพื่อให้มัน execute การ test ได้ เช่นเดียวกันกับกรณีการทำ Regression Testing
• Usability Testing หรือ User Interface Testing – เป็นการ Test User Interface ของ application ว่าสามารถเข้าใช้งานได้ทุกเมนู หรือทุกหน้าจอหรือไม่ รวมไปถึงหน้าตาของ application เหมาะสมกับการใช้งานหรือไม่ ทั้งในแง่ความสะดวกและความง่ายในการใช้งาน อาจรวมไปถึงการทำ User Manual หรือ Troubleshooting document ให้ user เมื่อ user เจอปัญหา ก็จะสามารถใช้ document ช่วยในการอ้างอิงได้
• Install/Uninstall testing - เป็นการ Test package ของ application ในแง่ของการติดตั้ง, การเอาออกจากเครื่อง (remove) และรวมไปถึงการ upgrade โปรแกรม (ถ้ามี) ซึ่งต้องครอบคลุมไปถึงการติดตั้งบน hardware / OS / Environment ที่ต่างกันด้วย
• Recovery testing – เป็นการ Test โดยที่จะดูการ recover ของระบบ หรือ application หลังจากที่เกิดเหตุการณ์ผิดปกติของระบบ เช่น Crash, Hardware เสียหาย และเหคุการณ์ที่ไม่คาดคิด ว่าสามารถเปิดขึ้นมาแล้วทำงานได้ปกติ
• Security Testing – เป็นการ Test ระบบเพื่อป้องกันการเข้าถึงข้อมูลโดยทุจริต หรือเรียกว่า Hack เข้าสู่ระบบ ไม่ว่าจะเป็นโจมตีทั้งภายในหรือภายนอก การ Test ประเภทนี้ส่วนใหญ่แล้วจะใช้กับบริษัทหรือองค์กรที่เก็บข้อมูลที่เป็นความลับ เช่น ธนาคาร เป็นต้น ซึ่งผู้ที่จะเป็น Tester ในประเภทนี้ต้องเป็นคนที่รู้เรื่อง Network Security และช่องทางที่เป็นไปได้ในการเจาะข้อมูลเป็นอย่างดี
• Compatibility Testing – เป็นการ Test การเข้ากันระหว่าง hardware/software/network/OS ว่าสามารถทำงานเข้ากันได้หรือไม่ ที่เคยเจอคือ case ว่า สามารถ Run application นี้ได้บน Windows 2003 แต่ไม่สามารถทำบน Windows 2008 Server หรือ Windows 7 ได้
• Comparison Testing - เป็นการ Test เพื่อเปรียบเทียบจุดเด่น จุดด้อยของแต่ละ version ที่ผ่านมา หรืออาจเปรียบถึง product ตัวอื่นๆที่ทำงานได้เหมือนกัน
• Data Comparison Testing – เป็นการดึงข้อมูลในแต่ละส่วนของ module มาเปรียบเทียบกันว่าข้อมูลเหมือนกันหรือต่างกันหรือไม่ โดยที่ต้นทางของข้อมูลจะต้องเป็นที่ที่เดียวกัน

เป็นอย่างไรบ้างครับ ประเภทของการ Testing มีเยอะอย่างที่เกริ่นไว้เยอะมากๆ ที่จริงตอนผมนั่งเขียนก็ไม่นึกว่ามันจะมีเยอะแยะขนาดนี้ แต่ไม่ว่าจะเป็นการ Test ประเภทไหน หรือมีกี่อย่าง เป้าหมายที่สำคัญที่เหมือนกันก็คือ Quality of Software ต้องมีสูงสุด และครอบคลุม Requirements ที่ลูกค้าบอกมาทุกประการครับ

ขอบคุณแหล่งข้อมูลจาก : http://charathbank.wordpress.com

5 ปัญหาหลักของกระบวนการพัฒนาซอฟต์แวร์

5 ปัญหาหลักของกระบวนการพัฒนาซอฟต์แวร์

5 ปัญหาหลักในการพัฒนาซอฟต์แวร์ หรือจะว่าเป็น 5 ปัญหาคลาสสิกเลยก็ว่าได้ครับ ถึงผมเองจะไม่เคยได้พัฒนาซอฟต์แวร์อย่างเต็มรูปแบบก็ตาม แต่ในช่วงเรียนปี 3 ก็พอมีอยู่บ้างเป็นโปรเจคใหญ่ที่ต้องนำมาพัฒนามีกระบวนการการทำงานต่างๆ เหมือนกับว่าเราทำงานจริงๆเลย และ อาจารย์ก็มักจะตรวจสอบความคืบหน้าของโปรเจคเราอยู่ทุกๆสัปดาห์เลย เพื่อให้อาจารย์มองเห็นปัญหาต่างๆ ในการทำงานของเรา ...และในช่วงสอบ Final เทอมหนึ่งของปีที่ 3 ก็ได้มีข้อสอบของรายวิชานึงวิชานี้จะเป็นจะมีการเรียนการสอนที่คล้ายกับ Team Software Process (TSP)  ข้อสอบรายวิชานี้จะเป็นปัญหาต่างๆของเราในการพัฒนาโปรเจค ซึ่งก็คือปัญหาหลักๆ หรือปัญหาคลาสสิกของนักพัฒนาซอฟต์แวร์นั่นเอง..

 มาดูปัญหาที่เกิดขึ้นกันครับ 

1.) ความต้องการ (Requirement) จากผู้ใช้ (User) ที่ไม่ชัดเจน คลุมเคลือ (Unclear) ขาดความสมบูรณ์ (Incomplete) เรียบง่ายจนเกินไป จนไม่สามารถวิเคราะห์ได้ว่าต้องการอะไร (Too General) และอื่นๆ อาจมีต้นเหตุมาจากความต้องการ (Requirement) อีกมาก

>>การจากเรียนกระบวนการพัฒนาซอฟต์แวร์ในรายวิชาต่างๆ จะเห็นว่าสิ่งสำคัญที่สุดในการพัฒนาซอฟต์แวร์ให้สำเร็จโดยเกิดปัญหาน้อยที่สุด ก็คือ Requirement เป็นมันคือจุดเริ่มต้นของซอฟต์แวร์ใดๆ บนโลกนี้เลยก็ว่าได้ครับ Requirement ที่ว่าไว้ดังกล่าวจะส่งผลทำให้เกิดเป็น Defects หรือ Bugs จำนวนมากมาย ซึ่งส่งผลต่อ Project Plan ทันที เนื่องจากจะต้องเสียเวลาในการมานั่งถกเถียง หรือสรุป ถึงสาเหตุ หรือหาข้อสรุป เพื่อปิด Defects หรือ Bugs เหล่านั้นว่าอันไหนที่จะไม่แก้ เนื่องจาก Requirement ไม่บอก หรือไม่ชัดเจน หรือถ้าอันไหนจะแก้ไข ก็ต้องไปเก็บข้อมูลมาเพิ่มเนื่องจาก Requirement ไม่ชัดเจนอีกเช่นกัน

จากสถิติคราวๆ ของ Defects Originate in Project Phase

56% เกิดจาก Requirement

27% เกิดจาก Design

10% เกิดจาก Coding

7% เกิดจาก Other 

จะเห็นได้ว่า Requirement เป็นส่วนสำคัญที่สุดที่สุดในการพัฒนาซอฟต์แวร์เลยก็ว่าได้ หากเรามีการเก็บ Requirement ที่ดี ติดต่อสื่อสารงานกับ User เป็นประจำ ก็จะทำให้ซอฟต์แวร์ที่เราพัฒนามีความถูกต้องสมบูรณ์ และเป็นที่ยอมรับของทั้ง 2 ฝ่าย  ครับ..


2.) แผนงานโครงการไม่ดี มีลัษกณะเป็นแผนงานที่เพ้อฝัน (Unrealistic Schedule) การวางแผนไม่ได้ตั้งอยู่บนข้อมูลที่แท้จริง ทำแบบเพ้อฝันไม่คิด ขาดข้อมูลที่ได้จากการปรึกษาหารือสมาชิกในทีม ไม่ว่าจะเกิดจากสาเหตุใดๆ ก็ตาม ขาดการประสานงานย่อยที่สำคัญกับผู้ใช้หรือลูกค้า การจัดทำแผนอาศัพเพียงความรู้ความเข้าใจของตนเองเป็นหลัก

>>ยกตัวอย่างของการวางแผนที่มีลักษณะเพ้อฝัน....ในหนึ่งโปรเจค ก็จะมี Project Manager หรือ Planning Manager เป็นผู้ดูแล ควบคุมเรื่องของการจัดทำแผน หากผู้จัดทำแผนดังกล่าว ทำแผนงานเสนอไปยังลูกค้า โดยมิได้ปรึกษาในส่วนของแผนงานย่อยๆในแต่ละส่วน ที่อยู่ใน Project โดยอาศัยเพียงความเข้าใจของตัวเองเป็นหลัก รับรองได้ว่า เหนื่อยแน่แน่ !! เพราะการจะวางแผนการทำงาน หรือกำหนดการส่งโปรเจคได้นั้น จะต้องมีการปรึกษากับสามาชิกภายในทีมเพื่อประเมินระยะเวลา การเขียนโค้ด หรือ ส่วนอื่นๆก่อน จึงจะสามารถสรุปผล และส่งมอบรายละเอียดให้แก่ลูกค้าได้..
(จากประสบการในการเขียนโค้ดส่งงานอาจารย์ที่ผ่านมา แค่การ Coding ก็ใช้เวลาถึงวันกำหนดส่งแล้วครับ 55555555)

3.) การทำสอบซอฟต์แวร์ไม่เพียงพอ (Inadequate Testing) มักจะพบปัญหาในลักษณะที่ว่าซอฟต์แวร์นี้ผ่านการทดสอบมาได้อย่างไร ปัญหามากมาย ไม่มีคุณภาพทั้งในระดับระหว่างการทำงานร่วมกันในทีม หรือหลังส่งมอบให้ลูกค้าแล้ว หรือมีการทดสอบซอฟต์แวร์ที่ขาดความรอบคอบเวลาในการทดสอบไม่เพียงพอ และอื่นๆ อีกมาก

>> บ่อยครั้งที่จะได้ยินคำบ่น "Test มายังไงเนี่ย Software มีปัญหาเยอะแยะเลย" หรือไม่ก็ "โห ตอน Test ไม่เจอเลยหรือ Bug พวกนี้" หรือไม่ก็ "ผ่าน Test มาได่้ไง ไม่มีคุณภาพเลย" เป็นต้น เหล่านี้เป็นภาพสะท้อน หลังจากส่งมอบงานให้่ลูกค้าบ้าง หรือบางทีก็คนในทีมพัฒนา Software เองก็ตาม

คุณภาพของงาน หรือสินค้าใดๆ ใช่ว่าใช้เวลาเพียงไม่นานจะสร้าง หรือผลิตให้ออกมามีคุณภาพได้ เช่นเดียวกันงานทางด้าน Software Testing นั้น เป็นงานที่ต้่องใช้เวลา และความละเอียดรอบคอบในการทำงานต้องยอมรับกันเลยว่าเวลาที่ให้มาในส่วนของ Software Testing นั้น น้อยจริงๆ หรือบางครั้งได้มาเยอะ แต่ก็จะถูกเบียดบังเวลาจากงานก่อนหน้านั้น ที่ไม่เสร็จแล้วมาแอบกินเวลาของ Software Testing ไป จนหดสั้น เหลือนิดเดียว ฉะนั้นอย่าได้หวังว่า Defects หรือ Bugs จะน้อยครับ
หากลูกค้าบ่น หรือติ มาเรื่องของคุณภาพ หรือความไม่สมบูรณ์ของ Software เมื่อท่านๆ เหล่้านั้น พบว่า Software มีปัญหา หรือล่มไประหว่างใช้งาน ก็ต้องยิ้ม และก้มหน้าแก้ไขไปครับ


4.) มีการเปลี่ยนแปลงไม่จบสิ้น (Always Change) ในระหว่างที่พัฒนาซอฟต์แวร์ มักจะขอให้มีการเปลี่ยนแปลง Features หรือ Functions ไม่ว่าจะเพิ่มขึ้นหรือตัดออก มั้กจะสร้างปัญหาให้กับทีมพัฒนาบ่อยครั้งที่กระทบกระเทือนถึง Solution Design ทำให้ต้องทำงานเพิ่มหรือทำงานใหม่เกือบทั้งหมด หรือในบางครั้งถึงกับต้องออกแบบใหม่ก็มี

>> หลังจากที่ Developer เริ่มพัฒนา Software ไป ในระหว่างก็มีการขอเปลี่ยนแปลง Features หรือ Functions ไม่ว่าจะเพิ่มขึ้นมา หรือตัดออกไป ไม่ว่าจะด้วยเหตุผลใดๆ ก็ตาม ใช่ว่าจะสร้างความปวดหัว, ขุ่นเคือง หรือไม่ปลื้ม ให้กับเหล่า Developer เท่านั้น ทางทีม Software Tester ก็ได้รับผลกระทบด้วยเช่นกัน

เมื่อมีการปรับเพิ่ม หรือลด Features หรือ Functions เกิดขึ้น สิ่งที่ตามมาก็คือการต้องปรับในส่วนของ Solution Design ที่ได้ถูกออกแบบมาแล้ว โชคดีไปหากการปรับเปลี่ยน Features หรือ Functions เหล่านั้น ไม่กระทบกับ Solution Design มากเท่าไร แต่หากว่าการปรับเปลี่ยนมีผลทำให้ต้องรื้อ Solution Design ใหม่ทั้งหมด ดีไม่ดี ต้องออกแบบกันใหม่

ทางทีม Software Testing เองก็ต้องออกแบบการ Testing รวมทั้งต้องเตรียมงานต่างๆ เพื่อใช้ในการ Testing ไม่ว่าจะเป็น Test Cases, Test Data และ Test Environment ต่างๆ ซึ่งการปรับเพิ่ม หรือลด Features หรือ Functions เองก็มีผลกับทางทีม Software Testing ด้วยเช่นกัน

5.) การขาดการติดต่อสื่อสารที่ดี (Miscommunication) ปัญหาหลายอย่างเกิดขึ้นจากการไม่เข้าใจกันและมีการติดต่อสื่สารกันอย่างผิดๆ หรือไม่มีการติดต่อสื่อสารกันเลย ปัญหาเช่นว่านี้เกิดขึั้นได้ในทุกๆระดับ ทั้งระหว่างทีมพัฒนาซอฟต์แวร์ด้วยกันเอง หรือปัญหาที่ไปเกิดกับผู้ใช้

>>ปัญหามักจะเกิดขึ้นเสมอหากเราต้องทำงานร่วมกันเป็นทีม(ประสบการณ์ที่พบเจอมา)  ซึ่งเป็นอีกหนึ่งเรื่องคลาสสิกก็คือ ไม่ค่อยจะคุยกัน หรือไม่ก็เข้าใจกันไปคน ละทิศ ละทาง Developer เองก็ไม่เข้าใจ หรือไม่รู้ว่าลูกค้าต้องการอะไร หรือไม่ Developer ก็พบว่าลูกค้าเข้าใจในบางเรื่องไม่ถูกต้อง ก็ไม่ชี้แจ้ง หรืออธิบาย เป็นต้น เหล่านี้ก็เลยเป็นที่มาของปัญหาในระหว่างการพัฒนา Software และก็ตามมาด้วย Defects หรือ Bugs ที่เกิดขึ้นเนื่องพัฒนา Software ออกมาไม่ตรงตาม Requirement หรือ System Design ที่ออกแบบไว้ก็ตาม

แต่ก็เช่นกันใช่ว่าจะเกิดปัญหาเรื่อวนี้เฉพาะ Developer กับลูกค้าเท่านั้น Software Tester กับ Developer เองก็เช่นกัน ไม่เข้าใจก็ไม่คุยกัน มีปัญหา หรือข้อสงสัยต่างๆ ก็ไม่คุยกัน ดังนั้นก็ก่อให้เกิด Defects หรือ Bugs ที่ไม่น่าจะแจ้งไปทาง Developer เองก็มี

ฉะนั้นหันหน้ามาคุยกัน หรือคุยกัน เมื่อพอปัญหา หรือมีข้อสงสัยใดๆ ในทีมพัฒนา Software เพื่อหาวิธีแก้ไขปัญหานั้นอย่างเร่งด่วน  "อย่าลืมนัดกันมาแล้วแก้ปัญหากันจริงๆ นะค้าบบบ"


เนื้อหาทั้งหมด เป็นบทความที่ผมเขียนขึ้นหลังจากเข้าสอบในรายวิชาหนึ่งเกี่ยวกับกระบวนการพัฒนาซอฟต์แวร์ภายในทีม ซึ่งข้อสอบจะเป็นการบอกถึงปัญหาต่างๆที่เกิดขึ้น แล้วให้พวกเรายกตัวอย่างหรือหาแนวทางในการแก้ปัญหา ซึ่งผมก็ได้เขียนบทความขึ้น ทั้งจากประสบการณ์อันน้อยนิด แล้วก็การศึกษาข้อมูลจากอินเตอร์เน็ต จากผู้ที่เคยพบเจอปัญหาต่างๆนี้โดยตรง มาเพื่อใช้เขียนบทความนี้ขึ้น ผิดพลาดประการใดขออภัย ด้วยครับ ^__^

ขอบคุณข้อมูลจาก : อาจารย์ผู้ดูแลโปรเจคที่ชี้ให้เห็นพื็นฐานของปัญหาในการทำงาน และ ข้อมูลจากเพิ่มเติมจาก http://www.welovebug.com ที่แสดงให้เห็นถึงปัญหาจริงๆ