คำถามติดแท็ก acceptance-testing

การทดสอบ TDD และการทดสอบหน่วยดูเหมือนจะคลั่งมากในขณะนี้ แต่มันมีประโยชน์จริง ๆ เมื่อเทียบกับการทดสอบอัตโนมัติรูปแบบอื่นหรือไม่ ฉันเดาว่าการทดสอบการรวมอัตโนมัตินั้นมีประโยชน์มากกว่าการทดสอบเครื่อง จากประสบการณ์ของฉันข้อผิดพลาดส่วนใหญ่ดูเหมือนว่าจะอยู่ในการโต้ตอบระหว่างโมดูลและไม่มากตรรกะ (ปกติ จำกัด ) ของแต่ละหน่วย การถดถอยยังเกิดขึ้นบ่อยครั้งเนื่องจากการเปลี่ยนแปลงส่วนต่อประสานระหว่างโมดูล (และเปลี่ยนก่อนและหลังเงื่อนไข) ฉันเข้าใจอะไรผิดพลาดหรือทำไมการทดสอบหน่วยได้รับความสนใจมากเมื่อเทียบกับการทดสอบการรวมระบบ เป็นเพียงเพราะการสันนิษฐานว่าการทดสอบการรวมเป็นสิ่งที่คุณมีและการทดสอบหน่วยเป็นสิ่งต่อไปที่เราต้องเรียนรู้ที่จะใช้ในฐานะนักพัฒนา หรือการทดสอบหน่วยอาจให้ผลตอบแทนสูงสุดเมื่อเทียบกับความซับซ้อนของการทำให้เป็นอัตโนมัติ? คุณมีประสบการณ์อย่างไรกับการทดสอบหน่วยอัตโนมัติการทดสอบการรวมอัตโนมัติและการทดสอบการยอมรับอัตโนมัติและจากประสบการณ์ของคุณสิ่งที่ให้ผลตอบแทนการลงทุนสูงสุด และทำไม? หากคุณต้องเลือกการทดสอบเพียงรูปแบบเดียวเพื่อให้เป็นอัตโนมัติในโครงการถัดไปของคุณ ขอบคุณล่วงหน้า.

29 testing  unit-testing  automation  acceptance-testing 

ฉันมักจะได้ยินคำว่า "ต้นขั้ว", "ต้นขั้วบางอย่างออก", "ต้นขั้ว" และอื่น ๆ การขัดหมายถึงอะไรในการเขียนโปรแกรมและคำนั้นมาจากไหน สามารถใช้บริบทใดได้บ้าง

26 unit-testing  testing  integration-tests  acceptance-testing  stub 

ที่ บริษัท ของเราเรามักจะตรวจสอบให้แน่ใจว่าเราได้ทำการทดสอบแบบครบวงจรสำหรับเว็บไซต์ / แอพเว็บของเรา นั่นหมายความว่าเราเข้าถึง URL กรอกแบบฟอร์มส่งแบบฟอร์มไปยัง URL อื่นและตรวจสอบผลลัพธ์ของหน้า เราทำสิ่งนี้เพื่อทดสอบการตรวจสอบแบบฟอร์มทดสอบว่าเทมเพลต HTML มีตัวแปรบริบทที่ถูกต้อง ฯลฯ นอกจากนี้เรายังใช้มันเพื่อทดสอบตรรกะพื้นฐาน ฉันได้รับการบอกเล่าจากเพื่อนร่วมงานว่าสาเหตุของเรื่องนี้คือเราสามารถลอกออกและเปลี่ยนแปลงการใช้งานพื้นฐาน ณ จุดใดก็ได้ตราบใดที่การทดสอบแบบ end-to-end ผ่าน ฉันสงสัยว่าการแยกประเภทนี้เหมาะสมหรือไม่หรือเป็นเพียงวิธีหลีกเลี่ยงการเขียนการทดสอบสำหรับโค้ดที่เล็กลง?

23 unit-testing  tdd  acceptance-testing 

