การวางแผนการใช้งาน Power BI: ตรวจสอบเนื้อหา

หมายเหตุ

บทความนี้เป็นส่วนหนึ่งของ ชุดการวางแผน การใช้งาน Power BI ของบทความ ชุดข้อมูลนี้เน้นไปที่ประสบการณ์การใช้งาน Power BI ภายใน Microsoft Fabric เป็นหลัก สําหรับบทนําสู่ชุดข้อมูล โปรดดู ที่ การวางแผนการใช้งาน Power BI

บทความนี้ช่วยให้คุณตรวจสอบเนื้อหาเป็นส่วนหนึ่งของการจัดการวงจรชีวิตเนื้อหา มีการกําหนดเป้าหมายเป็นหลักที่:

• ทีม Center of Excellence (COE) และ BI: ทีมที่มีหน้าที่ดูแล Power BI ในองค์กร ทีมเหล่านี้ประกอบด้วยผู้มีอํานาจตัดสินใจที่ตัดสินใจวิธีการจัดการวงจรชีวิตของเนื้อหา Power BI ทีมเหล่านี้ยังรวมถึงผู้จัดการฝ่ายวางจําหน่ายที่จัดการวงจรชีวิตของการเผยแพร่เนื้อหา และวิศวกรที่สร้างและจัดการคอมโพเนนต์ที่จําเป็นในการใช้และสนับสนุนการจัดการวงจรชีวิตอย่างมีประสิทธิภาพ
• ผู้สร้างเนื้อหาและเจ้าของเนื้อหา: ผู้ใช้ที่สร้างเนื้อหาที่ต้องการเผยแพร่ไปยังพอร์ทัล Fabric เพื่อแชร์กับผู้อื่น บุคคลเหล่านี้มีหน้าที่รับผิดชอบในการจัดการวงจรชีวิตของเนื้อหา Power BI ที่พวกเขาสร้าง

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

หมายเหตุ

โดยทั่วไปแล้ว คุณจะทําซ้ําตามลําดับขั้นสองและสามในวงจรการพัฒนาและการตรวจสอบความถูกต้องที่ต่อเนื่องกัน

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

รูปภาพต่อไปนี้แสดงวงจรชีวิตของเนื้อหา Power BI การเน้นขั้นตอนที่สามซึ่งเป็นที่ที่คุณตรวจสอบเนื้อหา

หมายเหตุ

สําหรับภาพรวมของการจัดการวงจรชีวิตเนื้อหา ดู บทความแรกในชุดนี้

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

• โยกย้ายข้อมูลไปยัง Power BI: ตรวจสอบเนื้อหา : บทความนี้อธิบายถึงข้อควรพิจารณาและการตัดสินใจที่สําคัญสําหรับการตรวจสอบเมื่อคุณโยกย้ายข้อมูลไปยัง Power BI จากเทคโนโลยีอื่นๆ
• BI การวางแผนโซลูชัน: ตรวจสอบเนื้อหา: บทความนี้อธิบายวิธีการวางแผนสําหรับวงจรการพัฒนาและการตรวจสอบความถูกต้องซ้ําเมื่อวางแผน Power BI หรือโซลูชัน Fabric ของคุณ

การตรวจสอบเนื้อหาเกี่ยวข้องกับการตัดสินใจหรือการดําเนินการที่เฉพาะเจาะจงเพื่อให้แน่ใจว่าเนื้อหาดําเนินการตามที่คาดไว้

เมื่อคุณตรวจสอบเนื้อหา คุณจะประเมินลักษณะต่างๆ ของโซลูชัน

