เนื่องจากผลิตภัณฑ์และบริการใช้งานได้เร็วขึ้นและเร็วขึ้นการประกันคุณภาพ (QA) จึงต้องปรับให้เข้ากับสภาพแวดล้อมที่มีการเปลี่ยนแปลงบางครั้งก็บรรลุความครอบคลุมในระดับเดียวกันในช่วงเวลาสั้น ๆ เราจะหลีกเลี่ยงข้อผิดพลาดได้อย่างไร ปริมาณมากกว่าคุณภาพ เหรอ? เราจะครอบคลุมมากขึ้นเพิ่มประสิทธิภาพและยังคงมีประสิทธิผลในงานของเราได้อย่างไร?

เราทุกคนทราบดีว่ากรณีทดสอบใช้เวลานานในการสร้าง เราต้องใช้เทคนิคต่างๆประเภทการทดสอบและเงื่อนไขเบื้องต้นของเอกสารขั้นตอนและผลลัพธ์ที่คาดหวัง นอกจากนี้เราต้องสร้างแผนการทดสอบ

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

การทดสอบ QA แบบดั้งเดิมตรงตามขั้นตอนของผู้ใช้

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

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

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

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

การเรียนรู้การเขียนโปรแกรมในc

ก้าวไปกับกระแส

โดยไม่ต้องรอช้าให้เราดำดิ่งสู่การสร้างโฟลว์ผู้ใช้สำหรับเว็บไซต์การส่งข้อความธรรมดา ๆ

อันดับแรกเราจะต้องมีเครื่องมือทำแผนที่ความคิดฟรี ผมเองใช้ XMind . อย่าลังเลที่จะดาวน์โหลดเครื่องมือใด ๆ ที่คุณพอใจเราจะใช้เฉพาะคุณสมบัติพื้นฐานเช่นการวาดแผนภาพการไหลการเพิ่ม 'บันทึก' ในหัวข้อบางหัวข้อการระบายสีเงื่อนไขต่างๆและการใช้ป้ายกำกับ

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

เงื่อนไขรัฐการดำเนินการ

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

การวิเคราะห์ข้อกำหนด

นี่คือหน้าแรกของเราซึ่งเป็นรัฐ เรามีการดำเนินการสองอย่างที่เป็นไปได้: ลงทะเบียนและเข้าสู่ระบบ

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

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

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

1. โฮมเพจ
2. หน้าต่างเข้าสู่ระบบ
3. หน้าต่างลงทะเบียน
4. แผงควบคุม

เราจดบันทึกการกระทำของเราในแต่ละเพจ / สถานะที่สามารถ 'โต้ตอบ' กับ:

1. โฮมเพจ
   1. เข้าสู่ระบบ
   2. ลงทะเบียน
2. หน้าต่างเข้าสู่ระบบ
   1. เข้าสู่ระบบ
   2. ยกเลิก
3. หน้าต่างลงทะเบียน
   1. TBD (ขึ้นอยู่กับผลิตภัณฑ์)
4. แผงควบคุม
   1. สร้าง
   2. แก้ไข
   3. ลบ

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

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

การวาด Flow Diagram

เราวาดข้างต้นใน XMind เพื่อให้ดูเหมือน:

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

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

สิ่งที่ขั้นตอนของเราขาดหายไปคือป้ายกำกับ เราให้ป้ายกำกับผลิตภัณฑ์เป็น 0 เนื่องจากเป็นรากของการไหล จากนั้นสำหรับแต่ละรัฐ (สีน้ำเงิน) เราเพิ่มป้ายกำกับ S # สำหรับแต่ละการกระทำ (สีเขียว) เราเพิ่มป้ายกำกับ A # และสุดท้ายสำหรับแต่ละเงื่อนไข (สีฟ้า) เราเพิ่มป้ายกำกับ C # ป้ายกำกับแต่ละรายการต้องไม่ซ้ำกัน เราลงเอยด้วยด้านล่าง:

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

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