สมมติว่าเรามีแอปพลิเคชันระดับองค์กรขนาดใหญ่โดยไม่มีการทดสอบหน่วย / การทำงานใด ๆ ไม่มีกระบวนการพัฒนาที่ขับเคลื่อนด้วยการทดสอบในระหว่างการพัฒนาอันเนื่องมาจากกำหนดเวลาที่เข้มงวดมาก (ฉันรู้ว่าเราไม่ควรสัญญาวันครบกำหนดที่แน่นเมื่อเราไม่แน่ใจ แต่สิ่งที่ทำเสร็จแล้ว!) ตอนนี้ทุกอย่างผ่านไปและทุกอย่างสงบลงทุกคนตกลงที่จะเปลี่ยนเราให้เป็นทีมงานที่มีประสิทธิผลของ TDD / BDD ... ตอนนี้คำถามเกี่ยวกับรหัสที่เรามีอยู่แล้ว: (1) มันยังไม่เป็นไรหรือเป็นความคิดที่ดีที่จะหยุดการพัฒนาส่วนใหญ่และเริ่มเขียนกรณีทดสอบที่เป็นไปได้ทั้งหมดตั้งแต่เริ่มต้นถึงแม้ว่าทุกอย่างจะทำงานได้อย่างสมบูรณ์ ? หรือ (2) เป็นการดีกว่าที่จะรอสิ่งที่ไม่ดีเกิดขึ้นจากนั้นในระหว่างการแก้ไขการทดสอบหน่วยการทดสอบใหม่หรือ (3) แม้กระทั่งลืมรหัสก่อนหน้าและเพียงแค่เขียนการทดสอบหน่วยสำหรับรหัสใหม่เท่านั้นและเลื่อนทุกอย่าง มีไม่กี่ที่ดีและบทความที่เกี่ยวข้องเช่นนี้ ฉันยังไม่แน่ใจว่ามันคุ้มค่าหรือไม่ที่จะพิจารณาเรื่องนี้เพราะเรามีเวลา จำกัด และโครงการ / งานอื่น ๆ อีกมากมายกำลังรอเราอยู่ หมายเหตุ : คำถามนี้อธิบาย / จินตนาการถึงสถานการณ์ที่น่าอึดอัดใจในทีมพัฒนา นี่ไม่เกี่ยวกับฉันหรือเพื่อนร่วมงานของฉัน มันเป็นเพียงสถานการณ์ในจินตนาการ คุณอาจคิดว่าสิ่งนี้ไม่ควรเกิดขึ้นหรือผู้จัดการฝ่ายพัฒนารับผิดชอบต่อความยุ่งเหยิง! แต่อย่างไรก็ตามสิ่งที่ทำเสร็จแล้ว หากเป็นไปได้โปรดอย่าโหวตเพราะคุณคิดว่าสิ่งนี้จะไม่เกิดขึ้น

17 unit-testing  testing  tdd  bdd  acceptance-testing 

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

16 unit-testing  testing  tdd  integration-tests  acceptance-testing 