• ฟังก์ชันการทํางาน: ไม่ว่ารายการและคุณลักษณะที่ประกอบด้วยโซลูชันจะทํางานหรือไม่ ตัวอย่างของฟังก์ชันการทดสอบคือว่าแบบจําลองความหมายสามารถทําการรีเฟรชตามกําหนดการให้เสร็จสมบูรณ์ได้หรือไม่
• ความถูกต้องของข้อมูล: ว่าตัวเลขและผลลัพธ์ที่แสดงนั้นสมบูรณ์และสอดคล้องกับความคาดหวังทางธุรกิจหรือไม่ ตัวอย่างของ การทดสอบความถูกต้องของ ข้อมูลคือว่าค่าในรายงานสอดคล้องกับข้อมูลพื้นฐานที่รู้จักหรือไม่
• Performance: ไม่ว่าคิวรีจะสร้างผลกระทบน้อยที่สุดกับทรัพยากรผู้ใช้ที่มีอยู่หรือเวลารอของผู้ใช้ ตัวอย่างของประสิทธิภาพการทดสอบคือว่ากระแสข้อมูลรีเฟรชได้อย่างเชื่อถือได้โดยไม่ต้องหมดเวลาหรือประสบกับระยะเวลาการรีเฟรชที่นาน
• Security: ไม่ว่าบุคคลที่ไม่ได้รับอนุญาตจะถูกจํากัดไม่ให้ดูหรือเข้าถึงข้อมูล หรือโซลูชันทั้งหมด ตัวอย่างของการทดสอบความปลอดภัยคือการเลียนแบบของผู้ใช้หรือบทบาทเมื่อตรวจสอบการรักษาความปลอดภัยระดับแถว (RLS)
• ประสิทธิภาพ: ไม่ว่าโซลูชันจะจัดการกับปัญหาหรือกระบวนการทางธุรกิจที่เกี่ยวข้องหรือไม่ และสนับสนุนวัตถุประสงค์ทางธุรกิจอย่างเพียงพอตามที่ตั้งใจไว้ ตัวอย่างของประสิทธิภาพการทดสอบคือการรวบรวมคําติชมของผู้ใช้เมื่อคุณดําเนินการทดสอบการยอมรับของผู้ใช้ (UAT)
• การเข้าถึง : ไม่ว่าโซลูชันตรงกับมาตรฐานการเข้าถึง ที่รู้จัก เพื่อให้สามารถใช้งานได้โดยผู้คนจํานวนมากที่สุดเท่าที่เป็นไปได้ ตัวอย่างของการทดสอบการช่วยสําหรับการเข้าถึงคือการตรวจสอบว่ารายงานของคุณตรงตามรายการตรวจสอบการเข้าถึงรายงานของ Microsoft หรือไม่

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

หมายเหตุ

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

ตัดสินใจว่าผู้สร้างควรตรวจสอบเนื้อหาอย่างไร

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

หมายเหตุ

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

ผู้สร้างเนื้อหาสามารถตรวจสอบเนื้อหาได้สองวิธี

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

ส่วนต่อไปนี้อธิบายวิธีการต่างๆ ที่ผู้สร้างเนื้อหาสามารถทําการทดสอบด้วยตนเอง การทดสอบอัตโนมัติ และการตรวจสอบเพียร์

ดําเนินการทดสอบด้วยตนเอง

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

ต่อไปนี้คือข้อควรพิจารณาเมื่อทดสอบเนื้อหาของคุณเอง

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

ส่วนต่อไปนี้อธิบายข้อควรพิจารณาหลักอื่น ๆ สําหรับการทดสอบด้วยตนเอง

ทดสอบแบบจําลองความหมายด้วยตนเอง

แบบจําลองเชิงความหมายเป็นส่วนสําคัญของโซลูชันใน Fabric และ Power BI เนื่องจากเป็นแหล่งอัพสตรีมสําหรับรายงาน แดชบอร์ด และเครื่องมือไคลเอ็นต์อื่น ๆ และปริมาณงาน Fabric ดังนั้น สิ่งสําคัญคือต้องตรวจสอบแบบจําลองความหมายของคุณก่อนการปรับใช้

ตอบคําถามต่อไปนี้เพื่อช่วยให้คุณตรวจสอบแบบจําลองความหมายของคุณ

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

คุณสามารถใช้เครื่องมือและวิธีการต่างๆ เพื่อช่วยให้คุณตรวจสอบแบบจําลองความหมายของคุณ

