การทดสอบ – อาจเป็นส่วนที่ด้อยค่าที่สุดของการพัฒนาแอปพลิเคชัน

ทำไมฉันต้องจ่ายเงินให้คุณเพื่อทดสอบงานของคุณเอง?

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

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

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

การทดสอบหน่วย

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

การทดสอบควัน

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

การทดสอบ UI

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

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

การทดสอบการถดถอย

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

UAT

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

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

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

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

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

การทดสอบความปลอดภัย

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

การทดสอบประสิทธิภาพ

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

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

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

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