ฉันมีประสบการณ์มากกว่า 2 ปีในการพัฒนาแอพพลิเคชั่น ในสองปีที่ผ่านมาแนวทางการพัฒนาของฉันมีดังต่อไปนี้ วิเคราะห์ข้อกำหนด Identity Core องค์ประกอบ / วัตถุฟังก์ชันที่จำเป็น, พฤติกรรม, กระบวนการและข้อ จำกัด สร้างคลาสความสัมพันธ์ระหว่างพวกเขาข้อ จำกัด เกี่ยวกับพฤติกรรมของวัตถุ & รัฐ สร้างฟังก์ชั่นการประมวลผลด้วยข้อ จำกัด พฤติกรรมตามความต้องการ ทดสอบแอปพลิเคชันด้วยตนเอง หากความต้องการเปลี่ยนแปลงแก้ไของค์ประกอบ / ฟังก์ชั่นให้ทดสอบโปรแกรมด้วยตนเอง เมื่อเร็ว ๆ นี้ฉันได้รับการแนะนำให้รู้จักกับ TDD และรู้สึกว่านี่เป็นวิธีที่ดีมากในการพัฒนาเนื่องจากโค้ดที่พัฒนาแล้วมีเหตุผลที่แข็งแกร่งที่มีอยู่ แต่ปัญหาของฉันคือฉันไม่สามารถสร้างการทดสอบก่อนได้ แต่ฉันจะระบุส่วนประกอบและเพียงแค่เขียนการทดสอบสำหรับพวกเขาก่อนที่ฉันจะเขียนส่วนประกอบจริง ๆ คำถามของฉันคือ ฉันทำถูกไหม? ถ้าไม่ใช่สิ่งที่ฉันต้องเปลี่ยนแน่นอน มีวิธีใดที่คุณสามารถระบุได้ว่าแบบทดสอบที่คุณเขียนนั้นเพียงพอหรือไม่ เป็นการดีหรือไม่ที่จะทดสอบการเขียนสำหรับฟังก์ชั่นที่ง่ายมากซึ่งอาจเทียบเท่ากับ 1 + 1 = 2 หรือเป็นเพียงภาพซ้อนทับ? มันเป็นการดีที่จะเปลี่ยนฟังก์ชั่นและตามการทดสอบว่ามีการเปลี่ยนแปลงข้อกำหนด?

15 programming-practices  unit-testing  tdd  acceptance-testing 

เรากำลังรวมกระบวนการทดสอบในกระบวนการ SCRUM ของเรา บทบาทใหม่ของฉันคือการเขียนการทดสอบการยอมรับของเว็บแอปพลิเคชันของเราเพื่อทำการทดสอบในภายหลังโดยอัตโนมัติ ฉันได้อ่านมากมายเกี่ยวกับวิธีการเขียนกรณีทดสอบ แต่ไม่มีใครให้คำแนะนำเชิงปฏิบัติแก่ฉันในการเขียนกรณีทดสอบสำหรับเว็บแอปพลิเคชันที่ซับซ้อนและแทนที่จะใช้หลักการที่ขัดแย้งกันซึ่งฉันพบว่าใช้ยาก: กรณีทดสอบควรสั้น:นำตัวอย่างของ CMS กรณีทดสอบสั้น ๆ นั้นง่ายต่อการบำรุงรักษาและเพื่อระบุอินพุตและเอาต์พุต แต่ถ้าฉันต้องการทดสอบชุดการทำงานที่ยาวนาน (เช่นการเพิ่มเอกสารการส่งการแจ้งเตือนไปยังผู้ใช้รายอื่นผู้ใช้รายอื่นตอบกลับเอกสารการเปลี่ยนแปลงสถานะผู้ใช้จะได้รับการแจ้งเตือน) สำหรับฉันแล้วดูเหมือนว่ากรณีทดสอบควรแสดงถึงสถานการณ์ที่สมบูรณ์ แต่ฉันสามารถดูว่าสิ่งนี้จะผลิตเอกสารทดสอบที่ซับซ้อนมากเกินไป การทดสอบควรระบุอินพุตและเอาต์พุต::จะเป็นอย่างไรถ้าฉันมีรูปแบบยาวที่มีฟิลด์โต้ตอบจำนวนมากที่มีพฤติกรรมแตกต่างกัน ฉันจะเขียนหนึ่งการทดสอบสำหรับทุกสิ่งหรือไม่หรือสำหรับแต่ละการทดสอบ? กรณีทดสอบควรมีความเป็นอิสระ:แต่ฉันจะใช้สิ่งนั้นได้อย่างไรหากการทดสอบการดำเนินการอัปโหลดต้องการให้การเชื่อมต่อสำเร็จ และใช้กับการเขียนกรณีทดสอบได้อย่างไร ฉันควรจะเขียนการทดสอบสำหรับแต่ละการดำเนินการ แต่การทดสอบแต่ละครั้งจะประกาศการขึ้นต่อกันหรือฉันควรจะเขียนสถานการณ์ทั้งหมดสำหรับการทดสอบแต่ละครั้งอีกครั้ง? กรณีทดสอบควรจัดทำเป็นเอกสารเล็กน้อย:หลักการนี้เฉพาะกับโครงการ Agile ดังนั้นคุณมีคำแนะนำเกี่ยวกับวิธีการใช้หลักการนี้หรือไม่? แม้ว่าฉันคิดว่าการเขียนแบบทดสอบตอบรับจะเป็นเรื่องง่าย แต่ฉันก็พบว่าตัวเองตัดสินใจทุกอย่างที่ต้องทำ (FYI: ฉันเป็นนักพัฒนาและไม่ใช่ผู้ทดสอบมืออาชีพ) ดังนั้นคำถามหลักของฉันคือ: คุณมีขั้นตอนหรือคำแนะนำอะไรบ้างในการเขียนเคสทดสอบการยอมรับที่ยอมรับได้สำหรับการใช้งานที่ซับซ้อน ขอขอบคุณ. แก้ไข : เพื่อชี้แจงคำถามของฉัน: ฉันทราบว่าการทดสอบการยอมรับควรเริ่มจากข้อกำหนดและพิจารณาว่าแอปพลิเคชันทั้งหมดเป็นกล่องดำ คำถามของฉันเกี่ยวข้องกับขั้นตอนการปฏิบัติในการเขียนเอกสารทดสอบระบุกรณีทดสอบจัดการกับการอ้างอิงระหว่างการทดสอบ ... สำหรับเว็บแอปพลิเคชันที่ซับซ้อน