• Power BI Desktop: Power BI Desktop ช่วยให้คุณสามารถตรวจสอบลักษณะที่แตกต่างกันของแบบจําลองความหมายของคุณโดยใช้คุณลักษณะต่าง ๆ ตัวอย่างของคุณลักษณะ Power BI Desktop ที่อํานวยความสะดวกในการทดสอบแบบจําลองความหมายได้แก่:
  • พื้นที่วิชวล : ทดสอบฟังก์ชันแบบจําลองและความแม่นยําด้วยวิชวลแบบลากแล้วปล่อย
  • มุมมองคิวรี DAX : ทดสอบความแม่นยําของแบบจําลองและ รหัส DAX ด้วยคิวรี DAX ที่คุณสามารถบันทึกและนํากลับมาใช้ใหม่ในภายหลัง
  • การวินิจฉัยคิวรี: ทดสอบประสิทธิภาพการรีเฟรชโดยการรับข้อมูลการวินิจฉัย เกี่ยวกับวิธีการประเมินคิวรีใน Power Query
• Fabric: คุณลักษณะและรายการในพอร์ทัล Fabric ช่วยให้คุณสามารถตรวจสอบลักษณะของแบบจําลองความหมายของคุณได้เมื่อมีการปรับใช้กับพื้นที่ทํางาน
  • Security: ทดสอบความปลอดภัยของแบบจําลองโดย เลียนแบบบทบาทความปลอดภัยหรือผู้ใช้
  • สมุดบันทึก: ทดสอบฟังก์ชันและความแม่นยําของแบบจําลองโดยใช้ลิงก์ความหมาย
  • การตรวจสอบฮับ : ทดสอบและตรวจสอบ รีเฟรชข้อมูลของแบบจําลองความหมายและรายการข้อมูล Fabric อื่น ๆ
• เครื่องมือของบุคคลที่สาม: เครื่องมือของบุคคลที่สามช่วยให้คุณสามารถตรวจสอบลักษณะอื่น ๆ ของแบบจําลองความหมายของคุณได้โดยให้รายละเอียดเพิ่มเติมหรือคุณสมบัติอื่น ๆ ที่ช่วยในการตรวจสอบ ตัวอย่างของเครื่องมือของบุคคลที่สามที่อํานวยความสะดวกในการทดสอบแบบจําลองความหมายได้แก่:
  • DAX Studio : ทดสอบและปรับประสิทธิภาพของโค้ด DAX ให้เหมาะสมโดยรับการแบ่งย่อยโดยละเอียดของการกําหนดเวลาคิวรี DAX และแผนคิวรี
  • ตัวแก้ไขตาราง: ทดสอบและแก้ไขจุดบกพร่องความแม่นยําของโค้ด DAX โดยการแยกย่อยโดยละเอียดเกี่ยวกับวิธีการประเมินคิวรี DAX และบริบทการประเมินผลใดที่ใช้งานอยู่

เคล็ดลับ

คุณสามารถใช้ การวินิจฉัย คิวรีเพื่อตรวจสอบและปรับประสิทธิภาพการทํางานของ Power Query จากรายการอื่น ๆ ที่ใช้ด้วยตนเอง เช่น กระแสข้อมูล

นอกจากนี้ คุณยังสามารถใช้มุมมองคิวรี DAX และเครื่องมือของบุคคลที่สาม เช่น DAX Studio เพื่อตรวจสอบและปรับคิวรี DAX ให้เหมาะสมสําหรับรายงานที่มีการแบ่งหน้าและดัชนีชี้วัดได้

รายงานทดสอบด้วยตนเอง

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

ตอบคําถามต่อไปนี้เพื่อช่วยให้คุณตรวจสอบรายงานของคุณ

