QA best practices
1.0.0
นี่เป็นบทสรุปของการใช้งาน QA Futurice ที่ใช้และแนะนำให้ใช้ ไม่ควรเป็นคำอธิบายโดยละเอียดและบางครั้งก็ไม่สามารถใช้งานได้อย่างเต็มที่ แต่เป็นภาพรวมของกระบวนการ QA ที่สำคัญที่สุดและรายการแนวทางปฏิบัติที่ดีที่ควรใช้
เพื่อจุดประสงค์ของความชัดเจนเอกสารนี้ไม่ได้อธิบายข้อผิดพลาดหรือกระบวนการเหตุการณ์ (เช่นข้อผิดพลาดใหม่พบได้จากการผลิต)
ทุกคนในทีม Futurice มีความรับผิดชอบ QA แม้ว่าจะมีผู้จัดการ QA หรือผู้เชี่ยวชาญด้าน QA ไปสู่อนาคต QA หมายถึงสามสิ่ง
ในการทำงาน QA ระดับสูงและการปฏิบัติสามารถแบ่งออกเป็นสองกระบวนการ
นอกจากนี้ยังมีการกระทำของ QA อื่น ๆ
Fouturice ใช้วิธีการ TDD และ ATDD (การพัฒนาแบบทดสอบการตอบรับ) เมื่อมีการพัฒนา
วิธีการบังคับให้ดำเนินการตามสถาปัตยกรรมและพิจารณาโมดูลที่ใช้ การใช้งานเริ่มต้นด้วยการเขียนการทดสอบอัตโนมัติก่อนจากนั้นใช้ฟังก์ชันการทำงานเพื่อผ่านการทดสอบ
Futurice ใช้วิธีการเขียนโปรแกรมคู่เมื่อมี นี่เป็นวิธีที่สะดวกมากในการแบ่งปันความรู้และประสบการณ์เกี่ยวกับโครงการและซอฟต์แวร์ที่อยู่ระหว่างการพัฒนา
การตรวจสอบรหัสช่วยให้สมาชิกในทีมคนอื่น ๆ ได้รับข้อมูลเกี่ยวกับการทำงานบางอย่างและให้ความเป็นไปได้ที่จะให้ข้อเสนอแนะกับผู้รับผิดชอบและยังมั่นใจได้ว่าการแบ่งปันความรู้ระหว่างสมาชิกในทีม
การทดสอบด้วยตนเองส่วนใหญ่ทำโดยใช้วิธีการทดสอบเชิงสำรวจและพบข้อผิดพลาดจะได้รับการแก้ไขทันทีหรือจัดลำดับความสำคัญและบันทึกไปยังเครื่องมืองาน/เรื่องราว/ข้อผิดพลาด การสำรวจแอพหรือบริการสามารถเริ่มต้นได้ทันทีหลังจากสิ่งที่ใช้งานได้คือ“ พร้อม”
การทดสอบเชิงสำรวจเป็นเครื่องมือที่ทรงพลังมากในการทดสอบต้นจนจบซึ่งระบบทั้งหมดครอบคลุมโดยการทดสอบ ในวิธีการทดสอบนั้นเกินกว่าสิ่งที่สามารถกำหนดได้ในกรณีทดสอบใช้การคิดแบบเหมือนผู้ใช้เช่นเดียวกับพยายามที่จะทำลายระบบโดยสถานการณ์ข้อผิดพลาดต่าง ๆ และไม่เคย“ เสร็จสิ้น” กับการทดสอบ
รอบ ๆ ข้อกำหนดการทำงานและการทดสอบมักจะมีข้อกำหนดที่ไม่สามารถใช้งานได้ซึ่งสามารถทดสอบได้โดยใช้การแปลการใช้งานการใช้งานประสิทธิภาพและการทดสอบโหลด ความต้องการและเครื่องมือเป็นโครงการที่เฉพาะเจาะจง สำหรับการทดสอบการใช้งาน Futurice มีห้องปฏิบัติการการใช้งานมือถือสำหรับใช้งาน สำหรับการทดสอบประสิทธิภาพ Futurice ได้ใช้บริการบนเว็บเช่น BrowserMob เพื่อตั้งชื่อ สำหรับการทดสอบโหลด Loadui และ J Meter นั้นมีการใช้งานเพื่อตรวจสอบความสามารถในการบริการในปริมาณการใช้งานที่สูงและเพื่อค้นหาคอขวดของบริการที่เป็นไปได้
ปัญหาที่พบจะถูกบันทึกไว้ในเครื่องมือหรือบอร์ดเฉพาะที่มีข้อมูลเช่นลำดับความสำคัญสภาพแวดล้อม (ข้อมูลซอฟต์แวร์และอุปกรณ์) ขั้นตอนในการทำซ้ำผลลัพธ์ที่คาดหวังเวลาและวันที่และภาพหน้าจอ เครื่องมือเช่น JIRA, Trello, PivotalTracker, Request Tracker นั้นถูกใช้อย่างแข็งขันสำหรับการติดตามข้อผิดพลาด
หนึ่งในหลักการของ Agile คือสาขารหัสหลักควรเป็นไปได้เสมอ นั่นหมายความว่าควรมีคุณภาพการผลิตเสมอ สิ่งนี้ทำได้โดยวิธีการต่อไปนี้:
เรื่องราวของผู้ใช้แต่ละเรื่อง (หรือคุณสมบัติ) ได้รับการพัฒนาเป็นรายบุคคลในสาขาคุณสมบัติของตนเอง จุดประสงค์ของสิ่งนี้คือเพื่อให้แน่ใจว่าการอัปเดตแต่ละสาขาหลักในเวลาเดียวกัน 1) มีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้และ 2) เรื่องราวที่สมบูรณ์และสมบูรณ์
ก่อนที่สาขาฟีเจอร์สามารถรวมเข้ากับสาขาหลักจะต้องผ่านรายการของการกระทำข้อกำหนดและการปฏิบัติที่เรียกว่าคำจำกัดความของ DONE (DOD) สิ่งนี้ถูกกำหนดพร้อมกับ PO ของลูกค้าและทีมพัฒนาและสามารถแก้ไขได้ในระหว่างโครงการควรมีการเปลี่ยนแปลงความต้องการของโครงการ
รายการต่อไปนี้ใน DOD ที่เสนอนั้นมีความกล้าหาญเนื่องจาก
กระบวนการปรับใช้เป็นกระบวนการที่รุ่นใหม่ (หรือเวอร์ชันในสาขาหลัก) ถูกนำไปใช้กับการผลิต สำหรับกระบวนการนี้มีสามสภาพแวดล้อมที่เกี่ยวข้อง
เซิร์ฟเวอร์ Integration Integration (CI) ใช้สำหรับการทดสอบอัตโนมัติและการปรับใช้รหัสกับสภาพแวดล้อม การทดสอบอัตโนมัติจะทำงานอยู่เสมอเมื่อมีการอัปเดตสภาพแวดล้อมเหล่านี้
สภาพแวดล้อมการทดสอบจะได้รับการปรับปรุงโดยอัตโนมัติโดย CI เมื่อใดก็ตามที่มีการอัปเดตสาขาหลัก ซึ่งหมายความว่ากรณีทดสอบอัตโนมัติจะทำงานโดยอัตโนมัติเมื่อมีการอัปเดตสาขาหลัก
สภาพแวดล้อมการทดสอบเป็นเซิร์ฟเวอร์ทดสอบหลักสำหรับอนาคต คาดว่าการเปิดตัวใด ๆ ที่ได้รับการทดสอบที่นี่พร้อมที่จะส่งไปยัง QA หรือการผลิต (ขึ้นอยู่กับคำศัพท์และการรวมเข้าด้วยกันที่ใช้ในโครงการ)
ไม่จำเป็นต้องเรียกใช้กรณีทดสอบการถดถอยด้วยตนเองเมื่ออัปเดตการทดสอบ บ่อยครั้งที่ใช้เวลาในการทดสอบเชิงสำรวจมีประโยชน์มากกว่า อย่างไรก็ตามมันเป็นวิธีปฏิบัติที่ดีในการดำเนินการทดสอบเหล่านี้อย่างน้อยหนึ่งครั้งต่อการวิ่ง
สภาพแวดล้อม QA ควรใช้เป็นสภาพแวดล้อมสำหรับการทดสอบการยอมรับการสาธิตหรือการทดสอบหรือการตรวจสอบของบุคคลที่สาม (ความปลอดภัยการแปลการโหลดการใช้งาน ฯลฯ ) นี่ไม่ใช่เซิร์ฟเวอร์การทดสอบหลักของ Futurice (ทดสอบคือ) การอัปเดตสู่ QA มักจะตกลงกันระหว่าง PMS ของลูกค้าและ Futurice
เหตุผลหลักที่มีสองสภาพแวดล้อมการทดสอบ (ทดสอบและ QA) คือการปฏิบัติตามข้อกำหนดด้านความปลอดภัยและการรวม การทดสอบช่วยให้ Futurice พัฒนาบริการโดยใช้หลักการ Agile QA ช่วยให้เวลาและการควบคุมสำหรับลูกค้าสามารถเรียกใช้กระบวนการ QA ปัจจุบันของพวกเขา
QA ไม่ควรอัปเดตเว้นแต่ว่าการเปิดตัวจะผ่านการทดสอบในสภาพแวดล้อมการทดสอบ
สภาพแวดล้อม Prod เป็นสภาพแวดล้อมสำหรับเว็บไซต์สด (การผลิต)
แนวปฏิบัติที่ดีคือการปรับใช้และเรียกใช้การทดสอบอัตโนมัติใน QA อย่างน้อยก่อนที่จะผลักดันการอัปเดตไปยัง Prod อย่างไรก็ตามในการทำงานที่สำคัญต้องมีการตรวจสอบหลังจากการปรับใช้ทุกครั้ง
ขอแนะนำให้ PO ยังมีสิทธิ์ที่จะผลักดันการอัปเดตไปยัง Prod โดยไม่ต้องทำการทดสอบใน QA (หากเวอร์ชันถูกส่งผ่านในการทดสอบ) สิ่งนี้เกี่ยวข้องกับการอัปเดตนั้นเล็กมากหรือเรียบง่าย
ในที่สุดในการพัฒนา Agile เมื่อบริการอยู่ในการพัฒนาอย่างต่อเนื่องเป้าหมายคือการมีการอัปเดตเล็ก ๆ น้อย ๆ มากมายเช่นกัน นั่นคือมันสำคัญกว่าที่กระบวนการปรับใช้จะไม่ติดมันและกันกระสุน ถือว่าสำคัญกว่าที่จะสามารถแก้ไขได้อย่างรวดเร็วมากกว่าที่จะมีบริการฟรีบั๊ก (เห็นได้ชัดว่ามี DOD และการทดสอบอัตโนมัติคุณภาพควรสูง) อนาคตไม่แนะนำให้เริ่มต้นด้วยวิธีการนี้ทันที อย่างไรก็ตามนี่ควรเป็นทิศทางที่ทั้งสององค์กรต้องการไป
แต่ละแพลตฟอร์มมือถือมี SDK ชุดเครื่องมือและแนวทางปฏิบัติที่ดีที่สุดของ Futurice
สำหรับ Android https://github.com/futuice/android-best-practices
สำหรับ iOS https://github.com/futuice/ios-good-practices
สำหรับ Windows Phone https://github.com/futuriice/windows-app-development-bractices
แพลตฟอร์มมือถือให้อีมูเลเตอร์ภายใน SDK ของพวกเขา
ในระหว่างการพัฒนาเฟสการใช้งานสามารถใช้อุปกรณ์จำลอง / เลียนแบบเพื่อตรวจสอบการเปลี่ยนแปลง แต่ไม่มีอะไรสามารถเอาชนะการทดสอบอุปกรณ์จริงได้ซึ่งระบบทั้งหมดจากหน้าจอสัมผัสและหน่วยความจำแบบรวมไปยังโปรเซสเซอร์มือถือได้รับการพิจารณา
เบราว์เซอร์มือถือยังสามารถทดสอบได้ด้วยบริการบนคลาวด์เช่น BrowserStack
Futurice มีอุปกรณ์และระบบปฏิบัติการที่หลากหลายในไลบรารีอุปกรณ์ตั้งแต่โทรศัพท์พื้นฐานไปจนถึงแท็บเล็ตขั้นสูง
สำหรับการทดสอบแอปพลิเคชันการจราจรข้อมูลอย่างหนักและการตรวจสอบประสิทธิภาพการทำงานของ Futurice ได้ใช้ ELISA Test Lab (ELISA เป็นผู้ให้บริการมือถือฟินแลนด์) ภายในสภาพแวดล้อมของห้องปฏิบัติการโหลดและความเร็วที่แตกต่างกันสามารถทดสอบได้ในสภาพแวดล้อมที่ควบคุม / แยกได้โดยไม่จำเป็นต้องจัดเรียงราคาแพงและไม่ได้มีการทดสอบภาคสนามที่มีประสิทธิภาพ
โดยปกติแล้วแอพมือถือจะเชื่อมต่อกับบริการแบ็กเอนด์ผ่านเครือข่ายมือถือ เพื่อให้ได้รับประโยชน์สูงสุดจากการทดสอบผู้ทดสอบจะต้องมีการควบคุมแบ็กเอนด์อย่างเต็มที่ซึ่งแอปพลิเคชันมือถือเชื่อมต่อกับเพื่อเตรียมและดำเนินการสถานการณ์การทดสอบจากจุดสิ้นสุดที่แตกต่างกัน
ในอุปกรณ์มือถือการติดตั้งบิลด์ทดสอบสามารถทำได้: ในพื้นที่โดยใช้สายเคเบิลโดยใช้เครื่องมือพัฒนา SDK เครื่องมือควบคุมแบบไร้สายผ่านเครื่องมือจัดจำหน่ายแบบสร้างเช่น TestFlight หรือ HockeyApp การปล่อยเฟรมเวิร์กมักจะรองรับการรวบรวมบันทึกความผิดพลาดและข้อมูลเวอร์ชัน นอกจากนี้ยังสามารถจัดเตรียม DEV, Alpha และ Beta เพื่อรวบรวมข้อเสนอแนะก่อนที่จะปล่อยแอปพลิเคชันไปยังร้านค้า Google Play Store มีตัวเลือกในการตั้งค่ากลุ่มทดสอบอัลฟ่าและเบต้าซึ่งแอพเฉพาะพร้อมใช้งานสำหรับสมาชิกกลุ่มเท่านั้น
ในการวิเคราะห์แอพพลิเคชั่นมือถือที่ทันสมัยและการรวบรวมข้อมูลแสดงถึงฟังก์ชั่นที่สำคัญซึ่งต้องการการทดสอบ Futurice พิจารณาว่าสิ่งนี้เป็นส่วนสำคัญของการทดสอบการทำงาน
เนื่องจากกระบวนการอัปเดตแอพมือถือนั้นแตกต่างจากเว็บแอปหนึ่งการตั้งค่าการวิเคราะห์จำเป็นต้องได้รับจากการลองครั้งแรกหรือไม่ได้รับข้อมูลที่มีค่า กระบวนการอัปเดตเสร็จสิ้นผ่านขั้นตอนการจัดเก็บแอปพลิเคชัน แต่การอัปเดตจะเสร็จสิ้นหรือไม่ขึ้นอยู่กับการตั้งค่าและกิจกรรมของผู้ใช้ ดังนั้นหากเวอร์ชันแรกพลาดฟังก์ชั่นการวิเคราะห์ที่สำคัญบางอย่างและผู้ใช้บางคนไม่เคยอัปเดตแอปพลิเคชันข้อมูลนั้นจะพลาด โซลูชันอาจถูกบังคับให้อัปเกรดซึ่งแอปไม่สามารถใช้งานได้จนกว่าผู้ใช้จะอัปเดตเวอร์ชันใหม่ล่าสุดที่มีอยู่ แต่อาจสายเกินไป
