การทดสอบการประกันคุณภาพสมบูรณ์แบบ – บทแนะนำขั้นตอนการใช้งาน

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

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

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

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

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

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

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

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

ไปกับกระแส

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

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

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

เงื่อนไข รัฐ การกระทำ

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

วิเคราะห์ความต้องการ

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

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

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

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

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

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

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

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

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

วาดแผนภาพการไหล

เราวาดด้านบนใน XMind เพื่อให้มีลักษณะดังนี้:

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

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

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

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

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

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

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

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

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

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

การสร้างกรณีทดสอบจาก Flow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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