• รายงานตรงตามความต้องการทางธุรกิจที่จัดทําเอกสารไว้หรือไม่
• มีการใช้ชนิดวิช วลที่ถูกต้องเพื่อตอบคําถามที่ถูกต้องหรือไม่
• หน้ารายงานมีความชัดเจนและรัดกุมโดยไม่มีสีที่ครอบงําหรือมีวิชวลมากเกินไปหรือไม่
• รายงานทํางานตามที่คาดไว้เมื่อกรองไปยังชุดย่อยของข้อมูลแคบหรือไม่
• รายงานอนุญาตการส่งออกไปยัง Excel หรือไม่ และถ้ามี จะอนุญาตให้ดึงข้อมูลสรุปหรือข้อมูลพื้นฐานหรือไม่
• สามารถใช้รายงานสําหรับการดูรายละเอียดแบบเจาะลึกข้ามรายงานหรือการตั้งค่าส่วนบุคคลของวิชวลได้หรือไม่

คุณสามารถใช้เครื่องมือและวิธีการต่างๆ เพื่อช่วยให้คุณตรวจสอบรายงานของคุณได้

• Power BI Desktop : Power BI Desktop ช่วยให้คุณสามารถตรวจสอบลักษณะที่แตกต่างกันของรายงานของคุณโดยใช้คุณลักษณะต่าง ๆ ตัวอย่างของคุณลักษณะ Power BI Desktop ที่อํานวยความสะดวกในการทดสอบรายงานประกอบด้วย:
  • พื้นที่วิชวล : ทดสอบฟังก์ชันการทํางานของรายงานโดยใช้ตัวแบ่งส่วนข้อมูล ตัวกรอง และองค์ประกอบแบบโต้ตอบอื่น ๆ
  • ตัววิเคราะห์ประสิทธิภาพ : ประสิทธิภาพรายงานการทดสอบโดย การวัดการแสดงผลด้วยภาพและเวลาการคิวรี DAX คุณสามารถคัดลอกคิวรี DAX ของวิชวลจากตัววิเคราะห์ประสิทธิภาพเพื่อใช้ในเครื่องมืออื่น และ บันทึกผลลัพธ์ ประสิทธิภาพการทํางานสําหรับเอกสารประกอบได้
  • การจําลองขีดจํากัดคิวรี: ประสิทธิภาพรายงานการทดสอบโดย จําลองขีดจํากัดหน่วยความจํา ในความจุที่จะปรับใช้
• Fabric: คุณลักษณะและรายการในพอร์ทัล Fabric ช่วยให้คุณสามารถตรวจสอบลักษณะรายงานของคุณเมื่อมีการปรับใช้กับพื้นที่ทํางาน
  • อัปเดตแอป: ทดสอบฟังก์ชันการทํางานและความปลอดภัยของรายงานเมื่อกระจายรายงานในแอป Power BI และตั้งค่าผู้ชมแอปที่แตกต่างกันเพื่อกําหนดว่าใครสามารถดูเนื้อหาใดได้บ้าง เมื่อคุณใช้ผู้ชมแอป คุณสามารถดูตัวอย่างว่ารายงานใดที่พวกเขามีสิทธิ์เข้าถึง และทดสอบประสบการณ์การใช้งานแอปด้วยตัวคุณเอง
  • มุมมองการอ่านในพื้นที่ทํางานหรือแอป: ทดสอบฟังก์ชันการทํางานและความแม่นยําของรายงานโดยใช้ในสภาพแวดล้อมเดียวกันกับผู้ใช้

หมายเหตุ

คุณสามารถพัฒนาและตรวจสอบแดชบอร์ดในพอร์ทัล Fabric เท่านั้น

สำคัญ

จึงจําเป็นต้องทดสอบรายงานของคุณทั้งใน Power BI Desktop และหลังการปรับใช้ในพอร์ทัล Fabric การแสดงภาพอาจทํางานแตกต่างกันในเครื่องของคุณเมื่อเทียบกับรายงานในพื้นที่ทํางาน Fabric นอกจากนี้ โปรดทราบว่าประสบการณ์ของผู้ใช้ในการใช้รายงานจากพื้นที่ทํางานหรือแอปมีความแตกต่างอย่างมากจากการใช้รายงานใน Power BI Desktop

ทดสอบด้วยตนเองโดยการดําเนินการตรวจทานแบบเพียร์

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

หมายเหตุ

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

เคล็ดลับ

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

