ใครควรเขียนแผนทดสอบ


10

ฉันอยู่ในทีมพัฒนาภายใน บริษัท ของฉันและเราพัฒนาเว็บไซต์ของ บริษัท ตามความต้องการของทีมการตลาด ก่อนที่จะปล่อยไซต์ให้พวกเขาสำหรับการทดสอบการยอมรับเราถูกขอให้พวกเขามีแผนการทดสอบเพื่อติดตาม

อย่างไรก็ตามทีมพัฒนารู้สึกว่าเนื่องจากข้อกำหนดมาจากผู้ร้องขอพวกเขาจะมีความรู้ที่ดีที่สุดในการทดสอบสิ่งที่ต้องระวังสิ่งที่ควรปฏิบัติและอื่น ๆ และไม่จำเป็นต้องมีแผนการทดสอบ เรามักจะโต้แย้งเรื่องนี้อยู่เสมอและนักพัฒนาพบว่ามันใช้เวลาไม่นานในการจดบันทึกสิ่งต่าง ๆ เช่น: -

  1. คลิกที่ปุ่ม
  2. ที่สำคัญในXYZในฟิลด์รูปแบบและคลิกปุ่มB
  3. คุณควรจะเห็นพฤติกรรมC

ซึ่งเราต้องทำซ้ำสำหรับแต่ละความต้องการ / คุณสมบัติที่ร้องขอ นี่คือการเรียบเรียงสิ่งที่มีอยู่แล้วในเอกสารข้อกำหนดอีกครั้ง

เรากำลังเคลื่อนไปสู่การใช้วิธี Agile สำหรับการจัดการโครงการของเราและสิ่งนี้จะถูกร้องขอเมื่อสิ้นสุดการทำซ้ำแต่ละครั้ง

การทดสอบหน่วยและการรวมเข้าด้วยกันใครควรเป็นผู้วางแผนการยอมรับของผู้ใช้ปลายทาง มันควรจะเป็นผู้ทดสอบหรือนักพัฒนาหรือไม่?

ขอบคุณมากล่วงหน้า

ขอแสดงความนับถือ
CK


1
สิ่งเดียวที่ควรป้อนเข้าสู่ devs นี้คือการแนะนำพื้นที่และอาจเป็นไปได้ว่ามีบางกรณีที่ควรทดสอบ (และไม่ลืม) แต่พวกเขาไม่ควรให้รายละเอียดทีละขั้นตอนเกี่ยวกับวิธีการทดสอบ
CaffGeek

คำตอบ:


10

นักพัฒนาไม่ควรเขียนแผนการทดสอบ ส่วนหนึ่งของแผนการทดสอบที่ต้องทำคือการตรวจสอบว่าผู้พัฒนาตีความความต้องการได้อย่างถูกต้องหรือไม่ ผู้พัฒนาไม่สามารถเขียนแผนการทดสอบบนโค้ดที่เขากำลังจะเขียนได้อย่างมีประสิทธิภาพ แผนการทดสอบควรเขียนโดยคนที่กำลังจะทำ QA หรือโดยนักวิเคราะห์ธุรกิจ หากนักพัฒนาต้องเขียนแผนไม่เคยมอบหมายให้ใครคนหนึ่งเขียนแผนสำหรับส่วนของโปรแกรมที่เขากำลังจะเขียน

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


นี่คือสิ่งที่ฉันพูดมาหลายปีในงานเดียว
David Thornley

1
ทำได้ดีจนถึงประโยคสุดท้าย แต่การทดสอบไม่ควรยึดติดกับการตรวจสอบแอปพลิเคชันเท่านั้นตามความคาดหวัง (แต่ควรครอบคลุมถึงสิ่งที่คาดไม่ถึง!) และการรู้อย่างน้อยนิดหน่อยเกี่ยวกับวิธีการออกแบบแอปพลิเคชันทางเทคนิคเสมอ รอยแตกที่ฉันสามารถนำชะแลงทดสอบของฉันลงไปเพื่อเปิดสิ่งที่เปิดกว้าง ;) มันเป็นความคิดที่ล้าสมัยเล็กน้อยที่จะจินตนาการว่าผู้ทดสอบดีกว่าที่ไม่รู้จักอะไรเกี่ยวกับการใช้งาน
testerab