14 testing  documentation  acceptance-testing 

(ฉันคิดว่านี่จะเป็นคำถามสัมภาษณ์ที่ดีแต่ในกรณีของฉันมันเป็นประโยชน์มากกว่านั้น) เรามีแอปพลิเคชั่นขนาดใหญ่และซับซ้อนที่จำลองกระบวนการปฏิกิริยาเคมีที่ยาวและซับซ้อนระหว่างส่วนประกอบทางเคมีหลายสิบชนิด เราอยู่ในขั้นตอนของการออกแบบการทดสอบการยอมรับสำหรับแอปพลิเคชัน แต่เราค่อนข้างหวาดกลัวด้วยจำนวนเส้นทางที่เป็นไปได้ในการทดสอบ มันเกิดขึ้นกับฉันว่าสถานการณ์ของเราเป็นเหมือนสิ่งที่ทีมงาน Google แผนที่ต้องเผชิญเมื่อถึงเวลาต้องทดสอบอัลกอริทึมการวางแผนเส้นทางในคุณลักษณะ "ขอเส้นทาง" เห็นได้ชัดว่าพวกเขาไม่สามารถทดสอบ (ตรวจสอบและตรวจสอบ) ทุกเส้นทางที่เป็นไปได้ ดังนั้นพวกเขาจึงมั่นใจได้อย่างไรว่าแอปพลิเคชันของพวกเขาจะทำงานได้ในทุกสถานการณ์ และเนื่องจากฉันไม่ได้คาดหวังว่าพวกเขาจะทำมันได้อย่างไรให้ฉันถามคุณ: คุณจะออกแบบชุดทดสอบที่มีรหัสครอบคลุมเพียงพอได้อย่างไร สำรวจทุกเส้นทางที่อาจเกิดขึ้นผ่านระบบ สิ่งที่ฉันกำลังมองหาคือหลักการที่คุณจะใช้ในการแยกแยะปัญหาที่ยากจะแยกออกเป็นชิ้นเล็ก ๆ ซึ่งหยั่งรู้ได้ผลรวมของการประเมินทั้งหมดเป็นที่น่าพอใจ: "ฉันไม่สามารถทดสอบทุกอย่างได้ แต่ฉันสามารถทดสอบสิ่งนี้ได้ นี่และนี่ - และก็เพียงพอแล้ว " ฉันไม่ได้มองหาวิธีการที่ "ถูกต้อง" แต่เป็นวิธีที่รอบคอบให้ข้อ จำกัด ด้านงบประมาณ / เวลาในโลกแห่งความเป็นจริง (ฉันใช้ตัวอย่าง Google maps เป็นฟอยล์เพื่อขอคำตอบเฉพาะเจาะจงที่สุดเท่าที่จะทำได้)