มีหลายวิธีที่คุณสามารถดําเนินการตรวจสอบเพียร์

• การตรวจสอบการทํางาน: การตรวจทานการทํางานมุ่งเน้นไปที่คุณลักษณะ กระบวนการ หรือข้อกําหนดทางธุรกิจที่โซลูชันควรเติมเต็ม ในการตรวจสอบการทํางาน ผู้ตรวจสอบจะใช้โซลูชันราวกับว่าพวกเขาเป็นผู้ใช้ปลายทาง พวกเขาบันทึกถึงข้อบกพร่องหรือปัญหาใด ๆ ที่พวกเขาพบพร้อมกับวิกฤติใด ๆ ในการปรับปรุงการใช้งาน
• การตรวจสอบทางเทคนิค: การตรวจสอบทางเทคนิคมุ่งเน้นด้านเทคนิคของโซลูชัน เช่น การสร้างแบบจําลองข้อมูล โค้ด หรือการออกแบบ ในการตรวจสอบทางเทคนิค ผู้ตรวจสอบประเมินว่าคุณลักษณะหรือการเปลี่ยนแปลงบางอย่างถูกนํามาใช้อย่างไร และแนะนําวิธีการทางเลือกหรือเน้นข้อบกพร่องหรือความเสี่ยงที่อาจเกิดขึ้นกับวิธีการปัจจุบัน
• คําขอดึงข้อมูล: เมื่อคุณดําเนินการควบคุมแหล่งข้อมูล คุณสามารถสร้างคําขอดึงข้อมูล (PR) เพื่อผสานการเปลี่ยนแปลงของคุณกับโซลูชันเวอร์ชันล่าสุด เจ้าของทางเทคนิคตรวจทานการเปลี่ยนแปลงที่เสนอและประเมินซอร์สโค้ด การตรวจสอบแบบนี้มีประโยชน์สําหรับการทําให้แน่ใจว่าโค้ดเป็นไปตามหลักทั่วไปมาตรฐาน เช่น การจัดรูปแบบรหัส DAX หรือ M หรือการระบุรูปแบบการป้องกันหรือรหัสที่อาจเป็นปัญหา

เคล็ดลับ

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

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

การทดสอบโดยอัตโนมัติ

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

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

การทดสอบอัตโนมัติที่มีประสิทธิภาพเป็นส่วนสําคัญของการใช้งาน DataOps DataOps ช่วยให้ทีมสามารถทําให้กระบวนการเป็นอัตโนมัติและปรับขนาดโดยนําแนวทางปฏิบัติที่ปรับปรุงและเร่งการส่งมอบข้อมูลและการวิเคราะห์ไปใช้

สำคัญ

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

เคล็ดลับ

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

ส่วนต่อไปนี้อธิบายข้อควรพิจารณาหลักสําหรับการทดสอบแบบจําลองความหมายและรายงาน Power BI โดยอัตโนมัติ

การทดสอบแบบจําลองความหมายโดยอัตโนมัติ

การทดสอบแบบจําลองความหมายแบบอัตโนมัติเป็นไปได้ แม้ว่าโดยทั่วไปจะต้องมีการตั้งค่าแบบกําหนดเองด้วยเครื่องมือและเฟรมเวิร์กของบุคคลที่สาม

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