1
ตรง @testerab การไม่ทราบว่า internals ช่วยออกแบบกรณีทดสอบบางประเภทในขณะที่การทราบความช่วยเหลือภายในในการทดสอบกล่องสีเทาเช่นฉันรู้ว่าพื้นที่เสี่ยงในรหัสฉันแค่ต้องพิสูจน์ให้แอปเข้าถึงรหัสนั้น
dzieciou

7

ทีม QA ควรเขียนและดำเนินการตามแผนทดสอบ

โดยหลักการแล้วควรมีการเขียนแผนการทดสอบควบคู่ไปกับข้อมูลจำเพาะของฟังก์ชั่นการใช้งาน - มันน่าทึ่งที่การคิดเกี่ยวกับการทดสอบการทำงานมุ่งเน้นที่จิตใจและปรับปรุงสเปค


3
อาจเป็นไปได้ด้วยความช่วยเหลือจากนักพัฒนา แต่ส่วนใหญ่เป็นทีมงาน QA
Zachary K

ถ้าเราไม่มีทีม QA ล่ะ งานนี้ควรตกอยู่กับผู้ร้องขอหรือไม่ จากคำตอบที่นี่สิ่งนี้จะสมเหตุสมผลที่สุด
ckng

หากคุณกำลังมุ่งสู่ Agile ให้ลองจ้างคนที่มีความเชี่ยวชาญในการทดสอบกับทีมพัฒนาปัจจุบันของคุณ (หมายเหตุ: อ่านข้อมูลเกี่ยวกับโรงเรียนที่ทดสอบก่อนอื่น ๆ บางโรงเรียนเข้ากันไม่ได้กับวิธี Agile - redcanary.mypublicsquare.com/view/hiring-software )
testerab

2
หากคุณไม่มีทีมงาน QA คุณจะต้องมาพร้อมกับผู้ร้องขอเพื่อทำการตัดสินใจ ในอีกด้านหนึ่งผู้พัฒนาไม่จำเป็นต้องทำแผนการทดสอบ ในทางกลับกันลูกค้าส่วนใหญ่ / ธุรกิจส่วนใหญ่ไม่รู้เกี่ยวกับการทดสอบและคุณจะใช้เวลาฝึกอบรมและการถือครองเป็นจำนวนมากในการเริ่มต้น เราลองครั้งนี้แล้วลูกค้าธุรกิจก็ต้องดิ้นรนครั้งใหญ่ กรณีปกติไม่ใช่เรื่องใหญ่ แต่เมื่อพูดถึงรายละเอียดและโดยเฉพาะกรณีทดสอบเชิงลบพวกเขาต้องดิ้นรน ดีกว่าที่จะได้รับ / การกำหนด QA คนหรือนักวิเคราะห์ธุรกิจกว่าที่จะมอบหมายให้กับลูกค้า
sdek

4

คำตอบที่แยบยล: หากคุณต้องการกำหนด 'คำจำกัดความของเสร็จสิ้น' คุณจะสังเกตเห็นว่าการมีแผนการทดสอบอย่างรวดเร็วกลายเป็นหนึ่งในรายการ คุณสามารถอธิบายเรื่องราวที่ต้องทำอย่างไรหากยังไม่ได้ทดสอบ

ใครเป็นผู้รับผิดชอบในการสร้างแผนการทดสอบ ทีมงาน

ทีมคือใคร บุคคลใดที่มุ่งมั่นที่จะตระหนักถึงผลิตภัณฑ์ควรเป็นสมาชิกของทีม