13 acceptance-testing  test-coverage 

หากดำเนินโครงการโดยใช้ BDD ที่มีเนื้อหาครอบคลุม 100% ของเรื่องราวของผู้ใช้ด้วยการทดสอบการยอมรับอัตโนมัติสิ่งที่จะเป็นบทบาทของผู้ทดสอบ / ประกันคุณภาพ ฉันเดาว่าฉันจะจินตนาการว่านักพัฒนาจะเขียนการทดสอบการยอมรับร่วมกับเจ้าของผลิตภัณฑ์แจ้งให้เราทราบหากนั่นดูเหมือนว่าเป็นข้อสมมุติที่โง่เขลา

13 testing  team  qa  bdd  acceptance-testing 

ฉันทำงานกับระบบธุรกรรมทางการเงินขนาดใหญ่สำหรับธนาคารที่ดูแลเงินบำนาญและการลงทุน หลังจากการเปลี่ยนแปลงคุณสมบัติ 15 ปีค่าใช้จ่ายในการทดสอบการถดถอยแบบแมนนวลก็เพิ่มขึ้นเป็น $ 200K ต่อการเปิดตัว (10M LOC ทำธุรกรรม $ 10M ต่อวัน) ระบบนี้ยังเชื่อมต่อกับ 19 ระบบอื่น ๆ ทั่ว บริษัท ที่ย้ายข้อมูลจำนวนมาก ระบบนี้ถูกนำไปใช้ใน Java อย่างไรก็ตามสิ่งที่เราสังเกตคือยิ่งเราใช้ค่าใช้จ่ายในการทดสอบการถดถอยมากขึ้น (เหตุผลที่คุณต้อง "ทดสอบรหัสที่คุณแตะ" - และรหัสที่ใช้ซ้ำ / แชร์จะส่งผลกระทบต่อสถานที่หลายแห่งเมื่อมีการแตะต้องดังนั้นแม้จะมี 'DRY - อย่าทำซ้ำตัวเอง' - นั่นคืออย่าคัดลอกและวางรหัส - เราสังเกตสิ่งจูงใจทางการเงินเพื่อคัดลอกและวางรหัสนี่คือการลดค่าใช้จ่ายในการทดสอบการถดถอยเนื่องจากเราไม่ต้องการแก้ไขรหัสที่สามารถแชร์ได้เพราะจะทำให้เกิดผลกระทบการทดสอบการถดถอยครั้งใหญ่) คำถามของฉันคือมีหลักการวิศวกรรมซอฟต์แวร์ที่อธิบายความสัมพันธ์ระหว่างต้นทุนการทดสอบซ้ำและการถดถอยซ้ำหรือไม่ เหตุผลที่ฉันถามคำถามนี้คือเนื้อหามีประโยชน์ต้นทุนในการย่อยสลายระบบเป็นส่วนเล็ก ๆ ที่จะทดสอบ สมมติฐาน: 'การทดสอบการถดถอย' หมายถึง 'การทดสอบการยอมรับ' - นั่นคืออีกกลุ่มใช้เวลาในการเขียนการทดสอบแบบเก่าและนำมาใช้ซ้ำกับระบบในนามของธุรกิจรวมถึงการตั้งค่าสภาพแวดล้อมและข้อมูล ฉันรู้ว่าปฏิกิริยาการกระตุกเข่าต่อค่าใช้จ่ายในการทดสอบการถดถอยครั้งใหญ่คือ 'การทดสอบอัตโนมัติมากขึ้น' นี่เป็นหลักการที่ดี ในสภาพแวดล้อมนี้มีความท้าทายสองประการ …

12 code-reuse  acceptance-testing  estimation 

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

11 testing  game-development  acceptance-testing 

