ผู้ทดสอบควรทำงานอัตโนมัติหรือไม่

9

เรากำลังพยายามตั้งค่ากระบวนการทดสอบของเรา เราสงสัยว่าผู้ทดสอบของเราควรพัฒนาแบบทดสอบการถดถอยอัตโนมัติหรือหากนักพัฒนาควรทำเช่นนั้น

แล้วการทดสอบอัตโนมัติประเภทอื่น ๆ ล่ะ? ผู้ทดสอบควรพัฒนามันหรือไม่?

testing automation

— Jader Dias
แหล่งที่มา

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

— Edward Strange

@Crazy แต่ไม่แพงกว่าที่จะมี 2 ทีมพัฒนาหรือไม่

— Jader Dias

5

มีราคาแพงกว่าอะไร ขายผลิตภัณฑ์ที่ผ่านการทดสอบต่ำหรือไม่? คอขวดกระบวนการพัฒนาเพราะนักพัฒนากำลังเขียนทดสอบแทนที่จะเป็นผลิตภัณฑ์?

— Edward Strange

12

ฉันบอกว่าผู้ทดสอบควรพัฒนาการทดสอบอัตโนมัติ - พวกเขามีวิธี "นอกตาคู่" ของรหัสและจะ (หรือที่ควรจะเป็นเพียงแค่ 'อาจ'?) จุดบกพร่องที่คุณไม่ได้คิดให้จัดการคนเดียว .

บวกกับความเข้าใจในความต้องการของฟังก์ชั่นอาจสูงกว่าความเข้าใจของนักพัฒนาดังนั้นนั่งอยู่ระหว่างความรู้ระดับต่ำของฮาร์ดคอร์ของโปรแกรมเมอร์ แต่ไม่สูงกว่าปริญญาตรี

— เจมส์เลิฟ
แหล่งที่มา

แต่พวกเขาไม่สามารถขอให้ผู้พัฒนาเขียนกรณีทดสอบได้หรือไม่

— Jader Dias

1

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

— James Love

ฉันไม่เห็นว่าการใช้งานกรณีทดสอบอาจแตกต่างจากบุคคลหนึ่งไปอีกคนหนึ่งได้อย่างไร

— Jader Dias

5

@Jader คุณต้องการให้คนอื่นเขียนการทดสอบอัตโนมัติมากกว่าที่เขียนรหัสต้นฉบับ มิฉะนั้นการทดสอบจะมีอคติในการทำงานกับรหัสตามที่เขียนไว้

— Marcie

3

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

— Ethel Evans

11

หากคุณสามารถทำให้เป็นอัตโนมัติให้เป็นไปโดยอัตโนมัติ

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

— CaffGeek
แหล่งที่มา

แต่ทำไมพวกเขาควรและไม่เพียง แต่นักพัฒนา?

— Jader Dias

@JaderDias ดังที่ได้กล่าวมาผู้ทดสอบไม่ควรมีอคติใด ๆ เกี่ยวกับรหัสที่พวกเขาพยายามจะทดสอบ

— CaffGeek

3

ในความเห็นของฉันผู้พัฒนาและผู้ทดสอบมีหน้าที่รับผิดชอบในการทดสอบประเภทต่างๆ

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

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

เนื่องจาก devs นั้นมักแนบกับรหัสมากเกินไปผู้ทดสอบควรจะสามารถช่วยล้างการทดสอบของ dev แต่ไม่ใช่ในทางกลับกัน

— ราคาเทย์เลอร์
แหล่งที่มา

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

— นางสาว Cellanie

1

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

— ราคาเทย์เลอร์

2

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

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

แก้ไขเพื่อเพิ่ม: ฉันเป็น SDET ที่มีประสบการณ์ 5 ปี ฉันทำงานกับผู้พัฒนาที่ดีที่มีประสบการณ์มากกว่า 10 ปีในแต่ละครั้งและเมื่อเร็ว ๆ นี้ได้ทำงานกับพวกเขาเพื่อให้ผ่านคอขวดทดสอบ

— Ethel Evans
แหล่งที่มา

0

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

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

— glenatron
แหล่งที่มา