ดังนั้นในกรณีของคุณคุณสามารถรวม (หรือจ้าง) บุคคลที่สามารถเขียนแผนการทดสอบลงใน 'ทีมพัฒนา' ของคุณ หากคุณกำลังย้ายไปที่ Agile คุณจะสังเกตเห็นว่าการสร้างแผนการทดสอบเกิดขึ้นในแบบขนานของการพัฒนา ทั้งคู่เริ่มจากเรื่องเดียวกันและจากการสื่อสารจบลงด้วยการซิงค์และส่งมอบในเวลาเดียวกัน คุณไม่ควรประกาศเรื่องราวของคุณ 'เสร็จสิ้น' ก่อนที่จะผ่านกรณีทดสอบที่ผู้มีส่วนได้เสียเห็นว่าสำคัญ


2

ฉันพบว่าแผนทดสอบการใช้งานควรถูกเขียนขึ้นโดยนักวิเคราะห์การทำงาน / ธุรกิจ พวกเขาเขียนการวิเคราะห์การทำงาน (แม้ว่าคุณจะทำงานคล่องแคล่วฉันถือว่าคุณมีการวิเคราะห์บางอย่าง) และดังนั้นพวกเขาควรจะเขียนว่าเส้นทางใดในแอปพลิเคชันที่ควรปฏิบัติตามเพื่อการทดสอบ

มันขึ้นอยู่กับว่าคุณทำงานอย่างไร แต่ในความเห็นของฉันนักพัฒนาไม่ควรเขียนเอกสารที่ใช้งานได้เกี่ยวกับวิธีการทดสอบแอปพลิเคชันข้อมูลใดที่จะใช้ในการทดสอบ ฯลฯ


2

นี่เป็นความคิดที่อาจทำให้ทั้งสองกลุ่มมีความสุขและสอดคล้องกับแนวทาง Agile

ทำการตรวจสอบการยอมรับของผู้ใช้โดยอัตโนมัติ

http://pragprog.com/magazines/2009-12/automating-screencasts

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

นอกจากนี้ยังมีวิธีการดำเนินการตามข้อกำหนดจริง ๆ - คุณเคยเจอข้อมูลจำเพาะที่ปฏิบัติได้ของ Gojko Adzic หรือไม่? ลองดูที่นี่: http://gojko.net/2010/08/04/lets-change-the-tune/ หากคุณคิดว่านี่เป็นวิธีในการรับข้อกำหนดในรูปแบบปฏิบัติการเพื่อสาธิตให้กับลูกค้าของคุณ จากนั้นดูเหมือนว่าจะไร้ประโยชน์น้อยกว่ามาก

ตอนนี้การใส่หมวกผู้ทดสอบของฉันฉันรู้สึกเป็นเกียรติที่จะชี้ให้เห็นว่าหากสิ่งที่ screencast จะปิดมันจะฟรีคุณ / ผู้มีส่วนได้เสียของคุณเพื่อทำการทดสอบที่เหมาะสม - เช่นพยายามกรณีขอบและการทดสอบที่ท้าทายแอปจริง ไม่ใช่เพียงแค่ยืนยันข้อกำหนด ฉันขอแนะนำให้คุณให้หน้าจอ screencasts พร้อมกับคำถามสั้น ๆ หรือข้อเสนอแนะสำหรับพื้นที่ที่คุณต้องการความคิดเห็นเพิ่มเติมเกี่ยวกับ:

1) นี่คือแบบฟอร์มการลงทะเบียนใหม่ของเรา - ดู screencast นี้เพื่อดูว่ามันทำงานอย่างไร!

สิ่งที่เราต้องการความคิดเห็นเกี่ยวกับ: เราได้เพิ่มการตรวจสอบเพิ่มเติมจำนวนมากในแบบฟอร์มนี้เพื่อให้แน่ใจว่าลูกค้าไม่สามารถป้อนข้อมูลที่ไม่ถูกต้อง - เราอยากให้คุณดูข้อความแสดงข้อผิดพลาดที่ลูกค้าได้รับเมื่อพวกเขา ใส่สิ่งที่ผิดและบอกเราว่าลูกค้าของเราจะเข้าใจง่ายหรือไม่
นอกจากนี้เราต้องการทราบด้วยว่าเราเข้มงวดเกินไปในบางกรณี - หากคุณมีข้อมูลลูกค้าที่ผิดปกติเป็นพิเศษ (อาจเป็นชื่อที่ยาวมากหรือชื่อที่สั้นมากหรือคนที่มีตัวอักษรผิดปกติในชื่อของพวกเขา หรืออย่างอื่นที่เราไม่เคยนึกถึงหรือที่อยู่ของพวกเขาอาจไม่มีชื่อถนนหรืออะไรแปลก ๆ แบบนั้น?) บางทีคุณอาจลองสักสองสามนาที?