• ตัววิเคราะห์แนวทางปฏิบัติที่ดีที่สุด (BPA): ตัววิเคราะห์แนวทางปฏิบัติที่ดีที่สุด ช่วยให้คุณสามารถระบุกฎที่คุณสามารถใช้เพื่อประเมินแบบจําลองความหมายได้ คุณสามารถเรียกใช้ BPA โดยใช้ ตัวแก้ไขตาราง ซึ่งจะระบุการละเมิดกฎใดๆ ในแบบจําลองความหมาย คุณสามารถทําการตรวจสอบการละเมิดกฎ BPA โดยอัตโนมัติโดยใช้อินเทอร์เฟซบรรทัดคําสั่งตัวแก้ไขตาราง (CLI) ร่วมกับ Azure DevOps หรือเป็นส่วนหนึ่งของกระบวนการที่กําหนดไว้อื่น
• Fabric notebooks และลิงก์ความหมาย: Notebooks in Fabric ช่วยให้คุณสามารถใช้ลิงก์ความหมาย เพื่อโต้ตอบกับแบบจําลองเชิงความหมายทางโปรแกรม คุณสามารถใช้สมุดบันทึกเพื่อเรียกใช้เฟรมเวิร์กเช่น ความคาดหวังที่ดี (GX) เพื่อตรวจสอบข้อมูล นอกจากนี้ คุณสามารถ ประเมินหน่วยวัดและคิวรี DAX จากนั้นทดสอบผลลัพธ์กับเส้นฐานที่รู้จัก
• Power Automate : Power Automate ช่วยให้คุณสามารถเรียกใช้คิวรีกับแบบจําลองความหมายและส่งออกรายงานโดยใช้ Power BI REST APIs คุณสามารถตรวจสอบผลลัพธ์คิวรีกับข้อมูลพื้นฐานที่รู้จัก แล้วดําเนินการตามการดําเนินการปลายทาง เช่น การทริกเกอร์การแจ้งเตือนไปยังเจ้าของเนื้อหา

เคล็ดลับ

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

ทําการทดสอบรายงานให้เป็นอัตโนมัติ

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

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

• ตัววิเคราะห์แนวทางปฏิบัติที่ดีที่สุดของรายงาน: มีเครื่องมือของบุคคลที่สามมากมายที่สนับสนุนฟังก์ชันที่คล้ายกับตัววิเคราะห์แนวทางปฏิบัติที่ดีที่สุดเพื่อทําให้การตรวจหาปัญหาในรายงานเป็นแบบอัตโนมัติโดยตรวจสอบข้อกําหนดของรายงาน เครื่องมือสองตัวที่สนับสนุนฟังก์ชันการทํางานนี้คือ PBI Explorer และ PBI Inspector
• Power Automate Desktop : เครื่องมืออัตโนมัติ UI เช่น Selenium สําหรับ Python หรือ Power Automate Desktop ช่วยให้คุณสามารถจําลองการโต้ตอบของเมาส์ผู้ใช้กับรายงานได้ โดยการกําหนดโฟลว์ผู้ใช้ คุณสามารถทดสอบการนําทางและการโต้ตอบได้ การทดสอบเหล่านี้ผ่านเมื่อพวกเขาสามารถทําโฟลว์ให้เสร็จสมบูรณ์และล้มเหลวเมื่อตรวจพบ คําหรือรูปภาพ ที่เฉพาะเจาะจงบนหน้าจอ (เช่น ข้อความแสดงข้อผิดพลาด หรือภาพว่าง)

ตัดสินใจว่าผู้ใช้ควรตรวจสอบเนื้อหาอย่างไร

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

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

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

สำคัญ

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

หมายเหตุ

คุณไม่สามารถปรับใช้หรือคัดลอกแอปจากพื้นที่ทํางานหนึ่งไปยังอีกพื้นที่ทํางานหนึ่งได้ การเปลี่ยนแปลงใด ๆ กับแอปจะต้องทําด้วยตนเองในการกําหนดค่าสําหรับพื้นที่ทํางานนั้น

ก่อนที่คุณจะเริ่มการตรวจสอบความถูกต้องผู้ใช้ คุณควรดําเนินการเตรียมการที่จําเป็น

• วางแผนว่าควรตรวจสอบความถูกต้องของผู้ใช้เมื่อใหร่
• ระบุว่าการตรวจสอบความถูกต้องของผู้ใช้ถูกจํากัดเฉพาะช่วงเวลาหรือเป็นส่วนหนึ่งของกระบวนการวนซ้ํา
• สร้างวิธีการเพื่อรวบรวมคําติชม เช่น โดยใช้ Microsoft Forms
• สื่อสารกับผู้ใช้ที่เกี่ยวข้องกับการตรวจสอบความถูกต้องของการวางแผนและความคาดหวัง
• จัดระเบียบการเริ่มต้นการตรวจสอบผู้ใช้เพื่อแนะนําผู้ใช้และจัดการความคาดหวัง
• ดําเนินการฝึกอบรมสําหรับผู้ใช้เพื่อสาธิตกระบวนการตรวจสอบความถูกต้องและคําติชม

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

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

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