Visual Studio 2010 (Premium หรือ Ultimate จำไม่ได้) มีบางอย่างที่บันทึกการทำงานของหน้าจอเพื่อทำการทดสอบ UI โดยอัตโนมัติ ฉันเห็นตัวอย่างนี้โดย Andrew Woodward MVP เมื่อทำการแสดง UI Testing SharePoint สิ่งที่เหลือเชื่อ

— James Love

บันทึกและเล่นอย่างถูกต้องมีชื่อเสียงไม่ดี มันค่อนข้างบอบบางและยากที่จะรักษา ใช่เร็ว & สกปรก "ฉันต้องเรียกใช้งานนี้ในศูนย์ข้อมูลที่แตกต่างกัน 4 แห่งฉันไม่ต้องการเก็บไว้ใช้ในอนาคต" มันใช้ได้ แต่ก็แย่มากที่ต้องรักษาเพราะคุณต้องทำซ้ำหลายครั้ง การเปลี่ยนแปลงองค์ประกอบขนาดเล็กเพียงครั้งเดียว - ในทันใดคุณต้องอัปเดตการทดสอบ 100 ครั้ง เจ็บปวด. มันไม่มีทางแทนที่การทดสอบด้วยตนเองซึ่งมีแนวโน้มที่จะได้รับการออกแบบโดยมีสมมติฐานว่ามนุษย์จะสังเกตเห็นสิ่งอื่น ๆ ทั้งหมดที่คุณไม่ได้ตรวจสอบอย่างชัดเจน

— testerab

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

— glenatron

การระบุปุ่มด้วย ID แทนที่จะเป็นตำแหน่งเป็นไปได้อย่างสมบูรณ์แบบด้วยเครื่องมือบางอย่าง บันทึกและเล่นสคริปต์ที่ทำเช่นนั้นยังคงน่ากลัวในการรักษา แต่น่าเสียดายที่มันไม่ได้แก้ปัญหาการทำซ้ำ ฉันไม่คิดว่าจะมีการหลีกเลี่ยงความต้องการในการออกแบบระบบทดสอบอัตโนมัติของคุณอย่างรอบคอบหากคุณต้องการเก็บสคริปต์ไว้รอบ ๆ หรือสร้างมากกว่าหนึ่งโหล คุณคิดว่าจะใช้บางสิ่งที่ขับเคลื่อนด้วยคำหลักเช่น Robot Framework พร้อมกับ Auto-It หรือไม่?

— testerab

0

หนึ่งความแตกต่างที่สำคัญที่เป็นสิ่งสำคัญมากที่นี่คือ: มีการทดสอบเพียงแค่การตรวจสอบหรือพวกเขาจะทดสอบ ?

นี้บล็อกโพสต์โดยไมเคิลโบลตันอธิบายได้ดีกว่า แต่ในสาระสำคัญ: พวกเขากำลังมองไปสู่พฤติกรรมที่ยืนยันเพียงหรือพวกเขากำลังมองหาที่จะมีปัญหาเกี่ยวกับระบบหรือไม่

ฉันคิดว่ามันยังมีประโยชน์ในการพิจารณาAgile Testing Quadrants (Brian Marick เดิมอธิบายเหล่านี้ แต่ฉันเจอพวกเขาใน Lisa Crispin และหนังสือ "Agile Testing" ของ Janet Gregory: แม้ว่าคุณจะไม่ได้ใช้วิธีการพัฒนาแบบ Agile ก็ตาม ความแตกต่างระหว่างการทดสอบที่วิจารณ์ผลิตภัณฑ์และการทดสอบที่สนับสนุนทีมนั้นมีค่าจริง ๆ เมื่อพิจารณาเรื่องระบบอัตโนมัติและพยายามพัฒนาแผนการสำหรับใครทำอะไรและทำไม

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

สิ่งอื่น ๆ ที่ฉันชอบเกี่ยวกับการนำเสนอของ Lisa Crispin ที่ฉันเชื่อมโยงคือมันชี้ให้เห็นว่าระบบอัตโนมัติยังสามารถใช้เพื่อสนับสนุนการทดสอบด้วยตนเอง - การสร้างข้อมูลทดสอบ ตัวอย่าง.

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

— testerab
แหล่งที่มา