ใครเป็นผู้รับผิดชอบด้านคุณภาพ?

เฮ้ ฮับ!

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

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

ด้านล่างเราจะพูดคุยกับหัวหน้าคณะกรรมการโปรแกรม หัวหน้าฝ่ายทดสอบที่ Tinkoff.Business ผู้สร้างชุมชน QA ที่พูดภาษารัสเซีย อนาสตาเซีย อาซีวา-เหงียน เกี่ยวกับสถานะของอุตสาหกรรม QA และภารกิจของการประชุมครั้งใหม่

- นาสเทียสวัสดี กรุณาบอกเราเกี่ยวกับตัวคุณ

Anastasia: ฉันจัดการการทดสอบที่ธนาคาร ฉันรับผิดชอบทีมงานขนาดใหญ่มาก - เรามีพนักงานมากกว่า 90 คน เรามีสายธุรกิจที่สำคัญ เรารับผิดชอบต่อระบบนิเวศสำหรับนิติบุคคล

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

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

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

— คุณใช้คำว่าการประกันคุณภาพและการทดสอบ ในสายตาของคนทั่วไป สองคำนี้มักจะทับซ้อนกันมาก ถ้าเจาะลึกจะต่างกันอย่างไร?

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

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

— โปรดบอกเราว่ายังมีสาขาวิชาประกันคุณภาพอื่นๆ อีกบ้าง มีอะไรอีกบ้างนอกจากการทดสอบที่รวมอยู่ที่นี่?

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

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

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

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

— ปรากฎว่าคุณภาพตัดกับระเบียบวินัยโดยรอบเกือบทั้งหมด ทำให้เกิดกรอบการทำงานกับทุกสิ่งรอบตัว

Anastasia: ขวา. เมื่อเราคิดถึงวิธีที่เราต้องการสร้างผลิตภัณฑ์ที่มีคุณภาพ เราก็เริ่มคิดถึงคุณลักษณะต่างๆ ของคุณภาพ เช่น วิธีตรวจสอบว่าเราได้สร้างฟีเจอร์ที่ลูกค้าของเราต้องการจริงๆ

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

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

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

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

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

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

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

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

สิ่งนี้ทำให้เกิดคำถาม - บางทีทีมอาจจำเป็นต้องใช้โครงสร้างพื้นฐานเป็นโค้ด

ฉันเชื่อว่าโครงสร้างพื้นฐานส่งผลโดยตรงต่อคุณภาพของผลิตภัณฑ์

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

— แล้วการวิเคราะห์และเอกสารล่ะ?

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

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

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

นักพัฒนาไม่ใช่ผู้รบกวนและอย่าเขียนโค้ดโดยมีข้อผิดพลาดโดยตั้งใจ

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

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

นี่คือแนวทางจาก Agile ที่อยู่ในใจ - เรื่องราวของผู้ใช้ที่มีเกณฑ์การยอมรับ สิ่งนี้ใช้ได้กับทีมที่พัฒนาแบบวนซ้ำเล็กน้อยมากกว่า

— แล้วการทดสอบการใช้งาน การใช้งานผลิตภัณฑ์ การออกแบบล่ะ?

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

แถมยังมีปัญหาอีกประการหนึ่ง ระบบการออกแบบกำลังได้รับความนิยม พวกเขาเป็นที่ฮือฮา แต่ประโยชน์ที่ได้รับนั้นไม่ได้ชัดเจนนัก

ฉันพบว่าในด้านหนึ่งการออกแบบระบบทำให้การพัฒนาง่ายขึ้น แต่ในทางกลับกันกลับกำหนดข้อจำกัดมากมายบนอินเทอร์เฟซ

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

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

— มีหัวข้อที่เกี่ยวข้องกับการประกันคุณภาพที่น่าประหลาดใจมากมาย มีการประชุมในรัสเซียที่สามารถพูดคุยทั้งหมดได้หรือไม่?

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

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

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

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

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

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

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

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

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

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

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

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

เราจะไม่มีรายงานเกี่ยวกับเครื่องมือเพื่อประโยชน์ของเครื่องมืออย่างแน่นอน รายงานทั้งหมดที่รวมอยู่ในโปรแกรมจะรวมเป็นหนึ่งเดียวกันโดยมีเป้าหมายร่วมกัน

— ใครจะสนใจสิ่งที่คุณกำลังพูดถึง ใครที่คุณเห็นเป็นแขกของการประชุม?

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

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

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

— คุณคิดว่าอุตสาหกรรมโดยรวมมีความพร้อมที่จะพูดคุยไม่เพียงแค่เกี่ยวกับการทดสอบ แต่เกี่ยวกับวัฒนธรรมแห่งคุณภาพหรือไม่?

Anastasia: ฉันคิดว่าฉันโตแล้ว ปัจจุบันบริษัทหลายแห่งกำลังเปลี่ยนจากแนวทางแบบ Waterfall แบบดั้งเดิมไปสู่ ​​Agile มีการมุ่งเน้นลูกค้า คนในทีมเริ่มคิดจริงๆ ว่าจะสร้างผลิตภัณฑ์ที่มีคุณภาพได้อย่างไร แม้แต่บริษัทระดับองค์กรก็ยังหันมาให้ความสำคัญกับการปรับปรุงคุณภาพอีกครั้ง

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

- ตกลง! เราจะปลูกฝังวัฒนธรรมและเปลี่ยนจิตสำนึก

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

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

ที่มา: will.com