ที่ทำงานเรามีระบบที่ค่อนข้างซับซ้อน เรียกระบบนี้ว่า System_A ทีมงาน QA ของเราได้สร้างระบบอื่นเรียกระบบนี้ว่า System_B เพื่อทดสอบ System_A วิธีที่ใช้ System_B มีดังนี้ เราสร้างอินพุต (โดยใช้ System_B เอง), IN, ประมวลผลอินพุตดังกล่าวกลับผ่าน System_B และสร้างเอาต์พุต O_B ดังนั้นกระบวนการดังต่อไปนี้: System_B(IN) -> O_B. จากนั้นเราก็ทำเช่นเดียวกันสำหรับ System_A เพื่อสร้างผลลัพธ์ของตัวเอง O_A: System_A(IN) -> O_A. เมื่อใดก็ตามจะถือว่า O_B เป็นเอาต์พุตที่คาดหวังและ O_A เป็นเอาต์พุตที่ตรวจพบ / เกิดขึ้นจริง โดยนัยก็คือ O_B เป็นแหล่ง "ทองคำ" (ความจริง) อย่างไรก็ตามเราพบปัญหาหลายอย่าง O_A ผิด O_B ถูกต้อง O_A …

10 unit-testing  testing  qa  acceptance-testing  integration-testing 

ฉันกำลังทดสอบ api REST สมมติว่ามันส่งคืนโครงสร้าง JSON วิธีทดสอบเซิร์ฟเวอร์ที่ดีที่สุดคืออะไร? แต่ละขั้นตอนการทดสอบจะประสบความสำเร็จก็ต่อเมื่อก่อนหน้านี้ทั้งหมดประสบความสำเร็จ โครงสร้าง A: ทดสอบทุกอย่างในครั้งเดียว - Test method 1: - make server request - assert http response code was 200 - assert returned file is not empty - assert returned file has valid JSON syntax - assert returned JSON contains key X นี่น่าจะเป็นทางออกที่ดีที่สุด ข้อดี: คำขอเซิร์ฟเวอร์เดียวเท่านั้น …

10 testing  acceptance-testing 

เมื่อไม่นานมานี้เราได้รับมอบหมายให้โครงการเข้ามาแทนที่ระบบเมนเฟรมเก่าของลูกค้าด้วยโซลูชัน ASP.NET อินทราเน็ตใหม่โดยใช้ SQL Server เป็นส่วนหลัง ส่วนหนึ่งของสิ่งนี้คือการปรับโครงสร้างของธุรกิจเช่นกัน - โดยพื้นฐานแล้วเมื่อเราเปลี่ยนระบบเราต้องคิดว่าเราจะทำธุรกิจได้ดีขึ้นอย่างไร ดังนั้นงานแรกคือการเข้ามาและทำแบบจำลองทางตรรกะและข้อมูลทางกายภาพ ลูกค้าอยู่ใน dicussions เหล่านี้และได้ลงชื่อออกอย่างสมบูรณ์ ขั้นตอนต่อไปคือการออกแบบและสร้างของแต่ละโมดูล เพื่อให้เนื้อเรื่องสั้นสั้นการเขียนโปรแกรมก็เสร็จสิ้นและตอนนี้เรากำลังทำการทดสอบระบบแบบขนาน สิ่งที่กำลังจะยอดเยี่ยมสำหรับส่วนใหญ่ของโมดูลจนถึง - ยกเว้นหนึ่ง เรามีระบบเดียวที่ - หากคุณต้องการให้ผู้ใช้ทางธุรกิจเห็นแอปพลิเคชันและรายงานทั้งหมดจะดี ทำงานร่วมกับเวิร์กโฟลว์แบบรวมใหม่และดำเนินกระบวนการแบบแมนนวลโดยอัตโนมัติก่อนหน้านี้และทำงานได้อย่างยอดเยี่ยมตามข้อกำหนด การทดสอบแบบขนานได้เปิดเผยปัญหาบางอย่างด้วยข้อมูลการย้ายข้อมูลแบบเดิม ผู้สร้างระบบเดิมกำลังทำความเข้าใจกับ schema และกระบวนการทางธุรกิจใหม่อย่างหนักดังนั้นพวกเขาจึงมีเวลาที่ยากลำบากมากในการทำความเข้าใจวิธีการใช้ข้อมูลดั้งเดิมและนำมาไว้ในสคีมาใหม่ ด้วยเหตุนี้พวกเขาจึงเรียกประชุมผู้ใช้ทางธุรกิจและผู้มีส่วนได้ส่วนเสียและบอกพวกเขาว่าระบบใหม่ไม่ได้ให้ข้อมูลที่ระบบเก่าทำ (เมื่อเป็นจริง) - ทำให้ระบบใหม่ดูไม่ดี นี่มันน่าหงุดหงิดที่จะพูดน้อยที่สุด ระบบใหม่ใช้งานได้ดีและให้ทุกสิ่งที่พวกเขาต้องการและต้องการและหากไม่ใช่เพราะเจ้าหน้าที่ไอทีไม่สามารถกรอกข้อมูลลงในตารางใหม่ด้วยข้อมูลเก่าผู้ใช้ทางธุรกิจจะพึงพอใจกับคุณสมบัติและฟังก์ชั่นใหม่ ฉันขอคำแนะนำเกี่ยวกับวิธีจัดการกับสิ่งนี้ เนื่องจากการเคลื่อนไหวทางการเมืองบางอย่าง "สถาปนิก" ใหม่จึงไม่ทราบว่าระบบทำงานอย่างไรและไม่สามารถเข้าใจถึงการเปลี่ยนแปลงที่เจ้าหน้าที่ไอทีร้องขอได้อย่างเต็มที่ เจ้าหน้าที่ไอทีต้องการเปลี่ยนแปลงระบบพื้นฐานซึ่งไม่จำเป็นโดยพื้นฐานและเป็นการออกแบบที่ไม่ดี แต่เป็นลูกค้า ความคิดใด ๆ