คือคุณนำเสนอหน้าจอที่ดีและจากนั้นขอความคิดเห็นสร้างกรอบโดยไม่เจาะจงเกินไปให้พวกเขาคิดเกี่ยวกับปัญหาที่อาจเกิดขึ้นแทนที่จะแค่ยืนยัน ทำให้พวกเขาคิดแทนที่จะคลิกสุ่มสี่สุ่มห้าผ่านแผนการทดสอบ โดยทั่วไปคุณเขียนกฎบัตรทดสอบสำรวจสำหรับพวกเขา (ถ้าคุณดูQuadrant การทดสอบแบบ Agileจะเป็นการทดสอบใน Quadrant 3)


คำตอบที่ยอดเยี่ยมวิธีที่ยอดเยี่ยมในการขจัดความน่าเบื่อหน่ายที่น่าเบื่อในขณะที่รับฟังความคิดเห็นจากลูกค้า และการเชื่อมโยงที่ยอดเยี่ยม
Ethel Evans

1

ยกตัวอย่างการตกแต่งบ้านของคุณ คุณจะยอมรับรายการตรวจสอบที่ทำโดยผู้รับเหมาของคุณขอให้คุณตรวจสอบสิ่งที่เขาทำเพื่อคุณหรือไม่ หรือคุณจะมาพร้อมกับรายการตรวจสอบของคุณเองและตรวจสอบว่าผู้รับเหมาทำในสิ่งที่คุณระบุไว้หรือไม่?

คำตอบนั้นชัดเจน: ผู้ร้องขอควรตรวจสอบเพื่อดูว่าสิ่งที่เขา / เธอร้องขอนั้นทำไปตามข้อกำหนดหรือไม่ เขา / เธอควรออกมาพร้อมกับรายการตรวจสอบของตนเองและทดสอบแอพ กับรายการนี้

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


1

แผนการทดสอบการยอมรับของผู้ใช้ปลายทางมักจะเขียนโดยลูกค้าหรือผู้ร่วมธุรกิจที่ บริษัท ที่เป็นตัวแทนลูกค้า มันควรจะเป็นตัวแทนของคุณสมบัติที่ลูกค้าต้องการและเสริมการทดสอบการรวมของ QA ทั้ง QA และการพัฒนาไม่สามารถวางแผนการทดสอบการยอมรับของผู้ใช้ได้อย่างมีประสิทธิภาพเนื่องจากหนึ่งในเป้าหมายหลักของการทดสอบการยอมรับของผู้ใช้คือเพื่อให้แน่ใจว่าสิ่งที่ QA และการพัฒนาคิดว่าลูกค้าต้องการอย่างแท้จริง


en.wikipedia.org/wiki/…สำหรับข้อมูลเพิ่มเติม
Ethel Evans

+1 สำหรับการชี้ให้เห็นว่าการทดสอบการยอมรับของผู้ใช้จะต้องได้รับการออกแบบโดยผู้ใช้ แม้ว่าฉันจะแนะนำวิธีการอื่นในคำตอบของฉัน (ดูเหมือนจะไม่มีทรัพยากร QA) แต่การทดสอบการยอมรับของผู้ใช้ไม่สามารถทำได้อย่างมีประสิทธิภาพโดยผู้ใช้ที่ไม่ใช่ผู้ใช้ ในสถานการณ์เช่นนี้ดูเหมือนว่าทั้งผู้พัฒนาและผู้ใช้อยู่ในสภาพอับจนดังนั้นฉันคิดว่าผู้พัฒนาต้องพยายามทำลายมันอย่างใด
testerab
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.