กฎเกสตัลต์ของ ________ บอกว่าเรามักจะจัดกลุ่มวัตถุที่อยู่ใกล้กัน

จากนั้นหน้าต่างเข้าสู่ระบบ:

จากนั้นลงชื่อเข้าใช้:

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

ในทีมส่วนใหญ่เราพบว่าการเปลี่ยนแปลงข้อกำหนดเป็นเรื่องยุ่งยากในการดูแลรักษา ไม่มีอีกแล้ว. สมมติว่าเราเพิ่งเรียนรู้ว่าผู้ใช้ครั้งแรกทุกคนต้องได้รับการนำเสนอด้วยหน้าต่าง Ts และ Cs และต้องยอมรับก่อนที่จะดำเนินการต่อในแดชบอร์ด - ไม่มีปัญหา เราสามารถเพิ่มสถานะและการกระทำได้ค่อนข้างง่ายดังต่อไปนี้:

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

การสร้างกรณีทดสอบจากโฟลว

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

สิ่งที่เราทำตอนนี้คือคัดลอกและวางสิ่งที่อยู่ในขั้นตอนของเราลงในเครื่องมือการจัดการกรณีทดสอบไซต์ Confluence หรือเอกสาร Excel ที่คุณต้องการ ฉันยังคงใช้ Excel เก่าที่เชื่อถือได้ ฉันเก็บบันทึกกรณีการทดสอบทั้งหมดของฉันไว้ในไฟล์เดียวที่เรียกว่า 'Baseline' ซึ่งเป็นต้นฉบับมาก เมื่อฉันคัดลอกวางเสร็จแล้วฉันจะได้รับสิ่งต่อไปนี้:

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

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

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

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

แนวทางแผนการทดสอบที่คล่องตัว

แล้วแผนการทดสอบล่ะคุณต้องคิด ง่ายๆแค่นี้เอง แผนการทดสอบประกอบด้วยส่วนต่างๆเช่น:

1. บทนำและขอบเขต
2. รายการทดสอบ
3. คุณสมบัติที่จะทดสอบ
4. คุณสมบัติที่ไม่ต้องทดสอบ
5. สมมติฐาน
6. เกณฑ์การเข้า
7. เกณฑ์การออก
8. WBS
9. ความเสี่ยง
10. ข้อกำหนดด้านสิ่งแวดล้อม

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

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

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

WBS คือค่าประมาณที่คุณกำหนดให้กับเรื่องราวในรูปแบบของเรื่องราวหรือชั่วโมงขึ้นอยู่กับโครงการของคุณ เกณฑ์การเข้าและออกจะเป็นส่วนหนึ่งของเรื่องราวอยู่แล้ว

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

เราได้เรียนรู้อะไรบ้าง?

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

แนวทางนี้มีประโยชน์ในการชี้นำให้ฉันจัดระเบียบครอบคลุมทุกพื้นฐานและ สร้างเอกสารที่ทั้งทีมเข้าใจ . ใน Agile สิ่งนี้จะมีประโยชน์จริงๆและส่วนที่ดีที่สุดคือเรายังคงปฏิบัติตามแนวทาง Agile อย่างใดอย่างหนึ่ง: “ ลดความซับซ้อนของเอกสาร”

ทำไมเราใช้โหนด js

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

ทำความเข้าใจพื้นฐาน

อะไรคือความแตกต่างระหว่างการเดินทางของผู้ใช้และขั้นตอนของผู้ใช้

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

แผนภาพการไหลของผู้ใช้คืออะไร?

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

ชื่ออื่นสำหรับแผนภาพการไหลของผู้ใช้คืออะไร?

ในอดีตเรียกว่าไดอะแกรม 'User Interface Flow' และ 'Task Flow'

เหตุใดการประกันคุณภาพจึงมีความสำคัญ?

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