10 design  customer-relations  acceptance-testing 

ฉันอยู่ในทีมพัฒนาภายใน บริษัท ของฉันและเราพัฒนาเว็บไซต์ของ บริษัท ตามความต้องการของทีมการตลาด ก่อนที่จะปล่อยไซต์ให้พวกเขาสำหรับการทดสอบการยอมรับเราถูกขอให้พวกเขามีแผนการทดสอบเพื่อติดตาม อย่างไรก็ตามทีมพัฒนารู้สึกว่าเนื่องจากข้อกำหนดมาจากผู้ร้องขอพวกเขาจะมีความรู้ที่ดีที่สุดในการทดสอบสิ่งที่ต้องระวังสิ่งที่ควรปฏิบัติและอื่น ๆ และไม่จำเป็นต้องมีแผนการทดสอบ เรามักจะโต้แย้งเรื่องนี้อยู่เสมอและนักพัฒนาพบว่ามันใช้เวลาไม่นานในการจดบันทึกสิ่งต่าง ๆ เช่น: - คลิกที่ปุ่ม ที่สำคัญในXYZในฟิลด์รูปแบบและคลิกปุ่มB คุณควรจะเห็นพฤติกรรมC ซึ่งเราต้องทำซ้ำสำหรับแต่ละความต้องการ / คุณสมบัติที่ร้องขอ นี่คือการเรียบเรียงสิ่งที่มีอยู่แล้วในเอกสารข้อกำหนดอีกครั้ง เรากำลังเคลื่อนไปสู่การใช้วิธี Agile สำหรับการจัดการโครงการของเราและสิ่งนี้จะถูกร้องขอเมื่อสิ้นสุดการทำซ้ำแต่ละครั้ง การทดสอบหน่วยและการรวมเข้าด้วยกันใครควรเป็นผู้วางแผนการยอมรับของผู้ใช้ปลายทาง มันควรจะเป็นผู้ทดสอบหรือนักพัฒนาหรือไม่? ขอบคุณมากล่วงหน้า ขอแสดงความนับถือ CK

10 web-development  testing  websites  acceptance-testing