รายการตรวจสอบ - เมื่อวางแผนวิธีตรวจสอบเนื้อหา การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

• เงื่อนไขการทดสอบและเอกสาร: อธิบายการทดสอบที่คุณจะทํา สิ่งที่ทดสอบ และวิธีที่คุณจะดําเนินการ
• ตัดสินใจเกี่ยวกับกระบวนการตรวจสอบเพียร์: อธิบายว่าใครจะตรวจสอบเนื้อหานอกเหนือจากตัวคุณเอง
• ตัดสินใจเกี่ยวกับวิธีการทดสอบด้วยตนเอง: ตัดสินใจว่าเครื่องมือและคุณลักษณะใดที่คุณจะใช้เพื่อตรวจสอบเนื้อหาที่คุณสร้าง
• ตัดสินใจว่าคุณจะใช้การทดสอบอัตโนมัติ: ระบุว่ามาตราส่วนและขอบเขตของเนื้อหาของคุณกําหนดค่าการทดสอบอัตโนมัติหรือไม่ ถ้าเป็นเช่นนั้น ตรวจสอบให้แน่ใจว่าคุณวางแผนสําหรับเวลาและทรัพยากรที่จําเป็นในการออกแบบและใช้การทดสอบเหล่านี้เพื่อให้สามารถตรวจสอบสิ่งที่คุณคาดหวังได้
• ปรับใช้เนื้อหาจากพื้นที่ทํางานการพัฒนาไปยังพื้นที่ทํางานทดสอบ: ปรับใช้การเปลี่ยนแปลงจากพื้นที่ทํางานการพัฒนาไปยังพื้นที่ทํางานทดสอบเพื่อให้ผู้ใช้มองเห็นการเปลี่ยนแปลงได้ ตรวจสอบให้แน่ใจว่าคุณได้ทํากิจกรรมหลังการปรับใช้ที่จําเป็นในพื้นที่ทํางานทดสอบ เช่น การตั้งค่าและการอัปเดตแอปทดสอบ
• ตัดสินใจเกี่ยวกับวิธีการทดสอบผู้ใช้: ตัดสินใจว่าผู้ใช้จะตรวจสอบเนื้อหาอย่างไร
• ระบุผู้ใช้ทดสอบ: ระบุบุคคลระหว่างชุมชนผู้ใช้จะตรวจสอบเนื้อหา บรรลุข้อตกลงกับบุคคลเหล่านั้นในกรณีที่มีความเกี่ยวข้องและความคาดหวัง
• รวบรวมคําติชมของผู้ใช้: ตั้งค่าเครื่องมือและกระบวนการเพื่อรวบรวมคําติชมโดยอัตโนมัติ ตัวอย่างเช่น คุณสามารถใช้ Tasks และ Planner ใน Microsoft Teams หรือ Microsoft Forms ได้
• ผลการทดสอบเอกสาร: จัดทําเอกสารผลลัพธ์ของการตรวจสอบเนื้อหาทั้งหมด และการเปลี่ยนแปลงใดๆ ที่เกิดขึ้นอันเป็นผลมาจากผลการทดสอบ ตรวจสอบให้แน่ใจว่าเอกสารนี้ง่ายต่อการค้นหา
• วางแผนการปรับใช้ของคุณไปยังการผลิต : เมื่อการทดสอบผู้ใช้รวมแล้ว ให้เตรียมการเพื่อปรับใช้เนื้อหาจากพื้นที่ทํางานทดสอบไปยังพื้นที่ทํางานการผลิต

เนื้อหาที่เกี่ยวข้อง

ใน บทความถัดไปในชุดนี้ เรียนรู้วิธีการปรับใช้เนื้อหาเป็นส่วนหนึ่งของการจัดการวงจรชีวิตเนื้อหา